想要回答“为什么需要 Service Mesh”这个问题，首先得弄明白 Service Mesh 是什么。关于 Service Mesh 的定义，业界似乎已经达成了共识：Service Mesh 是云原生服务通信的基础设施。在黄俊看来，Service Mesh 最关键的部分是将服务通信管理能力从业务应用中剥离下沉至基础设施的思想与实现。

其次，Service Mesh 主要是解决什么问题？“透明无侵入是 Service Mesh 的最大特性。”黄俊表示，“Service Mesh 可以提供服务间一致可见性和网络流量控制，无需修改业务程序代码，即可获得管控服务通信流量与层级观测的能力。”

Service Mesh 主要解决的是传统意义上的“服务治理”，覆盖服务间流量、容错、安全控制和全面遥测。传统的主流解决方法是使用 SDK 类库的方式显式地对业务应用程序进行改造，但是这种方式在提供能力的同时，也带来了相应的维护和使用成本，从而间接影响业务开发迭代的效率，例如，开发团队需要感知并掌握治理框架、需要持续改造应用程序、对开发语言、对主被调服务接入 SDK 版本有依赖等等。而 Service Mesh 的出现，从网络层面自下而上地提出了更好的解决方案与实现，基于服务通信基础设施的定位和无侵入的特性，Service Mesh 可对业务开发透明地提供“服务治理”能力。

在企业技术部门中，黄俊认为开发与基础运维团队应该要格外关注 Service Mesh，并且关注的侧重点还有所不同：

• 因为无侵入的特性，开发团队是感知不到 Service Mesh 的存在，因此在开发业务过程中，开发团队几乎不需要作任何适配，只需在服务部署上线后，直接下发指令与配置，对通信进行管控和查看观测数据。简而言之更偏向于“用”，Service Mesh 提供的能力作为工具为开发团队服务。

• 对于基础运维团队而言，Service Mesh 已经成为 PaaS 基础设施的一部分，在“用”的基础上，还要做好“维护”工作，保证 Service Mesh 控制面与数据面的稳定性与可靠性会是重点工作。除此之外，部分大型企业还要为业务团队打造定制化 Service Mesh 工具，包括集成企业自身发布系统、Devops 流程、环境治理平台、微服务治理平台等等。

早期，腾讯自研业务在内部做服务化拆分与部署时就已经在尝试应用 Service Mesh 相关技术来解决服务通信间的路由、容错、限流与监控。当时，腾讯内部多个业务线都有同类工具类落地，不过，都还停留在业务框架层面。近年，随着容器化技术的广泛应用，腾讯自研业务中也逐渐落地了 K8s，Service Mesh 才在腾讯的部分业务中有了真正意义上的落地，例如游戏、社交、工具平台等业务。

为了更清楚的阐述腾讯 Service Mesh 实践，我们将重点介绍一下其是如何利用 Service Mesh 进行后台环境管理。

腾讯后台环境具有多租户、多分支、多环境的业务特点，需要高精度自定义通信流量管控，可实现动态配置不同租户（用户）请求依赖任意指定环境中的指定分支版本，同时支持在流量层面隔离租户依赖环境。

在技术选型方面，腾讯采用了 Istio+K8s 来实现后台环境的管理。Service Mesh 也有很多实现方式，为什么会选定 Istio + K8s 呢？黄俊解释主要是出于两方面考虑：

• K8s 已经成为容器编排平台的事实标准，是 CNCF 与业界公认的云原生生态中枢。从广义上讲，Service Mesh 不依赖 K8s，Service Mesh 也不关心服务所运行的计算平台，但是与 K8s 结合能更完整地发挥 Service Mesh 的优势，K8s 的服务（负载）生产到 Mesh 的服务发现与通信接管可以是个自动化的过程。另外，业务容器化也是云原生的必选项。

• 选择 Istio 的主要原因是社区大势，Istio 与 K8s 原生集成，源自同一个团队。Istio 是对 K8s 服务通信管控能力的建设与完善，更像是 K8s 的下一个迭代。Google Cloud 的 CTO 还曾经预估过，未来两年内会有 90% 的 K8s 用户使用 Istio。在 Istio 已经定义了 Service Mesh 的事实标准，XDS v2 已经成为了 Service Mesh 通信的标准数据模型和协议的情况下，选择 Istio 不仅可以服务更多客户，而且可以完善基于 K8s 的容器服务平台。

据黄俊介绍，腾讯基于 Service Mesh 的后台环境管理实践可以分成 3 个阶段：

第一阶段：解决研发过程中开发调试与测试的冲突，开发测试环境与测试环境分离。这一阶段只要一次性把几套固定的环境搭建出来即可，但是一套环境中经常会出现相互冲突，例如测试同学之间的环境冲突。

第二阶段：一键自动化建立全新的测试环境，保证每个人在需要时，都有自己的开发测试环境。这一阶段，主要做了两部分工作：一是把环境进行容器化以便更好地做服务编排，K8s 能够让每个后台服务的搭建变得容易简单；二是对后台请求做精细化的路由管理，我们对 Istio Envoy 中的源码做了很多改造工作来支持更多的私有 RPC 协议。

第三阶段：结合 DevOps、CI/CD 以及自动化测试，在这一阶段，后台环境的持续部署能力将提升整体研发效能。

利用 Istio+ K8s 实现的后台环境管理，不仅降低了多种后台异构带来的环境成本，而且提升了研发测试过程的效率，根据黄俊的介绍整个实践过程的难点主要集中在以下三点：

支持私有 RPC 协议：Istio 不支持私有 RPC 协议的流量管理，而测试开发环境管理的核心就是需要 Istio 支持私有 RPC 协议流量的管理，同时，我们希望复用 Istio 原生的能力，而不是重复造轮子。

解决方案： 利用 Istio 支持的 HTTP/gRPC 作为私有协议数据的传输隧道，同时将需要作为流量管理的信息暴露到 HTTP/gRPC header（例如：染色信息）。

支持私有名字服务：私有协议改造后，下发的 HTTP/gRPC 路由规则不生效，host 匹配失败，即私有名字服务解析到的 POD IP 无法匹配 ServiceName、ServiceIP 以及域名。

解决方案：在 Istio-proxy 的服务发现逻辑中记录 Service 和 POD IP 的映射关系，具体流量解析时，再通过 POD IP 反查该 POD 所属的 ServiceName，将反查值作为 host 字段。

支持流量转发给本地 POD IP：Istio-proxy 流量拦截后，透传给相同 POD 下的业务服务时，目标地址为 127.0.0.1，而业务监听的 socket 基本为 POD IP，链路不通。

解决方案： 将下发的终点 socket_address 由 127.0.0.1 改为当前 POD 的 ip 地址，不过代价是舍弃 Istio 对 POD 调用自己流量的管控能力。

目前，国内的 Service Mesh 应用和开发基本都源自 Istio，无论是直接优化应用还是重构部分模块，主要投入者还是公有云云计算服务商，作为容器平台能力的补充。另外，传统的微服务框架开始集成 Service Mesh 的一部分能力作为服务接入的拓展方式，主要面向私有云与传统行业转型。

在落地方面，整个市场还处于早期阶段，但比较乐观的是，随着 K8s 的推广和普及，相比于之前的迟疑，大家对于 Service Mesh 的认可度提高了，各个行业已经逐步有客户在主动尝试并生产应用 Service Mesh。

黄俊表示：“作为技术，Service Mesh 还处于发展期，即使是最火的 Istio 项目也才推出了 1.2 版本，尚未达到 K8s 那样的成熟度。”他认为 Service Mesh 目前存在的问题主要集中在以下两点：

1. 性能损耗与拓展性：sidecar 主动劫持流量经过两次额外的 TCP/IP 堆栈穿越，与内核上下文切换，开源的版本平均每次调用将产生 5-8ms 延迟，这对敏感型业务来说，是比较难接受的。另外就是对服务通信私有协议的支持需要拓展。

2. 维护成本：以 Istio 为例，整个微服务化的 Service Mesh 控制面与业务成正比数量的 sidecar，部署、升级、伸缩都需要投入相当大的精力与成本。

至于未来发展，黄俊认为 Service Mesh 的发展还是会围绕云原生服务通信基础设施的方向，作为基础 PaaS 平台的核心组成支撑上层的业务应用平台。另外，各大云服务商也需要在 Service Mesh 产品服务化上持续发力，解决和优化核心技术问题，打造成熟的解决方案和最佳实践，帮助客户迁移和应用 Service Mesh 与容器相关技术。

在 QCon 上海 2019 的演讲中，他将重点阐述在腾讯云上如何利用云原生的解决方案 Istio+K8s 来对自研业务后台进行环境管理，过程中涉及到了如何来适配 RPC 私有协议、名字服务等技术细节。以及这套环境治理方案实际对业务在研发过程效率的提升效果。

如果你想知道 Facebook、LinkedIn、阿里巴巴、百度等公司是如何落地实践 AIOps 的，请关注 QCon 上海 2019，学习到他们的经验可以让大家权衡自己的系统整合落地方案，少走很多弯路。这里还有国内大型互联网公司在监控领域最前沿的产品、技术和理念，帮你平衡日增海量数据与实时精准展现之间的矛盾。大会报名倒计时 最后 3 天，团购享优惠，有任何问题欢迎联系票务小姐姐 Ring：17310043226（微信同号）