分布式环境下，RPC框架自身以及服务提供方的业务逻辑实现，都应该对异常进行合理地封装，让使用方可以根据异常快速地定位问题；而在依赖关系复杂且涉及多个部门合作的分布式系统中，我们也可以借助分布式链路跟踪系统，快速定位问题。1 Future超时处理案例以调用端请求超时处理为例，RPC框架如何处理超时请求。无论同步、异步调用，调用端内部都是异步，调用端在向服务端发消息前会创建一个Future，存储消息标
深入RPC，更好使用RPC，须从RPC框架整体性能考虑问题。得知道如何提升RPC框架的性能、稳定性、安全性、吞吐量及如何在分布式下快速定位问题。RPC框架如何压榨单机吞吐量？1 前言TPS一直上不去，压测时CPU压到40%～50%就再也压不上去，TPS也不提高，咋办？看业务逻辑，在执行较为耗时的业务逻辑基础上，又同步调用了好几个其它服务。由于这几个服务的耗时较长，导致服务业务逻辑耗时也长，CPU大
应对突发流量，限流是好手段，但还有其它手段，可最大限度保障业务无损。1 为何分组若在接口上再加一个分组维度去管理，不就让接口复杂了？实则不然，比如无汽车年代，道路很简单，就一条，行人、洋车都在上边走。那随着汽车普及，道路越来越宽，有高速、辅路、人行道。交通网的建设与完善不仅提高出行效率，还更好保障行人安全。RPC治理也一样。假设你是一个服务提供方应用的负责人，早期业务量不大，应用之间的调用关系简单
RPC面临高并发场景，提供服务的每个节点就都可能由于访问量过大而异常，如业务处理耗时过长、CPU飘高、频繁Full GC以及服务进程直接宕机。要保证服务稳定性和高可用性，就要业务自我保护。使用RPC时，业务如何自我保护？最常见的限流。RPC调用包括服务端和调用端，调用端向服务端发起调用。服务端与调用端分别是如何进行自我保护的。1 服务端自保要发布一个RPC服务，作为服务端接收调用端发过来的请求，这
0 前言应用启动居然也这么“讲究”？好比我们日常生活中的热车，行驶之前让发动机空跑一会，可以让汽车的各个部件都“热”起来，减小磨损。运行了一段时间后的应用，执行速度会比刚启动的应用更快。因为Java里，运行过程中，JVM把高频代码编译成机器码，被加载过的类会被缓存到JVM缓存，再使用时不会触发临时加载，使“热点”代码执行不用每次都通过解释，提升了执行速度。但这些“临时数据”都在重启后消失了。重启后
1 主动原则：主动做事工作要积极主动，刚进入职场的同学，以为“服从命令听指挥”“领导指哪打哪”就是积极主动，结果易养1.1 不好习惯① 认为主管肯定会帮你搞定晋升你可能非常信任主管，认为自己只要把主管安排的任务做好，晋升就是水到渠成的事情。所以你就算觉得现在分配的任务对自己的成长帮助不大，也不会主动跟主管沟通，而是认为“他这么安排肯定是有道理的”“也许过一段时间他就会给我安排新的任务”。这其实是不
1 连接模型的传输协议依赖 TCP 提供从客户端到服务器端间的连接。早期 使用一个简单模型处理这样的连接。这些连接的生命周期是短暂的：每发起一个请求时都会创建一个新连接，收到应答时立即关闭。这简单模型对性能有先天限制：打开每个 TCP 连接都相当耗费资源。客户端、服务器端间需交换好多消息。当请求发起时，网络延迟和带宽都会对性能影响。现代浏览器往往要发起很多次请求(十几个或更多)才
职级体系就是游戏的段位规则。定义：整体的段位等级分布（比如从倔强青铜到荣耀王者）每个段位的要求（比如钻石段位以后要学会怎么重新匹配一局游戏）晋级的规则（比如每个段位几颗星可以晋升下一个段位）如果你所在的公司已经有明确的职级体系，那么深刻理解职级体系的特点，有利于你设定合理的晋升目标和规划。这样你就能避免因为急于求成而心浮气躁，或者因为埋头苦干而错失晋级的机会。跳槽心仪公司，全面了解对方职级体系，有
1 简介SPI，Service Provider Interface，一种服务发现机制：有了SPI，即可实现服务接口与服务实现的解耦：服务提供者（如 springboot starter）提供出 SPI 接口。身为服务提供者，在你无法形成绝对规范强制时，适度"放权" 比较明智，适当让客户端去自定义实现客户端（普通的 springboot 项目）即可通过本地注册的形式，将实现类注册到服务端，轻松实现
1 异常重试的意义发起一次RPC调用，调用远程的一个服务，如用户的登录操作，先对用户的用户名以及密码进行验证，验证成功后，获取用户基本信息。通过远程的用户服务获取用户基本信息时，恰好网络故障，如突然抖了一下，导致请求失败，而这请求我们希望它能够尽可能执行成功，咋办？需重新发起一次RPC调用，代码中如何处理？catch一下，失败就再发起一次调用？这显然不优雅。考虑RPC框架的重试机制。2 RPC框架
1 需求流量高峰，突现线上服务可用率降低，排查发现，因为其中有几台机器较旧。当时最早申请的一批容器配置较低，缩容时留下了几台，当流量达到高峰时，这几台容器由于负载太高，扛不住压力。业务部门问题：当时给出方案：在治理平台调低这几台机器权重，访问流量就减少了。但业务说：当他们发现服务可用率降低时，业务请求已受影响，再如此解决，需要时间，那这段时间里业务可能已有损失。紧接提出需求：RPC框架有智能负载机
知道了什么样的人更易晋升，明确了方向。但努力提升后，能力到底有没有达到晋升要求？也许你自信满满，但评审人不一定认可若TL不认可，你连被提名机会都没若部门内的管理者不认可，预审时就会被刷掉若评委团不认可，你在评审阶段还是 fail什么样的能力水平经得起不同评审者和不同视角考核，能几乎无争议晋升？本文先看认清判断能力最本质的底层逻辑。1 似乎客观的做法判断能力的一些常见做法。评审阶段正式判断你的能力是
1 场景 服务A调用服务B，先插再删。俩请求过去了，落在不同机器节点，可能插入请求因某些原因执行慢些，导致删除请求先执行了，此时因DB没数据，所以啥影响也没；结果这时插入请求过来了，数据就插进去了。业务意图本应先插再删，这条数据最终应该没了，结果现在先删再插，最后数据还在。建议从业务设计时，不需要这种顺序性的保证，一旦引入顺序性保障，会导致系统复杂度上升，而且会带来效率低下，热点数据压力过大等问题
网页爬虫，解析已爬取页面中的网页链接，再爬取这些链接对应网页。而同一网页链接有可能被包含在多个页面中，这就会导致爬虫在爬取的过程中，重复爬取相同的网页。1如何避免重复爬取？记录已爬取的网页链接（也就是URL），在爬取一个新的网页之前，我们拿它的链接，在已经爬取的网页链接列表中搜索：存在，这网页已被爬过不存在，还没被爬过，可继续去爬等爬取到这网页后，将这网页的链接添加到已爬取的网页链接列表。如何记录
1 分布式问题定位障碍生产环境，代码在线上运行业务，不能debug，可查看当前异常日志。案例分布式的应用系统，启动4个子服务：服务A、B、C、D，服务依赖关系A->B->C->D，部署在不同机器。RPC调用中，若服务端业务逻辑异常，就会把异常抛给调用端，若现在这调用链中有个服务异常，如何定位问题？第一反应打印日志，那就打日志。假如这时发现A异常，这异常其实可能因B或C或D异常抛回
RPC里面该如何提升单机资源的利用率，你要记住的关键点就一个，那就是“异步化”。调用方利用异步化机制实现并行调用多个服务，以缩短整个调用时间；而服务提供方则可以利用异步化把业务逻辑放到自定义线程池里面去执行，以提升单机的OPS。1 为何要考虑安全问题？RPC是解决应用间互相通信的框架，而应用之间的远程调用过程一般不会暴露在公网，RPC一般用于内部应用通信。“内部”指应用都部署在同一大局域网。相对公
1 关闭为什么有问题？系统为啥非要拆分？更方便、更快速迭代业务，但也得经常更新应用系统，时不时还老要重启服务器。重启服务过程中，RPC怎么做到让调用方系统不出问题？2 上线流程当服务提供方要上线，一般通过部署系统完成实例重启。此间，服务提供方的团队并不会事先告诉调用方他们需要操作哪些机器，从而让调用方去事先切走流量。对调用方来说，它也无法预测服务提供方要对哪个机器重启，因此负载均衡就可能把要正重启
1 为什么选择路由策略？真实环境的服务提供方以集群提供服务，对服务调用方，就是一个接口会有多个服务提供方同时提供服务，所以RPC每次发起请求时，要从多个服务提供方节点里选择一个用于发请求的节点。这次请求无论发送到集合中的哪个节点上，返回结果都一样。每次上线应用的时候都不止一台服务器会运行实例，上线涉及变更，只要变更就可能导致原本正常运行的程序异常。为减少这种风险，一般选择灰度发布应用实例，如先发布
服务发现的作用：实时感知集群IP的变化，实现接口跟服务集群节点IP的映射。超大规模集群更要考虑最终一致性。“推拉结合，以拉为准”。1 健康检测因为有了集群，所以每次发请求前，RPC框架会根据路由和负载均衡算法选一个具体的IP地址。为保证请求成功，就要确保每次选出来的IP对应连接是健康的。但调用方跟服务集群节点之间的网络状况瞬息万变，两者之间可能会闪断或网络设备损坏等，怎么保证选出来的连接一定可用？
1 gRPCGoogle 开发并且开源的一款高性能、跨语言的 RPC 框架，当前支持 C、Java 和 Go。跨语言，通信协议基于HTTP/2，序列化支持 PB（Protocol Buffer）和 JSON。调用示例：定义一个 say 方法，调用方通过 gRPC 调用服务提供方，然后服务提供方会返回一个字符串给调用方。为了保证调用方和服务提供方能够正常通信，我们需要先约定一个通信过程中的契约，即
实现过统一拦截吗？如授权认证、性能统计，可以用 Spring AOP，不需要改动原有代码前提下，还能实现非业务逻辑跟业务逻辑的解耦。核心就是动态代理，通过对字节码进行增强，在方法调用时进行拦截，以便于在方法调用前后，增加处理逻辑。1 远程调用的魔法使用 RPC，一般先找服务提供方要接口，通过 Maven 或其他工具把接口依赖到我们项目。编写业务逻辑时，若要调用提供方的接口，只需通过依赖注入把接口注
HTTP协议（本文HTTP默认1.X）跟RPC协议又有什么关系呢？都属于应用层协议。1 HTTP协议浏览器收到命令后会封装一个请求，并把请求发送到DNS解析出来的IP上，抓包：2 协议的作用没有协议就不能通信吗？只有二进制才能在网络中传输，所以RPC请求在发送到网络中之前，他需要把方法调用的请求参数转成二进制；转成二进制后，写入本地Socket，然后被网卡发送到网络设备。传输过程中，RPC不会把请
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
