蚂蚁金服 Service Mesh 实践探索

做者 | 敖小剑

本文整理自蚂蚁金服高级技术专家在 QCon 上海 2018 上的演讲。

你们好，我是来自蚂蚁金服中间件团队的敖小剑，目前是蚂蚁金服 Service Mesh 项目的PD。我同时也是 Servicemesher中国技术社区 的创始人，是 Service Mesh 技术在国内最先的布道师。我今天给你们带来的主题是”长路漫漫踏歌而行：蚂蚁金服Service Mesh实践探索”。

在去年的QCon上海，我曾经作过一个名为 “Service Mesh：下一代微服务” 的演讲，不知道今天现场是否有当时听过去年这场演讲的同窗？（备注：现场调查的结果，大概十几位听众听过去年的演讲。）

固然，今天咱们的内容不是继续作 Service Mesh 的布道，按秀涛的要求，今年要好好讲一讲实践。因此今天我不会像去年那样给你们详细解释 Service Mesh 是什么，能作什么，有什么优点。而是结合过去一年中蚂蚁金服的实践经验，结合蚂蚁金服的 SOFAMesh 产品，帮助你们更深入的理解 Service Mesh 技术。

在开始今天的内容分享以前，咱们先来热个身，温习一下去年的内容。去年我是来QCon布道的，而布道的核心内容就是告诉你们：Service Mesh 是什么？

为了帮忙你们回答，我给出一个提示图片，了解 Service Mesh 的同窗对这张图片应该不会陌生。

这里咱们一块儿回顾一下Service Mesh 的正式定义：

Service Mesh是一个基础设施层，用于处理服务间通信。现代云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递。

在实践中，服务网格一般实现为一组轻量级网络代理，它们与应用程序部署在一块儿，而对应用程序透明。

黑色加粗部分是重点：

• 基础设施层：这是 Service Mesh 的定位，今天内容的最后一个部分我会和你们详细展开这个话题
• 服务间通信：这是 Service Mesh 的功能和范围
• 实现请求的可靠传递：是 Service Mesh 的目标
• 轻量级网络代理：是 Service Mesh 的部署方式
• 对应用程序透明：是 Service Mesh 的重要特性，零侵入，Service Mesh 的最大优点之一。

今天的内容会有这些：

• 先给你们快速介绍一下咱们的 SOFAMesh 项目，让你们对故事的背景有个大体的了解
• 而后给你们介绍一下为何咱们选择了用 Golang 语言来实现数据平面，这个是过去一年中各方对咱们产品方案最大的疑惑
• 再继续给你们分享一下过去一年中咱们在 Service Mesh 落地中遇到的典型问题和解决方案，给你们一些比较实际感觉
• 而后咱们将探索一下服务间通信的范围，看看 Service Mesh 能够在哪些领域获得应用
• 再接下来，给你们介绍一下在这一年实践中的最大感悟，和你们聊聊基础设施对服务网格的意义，这也是今年最想和你们分享的内容。
• 最后，总结一下今天的内容，分享一些信息

OK，让咱们开始今天的第一个部分，给你们快速介绍一下 SOFAMesh，目标在展开咱们的各类实践和探索以前，让你们了解一下背景。

SOFAMesh 是蚂蚁金服推出的 Service Mesh 开源产品，你们能够简单的理解为是 Istio 的落地加强版本。咱们有两个原则：

1. 跟随社区

   体如今 SOFAMesh 是 fork 自 Istio，并且紧跟 Istio 的最新版本，确保和上游保持同步。

   咱们在 Istio 上的改动都在 SOFAMesh 项目中开源出来，并且在验证完成后咱们也会联系 Istio，反哺回上游。

2. 实践检验

   一切从实践出发，不空谈，在实际生产落地中，发现问题，解决问题。在解决问题的过程当中，不将就，不凑合，努力挖掘问题本质，而后追求以技术创新的方式来解决问题。

原则上：Istio 作好的地方，咱们简单遵循，保持一致；Istio 作的很差或者疏漏的地方，咱们努力改进和弥补。

全部这一切，以实际落地为出发点，同时知足将来的技术大方向。

SOFAMesh 的产品规划，这是目前正在进行的第一阶段。架构继续延续 Istio 的数据平面和控制平面分离的方式，主要工做内容是：

1. 用 Golang 开发 Sidecar，也就是咱们的 SOFAMosn 项目，替代 Envoy。
2. 集成 Istio 和 SOFAMosn，同时针对落地时的需求和问题进行扩展和补充，这是咱们的 SOFAMesh 项目

在这个架构中，和 Istio 原版最大的不一样在于咱们没有选择 Istio 默认集成的 Envoy，而是本身用 Golang 开发了一个名为 SOFAMosn 的 Sidecar 来替代 Envoy。

为何？

咱们的第二部份内容将给你们解答这个问题。

MOSN 的全称是 “Modular Observable Smart Network”，正如其名所示，这是一个模块化可观察的智能网络。这个项目有很是宏大的蓝图，由蚂蚁金服的系统部门和中间件部门联手UC大文娱基础架构部门推出，准备将原有的网络和中间件方面的各类能力在 Golang 上从新沉淀，打形成为将来新一代架构的底层平台，承载各类服务通信的职责。

Sidecar 模式是 MOSN 目前的主要形式之一，参照 Envoy 项目的定位。咱们实现了 Envoy 的 xDS API，和 Istio 保持兼容。

在 Istio 和 Envoy 中，对通信协议的支持，主要体如今 HTTP/1.1 和 HTTP/2 上，这两个是 Istio / Envoy 中的一等公民。而基于 HTTP/1.1 的 REST 和基于 HTTP/2 的 gRPC，一个是目前社区最主流的通信协议，一个是将来的主流，Google 的宠儿，CNCF 御用的 RPC 方案，这两个组成了目前 Istio 和 Envoy（乃至 CNCF 全部项目）的黄金组合。

而咱们 SOFAMesh，在第一时间就遇到和 Istio/Envoy 不一样的状况，咱们须要支持 REST 和 gRPC 以外的众多协议：

• SOFARPC：这是蚂蚁金服大量使用的 RPC 协议(已开源)
• HSF RPC：这是阿里集团内部大量使用的 RPC 协议(未开源)
• Dubbo RPC: 这是社区普遍使用的 RPC 协议(已开源)
• 其余私有协议：在过去几个月间，咱们收到需求，指望在 SOFAMesh 上运行其余 TCP 协议，大部分是私有协议

为此，咱们须要考虑在 SOFAMesh 和 SOFAMosn 中增长这些通信协议的支持，尤为是要可让咱们的客户很是方便的扩展支持各类私有TCP协议。

为何不直接使用 Envoy？

几乎全部了解 SOFAMesh 产品的同窗，都会问到这个问题，也是 SOFAMesh 被质疑和非议最多的地方。由于目前 Envoy 的表现的确是性能优越，功能丰富，成熟稳定。

咱们在技术选型时也是重点研究过 Envoy，能够说 Envoy 很是符合咱们的需求，除了一个地方：Envoy是c++。

这里有个选择的问题，就是数据平面应该选择什么样的编程语言？

图中列出了目前市场上主要的几个 Service Mesh 类产品在数据平面上的编程语言选择。

• 首先，基于 Java 和 Scala 的第一时间排除，实践证实，JDK/JVM/字节码这些方式在部署和运行时都显得过重，不适合做为 Sidecar
• Nginmesh 的作法有些独特，经过 Golang 的 agent 获得信息而后生成配置文件塞给 nginx，实在不是一个正统的作法
• Conduit（后改名为Linkerd2.0）选择的 Rust 是个剑走偏锋的路子，Rust 自己极其适合作数据平面，可是 Rust 语言的普及程度和社区大小是个极大的欠缺，选择 Rust 意味着基本上没法从社区借力
• Envoy 选择的 c++
• 国内华为和新浪微博选择了 Golang

咱们在选择以前，内部作过深刻讨论，焦点在于：将来的新一代架构的底层平台，编程语言栈应该是什么？最终一致以为应该是 Golang，配合部分 Java。

对于 Sidecar 这样一个典型场景：

• 要求高性能，低资源消耗，有大量的并发和网络编程
• 要能被团队快速掌握，尤为新人能够快速上手
• 要和底层的 k8s 等基础设施频繁交互，将来有 Cloud Native 的大背景
• 很是重要的：要能被社区和将来的潜在客户接受和快速掌握，不至于在语言层面上有太高的门槛

不考虑其余因素，知足 Sidecar 场景的最理想的编程语言，天然是非 Golang 莫属。

可是到具体的技术选型时，面对要不要使用 Envoy，决策依然是很是艰难：关键在于，c++有 Envoy 这样成熟的产品存在，能够直接拿来用；而 Golang 没有能够和 Envoy 平起平坐的产品能够选择，须要白手起家。

两个选择各有优劣，短时间看：

• 直接使用 Envoy，优点在于这是一个成熟项目，表现稳定，并且也是 Isto 默认的 Sidecar，自己速度快，资源消耗低。能够直接拿来用，上手超简单，投入少而收益快
• 开发本身的 Golang 版本的 Sidecar，全是劣势：这是一个全新项目，工做量很是大，并且技术上颇有挑战，还有须要自行完成和 Istio 集成的额外工做量以及维护成本，最大的挑战还在于 Envoy 丰富甚至繁多的功能，要向 Envoy 对齐须要很是大的努力

能够说，短时间内看，选择 Envoy 远比自行开发 Golang 版本要现实而明智。

可是，前面咱们有说到，对于 MOSN 项目，咱们有很是宏大的蓝图：准备将原有的网络和中间件方面的各类能力从新沉淀和打磨，打形成为将来新一代架构的底层平台，承载各类服务通信的职责。这是一个须要一两年时间打造，知足将来三五年乃至十年需求的长期规划项目，咱们若是选择以 Envoy 为基础，短时间内天然一切OK，快速得到各类红利，迅速站稳脚跟。

可是：后果是什么？Envoy 是C++的，选择 Envoy 意味着咱们后面沉淀和打磨的将来通信层核心是c++的，咱们的语言栈将不得不为此修改成以c++为主，这将严重偏离既定的 Golang + Java 的语言栈规划。

而一旦将时间放到三五年乃至十年八年这个长度时，选择Envoy的劣势就出来了：

• C++ 带来的开发和维护成本时远超 Golang，时间越长，改动越多，参与人数越多，使用场景越多，差异越明显
• 从目前的需求上看，对 Envoy 的扩展会很是多，包括通信协议和功能。考虑到将来控制平面上可能出现的各类创新，必然须要数据平面作配合，改动会长期存在
• Golang 仍是更适合云原生时代，选择 Golang，除了作 Sidecar，锻炼出来的团队还能够用 Golang 去完成其余各类产品。固然选择 Envoy 也能够这么干，可是这样一来之后系统中就真的都是c++的产品了。
• 另外 Envoy 目前的官方定位只有 Sidecar 一种模式，而咱们规划中的 MSON 项目覆盖了各类服务通信的场景
• 往后如何和 Envoy 协调是个大难题。尤为咱们后续会有很是多的创新想法，也会允许快速试错以鼓励创新，选择 Envoy 在这方面会有不少限制。

因此，最后咱们的选择是：先难后易，着眼将来。忍痛（真的很痛）舍弃 Envoy，选择用 Golang 努力打造咱们的SOFAMosn 项目。

对于一样面临要不要选择 Envoy 的同窗，我给出的建议是：Envoy 是否适合，取决因而不是想“动”它。

• 若是只是简单的使用，或者少许的扩展，那么其实你接触到的只是 Envoy 在冰山上的这一小部分，这种状况下建议你直接选择 Envoy
• 若是你和咱们同样，将 Service Mesh 做为将来架构的核心，预期会有大量的改动和扩展，同时你又不肯意让本身的主流编程语言技术栈中 c++ 占据主流，那么能够参考咱们的选择

固然，对于本来就是以 c/c++ 为主要编程语言栈的同窗来讲，不存在这个问题。

今天的第三部分，给你们介绍一下 SOFAMesh 在落地期间遇到的典型问题。

这里给你们列出了三个主要问题：

1. 通信协议扩展

   前面也刚谈到过，就是咱们会须要支持很是多的TCP协议，包括各类私有协议。固然这个其实更应该归为需求，后面详细展开。

2. 平滑迁移传统架构

   所谓传统架构指的是传统的 SOA 架构，如基于 Dubbo 的不少现有应用，咱们但愿它们可以在 Service Mesh 中直接跑起来，而没必要必定要先进行微服务改造。

3. 适配异构体系

   异构体系指的是，当咱们进行 Service Mesh 落地时，会存在新旧两条体系，好比说新的应用是基于 Service Mesh 开发的，而旧的应用是基于传统框架好比说 Dubbo 或者是 Spring Cloud。

   当咱们作应用迁移的时候，考虑到原来的存量应用会有不少的，好比上千个应用，这些应用确定不可能说一个晚上所有切过去。中间必然会有一个过渡阶段，在这个过渡阶段新旧体系中的应用应该怎么通信，如何才能作到最理想。

   咱们如今正在作方案，就是如今POC中。咱们如今给本身设定的目标，就是但愿给出一套方案，可让现有应用不作代码改动，而后能够在新旧两边随便切，以保证平滑迁移。

   固然这套方案如今正在作POC，方案还未最终定型，因此今天咱们不会包含这一块的细节。你们若是有兴趣的话能够稍后关注咱们的这个方案。

今天给你们主要分享前面两个部分，咱们详细展开。

第一个要解决的问题是如何快速的扩展支持一个新的通信协议。

这个问题主要源于如今 Istio 的设计，按照 Istio 如今的方式，若是要添加一个新的通信协议，是有几大块工做要作的：

• 添加协议的 Encoder 和 Decoder

也就是协议的编解码，这个没得说，确定要加的。

• 修改 Pilot 下发 Virtual Host 等配置

• 修改 Sidecar 如 Envoy，MOSN 去实现请求匹配

后二者是大量重复的，就技术实现而言，须要修改的内容和现有的东西差很少，可是必需要再改出一份新的来。由于咱们协议比较多，由此带来的改动量很是大。根据咱们以前的实践，以这样的方式加一个新的通信协议可能须要几天的工做量，并且每次改动都重复大量代码。

在这里咱们最后给出了一个名为 x-protocol 的通用解决方案，细节咱们这里不展开，只给你们看个结果。根据咱们最新的验证状况，若是咱们要添加一个新的通信协议，大概就是一两百行代码，一两个小时就能完成。即便加上测试，基本上也能够控制在一天以内，咱们就可以为 SOFOMesh 新增一个通信协议的支持。

第二个要解决的问题就是让传统架构的存量应用上 Service Mesh 的问题。

就是刚才说的现有大量的基于 SOA 框架的程序，这些应用以传统的 SOA 方式开发，若是直接挪到 Service Mesh 下，如Istio，会遇到问题：由于 Istio 用的服务注册是经过 k8s 来进行，而 k8s 的服务注册模型和原有的 SOA 模型是不匹配的。

SOA 框架当中，一般是以接口为单位来作服务注册，也就是一个应用里面部署多个接口的，在运行时是一个进程里面有多个接口（或者说多个服务）。其实是以接口为粒度，服务注册和服务发现，包括服务的调用都是以接口为粒度。可是有个问题，部署到 Istio 中后，Istio 作服务注册是以服务为粒度来作服务注册，这个时候无论是注册模型，仍是按接口调用的方式都不一致，就是说经过 Interface 调用是调不通的。

左边的代码实例，你们能够看获得，通常状况下 Dubbo 程序是按照 Interface 来注册和发现，调用时也是经过 Interface 来调用。另外，在这个地方，除了经过接口调用以外，还有另一个问题：服务注册和服务发现的模型，从原来的一对N，也就是一个进程N个接口，变成了要一对一，一个进程一个服务。

怎么解决这个问题？最正统的作法是，是先进行微服务改造：把原有的 SOA 的架构改为微服务的架构，把现有应用拆分为多个微服务应用，每一个应用里面一个服务（或者说接口），这样应用和服务的关系就会变成一对一，服务注册模型就能够匹配。

可是在执行时会有难处，由于微服务改造是一个比较耗时间的过程。咱们遇到的实际的需求是：能不能先不作微服务改造，而先上 Service Mesh ？由于 Service Mesh 的功能很是有吸引力，如流量控制，安全加密。那能不能先把应用搬迁到 Service Mesh 上来，先让应用跑起来，后面再慢慢的来作微服务改造。

这就是咱们实际遇到的场景，咱们须要找到方案来解决问题：注册模型不匹配，原有用接口调用的代码调不通。

咱们设计了一个名为 DNS通用选址方案 的解决方案，用来支持 Dubbo 等SOA框架，允许经过接口名来调用服务。

细节不太适合展开，给你们介绍最基本的一点，就是说咱们会在 DNS 中增长记录，如图上左下角所示标红的三个接口名，咱们会在DNS中把这个三个接口指向当前服务的 Cluster IP。k8s 的 Cluster IP 一般是一个很是固定的一个IP，每一个服务在k8s部署时都会分配。

在增长完DNS记录以后，再经过 Interface 的方式去调用，中间在咱们的 Service Mesh 里面，咱们会基于 Cluster IP 信息完成实际的寻址，并跑通 Istio 的全部功能，和用服务名调用等同。

这个功能在现有的 SOFAMesh 中已经彻底实现，你们能够去试用。稍后咱们会将这个方案提交给 k8s 或者 Istio 社区，看看他们是否愿意接受这样一个更通用的寻址方式。

在这里咱们提出这样一个设想：先上车后补票。所谓”先上车”是指说先上 Service Mesh 的车，”后补票”是指后面再去补微服务拆分的票。好处是在微服务拆分这个巨大的工做量完成以前，提早受益于 Service Mesh 提供的强大功能；同时也可让部署变得舒服，由于不须要强制先所有完成微服务拆分才能上 Service Mesh 。有了这个方案，就能够在应用不作微服务拆分的状况下运行在 Service Mesh 上，而后再从容的继续进行微服务拆分的工做，这是咱们提出这个解决方案的最大初衷。

固然，这里面有比较多的技术实现细节，里面有不少细节的东西实在是不适合在这里一一展开。同时也涉及到比较多的 k8s 和 Istio 底层技术细节，须要你们对 k8s kubeproxy 网络转发方案和 Istio 的实现有比较深的认知才能彻底理解。这里给出了几篇文章，你们若是对这几个技术有兴趣，能够经过这些文章来了解里面的技术细节，今天就不在这里继续展开了。

MOSN 和 x-protocol 介绍：

• Service Mesh数据平面SOFAMosn深层揭秘
• 蚂蚁金服开源Go语言版Service Mesh数据平面SOFAMosn性能报告
• 蚂蚁金服开源的 SOFAMesh 的通用协议扩展解析
• Dubbo on x-protocol——SOFAMesh中的x-protocol示例演示

X-protocol 特性的详细讲解：

• SOFAMesh中的多协议通用解决方案x-protocol介绍系列(1)-DNS通用寻址方案
• SOFAMesh中的多协议通用解决方案x-protocol介绍系列(2)-快速解码转发
• SOFAMesh中的多协议通用解决方案x-protocol介绍系列(3)-TCP协议扩展

总结一下，咱们解决了以下几个问题：

1. 能够快速的用几个小时就在 SOFAMesh 中添加一个新的通信协议
2. 可让 SOA 应用在 SOFAMesh 上继续经过接口进行调用，不须要改代码
3. 能够实现不作 SOA 程序的微服务改造，就直接搬迁到 SOFAMesh，提早受益

第四块，涉及到流量劫持的方案。

Service Mesh 有一个很重要的特性，就是无侵入，而无侵入一般是经过流量劫持来实现的。经过劫持流量，在客户端服务器端无感知的状况下，能够将 Service Mesh 的功能插进去。一般特别适合于相似安全加密等和现有应用的业务逻辑彻底分离的场合。

但 Istio 的流量劫持方案作的还不够好，目前 Istio 只给了一个方案就是 iptables。这个方案有比较多的问题，因此咱们有几个思路：

1. 优化 iptables

   优化 iptables 主要是为了减小对Host主机的影响。

   用 iptables 有两种思路：一个是 pod only，就是说在pod里面作 iptables，这个Istio的官方作法，可是这样须要ROOT权限以便修改iptables配置；还有一种思路用Host主机上的 iptables，这个话能够不用ROOT权限。咱们对比以后，仍是以为放在pod里面更好一点，由于性能损耗比较小一些，因此暂时咱们用的是在pod中方案，但咱们会进行优化，好比把 iptables 的模块简化到最小。

2. 调研IPVS方案

   咱们如今正在调研IPVS方案。主要是 iptables 方案存在部署问题，就是 iptables 这个模块常常被限制使用。现场有没有作运维的同窗？大家的机器上开启了 iptables 吗？我能告诉你们的是，到目前为止，蚂蚁金服内部的机器上，iptables不只仅是禁用，而是整个 iptables 模块都被卸载。缘由是性能、安全、维护等你们周知的缘由，总之咱们蚂蚁金服内部是没有这个模块的。

   为了解决这个问题，咱们如今正在调研IPVS的方案，准备用IPVS来替换 iptables。这块工做正在进行，目前方案已经验证，可是还有一些细节没有完善，后面有更多的消息也给你们继续介绍。

3. 轻量级客户端的实践

   另外还有一个实践是考虑不作流量劫持。好比说，最典型的RPC方案，由于RPC一般来讲老是会有一个客户端的。在上 Service Mesh 以后，能够将原来的客户端的一些功能如服务发现、负载均衡、限流等精简，造成一个新的轻量级客户端，但此时终究仍是有一个客户端在的。

   这个时候，若是能知道 Sidecar 的访问地址，是能够不进行流量劫持的，由客户端直接将请求发给 Sidecar 就行了。因此，最基本的想法就是经过环境变量或者配置给出 Sidecar 的地址，告诉客户端 Sidecar 就在 localhost 的8080端口。而后客户端SDK简单读取一下，接下来直接将请求发过去就行了。这个方案能够轻松的绕开流量劫持的问题。

   这个方案咱们内部也实践过，早期用来替代多语言客户端的版本用的是这个方案。固然，实践中发现流量劫持仍是有必要的，这是另一个话题，后面有机会再详细解释。

但上面这三个都不是今天的重点，今天的重点是下面这个 Cilium + eBPF 的思路，这是咱们目前最密切关注的一个方案。

Cilium是一个很新的项目，Cilium的思路中会涉及到底层通信中TCP堆栈的问题。

这里的图片显示了用 iptables 和轻量级客户端方案的网络调用细节，左边是客户端 Service 和它的 Sidecar 之间的调用过程，能够看到它走了两次的TCP堆栈。而后还有 iptables 的拦截。轻量级客户端方案和流量劫持方案的差异在于减小一次iptables，避开了iptables的性能消耗。可是即便没有 iptables，最终仍是要走整个调用流程，虽然 Loopback 环回地址比network 网络通信快不少，可是它终究仍是走了两次TCP堆栈，两次TCP堆栈这里是有性能消耗的。

而Cilium则给出了一个很好的思路：想办法绕开TCP堆栈。

Cilium方案的好处，就在于在 socket 这个层面就完成了请求的转发，经过 sockmap 技术实现 redirect，固然这个技术细节我们就不在这里展开。今天主要是讲一下这个思路的好处和价值。Cilium 方案最大的好处，是能够绕开两次TCP堆栈，绕开两次TCP堆栈的好处，则会带来一个出乎意外甚至违背常识的结果：Cilium 劫持能够比轻量级客户端不劫持更快！这可能颠覆你们的观念。

咱们来体会一下。流量劫持，如 iptables，是要在原来的调用链当中插入一段，增长消耗致使性能降低，对吧？这是流量劫持最容易给人的留下的负面印象，就是流量劫持是有消耗的，因此优化的思路一般都在于减小这个消耗，或者选择不作劫持从而避开这个消耗。那 Cilium 的作法则是给出另一种解决流量劫持问题的思路：经过绕开两次TCP堆栈和其余底层细节，更快的将请求转发给 Sidecar！

Cilium的这个思路是咱们很是赞扬的，经过这样的方式减小服务和 Sidecar 之间的性能损失，能够解决 Service Mesh 中相当重要的一个问题：性能与架构的取舍。

熟悉 Service Mesh 技术的同窗，应该多少都有这样的认知： Service Mesh 是一门中庸的艺术。在性能与架构之间， Service Mesh 选择牺牲性能来换取架构。在传统的侵入式框架中，客户端业务代码和框架代码之间是经过函数来进行调用的，速度很是快彻底能够忽略。而 Service Mesh 是强行把框架和类库剥离出来，将上述的方法调用变成一个远程调用，以牺牲了一次远程调用的开销为代价来换取整个架构的优化空间。这是 Service Mesh 技术和传统侵入式框架的一个本质差别，也是 Service Mesh 技术和传统侵入式框架全部差别的源头。

这是 Service Mesh 技术最为重要的一次取舍：舍弃一次远程调用的开销，换取更富有弹性的架构和更丰富的功能。

Service Mesh 技术的发展，也由此出现两个大方向：一方面是继续在架构上获取好处，更多的功能，更丰富的使用场景，各类创新，竭尽量的获取红利；另外一方面，是在舍字上下功夫，尽量的将性能损失降到最低，以求获得前面的最大好处而将付出的代价降到最低。

咱们在前面列出的这四个实践，均可以说是在这条贪心的路上一步一步的探索和尝试，但愿能够将 Service Mesh 架构上的舍弃的部分再尽量多的要回一部分。

固然，Cilium 在实际落地的时候仍是会有一些问题，好比说如今最大的问题是 Cilium 对 Linux 内核的版本要求特别高，最低要求是4.9推荐4.10，而后里面的部分特性要求是4.14。Linux 内核4.14是2017年末才发布的，而目前 Linux 内核最新版本才4.18。Cilium 要求的 Linux 内核的版本实在太新了，部署时很难知足。另外就是 Cilium 仍是存在一些安全问题，主要是 eBPF 是将代码直接注入到内核运行，效率好是好，可是确定会存在安全隐患。

咱们接下来会重点跟踪 Cilium 技术，也有可能会给出其它的相似方案，有兴趣的同窗能够关注咱们的进展。

继续给你们介绍今天的第四部份内容，对服务间通信范围的探索。

Service Mesh 起初关注的是东西向通信，即系统内部各个服务之间的通信，而这一般都是同步的，走REST或者RPC协议。

在Service Mesh的实践过程当中，咱们发现，Service Mesh 能够提供的功能：

• 请求转发：如服务发现，负载均衡等
• 路由能力：如强大的 Content Based Routing 和 Version Based Routing
• 服务治理：基于路由能力而来的灰度发布，蓝绿部署，版本管理和控制
• 纠错能力：限流，熔断，重试，测试目的的错误注入
• 安全类：身份，认证，受权，鉴权，加密等

能够适用于 Service Mesh 以外的其余领域，也就是说咱们能够在其余领域引入并重用这些能力，实现比单纯的东西向通信更普遍的服务间通信。

第一个探索的方向是 API Gateway，和东西向通信直接对应的南北向通信。

主要缘由是南北向通信和东西向通信在功能上高度重叠，如服务发现，负载均衡，路由，灰度，安全，认证，加密，限流，熔断……所以，重用东西向通信的这些能力就成为天然而然的想法。

传统侵入式框架下，重用这些能力的方式是基于类库方式，也就是在 API Gateway 的实现中，典型如 Zuul，引入东西向通信中的类库。而 Service Mesh下，思路有所不一样，重用的再也不是类库，而是 Sidecar：经过将 Sidecar 用于南北向通信，重用 Sidecar 的请求转发和服务治理功能。

将 Service Mesh 引入 API Gateway 的优点在于:

• 统一微服务和 API Gateway 两套体系
• 大量节约学习/开发/维护的成本
• 能够在南北向通信中得到 Service Mesh 的各类特性
• 能够经过 Service Mesh 的控制平面增强对南北向通信的控制力

这个方向上，业界也有一些探索：

• Ambassador: Kubernetes-native microservices API gateway，基于Envoy构建，开源项目
• Gloo: The Function Gateway built on top of Envoy，一样是基于Envoy，不过这个不只仅用于传统的微服务API Gateway，也能够用于Serverless架构的Function
• Kong：在最近宣布，即将发布的1.0版本，kong将再也不是单纯的 API Gateway，而是转型为服务控制平台。可谓是一个反向的探索案例：从 API Gateway 向 Service Mesh 切。

而咱们的思路也很是明确：在 SOFAMesh 和 SOFAMosn 的基础上，打造新的 API Gateway 产品，以此来统一东西向通信和南北向通信。目前该项目已经启动，后续也会做为开源项目公布出来，对这个话题有兴趣的同窗能够保持关注。

前段时间咱们在考虑 Serverless 方向时，恰好看到 Google 新推出了它的 Serverless 新项目 Knative，时间点很是的巧。和其余 Serverless 项目不一样的是，Knative 项目关注的是 Serverless 平台的标准化和规范化。

Knative 项目是基于 kubernetes 和 Istio 的，在 Knative 中 Istio 用于实现部分组件之间的通信。在 Knative 项目中，对因而否应该引入 Istio 存在很大争议，由于以为 Istio 过重了，为了少许需求引入 Istio 有些兴师动众。不过这个问题对于原本就已经在用 Istio 的咱们来讲不是问题。

目前在 Serverless，尤为 Knative 方面，咱们还在探索，目前的初步想法是这样：

• Serverless 很重要

  尤为 Knative 的出现，昭示着 Serverless 领域新的玩法出现，Serverless 平台出现标准化和统一化的契机

• Kubernetes + Serverless + Service Mesh（尤为是扩展范围以后的 Service Mesh）是一个很好的组合

  从下向上，从底层基础设施到服务间通信再到 Function，在应用和系统之间造成了一套完整的支撑体系。

后续咱们的产品策略，会继续深刻调研 knative，一边POC一边规划产品，固然结合实际业务须要以落地为目标依然是基本要求。而后，很是天然的，咱们会将标准版本的 Istio 替换为咱们的 SOFAMesh 和 SOFAMosn。

举例，目前咱们在计划尝试使用 Serverless 的典型场景：

• 小程序
• AI：Serverless AI Layer，一站式机器学习平台
• Databus： 大数据处理

这是咱们目前探索和规划中的服务间通信的完整蓝图：

• Service Mesh

  负责东西向通信，实践中就是咱们的 SOFAMesh 产品，基于 Istio 的扩展加强版

• API Gateway

  负责南北向通信，还在探索中，咱们在尝试基于 SOFAMosn 和 SOFAMesh 开发新的 API Gateway 产品

• Serverless

  负责异步通信，事件驱动模型，粒度也从服务级别细化到Function级别，目前在积极探索和实践 knative

这里给出一个咱们的预测：在云原生的时代，服务间通信的将来都会是 Service Mesh 这种方式，将服务间通信的职责剥离并下沉。

这是今天的最后内容。前面四个部分的内容基本上都是给你们介绍咱们的产品实践，落地遇到的问题，以及咱们正在作的一些探索，比较偏实际。第五部分会特殊一点，可能就有点务虚了。这块要讲是在过去一年当中，在项目落地的过程当中的特别感觉，其中最关键的一点就是基础设施和服务网格之间的关系，或者说基础设施对服务网格的意义。

里面有一个时代背景：Cloud Native，云原生。而在今年6月，CNCF 技术监督委员会经过了 Cloud Native 的定义，中文翻译如上。

这里咱们将关注点放在标红的这一句来：云原生的表明技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

对于云原生架构，蚂蚁金服的策略是：积极拥抱! 咱们将来的架构也会往这个方向演进。

对于前面列举的云原生表明技术：

• 容器：大阿里在容器技术上有很是深度的积累，实践多年，而新版本的 Sigma3.* 版本也将基于 k8s。
• 微服务：微服务的前身，SOA 服务化，在大阿里也是实践多年， Dubbo / HSF / SOFA 可谓名满江湖，目前也在陆陆续续的微服务改造中。
• 不可变基础设施和声明式API：也是高度承认和长期实践的技术。

对于Service Mesh的定位，咱们是这样理解的：

• Service Mesh 是承上启下的重要一环
• 一方面充分利用底层系统能力
• 一方面为上层应用提供坚实的底座

对于 Service Mesh，咱们有一个重要判断，这也是今天最想和你们分享的一点：Service Mesh 的归宿，或者说最终的形态，是下沉到基础设施！

从 Service Mesh 的发展看，从简单的 Proxy，到功能完善的Sidecar（如Linkerd和Envoy），再到以 Istio 为表明的第二代Service Mesh，演进的方式如上图：

1. 第一步：从应用剥离

   经过将原有的方法调用改成远程调用，将类库的功能套上 Proxy 的壳子，Service Mesh 成功的将服务间通信从程序中剥离出来，今后服务间通信再也不是应用程序的一部分。

   这一点是你们最容易接受的，对吧？这一步也是最容易实现的，只要搭起来一个 Sidecar 或者说 Proxy，将原有类库的功能塞进去就行了。

2. 第二步：下沉为抽象层

   这些剥离出来的服务间通信的能力，在剥离以后，开始下沉，在应用程序下造成一个单独的抽象层，成为服务间通信专用基础设施层。此时，这些能力以一个完成的形态出现，再也不存在单独的类库或者框架形式。

   第二步和第一步每每是一脉相承的，一旦走出了第一步，天然而然会继续。由于服务间通信被抽取出来以后，继续往前发展，就会很天然地把它就变成一个基础设施层。

3. 第三步：融入基础设施

   继续下沉，和底层基础设施密切联系，进而融为一体，成为平台系统的一部分，典型就是和 kubernetes 结合。

   Istio在这方面作了一个很是大的创新，Istio的创新，不只仅在于增长控制平面，也在于和 kubernetes 的结合。

若是你们有在去年QCon听过个人演讲，会发现我在去年的时候对 Service Mesh 的理解和如今不太同样。在去年的这个时候，我认为 Istio 最大的创新是增长了控制平面。可是，今年我以为还再加一个关键点，除了控制平面的增长以外，Istio很重要的一点是开始跟k8s融合，充分利用 k8s 的能力。k8s 表明的是底层基础设施，全部的各类能力在k8s上沉淀。在Istio上，已经可以看到这样一个很是明显的趋势： Service Mesh 已经开始和底层基础设施密切联系，融为一体，成为整个平台系统的一部分。

你们注意体会这中间的细微差别，第一步和第二步，将服务间通信的能力抽取出来沉淀成一个抽象层，而若是止步于第二步的话，这个抽象层和底层基础设施是没有任何关系的。注意，好比说 Linkerd 或者 Envoy，在部署的时候，无论是物理机、虚拟机或者容器，都没有任何关系，自己也不利用底层的任何能力，可谓泾渭分明。可是一旦演进到了Istio，包括如今的Linkerd 2.0，就会发现转为第三步的这种形态。

今天想跟你们说的是，Service Mesh 的将来，是将服务间通信的能力下沉到基础设施，而后充分利用底层基础设施的能力来架构整个体系。而再也不将底层基础设施抽象成为就是一个简单的操做系统抽象：给我cpu，给我内存，给我网络，给我IO，其余的事情和底层没有任何关系，我本身上面所有搞定。这个思路在 Service Mesh 的将来发展中是不合适的， Service Mesh 将来必定是经过和基础设施融合的方式来实现。

注意这个方式跟传统方式的差别，不只仅在于技术，而是这个方式会混淆两个传统的部门：一个叫作中间件，就像我所在的部门，或者有些公司叫作基础架构部门；还有一个部门一般是运维部门或者叫作系统部门，负责维护底层基础设施。大部分公司通常这两个部门在组织架构上是分离的。作k8s的同窗，和作微服务框架好比 Dubbo，Spring Cloud 的同窗，一般是两个不一样的组织架构，彼此泾渭分明。第三步要走通的话，就会要求中间件部门和基础设施部门关系要协调的特别好，要密切的合做，才能将事情作好。

这是在过去这一年当中，咱们在实践中获得的最大的一个感觉，也是今天整个演讲中最但愿给你们分享的内容。

这里抛出一个问题，和传统的 Spring Cloud，Dubbo等侵入式框架相比：

Service Mesh的本质差别在哪里？

若是去年的我来回答这个问题，那我会告诉你：下移，沉淀，造成一个通信层。而今天，我会告诉你们，除了这点以外，还有第二点：充分利用底层基础设施。这是Dubbo，Spring Cloud历来没有作到的！

这是今天最想和你们分享的观点，也是过去一年实践中最大的感悟：

Service Mesh 和 Spring Cloud / Dubbo 的本质差别，不只仅在于将服务间通信从应用程序中剥离出来，更在于一路下沉到基础设施层并充分利用底层基础设施的能力。

最后，咱们总结一下今天的内容：

• 给你们介绍了一下咱们的 SOFAMesh 项目，若是你们有计划应用 Service Mesh 技术，想上 Istio，能够尝试了解一下咱们的这个项目，会让你们落地更舒服一些
• 其次给你们介绍了选择 Golang 的缘由，主要是由于语言栈的长期选择。若是有正在进行 Service Mesh 技术选择的同窗，能够做为参考。若是和咱们同样，更愿意在将来保持 Golang 和 Java 为主要语言栈，则能够参考咱们的方案，固然咱们更但愿大家能够和咱们一块儿来共建 SOFAMesh 这个开源项目
• 而后给你们分享了咱们遇到的几个典型问题，如何快速的支持更多通信协议，如何让传统的SOA架构的应用程序在不进行代码修改的状况下也能从 Service Mesh 中受益，实现系统的平滑迁移。对于准备实际落地的同窗会有帮助，因为时间所限未能将细节展开，你们能够会后查看资料或者直接找咱们交流
• 对服务间通信的范围进行了探讨，从原有的东西向通信，扩展到南北向通信，还有在 serverless 项目中的使用。但愿可以让你们了解到 Service Mesh 技术能够应用的更多场景。
• 最后谈了一下切身感觉：Service Mesh 技术要想彻底发挥做用，须要和底层基础设施融合，以充分发挥基础设施的能力。这块的认知，会影响到 Service Mesh 的技术选型，产品方案，甚至影响组织关系。可谓相当重要，但愿每位有志于此的同窗能认认真真的审视这个问题。

Service Mesh 是一个新生事物，新事物在刚出现时老是会遇到各类挑战和质疑，尤为在它自身还不够彻底成熟的时候。而Service Mesh 背后的Cloud Native，更是一场史无前例的巨大变革。

咱们心怀美好愿景，憧憬将来的 Cloud Native 架构，那里有咱们的 Service Mesh，有k8s，有微服务……而新的架构，新的技术，历来都不是能一蹴而就的，更不存在一路顺风之类的美好而天真的想法。

道路历来都是人走出来的，或者说，趟出来的。做为国内 Service Mesh 技术的先驱者，咱们坦言 Service Mesh 技术还不够成熟，还有不少问题等待解决，还有很是多的挑战在前面等着咱们。但咱们有信心相信，咱们的方向是正确的，咱们今天的每一份努力，每一份付出，都在让咱们离目标更近一步。

鲁迅先生说：地上本没有路，走的人多了，也便成了路。在 Service Mesh 的这个方向，相信会出现愈来愈多努力探索的身影。这条路，咱们终究会努力趟出来！

长路漫漫，吾辈当踏歌而行！

目前 SOFAMesh 和 SOFAMosn 项目都已经在 github 开源，地址以下：

• sofa-mesh: github.com/alipay/sofa…
• sofa-mosn: github.com/alipay/sofa…

欢迎你们关注这两个项目的进展，若是能star一下表示支持就更好了，感激涕零！

更但愿能够一块儿来参与这两个项目的建设，期待Issue，期待PR！

对 Service Mesh 技术感兴趣的同窗，能够关注servicemesher社区，这是一个中立的纯技术社区，聚集了当前国内大部分 Service Mesh 的技术人员。我本人也是 servicemesher 社区的创始人之一，这个社区的使命是传播 Service Mesh 技术，增强行业内部交流，促进开源文化构建，推进 Service Mesh 在企业落地。

能够经过访问社区网站 www.servicemesher.com 获取各类技术资讯和社区活动信息，能够关注 ServiceMesher 社区的微信公众号获得及时的信息推进。咱们拥有一个庞大的翻译组，除了翻译各类 Service Mesh 相关的技术博客和新闻，还负责 Envoy 和 Istio 两个项目官方文档的平常维护。

也欢迎你们加入 ServiceMesher 社区的微信交流群，请按照 servicemesher.com 网站的 “联系咱们” 页面的要求加入微信交流群。

最后，厚颜推荐一下我本身的我的技术博客 skyao.io ，欢迎浏览和交流。

今天的内容到此结束，很是感谢你们的聆听，有缘下次再会！谢谢你们！

做者介绍

敖小剑，资深码农，十六年软件开发经验，微服务专家，Service Mesh 布道师，Servicemesher.com 社区联合创始人。专一于基础架构和中间件，Cloud Native 拥护者，敏捷实践者，坚守开发一线打磨匠艺的架构师。曾在亚信、爱立信、惟品会等任职，目前就任蚂蚁金服，在中间件团队负责 Service Mesh 等产品开发。

ServiceMesher社区信息

微信群：联系我入群

社区官网：www.servicemesher.com

Slack：servicemesher.slack.com 须要邀请才能加入

Twitter: twitter.com/servicemesh…

GitHub：github.com/

servicemesher

更多Service Mesh咨询请扫码关注微信公众号ServiceMesher。