前言

2018年的QCon上海有幸去现场听了一天，在这里记录我听的几个主题的感受和一些想法.先直接讲我听了哪些内容：

1. 面向大规模研发的自动化持续交付
2. The past, present ,and future of Go
3. Dubbo Mesh
4. SOFA Mesh
5. 携程容器云弹性构建之路
6. 阿里统一调度系统Sigma

不多哔哔，我先直接讲大家最关心的阿里下午两场关于Service Mesh的分享.

正文

关于Service Mesh

首先值得一提的是，阿里下午这两场关于Service Mesh的分享可以说是听众爆满，人非常非常多。基本上整个会场都坐满了，然后后面站了一大堆人都在那听。

究其原因，我觉得可能是Service Mesh这个概念对于大多数听众来说ServiceMesh是一个非常新的概念。阿里的这两场Mesh的分享，基本上都是在了解一点Mesh的概念上进行的，所以如果有对ServceMesh / K8S 不大理解的话，可能不一定能理解。

两场Mesh的分享

Dubbo Mesh这场分享更多的专注于为什么要上ServiceMesh这一个问题。

首先李云开篇立论就讲了，你要上Mesh，你首先得是一个微服务架构。你如果整个业务是单体超大应用的话，也没必要继续往下听了。所以以下的所有谈论内容都基于一个最重要的前提，那就是你整个业务的架构是微服务架构。

那么既然是微服务架构，那么对于应用的水平扩展以及在技术团队的管理上就会方便许多，比如不同服务的技术团队可以分居两地，分开管理等好处。但是坏处是在微服务下，集群管理与容器管理的成本就会急剧上升，你不得不花很多力气去做监控，追踪，收集，流量管理等一系列工作。

为了解决这个问题，微服务架构面临的挑战就是： （这里直接用Dubbo Mesh上的总结）

1. 微服务框架自身演进困难，业务与框架代码强耦合，强绑定。 （ 说白了就是你一个应用服务，除了处理你负责业务逻辑以外，你还要接很多业务无关的配置项才能融入集群/容器管理体系。 比如你必须告诉他服务注册中心，给他接Tracing组件之类的。
2. 多语言支持弱，异构服务框架难以共存演进， 在问题1的基础上，我们可以给应用开发特定的基础设施相关SDK给业务服务用。但是很明显对于阿里这种超大集群与超多业务与服务的情况下，他的技术栈语言肯定是非常多样化的。为了将所有服务都接入管理体系中而特地开发一个SDK明显是很不合理的，并且非常打击工程师积极性的。
3. 服务治理整体缺乏全局观，易用性和可控性。 ( 这里我大概能理解他的意思，设想一下对于阿里这种超多、超大集群的角度来说，如果有一个统一的总控平台肯定是巨爽的。从基础设平台建设的角度，如果每个事业群，业务线都在集群/容器管理上各玩各的，自成一套规则，估计要心累到爆了。

也就是说，在微服务架构下，如果我们碰到了上述的问题，就适合去接入Service Mesh。当然，在Mesh这个领域里，活跃的Istio正式发布1.0-stable也只不过是今年的事情，但是微服务化却已经早就存在好多年了。所以在接触ServiceMesh时，我们首先理解一件事情，微服务给我们带来的好处是人力成本上管理更加分而治之，但是在集群/容器管理难度上就上了好几个数量级。但是集群/容器的管理在Mesh出来之前也是有解决方案的，所以Mesh不光光为了去解决微服务的带来的问题，而是大家发现为了解决微服务所带来的管理问题，现有的解决方法又引发了一些新的问题，即上述所说前两个问题。为了解决上述所说的问题并且还要保留原来的集群/容器管理能力，也就诞生了ServiceMesh。

所以在Dubbo Mesh这场分享里，分享人着重强调了Mesh的价值在于他所提供的解决方案根本不care你服务的语言，让应用本身只专注于业务而没有任何多余的代码。也就是说你一个Web应用，就只要写传统的Controller,Service,DataAccess就行了。其他逻辑你通通不要管也不要写在业务代码里，这就是ServiceMesh的最终形态。所有业务应用，不管你是什么语言写的，Java也好Go也好C++也好。最终你的服务内只有业务代码，(几乎)没有管理相关的配置与代码。

当然这块听起来很美好，但是具体咋做呢？ServiceMesh领域里目前唯一的成熟的产品只有Istio，但是Istio是紧密绑定G家的K8S平台的，他实现的概念也是通过K8S POD这一特性通过Linux Network namespace去实现的，这一块以后我会整理分享一下Docker与Namespace相关的内容，这里就不展开细讲。

但是作为一个共识，目前整个Mesh领域内对于ServiceMesh的具体实现，都普遍认为Sidecar模式和数据层与控制层这两个设计概念是正确的，而落地到具体的应用中去，真正的区别无非就是Sidecar的对象是谁即可。所以对于Istio这一产品来说，他的sidecar所瞄准的对象则是单个业务服务容器，并且由于Istio天生绑定K8S的基础下，Istio所给出的解决方案就是利用K8S的POD特性，在每个POD内注入Istio proxy作为sidecar，去劫持所有进入和出去这个POD的网络流量(tcp层与http层)

但是对阿里的现状，那么多的服务肯定啥情况都有，我们将物理机/虚拟机和单机应用/容器这两组来做个排列组合就有4种情况。但是想要用Istio就必须得是K8S平台，另外一个方面，由于sidecar劫持了所有流量并且istio本身是G家主导开发的，所以除了支持Http协议以外，istio很自然的也支持了grpc。

换言之就是Istio本身目前不支持定制添加协议，所以基于以上两个原因，阿里想要用上ServiceMesh，一来首先需要支持多个平台环境，二来需要支持自己特有的协议，所以Dubbo Mesh应运而生。

Dubbo Mesh的发展思路基本上就是照搬Istio，在控制层与Data层做支持Dubbo协议的扩充。这个是Dubbo Mesh里明确指出的，不过分享里没有明确提到DubboMesh目前在支持的平台上目前支持到哪一个级别，这个同样也很关键。所以整场Dubbo Mesh的分享上，分享人着重描述了ServiceMesh价值，形态，和所要解决的问题。然后带了一笔Dubbo Mesh。 值得一提的是，分享人还特意指出，他们认为由于sidecar会劫持所有的网络流量，所以对于性能的要求非常高，所有会进行GC的语言都是不适合作为sidecar的，所以他们决定基于Enovy去做他们Dubbo Mesh的sidecar。虽然给我听上去感觉就是目前只给envoy增加了一个Dubbo协议解析。

SOFA Mesh

SOFA Mesh是作为蚂蚁金服内部孵化的一个ServiceMesh产品，这个分享就比较实在。分享的内容基本上就着重于目前SOFA Mesh发展的进度如何，有了哪些feature。首先SOFA Mesh也是设计模式也是完全照搬Istio，他的控制层目前完全使用Istio的控制层，但不同的是他自己重写了数据层。在Istio体系下，数据层所使用的应用是Envoy，而SOFA Mesh体系中使用的是他们自研的SOFA Mosn。

Mosn有两个特点，一个是不同于Enovy,Mosn使用的是Go语言编写，另一点是Mosn目前也支持了多种协议。还有分享人关于Mson的说法是先上车后补票，也就是说对于没有上K8S平台的物理机/虚拟机容器应用，SOFA Mson同样也是支持将其纳入到SOFA Mesh的管理体系中。如果这点目前完全实现的话，那么阿里内部接入Mesh就不需要经历漫长的K8S迁移过程而是在保持原有架构不变的情况下直接享受到Mesh管理的好处。然后在全面接入Mesh的前提下，慢慢完成K8S平台的迁移。

对于物理机虚拟机架构的sidecar模式，我猜测很可能是采用唯品会Mesh的解决方法，将sidecar的粗粒度调粗。在Istio体系下，sidecar利用Network namespace的特性就是直接劫持你POD的网络流量，将粗粒度控制在容器级别。而唯品会的解决方案则是将sidecar的控制对象从容器提升到了宿主机，sidecar也就从proxy变成了daemonset。

另外一点来说，SOFA Mesh还特意提到了自己为何使用Go语言来作为sidecar的编写语言，从分享人的陈述中来看，SOFA Mesh是有信心至少要运行10年的产品，从开发维护的角度上来讲，C++的维护成本太大，所以最终选择了Go语言来作为开发语言。而使用Go语言所带来的好处这是，他们这个项目如果要增加一个新的协议支持只需要几个小时，一百行左右的代码即可完成。

所以在听下来两场Mesh之后，我个人感觉Dubbo Mesh与SOFA Mesh在理念与努力的方向上基本是一致的，但是在完成度上Sofa Mesh比Dubbo Mesh完成度更高一点。由于我今年7月毕业以后就一直在国际站项目里负责了K8S与Istio维护，而对于物理机和虚拟机容器架构应用如何去解决相关的问题这一方面基本上不怎么了解。在目前的情况下，国际站已经完全上了K8S和Istio作为底层平台和ServiceMesh管控，所以对于ServiceMesh在理念上想要提供的请求转发即服务发现和负载均衡上，这些都交给了K8S去完成，在我的眼中Istio更倾向于去解决服务治理与服务安全这些内容。不过对于物理机/虚拟机容器的架构，我认为SOFA Mesh是非常合适这个场景的，如果SOFA MESH真的达到了他所说的效果。

另外一方面，分享人也注重提到了关于Mesh这一概念在整个架构中的定位，如果我们将K8S看做平台，将每个服务实例看做应用层，那么Mesh则是夹在平台层与应用层当中的通讯层。这个通讯层，就是指将目前微服务架构下把服务治理从应用中剥离出来，单独抽象为一个层，融入到基础设施的建设当中。同时，由于sidecar会劫持流量，这也就意味着本来生产者发送到消费者的网络调用则会变成生产者，生产者的sidecar,消费者的sidecar,消费者的网络调用，即多了2个中间环节。所以对于流量劫持的性能优化方案，分享人给出了三个思路，一个是iptables的优化，一个是IPVS方案，还有一个是Cilium+eBPF的思路。

以上基本上是这两场分享所讲的大概内容。

一些想法

站在我自身的角度来看，这两场分享我听下来我个人感觉就是阿里和蚂蚁金服向国内布道了ServiceMesh这一概念并且宣布入场。虽然我接触ServiceMesh也有将近半年的时间了，不过阿里和蚂蚁金服更像是Mesh的开发者而我则是Mesh的使用者。我个人感觉在管理国际站项目的K8S平台与Istio的过程中，我可以通过个人的精力去维护整个国际站的服务治理与流量管控这一点就是完全通过Istio来实现的，即灰度发布，ABTest，而K8S平台则天然解决了服务发现和负载均衡这两个问题。

另一方面，K8S与Istio所倡导的声明式API配合GIT的使用则更进一步高效和科学的去管理集群配置与Mesh配置。以国际站目前的情况而言，在完全基于K8S平台和HTTP通信的情况下，我认为在ServceMesh这一块坚持使用Istio即可。作为整个ServiceMesh领域中来说，Istio比起SOFA Mesh和DubboMesh而言没有历史包袱。不过对于整个Istio社区内，目前也没有比较好/普及的关于Istio在服务治理上的使用实践。所以目前对于国际站而言，就是在现有Istio提供的能力下，探索出一条适合我们现有体系架构，利用Istio进行管理的服务治理方案。 对于国际站目前在Istio这一块的探索实践以及所达成的进度，可以参考Istio 实践

另外有意思的一点是，SOFA Mesh和Dubbo Mesh这两个产品是否是整个阿里集团内部的赛马产品？两个分享人都故意的没有谈对方产品，也许可能蚂蚁金服作为一个独立的公司，SOFA Mesh则是只会影响到蚂蚁金服这个业务内的Mesh领域，两个产品可能井水不犯河水。 关于这点就不得而知了。

暂时先写Mesh这两块的听后感，关于其他分享的听后感后续接着补。