微服务：微博Mesh服务化改造如何支撑？

大家好，我今天的分享主要围绕以下几点，首先跟大家简要介绍一下微博服务化的演进过程，其次是微博自研跨语言RPC 框架 Motan 实现的一些关键技术要点，主要是跨语言方面，再次，结合目前市面上的一些Service Mesh 实现对比，给出基于 Motan-Go 的更符合微博场景的Weibo Mesh 实现。

最后，是我个人对于面向未来泛服务化架构的一些思考。一些同学对Service Mesh比较感兴趣，也想再生产上做一些实践，如果没有历史包袱，新开发一个项目用什么架构，怎么实现都是可以的。由架构去取舍，看我们更迫切需要的是什么，所追求的是性能还是其它高扩展性等等，目前也有一些现成的解决方案。但是如果没有做任何服务化，或者服务化过程中历史包袱比较重，可能很难找到一种可以直接实施的现成方案，因为需要考虑的往往会更多。本次分享更多是关于操作性内容，希望对大家有一定的借鉴意义。

微博平台服务化演进

我们先看微博平台服务化的演进过程。

 

微博2009年上线，在业务高速发展的初期是传统的模块化单体服务，每个小的业务都有可能随时爆发成长为一个核心业务。我们的目标很简单，就是满足业务快速发展的需求，并且在突发流量增长时保证服务的高可用。随着业务的扩张，单体架构各个模块严重耦合，致使相互的影响越来越大，请求成功率得不到保障，长尾问题严重。为了解决这一系列问题，微博从 2013 年开发了Java 语言的 Motan RPC 框架，并基于此完成了服务化改造。Motan 从2013年上线至今经历过每次热点事件、三节高峰的严峻考验，稳定性和可靠性都得到了实际场景的验证。这些经历之下微博 Motan 也积累了一套服务治理型 RPC 的服务化体系。

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

 

上图是当时微博平台技术体系的概貌，是一个基于 Open DCP 弹性云计算平台和 Motan RPC 的服务化架构，经过几年的运营和考验，我们已经在混合云的服务化方向有了丰富的经验和积累。但在解决了微博平台内部服务高可用、高性能的问题后，业务方平台服务调用的问题开始显现出来。比如调用链路过长，导致坑多性能差，又比如，每个业务方都需要做高可用和服务治理，而这些事情平台已经有丰富的积累，大家都再做一遍特别重复且浪费。当想把在平台上的技术积累服务到微博更多的业务方时，平台内部基于 Java 的服务化体系已经不能完成任务，所以我们需要一个跨语言的解决方案。从2016年起，我们开始了跨语言服务化改造之路。

跨语言RPC要点

异构系统如何做整体服务化的解决方案，也是今天探讨的一个主题。

服务化经历了前面几个阶段后，需要构建一个跨语言的服务化体系，将原来在 Java 体系积累的经验加以总结，给其它的技术栈业务赋能，更好的维护微博整体的稳定和高可用。

 

上图我简单列举跨语言 RPC 的几个技术要点，最下面是可靠性和易用性，比如我们的 Motan 有 Cluster 的概念，每次调用都是从这个 Cluster 里面通过负载均衡（LB）策略来找出可用的节点（Endpoint），再通过一种高可用的策略（HA）完成调用。整个过程的各种理念可复用，各种语言照章实现就好。各种策略也是可以按需根据实际情况进行扩展的。而传输、I/O、进程线程模型等各个语言都不一样，需要根据语言自身的特性来选择。

协议和系列化，这是解决跨语言比较重要的一点，因为要让各种语言互相理解对方，互相沟通。

 

上图的故事大家可能都有所耳闻，人类很狂妄地说，我要建一个塔直通到天堂。但是上帝听到以后觉得很不爽，所以让人类说不同的语言。因为语言不通，导致塔建歪了，整个工程就失败了，这是说交流的重要性。要做跨语言服务化，负责数据通信的RPC 框架跨语言是重中之重的基础设施。而协议和序列化如何取舍，很关键。

 

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