Weibo Mesh的发展

初代Motan

微博从2013年开发了Java语言的Motan RPC框架，基于此完成了服务化改造。Motan从2013年上线至今经历过每一个热点事件，三节高峰的挑战，稳定性和可靠性都获得了实际场景的验证。这些经历之下微博Motan也积累了一套服务治理型RPC的服务化体系。

除了Motan，2015年开始，为了应对愈来愈猛的流量洪峰，更合理的对资源进行整合利用，开发了Open DCP弹性计算平台。实现了动态的弹性扩缩容，告别了以往花费动辄几千万的资源成本，及节前几个月开始的劳民伤财为三节作准备的日子，也不须要为一个个热点事件提心吊胆。

上面是微博平台技术体系概貌，是一个基于Open DCP弹性云计算平台和Motan RPC的服务化架构，通过几年的运营和考验，咱们已经在混合云和服务化方向有了丰富的经验和积累。在解决了微博内部服务高可用，高性能的问题后，业务方平台服务调用的问题开始显现出来。好比调用链路过长，致使坑多性能差，好比每一个服务自己须要作高可用和服务治理，这些事情平台已经有了丰富积累，你们在作一遍重复严重且浪费资源。平台但愿将平台技术服务到业务方时，须要一个跨语言的解决方案。从2016年起，咱们开始了跨语言服务化改造之路。

跨语言RPC要点

异构系统之间如何作到服务化的解决方案呢？

将原有Java体系积累的经验加以总结，给其余技术栈业务赋能，更好的维护微博总体的稳定性和高可用。

上面是跨语言RPC的几个技术要点，最下面是可靠性和易用性，好比咱们Motan有Cluster的概念，每次调用都从这个Cluster里面经过负载均衡策略来找出可用节点endpoint，再经过高可用策略完成调用。整个过程各类理念可复用，各类语言按章实现就好。各类策略能够按需根据实际状况进行扩展。而传输，IO，进程线程模型等各类语言不同，须要根据语言特色来选择实现。

协议和序列化是跨语言比较重要的一点，由于要让不一样语言互相理解，互相沟通。

Motan解决的是微博内部Java服务之间的调用，所以Motan1协议时，其实没有考虑到跨语言的问题，用的是对Java友好的Hessian。后期在跨语言方面，Motan1的协议显然对跨语言不友好，Motan2对协议就给了一个足够容易理解的协议，是一个简单的TCP描述。好比，请求一些方法，服务的分组，或者Body，请求发过去，对方收到语言后，怎样让这个语言理解呢？关键一点在于序列化。

如今Motan使用简单序列化方式，只支持几种简单的类型，不过也一直在迭代中。本质上，它仍然是简单协议，会尽可能保证它的简单。只有足够的简单，才能在跨语言上下降成本，开发成本还好，主要是语言沟通起来解析成本，好比，编译型语言有各类明确的强类型，而解释型语言不须要强类型约束，如何让他们很好的沟通，就须要取舍。

Weibo Mesh是基于Motan来作的，须要对Motan有个总体的了解。

Weibo Mesh最开始支持Java，如今支持Golang，Openresty，Php。

基于Motan-Go的Weibo-Mesh

我认同Service Mesh是下一代微服务，系统若是很复杂，服务化到必定程度，因为微服务的粒度和规模慢慢增大，出现依赖复杂度增长带来的流量交错，难以管控及难以治理等一系列问题。为了解决这些就须要一个东西很好的管控这些服务和流量，这就是Mesh。

看一看Mesh Istio怎么玩的，Istio有一个基于Envoy的数据传输层，另外是控制面板，Istio经过这个控制面板完成流量调度，鉴权，服务治理等工做。这是Istio如今的玩法。

Weibo Mesh最开始只是想作跨语言，解决调用链路长的问题。以前的请求须要到注册中心寻找目标服务，经过HA作服务路由，绕了一大圈，链路特别长，咱们但愿跨语言的Motan RPC，Client对Server发起直连，经过点对点的通讯来解决链路过长的问题。

最开始作跨语言想GRPC已经作好了，就想经过Motan支持GRPC协议方式来实现Motan实现跨语言调用。 后来改完以后准备对接Php，发现须要大范围的改代码，并且性能没有宣传的那么好。若是经过GRPC作跨语言，服务治理怎么作呢？

以Php为例，每一次请求过来过程就结束了，没有一个常驻内存可用于存储每次请求状态的地方来实现服务发现，服务治理之类的事情。

咱们尝试在本机的后台进程作服务发现，或者在Nginx上基于OpenResty的timer来实现服务发现，并发送结果写到Php的$_SERVER变量中，让Php能直接使用等，但效果并不理想。

因此总体用GRPC作跨语言的方案并不理想，后来咱们想既然解释型语言的跨语言服务化因为语言自己特性和特殊场景下，不适合直接经过语言自己实现，这样，不如作个代理。这个代理就是Weibo Mesh的雏形，相似于Service Mesh中的SideCar。

好比Java启动一个服务，这种状况下，Java Client访问这个服务是这样的流程：

• Java Client启动时会根据配置去注册中心订阅本身要访问的服务；
• 请求过程当中会有一个线程不断从注册中心发现当前可用的节点列表回来；
• 针对于Php就给它一个Go Agent，服务发现，订阅，治理这些事情就让Motan Go Agent来作，其余都同样。

若是Php要作Server呢？

Php要作Server，咱们使用Motan Go Agent来帮助Php的服务导出，因此Motan Go Agent既要作服务发现，也要负责Php服务的注册，Motan Go Agent更像一个Motan Server。 启动时须要导出Php的服务，并保持注册中心状态的上报更新。同时须要把请求转发给后段Php作处理，他们之间可能基于CGI或是Http协议完成。

这样咱们须要的服务治理方式，高可用等保障，经过逻辑封装实现起来就容易多了。

针对于Java，Golang这种方便实现服务化的语言，用Motan实现，其余的语言经过Motan Go导出服务。

改造后性能符合预期，规模大了以后，节点多了以后，经过扩展注册中心功能来解决。

Istio中经过一些请求的Header数据，经过一些规则基于Iptables的流量转发，而Weibo Mesh不须要转发，由于服务都是经过发现回来的，调用时明确的，不须要转发，同时为了流量更均匀，更好的控制流量，须要一个自动流量调度和弹性扩容。

Weibo Mesh改造收益

将来的架构

在Service Mesh中没有了Client和Server的概念，都是Service。