03 | 异构系统跨语言服务化

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。

一、RPC

remote procedure call = RPC :远程服务调用，主要解决远程服务通信的问题。

RPC 协议通常包括：stub、通信协议、RPC消息解析这几部分。
一般的RPC框架除了包含点对点的通信外，还包含服务发现¹和治理等相关功能。

Motan实现了：服务发布、订阅机制，失败重试、快速失败、异常隔离等高可用策略；低并发度优先，一致性Hash，随机请求，轮询等负载均衡策略；SPI²展机制，调用统计，流量控制等。

结合微博自研的Vintage注册中心(类似开源的zookeeper、etcd)
服务端时启动会向注册中心按照服务和分组注册自己的的服务（当然还包括版本号协议等信息），并不断向注册中心汇报自己的健康状态，保证注册中心有最新的集群状态信息。

客户端启动时根据服务名和分组订阅自己所需要的服务，同时将服务发现现成实时发现回来的最新可用节点组成Cluster，并使用所配置的负载均衡策略获取最终访问的服务节点信息，然后对服务端发起请求。 当服务端状态发生变化时，注册中心可以实时感知到变化，并通知客户端更新相关服务信息。

Motan在服务治理方面通过对服务分组，解决了服务环境隔离，微服务切分，就近访问等问题，引入Cluster对服务发现的结果进行抽象，屏蔽了底层对节点的操作，并使用配置化可插拔的负载均衡及高可用策略，完成了对服务端的均衡、高可用调用。 注册中心实时维持整个集群的最新状态，提供了自动化的可用性保障，基于注册中心实现的流量控制与指令系统对集群状态的干预提供了支持，也为后来的mesh 的动态流量调度建立了可编程的基础。

扩展性方面，java版本的Motan基于java的SPI机制对相关功能做了良好的解耦和模块化拆分，支持对过滤器，高可用策略，负载均衡策略，序列化，传输协议，注册中心，通信机制等进行扩展和二次开发。

二、Motan跨语言

service mesh 刻画的是一个语言中立的通信和控制层，介于应用层和传输层之间。

跨语言包括2个方面：通信协议和序列化协议

• 通信协议(比如gRPC、thrift)：解决的是服务调用的问题，以哪种协议封包传输，关注协议的结构和传输、解包速率。
• 序列化协议关注协议是否为一种语言无关的协议(比如gRPC中使用的PB序列化协议)，或者如果是跨语言协议的话， 是否对跨语言足够友好，支持足够多的语言数据类型，更多的语言原生的数据结构。

Hessian序列化协议对java对象结构支持更好，Simple序列化协议语言更为中立。

跨语言RPC的另一个核心在于跨语言治理，通过RESTful接口进行服务调用时，服务发现和治理都通过部署在集群前段的四层、七层来保障。
这样到达集群的请求不知道自己该有哪个节点来处理，相当于去医院看病挂号，不知道找哪个医生，把单子交给分诊台，分诊台的护士帮你分配医生。

上面说的方式属于server端的服务治理范畴，而基于RPC的系统则不然，client依赖哪些服务都是事先是明确的，启动时已经订阅了这些服务，在运行过程中会有服务发现进程(线程)实时从注册中心将所依赖服务的最新集群信息同步过来。

就像出门旅游时路线和机票等都准备好了，直接发起点对点的请求，是client端的服务治理范畴。

每种语言都实现一套业务无关的服务治理逻辑，浪费资源。
所以把业务无关而所有业务又都需要的通用逻辑单独提出来的根本原因。

service mesh将这部分的逻辑独立出来，以基础设施的角色提供出来，对业务透明化。

---

1. 服务发现分为客户端和服务端两种。 参考文档：https://blog.csdn.net/mr_seaturtle_/article/details/77618403#%E6%9C%8D%E5%8A%A1%E5%8F%91%E7%8E%B0%E7%9A%84%E6%A8%A1%E5%BC%8F ↩︎

2. Service Provider Interface 服务发现的一种机制。 ↩︎