一个商用级Service Mesh服务的设计之道

作者介绍：田晓亮，8年软件行业经验，曾就职于三星，2012年进入云计算领域，对PaaS，DevOps，APM有深入的研究和实践经验，方案支撑近千台VM中的应用部署监控。 2016年加入华为担任架构师，负责微服务的Go语言开发框架及Service Mesh设计和落地，Go语言微服务框架已被华为5G核心网络采用，Service Mesh服务也已在华为云商用上线。
本文首发自《程序员》，谢绝转载，如需订阅，请点击这里（责编／魏伟）

微服务架构是个难题，但解法有多个

微服务是一个很大的概念，从团队组织到最佳实践似乎都有实施微服务的一些指导。我们这里只提构建微服务的架构模式，也就是关乎到你用什么样的方式来构建你以微服务架构来组织的应用系统。

近些年随着微服务的火热，越来越多的团队开始进行实践，将微服务纷纷落地，也许你是从0开始，一步步地完成了单体应用向微服务的改造，让我们来看看，你解决了多少问题。

图1 微服务架构需要解决的问题

微服务将原本内存中函数的调用转换为网络中的调用后，就牵扯到这些问题，而任何一个分支展开，都会涉及一系列的问题。业务开发者也许真的有精力去学习架构相关的复杂问题，然而对于公司来说，真正有价值的是业务本身，让业务开发者解决这些问题需要花费浪费大量的时间精力，导致业务上线受到影响。那我们来看看是否有便捷的方式来解决业务开发者的痛点。

Chassis模式

一句话来概括：一种语言开发框架来作为微服务开发的底座，封装掉复杂性，帮助你解决跨网络带来的问题，让用户聚焦在上层业务逻辑的开发。通常情况下会实现以下功能：

• 日志、Metrics、分布式追踪数据上报
• 健康检查
• 对接统一的配置中心实现动态配置
• 对接注册中心
• 实现负载均衡、熔断降级、容错、限流等保证高可靠运行的功能

现在我们来看看业界有哪些可用的Chassis框架

• Spring Cloud
• ServiceComb
• Dubbo
• Go-Micro
• Go-Kit

先不细去纠结微服务的严格定义，也先暂且搁置诸如“某些老旧框架是否是真的微服务框架”这类争议，从实现方式来看，上述服务化框架都是将分布式系统开发的复杂性进行了一定程度的封装然后提供了简便的开发接口供使用者调用。但是，用这种方式构建微服务还有一些问题：

• 多语言SDK支持：微服务提倡不同组件使用最适合它的语言开发，但是这需要每种语言都有开发框架，不断实现相同的功能。上面可以看到只有go语言和Java语言出现了微服务开发框架，其他语言呢？
• 不论代码侵入程度，都需要开发者思考如何与SDK结合，并从代码层面做出改变，对于大部分开发者来说都是一个高曲线的学习过程。
• 绑定了特定技术栈，一旦想抽身就需要一定程度上的代码改造。
• 老旧单体应用由于无人维护，耦合程度高等问题无法进行改造，在进行微服务拆分的过程中重用遗留代码变得无比困难。而且微服务的拆分难以分步进行，需要一个相对较长的周期将系统整体拆分后才能上线。

我们知道技术演进来自于在实践中不断地将功能抽象，解耦，封装，服务化。

• 云计算技术出现前是数据中心虚拟化，不断地实践使技术发展形成理论和新的实践。IaaS是一种封装，如今开发者与大部分技术团队不需要再学习虚拟化等技术以及如何维护数据中心。
• 没有TCP/IP的时代，开发人员需要自己考虑网络间数据包的传输，以及网络传输代码与业务代码完全耦合的问题，如今，开发者已经不需要关心，操作系统和开发语言已经封装好网络传输过程。
  是否也可以把语言框架提供的能力抽象，成为服务？

在引入后面内容前，我先介绍下SideCar模式

SideCar模式

• 在近些年受到Kubernetes对容器调度方式的启示而日渐受到关注的一种功能部署模式，也是一种微服务的设计模式。
• 主要利用了一个Pod中的容器可以共享存储与网络的能力，或者说在一个Host中，这个模式也同样适用。
• 一般分为应用容器和工具容器，工具容器可以重用。

一个典型的场景如下:

图2 SideCa