提纲：

• 微博服务化挑战

• 服务化新思路

• WeiboMesh方案介绍

• 生产实践

• 总结

Service Mesh是近两年比较火的微服务化新方式，也产生了一大批以Istio为代表的Service Mesh实现。微博基于实际业务需求，打造并开源了自己的Weibo Mesh，并且内部已经在重点业务上进行大规模落地。今天我将为大家详细解读Weibo Mesh，希望可以为大家带来服务化方向上的一些灵感，更好的服务于自己的业务。

首先，我为大家介绍下微博服务化面临的挑战。

01微博服务化挑战

微博的形态比较特殊，除去常态午/晚高峰流量较高外，突发热点事件的杀伤力更大。热点事件来袭时，流量极短时间内呈现爆炸式增长，并且往往事件爆发没有任何征兆。这对于微博服务化及稳定性均带来了极大挑战。如果其中某一个环节掉链子，不能及时感知并作出应对，极有可能会导致雪崩式宕机，导致全站挂掉。

那么怎么解决这种问题呢？首先会想到自动扩缩容/降级建设，但是我们决策依赖是什么呢？又如何满足系统可观测性要求，以及如何评价系统可用性及冗余度呢？究其本质，系统的服务治理建设非常重要，它会直接影响到服务可用性。但是微博技术栈的多样性又导致了在微服务化和服务治理方面困难重重。

从技术层面看，微博的典型服务调用大致如上图，业务体系会调用平台体系的多个接口，例如通过平台接口获取微博内容。平台体系主要是Java技术栈，本来微服务相关解决方案也多，再加上服务化时间较早，平台微服务体系建设相对比较完善，同时也产出了一些优秀开源框架，比如Motan微服务框架。

业务方的语言栈：多样化，基本涵盖了所有主流语言，其中PHP相关系统流量占比较大。

调用链路：通常情况下业务方和平台使用RestFul API进行交互。一次请求调用要经过4，7层的层层调度，服务稳定性还时常遭受网络抖动及dns不稳定的困扰，在中间层的消耗是不容忽视的。另外，业务部门的语言种类繁多，间接导致了各部门微服务体系建设参差不齐。峰值流量应对需要所有部门所有业务模块的通力协助和联动，考验是整站的实力，我们需要所有模块都能具备高水平的服务治理能力。因此我们迫切需要解决跨语言微服务化问题。

上图是微博平台内部的微服务体系支撑图，平台实现以Motan框架为核心的微服务治理体系 ，此外，还有自研的Vintage注册中心及OpenDCP智能弹性调度平台以及Graphite实时监控平台，可以看出平台微服务架构有完善的DevOps支撑。此外，业界的大趋势是云原生，微服务作为云原生重要的一环，是我们必须要突破的。

02微博服务化新思路

为了解决跨语言服务治理的问题，我简单介绍一下我们尝试过哪些解决方案。

这里有个大背景，Motan由于是微博内部使用已久，经历过重大考验并且开源的优秀框架，它积累了很多优秀的服务治理经验，所以我们服务化改造要充分考虑Motan的存在。

我们尝试将Motan适配Yar这种PHP的RPC协议，PHP可以与Server端的Java进行通讯，但PHP并不能进行服务发现，于是我们在PHP旁边加一个Daemon程序，也考虑过使用Nginx，来做服务发现。当然问题也是显而易见的，这样改造会导致业务侵入变高，成本变大，扩展性也较差，何况并没有解决PHP做Server端的服务治理问题。

我们也尝试过GRPC，当然跨语言调用能解决，但是这里遇到几个问题，一个是如何进行服务治理，另外一个是PB序列化问题。由于微博场景的内容结构体非常大，效率并不比json高，业务变更导致PB文件的变更让升级维护成本变得难以接受，另外序列化数据遇到问题调试也变的困难。

此外 ，技术栈的多样性也会引发一系列的问题。即使我们解决了PHP到Java的调用问题，但是相同的治理功能，不同的语言不可能再实现一遍，Motan框架积累下来的服务治理经验是我们需要传承和发扬的，那如何均衡这些问题及解决方案呢？

我认为跨语言服务化的本质，总结下来有两点：一是数据交互，二是服务治理。数据交互设计要考虑跨语言及协议中立，服务治理设计要灵活全面且可扩展。

上图我列举了跨语言服务化方式的优缺点。

• 传统的Http代理，可以解决不同服务之间的调用。Http就是传统的走网关，较容易实现，但因为内部的调用每个人都要加网关，这就增加了链路，导致扩展能力低。

• RPC模块或者Agent代理。RPC框架业界有很多，大多Java栈的，功能也齐全，但跨语言维护成本非常之高；Agent代理是一个新的思路，Agent代理的研发成本、维护成本、使用成本对比起来均比较折中，即我们独立一个Agent来专门解决我们遇到的跨语言服务化困扰，那样既能释放传统的业务端的服务治理压力，又能传承Motan框架的精髓，也不需要实现多语言服务治理逻辑，更可以让业务和Agent互相独立发展，可谓一举多得。这个思路最终也演化成了今天的WeiboMesh。

由此微博走向了Service Mesh。微博走向Service Mesh，并不是盲目追赶最新的技术潮流。我们立足于现状，立足于解决实际业务问题，并一步步探索过后，发现最终的解决方案与Service Mesh思路不谋而合。从侧面也验证了Service Mesh思路解决服务化问题的合理性和前瞻性。

上图，我们可以用正交分解法来理解Service Mesh，可以看到，原有的微服务被拆分成业务逻辑层和服务交互治理层，其中服务交互治理层抽象为Service Mesh。

Service Mesh把服务间的交互与治理逻辑从业务中进行解耦，抽象独立成一个专门的处理模块，通常Mesh Agent以Sidecar的形式和业务进行本机部署，Agent（以下Mesh Agent简称Mesh或Agent）可以理解为服务的基础设施层，业务无需关心服务间交互/治理细节，全部交由Agent统一处理。Service Mesh带来的是微服务架构思路的转变，为业务开发带来了诸多架构上的优势，Agent及业务均可独立发展，通常Agent交由运维管理，业务开发交由业务线，固整体可以做到持续开发、持续集成。Mesh思路不光可以解决跨语言服务化的问题，也可以解决资源服务化问题，而这些改造基本都对业务方透明。

下面具体介绍下WeiboMesh的实现方案。

03WeiboMesh方案介绍

上图是Weibo Mesh架构图。除了必须的Mesh Agent外，考虑到业务迁移及实际落地需要，这里在业务代码和Mesh之间增加了Client。

这个Client非常轻，其核心功能是封装Mesh请求，方便业务进行Mesh调用，最大限度降低业务迁移成本。实际上在Client中我们也实现了其他一些对业务友好的功能，同时对Mesh调用进行了功能增强。比如可以在Client中进行跨语言的序列化，Mesh故障转移，请求多发，超时控制等。当然不同业务方可以进行功能定制。Client和业务相同的语言编写，其核心目的是帮助业务进行平滑迁移。

Mesh层实现了Service Mesh的核心功能，包括发现、交互、路由、治理。WeiboMesh是由Go实现的，国内各大厂商的Mesh数据平面也大多使用Go来实现，Go具有优秀的性能及易用性，又是云时代比较推崇的语言，未来Mesh层极有可能结合容器，沉淀成为容器的一个基础设施层。

剖析一个Service Mesh服务，一般通过数据面和控制面。首先来看一下Weibo Mesh在数据平面的表现，包含五个核心模块：

1.Cluster（集群管理），对分组下通过服务发现回来的的节点列表的抽象管理。

2.HA（高可用策略）

3.LB（负载均衡）

4.Endpoint（服务节点的抽象），本质上是IP和端口，但从代码层面看，它是服务节点的抽象，通过Endpoint可以进行直接的调用，可以理解为它是调用的一个单元。

5.Protocol（Motan2/传输协议+Simple/序列化协议）。

下面一一介绍这些模块。

Cluster模块

调用方请求通过本机的Mesh，在Cluster模块处理中，首先经过一系列集群粒度的Filter Chain（过滤链，包含集群Metric，熔断，拦截，鉴权，分组切换等功能，它们以链式结构进行组织调用，支持任意过滤功能扩展），然后再经过高可用策略跟负载均衡策略筛选出一个可用的Endpoint，在Endpoint中又会进行请求粒度的Filter Chain（单机的日志记录，metric等），通过进行请求序列化，根据传输协议进行组装，最终通过Endpoint把请求发到对端的Mesh上。

高可用策略

Weibo Mesh中的高可用策略，支持一般的常用策略，比如Failfast，Failover等，负载均衡支持权重轮巡，根据权重轮巡、随机等常用策略。当然也可以定制自己的HA/LB策略。

WeiboMesh中推荐采用的高可用策略是Backup Request，又叫双发。双发继承自Motan框架，是我们探索出来的比较高效可靠的机制。它可以有效解决长尾问题，同时能提升系统吞吐量。传统解决接口超时问题可能通过重试，在一次请求发送之后等待指定的超时时间，如果没有返回则再请求一次，最差情况下要消耗2倍的超时时间。而双发机制则不然，在发送一次请求后等待P90（在T1时间内有90%的请求都能返回则称P90=T1，通常系统的P90和程序设置的超时时间相比小很多）时间，如果请求没有返回则在此刻再次发送一次请求，在超时时间内，这两个请求中取最快返回的那个。当然，这里有个防雪崩机制，假如，超过一定数量的请求（比如15%）都在进行双发，则认为服务整体有问题，会自动停止双发。实践证明，双发机制的去长尾效果非常明显。

节点抽象

Endpoint是调用方Mesh到对端Mesh的调用单元。当我们启动WeiboMesh，在初始化Cluster的同时，也会对Endpoint进行初始化，绑定Filter Chain，并为每个Endpoint保持一定数量的长链接供选择调用。当然这里还会有一些细节，如果某个节点的调用失败计数超过一定阈值则自动摘除节点，并进行定期探测等待可用，再重新加入可用节点列表。

Motan2 传输协议

WeiboMesh整体沿用了Motan的协议设计，并进行了升级。Motan支持Java的序列化，当时考虑的是java间相互通信，但是考虑到跨语言通信及未来扩展需要，我们把协议设计分成序列化协议与传输协议。传输协议负责把序列化后的数据进行传输，序列化协议是跨语言的关键。

Motan传输协议是典型的三段式：Header、Metadata和Body。Header中会标记序列化类型，消息类型（心跳还是正常请求），可以定义自己的PB序列化或是自研的Simple序列化。在Metadata中会有一些方法名、属性名、用户参数；在Body中存放的是经过序列化后的请求/响应体。

Simple序列化

Simple设计比较简单实用。目前Simple序列化支持了基础类型，包括Bool、String、Int、Float，当然它还会支持一些组合类型，例如，String、Bool组合成的Map，Array等。

上图示例，type是一个字节的数据类型，比如Bool、String，接下来是字节长度，接下来是UTF-8字节流。Content中可以进行嵌套，下方就是进行嵌套的例子。

协议转换过程

从协议层面看Weibo Mesh请求流转是调用方通过函数调用Client，然后经过Motan2传输协议以及Simple序列化后，经过本机Mesh，Mesh层再转发给对端的Mesh。对端Mesh上层可能是任意一种形式的服务，比如非RPC服务，所以这里我们有个Provider模块，可以代理http/cgi等非标准Service Mesh服务，它能把这些服务导出成一个具有Motan协议的RPC服务。通过Provider屏蔽了Server端服务的真实协议。Provider外面是标准的Motan协议服务，内部是原有协议的服务，这样对Server端来说，迁移到WeiboMesh成本极低。

控制面主要分两方面：

1.策略扩展

Cluster和Endpoint都有相应的Filter Chain，他们实现了不同纬度或者粒度的调用控制策略。Filter Chain包括访问日志记录、Metric、熔断、限流、降级等。折中调用效率和耦合程度，它们都是以插件形式存在于Weibo Mesh中，也可以自由定制Filter策略及调用顺序。

2.流量调度

WeiboMesh的流量调度基于注册中心。注册中心不仅为Mesh提供了服务的注册和发现，也提供了服务的配置下发，Mesh在订阅注册中心的同时，也需要订阅相关的配置项。比如我们把A机房的流量都路由到B机房去，我们在Mesh只要支持这条指令就可以。

04生产实践

上图是网关，mesh在微服务架构中的整体分布图。一般情况下网关架设在服务边缘，边缘节点主要把控宏观的流量调度控制问题。

在内部，各微服务之间构建WeiboMesh，来有效提高服务间通信质量、可观测性等要求。

• 真正将Service Mesh引入到业务场景中时，需要考虑一些问题点，比如业务部署模式是非云，混合云还是云原生？像微博是混合云，场景不同，因此架构也不尽相同。

• Weibo Mesh要适配注册中心

• 各语言要适配Client，目前已经支持php/c++/c/python/lua等主流语言，Java/go原生支持。

• 要适配相应的DevOps建设。需要相应的监控/统计等平台支撑，任何架构改造都要有足够的DevOps支撑。

接下来我将为大家介绍WeiboMesh正反向代理实践。

上图是Weibo Mesh场景下的正向代理流程。Server端服务进行注册，被调用方订阅到，调用方请求经过Client，再经过本机Mesh，最终到对端的Mesh。需要注意的是虚线部分是故障转移的流程。假如本机Mesh agent挂掉，Client会通过服务发现回来的节点快照选择可用节点进行调用，达到故障转移的目的。

上图是Weibo Mesh场景下的反向代理流程。一般我们的服务类型是HTTP/CGI，或者其它私有协议。

反向Mesh的亮点在于，不需要Server端做任何架构的改造，直接架WeiboMesh就可以了，Mesh Agent通过Provider，将原有协议导出成Motan2协议的服务对外进行暴露，只需要把导出的服务注册到注册中心即可提供服务。同时也不会影响原有服务的提供。这里如果你需要把私有协议导出成Motan2协议服务，可以自行扩展开发。默认支持 http/php-cgi服务的导出。

• 提供HTTP/cgi provider，可定制扩展

• HTTP框架自动转RPC，业务无需开发新RPC框架

• Mesh对Server改造无侵入

05总结

传统服务调用，中间可能经过网关或者RPC。服务治理只能存在于一端，一般在Server端进行服务治理。但是Mesh服务，由于Agent本机部署，封装了服务治理，可以实现Client端或Server端的双向治理，这是Mesh服务的一大特色。

上图可以看到，Mesh服务的Client端RT曲线逼近Server端的RT，这说明点对点的Mesh调用，由于没有中间层的损耗，再加上合适服务治理手段，两端性能也比较接近。而HTTP服务则有较多的中间层损耗。右图可以看到双发的p999曲线相对比较直，这说明双发起到有效削长尾功能，间接也对系统性能有提升。

目前，微博内几个核心业务之间调用已经Mesh化，并经历过重大事件以及春晚的考验，支撑流量还是相当大的。

从控制层面看，Weibo Mesh把类似Istio中的Mixer和CA的功能以插件化的形式放到Filters里面，Istio服务需要通过Pilot来做服务发现，而WeiboMesh是直接通过注册中心，Istio用Envoy做Sidecar，而我们基于Motan打造了全新的Agent。Istio有一个特色，上面每个模块都可以理解为一个微服务，都可独立拆分署。但是Weibo Mesh为了效率和内部落地的方便，更多的进行了插件式耦合，整体性能相比Istio也会更好。

上图可以看到Istio通过云平台适配各种API，来进行服务发现，WeiboMesh则是适配注册中心。Istio更强调依据容器层面的发现（直奔云原生），Weibo Mesh则可支持通用注册中心比如Consul、ZK等。

WeiboMesh通过Client拦截Mesh请求，模块化耦合部分功能。高定制化时，并不能对服务做到完全透明。而Istio通过IPtables流量拦截实现了业务完全无感知。

我们知道Mesh Agent并不关心代理转发的是什么服务，所以就有一个新方向，即资源服务化，让资源存储层也能进行服务化。WeiboMesh解决跨语言服务化的思路也同样适用于服务与资源之间的调用问题。微博服务有很多资源依赖，MC、Redis、MySQL、MCQ等。我们可以在资源层架设Agent，同样可以达到资源即服务，也就是泛服务化。目前我们内部也已经有基于WeiboMesh的资源服务化使用场景。

未来WeiboMesh主要有两个方向，一个是继续推进云原生，一个是在易用性方面继续打磨。WeiboMesh打通云平台和注册中心推进云原生，结合容器编排在服务治理上进行优势互补。此外，我们也会积极努力推进，让Mesh整合进L5这一层。我们还会继续进行探索解决业务方接入不方便的地方，比如说更加方便的流量拦截方式；更广泛的语言支持…

WeiboMesh始终推崇落地简单功能高效可靠，随着Mesh更大规模的推广，场景越来越极端，性能要求越来越高，我们在这方面也会持续打磨。欢迎大家一起加入WeiboMesh！

以上内容来自丁振凯老师的分享。点击“此处”，按照指定步骤操作，即可免费学习丁振凯老师的演讲视频哦！