1 服务发现的意义 为高可用，生产环境中服务提供方都以集群对外提供服务，集群里这些IP随时可能变化，也需要用一本“通信录”及时获取对应服务节点，这获取过程即“服务发现”。 对服务调用方和服务提供方，其契约就是接口，相当于“通信录”中的姓名，服务节点就是提供该契约的一个具体实例。服务IP集合作为“通信录”中的地址，从而可通过接口获取服务IP的集合来完成服务的发现。即PRC框架的服务发现：RPC服务发
1 Dubbo 整体架构设计dubbo-remoting 模块提供多种客户端和服务端通信功能。最底层部分即为 Remoting 层：包括 Exchange、Transport和Serialize 三层。本文主要描述 Exchange 和 Transport 两层。Dubbo直接集成已有的第三方网络库，如Netty、Mina、Grizzly 等 NIO 框架：dubbo-remoting-zooke
分布式环境下，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 分布式问题定位障碍生产环境，代码在线上运行业务，不能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调用，调用远程的一个服务，如用户的登录操作，先对用户的用户名以及密码进行验证，验证成功后，获取用户基本信息。通过远程的用户服务获取用户基本信息时，恰好网络故障，如突然抖了一下，导致请求失败，而这请求我们希望它能够尽可能执行成功，咋办？需重新发起一次RPC调用，代码中如何处理？catch一下，失败就再发起一次调用？这显然不优雅。考虑RPC框架的重试机制。2 RPC框架
1 需求流量高峰，突现线上服务可用率降低，排查发现，因为其中有几台机器较旧。当时最早申请的一批容器配置较低，缩容时留下了几台，当流量达到高峰时，这几台容器由于负载太高，扛不住压力。业务部门问题：当时给出方案：在治理平台调低这几台机器权重，访问流量就减少了。但业务说：当他们发现服务可用率降低时，业务请求已受影响，再如此解决，需要时间，那这段时间里业务可能已有损失。紧接提出需求：RPC框架有智能负载机
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号
