腾讯云 Service Mesh 实践：利用Istio+K8s进行后台环境管理

1为何须要 Service Mesh？

想要回答“为何须要 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 流程、环境治理平台、微服务治理平台等等。

2腾讯 Service Mesh 实践

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

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

 技术选型：Istio+K8s

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

在技术选型方面，腾讯采用了 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 调用本身流量的管控能力。

3Service Mesh 将来发展

目前，国内的 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 与容器相关技术。