随着云计算的快速发展，软件开发的方式也从传统的单体应用过渡到了SOA及时下流行的微服务。软件方式的转变也催生了一些新的技术发展，Service Mesh 就是在此环境下诞生的新的热点技术。
当互联网架构面临数据量，高并发、高可用场景几何增长的情况，Service Mesh可以在其中发挥什么样的作用？什么样的场景适合使用Service Mesh？如果有需要使用，又将如何来实现Service Mesh呢？…针对上述问题，InfoQ记者在ArchSummit 全球架构师峰会（深圳站）2019的现场采访了同程艺龙研发中心架构师雷飞尉。
什么是Service Mesh？
什么是Service Mesh呢？目前业内公认的是Linkerd CEO Willian Morgan 对Service Mesh的定义，即Service Mesh是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，Service Mesh保证请求可以在这些拓扑中可靠地穿梭。在实际应用当中，Service Mesh通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但应用程序不需要知道它们的存在。
Service Mesh定义中有这么多关键词，那么到底什么才是最关键的呢？在雷飞尉看来，Service Mesh最关键的部分在于设计时所定义的服务模型。Service Mesh 模型设计不仅有服务的概念，还会有环境的概念，而这些概念的提出会使得Service Mesh系统不再是一个普通的提供服务发现、负载均衡等功能的服务治理框架， 我们可以依此实现强大的服务环境间路由功能, 让7层的服务间调用也能像3层的IP报文一样路由起来。
如果我们把之前经典的服务发现+RPC的服务治理框架看作是服务治理1.0的话，那么Service Mesh技术就可以称为服务治理2.0，它是业界基于之前的服务治理实践总结出来的全新思路。
Service Mesh实际上是在解决什么问题呢？雷飞尉认为Service Mesh主要解决的就是服务间调用解耦的问题。
在没有Service Mesh之前，服务间调用要么写死IP地址，要么写死域名，但是这些方案太死板了，写死域名虽然比写死IP地址稍微灵活一点点，但由于各种历史包袱，很多DNS解析库对域名的处理并不规范，典型的就是忽略域名的TTL导致不能快速变更域名的IP地址列表。
第一代服务发现+RPC的服务治理框架虽然解决了最基本的IP地址调用的问题，但是对于多环境间的请求路由要么完全没有考虑，要么非常不灵活，这就造成很多业务为了实现A/B 测试或泳道发布，不得不多写很多专门的代码。而Service Mesh在请求路由的层面进一步解耦了服务间调用，使得以前需要每个业务专门写代码处理的问题，有了一套通用而且业务无关的解决方案。
Service Mesh的实现方式
目前业内比较流行的Service Mesh开源软件有Linkerd、Envoy、Istio、Conduit、nginMesh和 Kong。
其中Istio是Service Mesh比较经典的实现方式，它是由 Google、IBM 和 Lyft 联合开发，于2017年5月24日首次发布。Istio在逻辑上可以分为数据层和控制层，数据层是由一组智能的代理（Envoy）构成，负责协调和控制服务间的所有网络的通信，而控制层负责管理和配置路由转发流量，就是运行时实施的策略。
上图是Istio的架构图，从图中我们可以看到Istio的核心组件主要包括Proxy代理、Mixer混合器、Pilot引导、Citadel堡垒和Galley。其中，Proxy代理的代理组件主要是Envoy，用来拦截所有想拦截的流量；Mixer混合器混合了各种策略以及后端数据采集或遥测系统的适配器，实现了前端Proxy与后端系统的隔离与汇合；Pilot引导提供了一系列rules api，允许运维人员指定一系列高级的流量管理规则；Citadel堡垒管理着集群的密钥和证书，是集群的安全部门；Galley主要是用来验证用户编写的Istio api配置。
作为经典的Service Mesh实现方式，Istio在架构设计和服务模型设计方面都没有问题，但也不是完全完美。雷飞尉表示：“Istio因为出现时间较短，所以有很多场景没有覆盖到，例如跨地域的Service Mesh，Istio的实现方案暂时不是那么漂亮；而多环境路由方案由于可能要侵入业务， Istio 暂时也没有提出统一的解决方案。”
Service Mesh的实践价值
Service Mesh作为一种新兴的技术，哪些企业适合使用呢？对于企业来说有哪些价值？落地过程中又会存在哪些问题呢？
雷飞尉认为Service Mesh适合所有的IT公司使用，只要其业务规模已经大到需要拆分为不止一个服务，那么就需要服务治理，就应该使用Service Mesh技术。
Service Mesh的价值主要体现在三个方面，一是增强了业务服务的快速故障恢复能力，例如当某个业务实例出现故障可以自动健康检查剔除掉，又或者整机房出现故障，只需要一句select语句更新一下即可；二是增强了业务服务的快速迭代能力，业务可以通过Service Mesh轻松实现小流量功能，这样业务验证的速度就非常快；三是节省了大量硬件和人力成本，基于Service Mesh的泳道发布方案把硬件资源的耗费降到了最低，同时也把人力配置和沟通的成本降到了最低。
当然，任何事情都是机遇与挑战并存，所以Service Mesh在企业落地时也会存在很多挑战。“Service Mesh在落地时最大的挑战在于存量业务”，雷飞尉认为：“存量业务由于历史原因往往会使用一些比较老的服务间调用方案，如写死IP地址或者域名，在这种情况除了改造业务别无他法。”
如果企业存量业务使用了服务发现+RPC这样的第一代服务治理方案，那么可以使用Service Mesh的服务发现 + Sidecar去兼容以前的RPC协议。通过这种方式，我们可以以最小的修改代价将该存量业务升级到Service Mesh，业务只需要进行重新编译，如果该业务暂时用不到Service Mesh的流量路由功能， 甚至都可以不用编译，无缝接入。
同程艺龙的Service Mesh实践
同程艺龙的Service Mesh实践可以追溯到2016年底，当时同程艺龙技术团队研发了一个服务发现系统，之后基于此系统不断外延，形成了一个完善的、自研的Service Mesh系统。雷飞尉表示：“Service Mesh是所有业务系统的底层支持技术，如果Service Mesh垮了，那么全公司的业务都会受影响，轻则不能变更配置，重则损失全部用户流量。所以，在技术选型时，我们没有直接使用Istio，而是选择了自研Service Mesh系统，并且在应用时提前准备了处理各种故障场景的预案，设计层层保底方案。”
Service Mesh系统不仅可以处理传统的服务发现、负载均衡等应用，更为关键的是其拥有7层路由功能，基于此功能，同程艺龙开发了可同时支持几百个泳道发布的泳道发布系统，并将人力成本降到了最低。
以推荐功能为例，由于同程艺龙的酒店业务本质上是一个垂直搜索引擎，搜索结果中的推荐位就很关键，向用户推荐什么样的酒店直接关系到用户体验，所以必须要做大量的A/B测试来验证模型的效果。
雷飞尉把同程艺龙酒店业务推荐功能的Service Mesh应用分成了三部分：
第一部分：Service Mesh刚刚上线，业务同学不认可，怎么办？这时就要考虑谁是最需要Service Mesh的人，当然是运维同学，他们需要维护nginx、lvs、RPC等各种负载均衡系统，而Service Mesh中刚好有服务发现功能。所以，我们首先解决了运维同学统一维护负载均衡系统的upstream列表的需求，把所有服务导入到Service Mesh上，再由Service Mesh去对接nginx/lvs/RPC等各个系统。通过这样的方式，运维同学不再需要配置nginx、lvs、RPC等多个系统，只需在Service Mesh系统上统一维护每个服务的IP列表。
第二部分：接下来，我们做的是业务系统直接对接Service Mesh的Sidecar，这种方式可以省掉对接nginx的开销。这一部分会比较难一点，因为Sidecar要过流量，大家的疑虑就会大一些。针对此，我们的方案是稳扎稳打，按灰度发布的路子稳步推进。
第三部分：业务对接Java Agent，这是我们设想中的Service Mesh完全体，只有这样才能实现最灵活的Service Mesh的动态流量调度功能。 我们的方案是配合发布系统来做这件事， 直接把Java Agent内置于JVM中。这样，随着业务不断迭代发布，就把Java Agent带到了线上。Java Agent上线以后，Service Mesh的作用就能得到充分发挥，极大的方便了A/B测试，业务可以在整个调用链的任意一点创建多个灰度环境，并把多个环境串联起来，同时进行多个A/B测试。通过这种方式，模型验证的效率得到了极大的提高。
写在最后
Service Mesh虽然现在热度很高，但是其在企业当中的实践还处于起步阶段，对于其实践价值，很多企业也存疑。作为Service Mesh实践的先行者，雷飞尉表示：“前面的风景真的很好，我们还想继续往前走！”
谈到Service Mesh未来的发展方向，雷飞尉表示：“无论如何演进，Service Mesh的基本架构都逃不脱控制平面和数据平面这两部分。控制平面本质上是个存储系统，所以其演进基本就是在一致性和可用性上做平衡；而数据平面主要是在高效率和低侵入性方面做平衡。例如，Sidecar虽然是数据平面的典型方案，但并不是唯一方案，RPC框架也可以做数据平面，且效率会更高，但相对的侵入性也更高。”