蚂蚁金服大规模微服务架构下的Service Mesh探索之路

小蚂蚁说：

本文是根据蚂蚁金服 Service Mesh 布道师敖小剑在 Service Mesher社区进行的第一次 Meetup 上分享的《大规模微服务架构下的 Service Mesh 探索之路》现场演讲内容实录整理编辑而成，但愿能给关注 Service Mesh 产品的朋友们带来帮助和了解。

讲师PPT下载地址：

https://github.com/servicemes...

视频直播回放：

http://www.itdks.com/eventlis...

蚂蚁金服Service Mesh 布道师敖小剑

前言

今天给你们带来的内容叫作Service Mesh探索之路，可是在前面加了一个定语：大规模微服务架构下。之因此加上这个词，是由于咱们这个体系是在蚂蚁金服这样一个大的架构下进行的，蚂蚁金服的体量你们能够想象，因此这个探索会带有一个很是隆重的色彩：对性能/规模/高可用等方面的思考。

今年6月初，在深圳的GIAC大会，咱们同事披露了这个正在开发中的 Service Mesh产品，咱们如今暂时命名为 SOFA Mesh。咱们目前的产品都在 SOFA品牌下，好比 SOFA RPC，SOFA Boot等。今天咱们详细介绍 SOFA Mesh这个单独产品，上次大会只是简单披露，也就是给你们介绍说咱们有这样一个产品，而我今天的内容是把这个产品详细展开。

主要是三个内容：一是 SOFA Mesh的技术选型，二是它的架构设计，以及在最后跟你们聊一下，蚂蚁金服在 SOFA Mesh上的开源策略。

1、技术选型

先上来一堆要求，刚才咱们提到过的，由于是大规模，而蚂蚁金服的体量，你们能够想象到的。实际上在性能，稳定性上，咱们的衡量标准，咱们考虑的基石，都是以蚂蚁金服这样的一个规模来考虑的。

在这样一个规模下，咱们会涉及到一些跟其余公司不太同样的地方，好比说：咱们在性能的考量上会比较重一些。由于若是性能不高的话，可能无法支撑咱们这样一个规模。在考虑性能的时候，就有另一层考量：架构和性能之间的这个权衡和取舍是要很是谨慎的。性能要求不过高的状况下，架构可能的选择，和须要比较高性能的状况下，可能会有彻底不同的取舍。稳定性就没必要说了。

部署方面的要求，首先是咱们会用于多种场合：

主站是指咱们蚂蚁金服内部，好比你们用的最多的支付宝。

金融云，可能有一部分和咱们有联系的同窗会有所了解，这个是咱们推出的针对金融行业的云。

而后还有咱们的外部客户

部署上会要求这三个场合都能使用。

部署环境也会有多种，刚才咱们调查到，有部分同窗相对比较前沿一些，如今就已经上k8s了。有部分同窗仍是停留在之前的虚拟机以及物理机这种状态，也有一部分本身上了容器，还有部分同窗可能会使用不一样的公有云和私有云。这几种不一样的环境，咱们都是须要知足的。

第三点可能要特殊一些，须要知足各类体系。刚才咱们在调查的时候了解到，有部分同窗是在作旧有系统改造，那在改造的时候就会遇到一个问题：除了Service Mesh以外，还须要跟原来的体系，好比说 SOFA，或者社区主流框架如Dubbo，Spring Cloud，相互之间打通和过渡。怎么在技术转型期间平滑的让业务作变动，是咱们在整个技术选型以前提出的实际要求。整个技术选型是在这样一个背景下进行的。

咱们作技术选型的时候，有两大方向：

一个选择是在开源产品上作

咱们先看右边的路线，起点是找一个开源产品，fork出来，作加强/扩展/定制，和内部集成。由于开源产品还在继续往前走，因此咱们会持续作版本更新，也能够从社区拿到最新版本。至关因而从开源社区作获取，而后接下来作反馈，让咱们的一些产品，咱们作的东西反馈回去。

这条路线比较大的好处是从一开始就能够获得社区的支持，社区往前走的时候也跟着往前走。若是作的比较好，愿意让本身的产品反哺社区，那么社区也能够从中受益。

固然这里面有一个小问题，就是说可能咱们本身这个产品路线和开源产品路线可能会有一些分歧，可能咱们领先一步，也可能他们领先一步，或者一个事情可能有两个作法。这种状况下，如何让社区的接受咱们的改动，会变成这条路线上比较头疼的一个问题。

这是两条路线上的第一条，选择以开源产品为起点。

另一种思路全新打造

或者，若是手上已经有一套类库或者框架，能够在这个基础上作包装。

这条路线有一个好处，可控性比较强。由于整个体系是全新打造或者在原有体系上演进而来的，整套体系基本上都是本身的开发团队彻底可控的。

这条路线会遇到一个问题，由于长期上看咱们也是但愿开源的，而开源就意味着不能将本身内部太多的定制化的东西直接作进去，因此在架构上须要考虑可扩展性，能够定制化。由于开源出去的应该是一个标准产品，这样的产品才能够获得社区和客户的承认。客户但愿看到一个干净的东西，也须要作扩展，整个体系在设计上会有所不一样。

两条路线的终点，从图上看，咱们有两个目标：

第一个目标是内部落地

前面提到的，咱们须要在蚂蚁金服主站这样的一个巨大规模的场景下落地，这是蚂蚁金服自身的需求。

第二个目标是技术输出

由于蚂蚁金服在公司策略上有科技输出的内容，不只仅咱们本身用，咱们还须要给出去。

如今咱们来看这个问题：目标在这里，而后有左右两条路线，咱们该怎么选择？在作的技术选型的时候，这是一个很是大的分歧点，究竟是从左边走，仍是从右边走？

在公布结果以前，咱们先来看一下有什么可选方案。

这是开源方案的选择，第一代的Service Mesh。

左边的Linkerd，这个基本上，目前看，你们都已经有点嫌弃了。由于它没有控制平面，用Scala写的，基于JVM，资源消耗比较大。它的可扩展性比较有限的，相对于Envoy的扩展性。而后它里面有个dtab，有接触到的同窗就会有认识：dtab的语法，很是的不人性，很难理解，使用不太方便。另外它的功能是远远不够的，对于蚂蚁金服来讲。另外这个产品自己的发展前景已经很暗淡了，因此这个选项就被淘汰了。

Envoy是很是不错的，作了一些令咱们意外的事情：安心的去作好数据平面，没有往上面作不少的东西，而是创造性的提出了XDS API。整个设计是很是优秀的，性能和稳定性也表现得很是好，甚至看到业界有一个趋势，有一部分的公司开始把他们的nginx替换了，再也不用nginx了，而是用envoy。也就是说，如今它的稳定性和性能达到和nginx一个级别，nginx你们应该都有据说过，envoy已是这样一个工业成熟度。

咱们当时选型时是比较头疼的，由于它是c++写的，c++14。和咱们技术栈的差别会比较大，由于蚂蚁的技术栈是以Java为主，长期的话，咱们可能部分转到Golang上去。在这种状况下，C++的技术栈，会让咱们比较尴尬，也不是说咱们找不到会c++的同窗，而是说，长期上会和咱们的方向不一致，咱们要在Java和Golang的技术栈以外再加一个c++，这就比较难受。

而后咱们内部会有大量扩展和定制化的需求。由于咱们内部有咱们本身的产品，咱们本身的需求，咱们的通信方案，咱们内部的追踪，监控，日志方案，因此工做量很是大。

总结说，咱们以为Envoy很好，可是咱们不能简单用。可是它在数据平面上的表现咱们是很是承认的，Envoy在这点作得很是好。

开源方案里面的第二代，istio是咱们当时的第一选择，重点关注对象。Istio如今最大的问题在于它迟迟不能发布生产可用版本，你们若是对istio有了解的话，会知道istio刚刚发布了0.8版本，第一个长期支持版本，可是这个版本也不是生产可用。不出意外的话，按照目前的进度，istio应该会在7月份发布它的1.0版本，可是从咱们目前的感觉上看，1.0估计可能仍是不能工业级的使用。因此须要等，而咱们无法等，可是Istio的理念和方向咱们很是承认。你们看一看，咱们这个技术选型有多纠结。

右边的Conduit，如今Conduit的最大限制是它只支持k8s。而如今蚂蚁金服尚未普及k8s，咱们如今还有不少系统是跑在非k8s上的。第二是它的数据平面是Rust编写的，这个语言更加小众了，在座的同窗有没有人了解Rust这门语言？或者听过。（备注：现场大概十几我的举手）大概10%左右的同窗听过。好，Rust语言排名大概在50名左右。这个语言自己仍是蛮承认的，我还很喜欢这个语言，它的一些特性仍是很是有道理，若是掌握好仍是能够写出很是好的产品，可是它的入门台阶会比较高一点。这个地方比较讨厌的事情是说，由于这个语言自己比较小众，因此基本上是没办法从社区借力的。这里能够举个例子，你们能够看一下Conduit的committer的人数，大概是25个左右，还包括像我这种只提交了几行代码的。Conduit从12月份开源到如今已经有半年时间，半年时间只有这么多的committer，其中真正有贡献大概9到10我的，基本上都是他本身的员工。也就说这个产品基本上没办法从社区借力，一个产品，若是你们一块儿来帮忙，其实不少的细节是能够完善的，可是Conduit就卡在Rust语言上。

而后仍是一样有技术栈的问题，由于这个缘由，基本上Conduit咱们也无法用了。

咱们再看一下国内的在Service Mesh领域，其余的一些比较前卫的同窗，他们的选择会是什么？

首先是华为，华为本身作了一套Golang版本，名字叫作Mesher。这是由他们以前的一套类库演进而来。它走的路线是，先有类库和框架，而后加proxy，proxy打通了以后再慢慢的开始添加控制平面。这是一条很是很是标准的路线，我这边给一个词叫作老成持重，由于这条路是最安全的：每一步都是基于现有的产品，很快就能够到下一个里程碑，而后每一个里程碑均可以解决一些实际问题，能够直接获得一些红利，这个方案是比较比较稳妥的。好比说第一步是把proxy作进去，有了这个切入口以后，就在第一时间获取跨语言的红利，还有技术栈下沉的好处。而后控制平面的创新，能够在这个基础上慢慢往前作。

在对接Istio这一条上，如今华为的策略，咱们如今从公开途径了解到的是：部分对接istio，也就是有一部分的API兼容Istio。可是细节上还不太清楚，由于它的开源还没出来，目前获得的消息是，会在7月份开源。

第二个是新浪微博的Motan Mesh，他们也是Golang的，但他不太同样，是全新实现。他们用Go语言从新写了一把，主要缘由是由于它没有golang类库，Motan是基于Java的。

刚才看到的这两个产品，他们的思路大致上是相同的，差别在哪里？就是启动的时候是用已有的类库仍是从新写？这两个选择之间最大的麻烦在于编程语言，华为原来有go的类库，因此继续用golang包装一下就行了。可是新浪的类库用的是Java，而sidecar选择的是go语言，因此只能从新作了。

咱们再看腾讯，最近看到他们有相似的产品出来。咱们看看他们的资料：在数据平台上继续选择Envoy，由于它比较成熟。腾讯的话你们比较熟悉，尤为是腾讯有很是深厚的c++背景，因此Envoy对他们来讲，技术栈是很是OK的。并且以前内部其余领域Envoy也是在用的，因此底层很是天然的选择了Envoy。而后控制平面上，据传是"挣扎了一下"。这个词是我抄过的，"他们挣扎了一下"，最后仍是选了Istio。而后本身作定制和扩展，而后注意到他们也解耦了k8s。这也是其中一个关键的点：要不要绑定k8s？

这里还有UCloud的一个颇有意思的作法，另辟蹊径啊。他的方案颇有意思，是一个轻量级的实践：从Istio里面，将Envoy和Pilot单独剥离出来。就是说不用Istio总体，把Mixer和Auth的模块去掉，只要最重要的Envoy，而后把Pilot剥离出来。而后这个Pilot仍是个定制版，把其余的adapter干掉了。Pilot主要是作服务发现，它底层用ETCD，作了一个ETCD的adapter，把其余的adapter从Pilot中去掉。作完这几个事情以后，整个体系就能够脱离k8s了，这是一个比较有意思的实践。

总结：在讲咱们技术决策过程以前，咱们过了一下目前市场上的主要产品，以及一部分实践者的作法。

咱们如今来详细讲一下，SOFA Mesh在技术选型上的考虑。

首先第一个，数据平台上Envoy是最符合咱们要求的，Envoy确实好。第二个事情是Envoy提出的XDS API设计是很是使人称道的，咱们如今对这个的评价是很是高的。它其实是一套通用的API，因为时间的缘故，我今天就不在现场展开API的细节。只能说XDS API基本上已经成为数据平面和控制平面之间的一个事实标准。

在这种状况下，咱们实际上是想用Envoy的，可是刚才提到咱们有个技术栈选择的问题：咱们不肯意将c++归入到咱们主流的技术栈。而后咱们自己有太多的扩展和定制，逼得咱们不得不去改Envoy，咱们不能简单的拿过去用，咱们须要作不少扩展的。

另一个事情是，咱们这个proxy不只仅是用于Mesh，咱们有可能把它引入到API Gateway里头，以及后面会提到的名为Edge Sidecar的模块。由于这个缘由，因此，怎么说呢，想用，可是不合适用。

第二就是在Istio上，控制平面这一块Istio能够说是作的最好的。基本上，到目前为止，在控制平面上，暂时咱们尚未看到作的比Istio更好的产品，或者说思路。目前Istio整个设计理念，包括它的产品方向，也是咱们很是承认的。

可是Istio的性能是目前最大的问题，而咱们有一个重要的前提：大规模应用。要用在蚂蚁金服主站这样一个场景下，性能和稳定性对咱们很是很是的重要。第二个问题是它对非k8s的支持不够理想，由于咱们还涉及到一个k8s没有彻底上线的问题。第三个是和侵入式框架互通的问题，咱们内部用的是SOFA，对外推出的时候咱们的客户用的多是Dubbo或者Spring Cloud，Mesh上去以后，两个系统如今走不通，这是大问题。

最终咱们的策略是这样的，这是咱们 SOFA Mesh的技术选型：左边是Istio现有的架构，Envoy/Pilot/Mixer/Auth，右边是咱们 SOFA Mesh的架构。

最重要的第一点：咱们用Golang开发的Sidecar替换Envoy，用Golang重写整个数据平面。
第二点是咱们会合并一部分的Mixer内容进到Sidecar，也就是Mixer的一部分功能会直接作进Sidecar。
第三点是咱们的Pilot和Auth会作扩展和加强。
这是咱们整个的技术选型方案，其实是Istio的一个加强和扩展版本，咱们会在整个Istio的大框架下去作这个事情，可是会作一些调整。

2、架构设计

而后咱们来详细介绍一下在这个技术选型上咱们怎么去作实现。

首先是Golang版本的Sidecar，咱们会参考Envoy，很是明确的实现XDS API。由于XDS API是目前的事实标准，因此咱们选择遵循，而后咱们会让它兼容Istio。

在协议支持上，咱们会支持标准的HTTP/1.1和HTTP/2，也就是你们常见的REST和gRPC协议。而后咱们会增长一些特殊的协议扩展，包括 SOFA协议，Dubbo协议，HSF协议。咱们如今正在作这几个协议的扩展，而后XDS API咱们支持，mixer service咱们没有改动，遵循现有实现。

最大的变化在Mixer，其实刚才的Sidecar虽然是全新编写，可是说白了是作Envoy的替换，在架构上没有什么变化。可是第二步的变化就很是大，咱们会合并一部分的Mixer功能。

Mixer的三大功能：

一、check。也叫precondition，前置条件检查，好比说黑白名单，权限。

二、quota。好比说访问次数之类。

三、report。好比说日志，度量等。

三大功能里面，注意到，前两个功能是同步阻塞的，就是必定要检查经过，或者是说quota验证OK，才能往下走。若是结果没回来只能等，由于这是业务逻辑，必需要等。而Report是能够经过异步和批量的方式来作的。

在这里，咱们如今的决策是：咱们会将其中的两个部分(check和quota)合并进来，原有report部分咱们会继续保留在mixer里面。

可能你们会问：为何咱们要选择用这个方案，而不是遵循Istio的标准作法？咱们以前聊到，咱们会尽可能去和Istio作兼容，跟随Istio的设计理念和产品方向，可是咱们在它的架构上作了一个重大的调整。为何？

最大的问题就是对性能的影响。

给你们解释一下，看右边这个图，Envoy在每次请求进来的时候，要去作两次调用：

第一次在请求转发以前要作一次check，这个check里面包含了quota。Check完成经过，才能把请求转发过去。
请求转发完成以后，再调用report，报告一下响应时间，日志，度量等信息
每次traffic都会有两次调用：一次check，一次report。而这是远程调用，由于这两个模块是两个进程，Mixer是单独部署的。

同步阻塞意味着必需要等，远程调用意味着有开销并且有延迟。这个事情是发生在每一次请求里面，意味着整个的性能必定会受影响。而考虑到咱们蚂蚁金服这样一个体量，其实咱们是很难承受。因此咱们有本身的观点：咱们不是太承认这样的一个方式，咱们的想法是说咱们要把它拆分出来想想：

若是是须要请求作同步阻塞的功能，好比说黑白名单的验证，可能要检查IP地址，可能检查quota。这些逼请求必定要作同步阻塞等待结果的功能，就不该该放在Mixer中去完成去远程调用，而应该在Sidecar中完成。
这是咱们的观点，缘由就是远程调用带来的系统开销，这个代价实在是过高了！
而后其余的功能，好比说能够优化为异步的，或者能够以批量方式来提交的，最典型的就是Report。Report实际上是能够异步提交，能够把十个请求打包到一个report同时提交，这些都是OK的。
这是咱们的基本想法。

这个问题其实在Istio里面是给了一个解决方案的。最先的时候，Istio 0.1版本中，一出来就发现这个问题。从去年5月份开始到如今，13个月的时间里，他只给了一个解决方案，就是在Mixer上的这个位置加了一个Cache。这个的Cache的想法是：把这些结果缓存在Envoy的内存里面，若是下次的检查参数是相同的，那咱们能够根据这样一个缓冲的设计，拿到已经缓存的结果，就能够避免远程调用。这个方式是很理想的，对吧？只要缓存可以命中，那就能够避免这一次远程调用。

而后第二个优化是report，如今的report是经过异步模式完成的，并且是批量。

理论上说，若是这两个事情作到足够理想，Mixer应该就不是瓶颈。对吧？

问题在于：这个Cache真的搞得定吗？

咱们给一个简单的例子，我如今假设Mixer有三个adapter。而后它的输入值是不一样的属性，属性是istio的概念，理解为若干个输入值。假设，须要三个adapter分别检查A/B/C。若是这三个属性A/B/C，他们只有100个取值范围，每一个都是从0到100，咱们假设这种最简单的场景。

若是这三个adapter分别作缓存的话，须要多少个缓存项？很容易计算吧？100个a，100个b，100个c，很是容易计算，这种状况下，其实就是a+b+c等于300嘛。理解一下：有三个输入，每一个输入只有一百个取值范围，咱们要把他们缓存起来。这些缓存大小，就是容许的范围，而后加起来。只要有300个key，就均可以缓存起来。

可是，这个方法中，缓存是作在mixer这边，每一个adapter单独缓存。可是，在Istio中，缓存是作在Envoy这端的，由于作在mixer这端是没有用的，仍是要远程调用过去。它作缓存的很重要的目标是要在客户端避免远程调用。因此，这种状况下，把缓存放到这里（备注，图中绿色方块）。

你们如今想想，如今这里只有一个缓存，只有一个key/value。如今还有刚才的这个场景，A/B/C各自的取值范围都是一百。可是如今缓存放在这边的话，实际上的这个key要考虑三个值了，A/B/C的组合。这种状况下，它的最大缓存个数是多少？

（备注：现场回答，a 乘 b 乘 c）

a b c？还能 a + b + c吗？作不到了，对不对？如今是 a b c，从300变成这么大的数了。为何？由于缓存是在这个地方作的，根本没有办法像这样分开作，因此这里就变成了一个笛卡尔乘积。

这个笛卡尔乘积有一个很大的麻烦，也就是说，若是adapter检查的某个属性，它的取值范围比较大，好比说要检查客户端的IP地址？你想一想，这个IP地址有多少个取值范围？数以几十万几百万计，对吧？这种状况，哪怕在前面再乘以特别小的值，哪怕只是十，二十，若是是加20根本没所谓的，加200，加2000都没所谓的，那乘个200，乘个2000试一下？瞬间就被干掉。IP地址可能只是百万级别，再在前面乘个100，乘个1000，瞬间就疯掉了。这个key值基本上已是大到不能接受：要么就全放内存，内存爆掉；要否则限制缓存大小，就放1万个，缓存的命中率会很是低，整个缓存至关于失效了。

这个细节，由于时间缘由，不在这里详细讲了。

这里讲第二点，咱们的检讨：隔离怎么作？

Mixer有一个基本的设计目标，就是但愿提供一个统一的抽象（就是这个adapter的概念），用它来隔离基础设施后端和Istio的其余部分。可是在这个点上咱们的反思是：咱们承认这样一个隔离。你们理解基础设施后端的概念吧？举个例子，日志处理如prometheus，各类后端监控系统。这些系统和应用之间，咱们认为这种状况下的确应该作隔离，不必每一个应用都去和基础设施后端产生直接的联系。这个观点是咱们是赞许的。

可是咱们如今的意见是，咱们把这条线(备注：链接应用和基础设施后端的标记有红叉的线)从应用里面拿下来以后，咱们把它下沉。下沉到Sidecar，够不够？Istio的作法是，它以为这个地方应该再往前走一步，到Mixer里面。由Mixer去完成和基础设施后端的链接，走这根线（备注：图中链接Mixer和基础设施后端的线）。可是多了这样一个隔离以后的代价，就是在中间的这根红线上，会多一次远程调用。

如今只有两个选择：和基础设施怎么连？这条线（备注：最左边的）你们都认为不必，这两条线（备注：中间和右边的线）之间选，两条线的差别，就是要付出一次远程调用的代价。

继续检讨：什么是基础设施后端？

这里咱们作一个列表，整个Istio现有的adapter，你们能够看到，大概是这些。前面这两个部分是实现check和quota的adapter，后面这些adapter是实现report功能。

在这里，咱们的检讨是：这些功能，好比说黑白名单，好比说基于内存的quota，或者基于外部redis的quota。咱们认为这些功能不太应该视为后端基础设施，由于这些功能更应该是说是体系内置的基本能力，应该直接把它们作成Mesh的内置产品，或者说能够作标准化，而后和外部系统集成。这些我认为应该是Mesh的最基础的功能，好比说咱们 SOFA Mesh能够提供基于Redis的quota方案，直接就把这个功能给出来了。我不认为应该再去跟外界的一个所谓的基础设施后端发生联系。

可是下面这些咱们是以为OK的。这些adapter你们有概念吧，prometheus你们应该都接触过的。剩下的这些在国内可能用的很少，是各类日志和metric相关的功能。把这些视为基础设施后端，咱们是很是理解的。包括咱们内部，咱们蚂蚁也有不少这样的系统，相信各位自家的监控方案也是不同的。

这些视为基础设施，和系统隔离开，咱们认为这是很是有必要，能够理解，能够接受。

这是咱们在这一点（备注：何为基础设施后端）上和istio的差别。

由于时间缘由，咱们就再也不深刻去讲，这里我给了一些我博客上的文章。前段时间，咱们在作技术选型，在作前面整个架构设计时，在这一点上有些讨论。以及咱们最重要的决策：为何要把Mixer合并进去。细节都在这几篇文章里面，你们若是有兴趣，能够去详细了解。

备注连接地址（请复制网址到浏览器打开）：

Service Mesh架构反思：数据平面和控制平面的界线该如何划定？
https://skyao.io/post/201804-...

Mixer Cache: Istio的阿克琉斯之踵
https://skyao.io/post/201804-...

Istio Mixer Cache工做原理与源码分析(1)－基本概念
https://skyao.io/post/201804-...

Istio Mixer Cache工做原理与源码分析(2)－工做原理
https://skyao.io/post/201806-...

Istio Mixer Cache工做原理与源码分析(3)－主流程
https://skyao.io/post/201806-...

Istio Mixer Cache工做原理与源码分析(4)－签名
https://skyao.io/post/201806-...

咱们还有一部分如今没有合并进来的adapter和mixer，report的这部分。可是这块不是说彻底没有问题，咱们如今有一个担忧，report这块可能会存在一个叫作网络集中的问题。好比说，你们会注意到，应用和Sidecar是一对一部署的，有一万个应用，就有一万个Sidecar。基础设施后端也是多机部署的。

而如今的方式，流量会先打到Mixer来，Mixer也是高可用的，也是会部署多台。可是这个数量确定不是一万这个级别，跟这个确定会有很大的差别。这样流量会先集中，通道会忽然间收缩一下。总的流量没变，可是通道的口径要小不少。

对网络吞吐量也会有影响。好比最简单的，若是应用直连，走交换机直接就过去了。

若是是Sidecar模式，是在这个位置上（备注：应用和sidecar之间的绿色连线）加一个远程调用，可是应用和Sidecar之间走的是localhost，localhost根本就不走网卡，直接环回地址就走了。对性能不会有什么影响，对网络流量的影响就为零了。因此这两个方案相比，吞吐量不会有变化。

可是，若是在Sidecar和Backend之间再加一个Mixer，这意味着要走两次网络，这样的话会有一个流量翻倍的问题。

因此这个地方可能会带来一些问题，但暂时咱们如今还没作决策，咱们如今还不是很肯定这个问题会不会致使质的影响。因此咱们如今暂时仍是把它放在这里，就是说咱们后面会作验证，若是在咱们的网络方案下，这个方式有问题的话，咱们可能再合进去。可是若是没问题的话，咱们认为分开以后架构确实会更理想一些，因此咱们如今暂时先不合并。

给你们一些参考，目前Conduit最新版本已经把report的功能合并进来，而后check的功能，会在后续的计划中合并。咱们在国内作一些技术交流，华为新浪微博他们如今统统都是选择在Sidecar里面实现功能，不走mixer。

这是咱们称之为梦幻级别的服务注册和治理中心，咱们对他的要求是比较多的：

咱们须要他支持跨集群，好比说咱们如今有多个注册中心，多个注册中心之间能够相互同步信息，而后能够作跨注册中心的调用
还有支持异构，注册中心多是不同的东西。能理解吧，有些是Service Mesh的注册中心，好比Istio的，有些是Spring Cloud的注册中心，好比Consul。
而后终极形态，咱们但愿在两种场景均可以支持。
右边的这个图，是咱们构想中的比较理想化的注册中心的架构，咱们会有各类adapter实现，会有一个抽象的模型，把他们抽象起来，而后有一些接口。后来，在咱们实现的时候发现，Istio的路线跟咱们有点像，Istio自己也是作了跨平台的Adapter，也作了一层抽象，而后它也提出了一些API。因此咱们最终的决策是：往Pilot靠。

咱们以Istio的Pilot模块为基础去作扩展和加强：

增长 SOFA Registry的Adapter，SOFA Registry是咱们内部的服务注册中心，提供超大规模的服务注册和服务发现的解决方案。所谓超大规模，你们能理解吧？服务数以万计。
再加一个数据同步的模块，来实现多个服务注册中心之间的数据交换。
而后第三点就是但愿加一个Open Service Registry API，增长服务注册，由于如今Istio的方案只有服务发现，它的服务注册是走k8s的，用的是k8s的自动服务注册。若是想脱离k8s环境，就要提供服务注册的方案。在服务发现和服务模型已经标准化的状况下，咱们但愿服务注册的API也能标准化。

这里还有一个比较特殊的产品，由于时间限制，给你们简单了解一下。

咱们计划的Edge Sidecar这个产品，它是东西向服务间通信的一个特殊桥梁。所谓东西向，你们能理解吧？东西向指服务间通信，也就是A服务调用B服务。对应的还有南北向，南北向一般是指从外部网络进来调用服务，如走API Gateway调用服务。在东西向通信中，咱们有时会须要一个比较特殊的途径，好比说在这个图中，咱们有两个集群，两个集群各有各自的服务注册中心。咱们经过加强Pilot的方式打通两个注册中心，能够知道对方有什么服务。

当A服务发出一个请求去调用B服务的时候，因为两个集群是隔离的，网络没法相通，确定直接调用不到的。这时local sidecar会发现，服务B不在本集群，而在右边这个集群里，Local Sidecar就会将请求转发给Edge Sidecar，而后由Edge Sidecar接力完成后续的工做。

这个模块的功能会比较特殊一点，由于时间限制，在今天的过程中，Pilot和Edge Sidecar就再也不详细展开。

下个月在北京的meetup上，咱们这边负责这一块工做的专家，俊雄同窗，会给你们详细展开。

3、开源策略

SOFA Mesh的开源策略，可能会和你们以前接触到的一些开源产品，有质的差别，很是的不同。

备注：这块就不整理了，直接看图中文字。

这是整个大的愿景。

SOFA Mesh的开源态度，其实我写左边这些的时候是有很大压力的。用官方话语说，不针对任何人和任何项目，咱们不影射任何人。

可是，你们若是常常用各类开源产品的话，会发现一些问题。好比说，开源的时机。你们接触的开源产品，尤为是国内的，无论是多大的公司，一般都是产品完成以后，甚至是使用好多年。好处是相对稳，缺点是什么？（备注：现场回答，老）对，技术可能已经很老了，十年前的！还有多是它都已经放弃了，开源出来时本身再也不使用。或者说是一个很新的产品，真的很新，他本身不用，说就是作出来给你用的。（备注：现场哄笑）本身不用的产品给你用，你的第一反应是什么？小白鼠是吗？你愿意作小白鼠吗？你敢把公司的这个产品放上面吗？

SOFA Mesh此次比较特殊，很是很是特殊。咱们这个产品，会在很是早的时间点上开源给你们。我甚至能够跟你们说，其实在这个点上，咱们更重要的是摆明态度：咱们要开源，咱们要把这个产品开源给你们，甚至早到咱们本身都不认为这是一个完整的产品。为何？

有几个事情，这几点你们承认吧？业界最新的技术，Mesh是最新技术你们都已经达成共识了吧？业界最好的架构，固然这个咱们还在努力中，尽可能作好。而后咱们会给你们一个承诺，你们不用担忧作小白鼠，你能拿到的产品，咱们已经趟过一遍了。

开源动机，这个地方咱们也不说大话，就是咱们但愿能吸引整个社区，谋求这样一个合做，走开源共建的方式。这是为何咱们会选择在如今这个时间点上开源出来。

整个产品的维护，什么样的产品会让你有信心，不用担忧中间断掉？最重要的一点是咱们本身在用。想一想，若是支付宝在用，你担忧这个项目死掉吗？对不对？若是这个产品自己是蚂蚁金服这样级别的公司，在它的线上将会使用的产品，并且是一样一个核心的版本。相信在这种状况下，你们就放心了吧？

SOFA Mesh的合做模式，我称之为"多层次全方位开放"。

中间这幅图，最底下的是基础类库，实现各类功能。咱们但愿有这样一套基础类库，类比Netflix的OSS套件。由于Golang的类库作的不是很好，没有Java沉淀的那么好。目标是但愿在这个产品作完以后，能给整个社区沉淀出一套Golang的微服务基础类库。最重要的一点，是但愿最好能你们协力，在这个点上作出一套成熟稳定性能足够好的产品。这是在类库层面。

在类库之上，功能模块层面，好比说Golang版本的Sidecar，咱们但愿它能替换Envoy的功能。在原来使用Envoy的状况下可使用这个Sidecar来替代。体如今什么层次？就是说，若是想用Envoy，也很喜欢它，可是可能又受限于C++语言栈，更但愿是Golang语言栈的时候，能够选择咱们这一套。或者若是咱们抱有一样的想法，好比想把Mixer合进来，能够在Sidecar这个层面上来重用咱们的产品，跟咱们作合做。或者咱们刚才提到的这个产品，加强版本的Pilot，你们有印象吧？咱们会实现一个很是强大的，跨各类集群，各类异构的服务注册机制。而后是Edge Sidecar，在两个不一样的区域之间，好比两个不一样的机房，IP地址不通的状况下，帮你打通服务间调用。这些功能模块，会以单独的产品和项目出现，你能够在某一个产品上跟咱们合做。

第三点就是完整的产品，若是你须要一个完整的Service Mesh的产品，把这些全部的功能都包括进来，没问题，SOFA Mesh能够拿来用。

有些同窗可能会须要更完整的解决方案，咱们的金融云会提供 SOFA Mesh的支持，这是咱们的目标。你能够将你的系统，架构在金融云之上。

今天的几位讲师来自不一样的公司，咱们很是欢迎业界参与。若是你们有意在Service Mesh领域作一些事情，你们能够相互之间作技术的沟通，技术的交流，在社区合做上作一些事情。

有些同窗说，我只是用一下，好像无法作什么贡献。其实，"用"是一个很重要的合做，你可以用，你就会遇到问题，有你的诉求，遇到什么样的bug，有什么样需求没有知足。这些对咱们来讲，是很是重要的输入。在这一点上，欢迎和咱们保持合做。

SOFA Mesh的开源宣言，写的比较狗血。可是在这一点上，我以为这一次SOFA Mesh在开源上仍是作的比较有诚意。

首先咱们承认这个大方向，咱们看好Service Mesh的前景。体如今什么上呢？咱们如今规划，将来整个蚂蚁金服内部的大部分应用都会逐渐的往Service Mesh上落。这个内部已经达成一致了，会往这个方向走。

第二是说，"勇敢探索"，"耐心填坑"，有在1.0版本以前用过大型开源产品的同窗，对这两个词都应该有深入体验，对吧？包括前两年用0.*版本和1.1/1.2版本的k8s的同窗。任何一个新的技术，一个大的方案出来，前期的时候，这些事情是必定会遇到的。可是咱们以为仍是要去趟这个事情。

咱们要继续推动这样一个技术进步，包括Service Mesh技术社区的推广。你们若是有注意的话说，Service Mesh技术社区已经从新启动了，咱们在跟不少的公司，包括甚至咱们一些竞争对手合做。从技术进步的角度说，咱们欢迎你们在一个公平的基础上作技术交流。

而后咱们是愿意作分享的，整个产品，咱们接下来全部能开源的东西都会开源出来。除了一些内部定制化的东西，内部没有开源的产品的集成。基本上，大家能看到的东西，也就是咱们内部用的东西。

咱们寻求和你们的合做，包括刚才讲过的各个层面的合做，哪怕是简单的使用，发现问题给咱们提交一些bug，也是很是好的合做契机。

这里我喊一个口号，这个口号有点大，"集结中国力量，共建开源精品"。这里面有个词，比较大一点，我也斟酌了一下，中国这两个字敢不敢用。最后我以为仍是用吧，至少到目前为止，Service Mesh这个技术领域，在全世界目前都尚未成熟的场景落地的状况下，咱们目前在这方面的探索，已是走在最前面的了。

在这一点上，咱们是但愿能联合国内在这个领域作探索的同窗，咱们一块儿来作这个事情。咱们开源的一个重要目的，是说无论你们在商业上有什么样的竞争，至少在技术领域上，包括刚才说的能够在类库层面，产品层面，或者社区合做方面，开展合做。咱们但愿可以尽量的联合国内的合做伙伴，包括竞争对手一块儿来营造整个技术氛围，把整个Service Mesh技术体系的基本水准提高上来。

这一点应该是你们比较关注的，何时开源? 咱们只能告诉你们说，on the way，正在路上。

原本这一页的写法应该是贴个地址给你们的，可是由于进度的缘由尚未实现，有可能会在一到两个星期以后，在7月份的时候开源给你们。

须要澄清的一点，你们的指望值不要过高，由于咱们开源出来的第一个版本，主要是释放姿态，把咱们的开源共建的姿态释放出来。咱们的第一个版本，确定不是一个完善的版本。（备注：现场有同窗问，有在用吗？）内部有用一部分，Sidecar内部已经在用了，可是第二部分的内容，好比说XDS API的集成，咱们如今正在作。咱们不但愿等把产品作完善了，好比说两年以后很是成熟的状况下再来开源。咱们但愿尽量早的开源。

（备注：现场提问，7月份的版本，不必定是生产环境可用？）对，是的。有一部分功能是生产可用的，有一部分功能不是，由于咱们是迭代上去的。

4、官方社区网站

这是咱们刚刚开通的Service Mesh技术社区的官方网站，欢迎访问。（http://www.servicemesher.com 请将网址复制至浏览器中打开便可查看）

5、线下活动

蚂蚁金服将在7月6日与ArchSummit深圳合做举办云原生架构探讨晚场技术交流活动，邀请微服务、中间件、应用开发架构、分布式事务解决方案等技术专家，共同讨论云原生、容器、微服务、海量数据访问等话题，Service Mesh、K8S、海量数据一致等，六大热点技术邀你来聊！

报名连接：

https://www.bagevent.com/even...

本文做者：兔子酱

阅读原文

本文为云栖社区原创内容，未经容许不得转载。