这是我参与「第五届青训营 」伴学笔记创作活动的第 14 天
服务框架
服务框架的核心是服务调用，分布式服务架构中的服务分布在不同主机的不同进程上，服务的调用跟单体应用进程内方法调用的本质区别就是需要借助网络来进行通信。 主流的服务框架的实现都是这套架构，如 Dubbo、SpringCloud 等。
- Invoker 是服务的调用方
- Provider 是服务的提供方
- Registry 是服务的注册中心
- Monitor 是服务的监控模块
Invoker 和 Provider 分别作为服务的调用和被调用方，这点很明确。
但是仅有这两者还是不够的，因为作为调用方需要知道服务部署在哪，去哪调用服务，所以有了 Registry 模块，它的功能是给服务提供方注册服务，给服务调用方发现服务。
Monitor 作为服务的监控模块，负责服务的调用统计以及链路分析功能，也是服务治理重要的一环。
核心模块
服务注册是服务提供方向注册中心注册服务信息；当提供服务应用下线时，负责将服务注册信息从注册中心删去。
服务发现是服务调用方从注册中心订阅服务，获取服务提供方的相关信息；当服务注册信息有变更时，注册中心负责通知到服务调用方。
服务调用是服务调用方通过从注册中心拿到服务提供方的信息，向服务提供方发起服务调用，获取调用结果。
对照上述流程图，我们按照请求的具体过程进行分析。
作为服务调用方 Invoker 的具体流程是：
- Request 从下往上，由于服务调用方只能拿到服务提供方提供的 API 接口或者 API 接口的 JAR 包，所以服务调用方需要经过一层代理 Proxy 来伪装服务的实现；
- 经过代理 Proxy 之后，会经过路由 Router、负载均衡 LoadBalance 模块，目的是从一堆从注册中心拿到的服务提供方信息中选出最合适的服务提供方机器进行调用。另外，还会经过 Monitor 监控等模块；
- 接着会经过服务编码 Codec 模块，这个模块的目的是因为请求在网络传输前需要按照通信协议以及对象的序列化方式，对传输的请求进行编解码；
- 最终会经过网络通信 Transporter 模块，这个模块将 Codec 编码好的请求进行传输。
作为服务提供方 Provider 的具体流程是：
- Request 从上往下，经过网络通信 Transporter 模块，获取到的是由调用方发送的Request字节数组。
- 接着经过服务编码 Codec 模块，根据通信协议解出一个完整的请求包，然后使用具体的序列化方式反序列化成请求对象。
- 紧接着会经过监控、限流、鉴权等模块。
- 最终会执行服务的真正业务实现 ServiceImpl，执行完后，结果按原路返回。
按照上述流程分解一个服务框架的相关工作，再去看一些开源的服务框架也就不难理解了。
一般服务框架的核心模块应该有注册中心、网络通信、服务编码（通信协议、序列化）、服务路由、负载均衡，服务鉴权，可用性保障（服务降级、服务限流、服务隔离）、服务监控（Metrics、Trace）、配置中心、服务治理平台等。
