2018年，微服务方兴未艾，Service Mesh（服务网格）又快速崛起。有观点认为，2018年可被称之为“Service Mesh元年”，在未来两年中，Service Mesh将迎来爆发式增长，成为下一代的微服务架构。
那么，Service Mesh到底是什么？自2016年被提出，为何不到两年就获得了如此高的人气？Service Mesh又能为企业解决哪些问题？在近日召开的GIAC全球互联网架构大会上，蚂蚁金服高级技术专家黄挺以蚂蚁金服的自身实践为例，深入解读了Service Mesh。
蚂蚁金服高级技术专家黄挺
解决蚂蚁金服三大难题
“Service Mesh”最早由开发Linkerd的Buoyant公司提出，2016年9月第一次公开使用该名词。对于什么是Service Mesh，Linkerd首席执行官William Morgan曾经给出这样的解释：
“服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传输。在实践中，服务网格通常实现为一组轻量级网络代理，它们与应用程序部署在一起，而对应用程序透明。”
这听起来还是有些抽象，黄挺用蚂蚁金服自身的例子，解读了Service Mesh的三个主要应用场景：
其一，解决多语言通信的问题，用同一套基础设施解决不同的语言的通信问题。
众所周知，SOFA 中间件（Scalable Open Financial Architecture）是蚂蚁金服自主研发的金融级分布式中间件，被蚂蚁金服广泛应用于支付、借贷、信用、基金、保险等全金融场景，支撑蚂蚁金服平稳度过历次“双11”、“双12”、“新春红包”等苛刻考验。
如今SOFA包含丰富的组件，如SOFA Boot、微服务、数据访问代理、分布式事物、消息队列、分布式链路跟踪等，基本上包含了分布式架构所需的各种中间件。
“然而有一个问题是，这些中间件都是用Java写的”，黄挺指出，当前蚂蚁金服技术栈大部分基于Java语言，包含2000+应用和20000+服务；但还有一部分应用是基于NodeJS、C++、Golang和Python语言，要把这些应用融入到SOFA体系，按照传统的方式，各种语言的客户端都需要再实现一遍，带来巨大的工作量，同时要承担大量风险。
而通过Service Mesh中的Sidecar，服务注册中心、限流熔断、动态配置、故障注入等客户端可以和NodeJS、C++、Golang、Python等具体语言解绑，让基础中间件和具体的应用脱离关联，即“一次实现，搞定所有语言的客户端”，用一套基础设施解决不同语言的通信问题，大大节省了工作量。
其二，解决遗留系统融入问题，让一些遗留系统更好的融入到云原生体系。
很多传统企业，包括金融机构往往有着大量的遗留系统，随着传统企业云化的深入，这些遗留系统也需要转变为云原生应用。“一种方式是直接把系统代码重新做一遍，直接用云原生的方式再写一遍”，黄挺认为，这种方式虽然比较直接，但是也比较粗暴，有可能在迁移过程当中出现非常多的Bug。
而有了Service Mesh之后，通过Sidecar，遗留系统不经改造，或是只需要很少的改造，可以非常方便的和云原生体系融合到一起。
其三，解耦基础设施团队和应用研发团队，增强基础设施团队的交付能力和交付速度。
近些年，蚂蚁金服的技术架构逐渐从单体应用向服务化架构演进。据黄挺介绍，在单体应用中，通常需要多个团队去改同一套代码，一起部署、一起发布，以及发现问题一起回滚，这个过程非常痛苦。
“应用研发有时候无法很好的理解基础设施的东西，升级容易出现问题。基础设施团队有时候也无法很好地去了解应用研发。应用研发和基础设施团队耦合在一起发布、变更、升级，非常容易出现问题”，黄挺说。
Service Mesh让蚂蚁金服找到了解决问题的方法，通过Service Mesh，应用研发和基础设施团队能够最大程度地解耦，做厚技术中台，让中间件可以更快的交付业务需要的能力。
黄挺举例说，以前SOFARPC中新的能力需要半年甚至一年的时间才能逐步应用于蚂蚁金服核心系统，有了SOFA Mesh（蚂蚁金服自研的Service Mesh），蚂蚁金服可以在一个月的时间内将新的能力快速地提供给所有的业务系统，而不用一个个的去升级业务系统。
蚂蚁金服SOFA Mesh自研路
Service Mesh是一个很新的框架，2016年1月 15日，Linkerd 0.0.7版本发布，这是能够在Github上看到的第一个Service Mesh。如今，业界流行的Service Mesh框架已经包括Linkerd、Istio和Conduit等。
据黄挺介绍，蚂蚁金服在考量业界主流Service Mesh框架的时候，有着两个明确的需求：其一，能否从蚂蚁金服当前的架构下渐进式地演进到Service Mesh架构之下；其二，在性能和稳定性上能否满足蚂蚁金服金融级以及高流量的要求。
经过大规模的验证，当前业界主流的Service Mesh并不能很好地满足蚂蚁金服这两个需求。例如，Istio在性能上存有缺陷，无法满足蚂蚁金服高流量和高性能的需求；Linkerd架构不够开放，资源占用率较高；Conduit当前版本还不够成熟，并且基于非常新的RUST语言，精通的人较少。
现有Service Mesh架构均不能满足需求，而蚂蚁金服在传统服务化架构上已经有十余年积累，这两个因素让蚂蚁金服选择自研Service Mesh——SOFA Mesh。
但“自研”并不代表一定要“从零开始”。“我们没有从零开始直接构建一个Service Mesh框架，而是借鉴了一些现有Service Mesh框架的优秀经验，同时尽量遵从整个Service Mesh社区的规范”，黄挺表示，例如，在Control Plane的Pilot以及Auth，SOFA Mesh直接选择了集成Istio的部分，并且进行了适当地增强。
“SOFA Mesh一切的技术选择都是能够让蚂蚁金服稳定、高效、渐进式地演进到 Serivce Mesh 架构下，因此SOFA Mesh在技术上的选择更加务实，也希望能够和业界保持技术上的互通”，黄挺强调。
尽管不是从零开始构建，但SOFA Mesh的开发过程也并不简单。
黄挺回忆说，SOFA Mesh自研过程中最大的困难是第一次上线时候的进度压力，因为当时有着切实的业务需求：“当时的一个场景需要用C++去调用后端一个用SOFA写的Java系统，为了满足业务上的要求，我们集结了应用网络和中间件团队，组成了技术攻坚团队，最终花了差不多两个月的时间从零开始构建了SOFA Mesh Golang版本的Sidecar，并且对接到SOFA服务化体系下，最终保证了业务的正常上线，在性能以及稳定性上都满足了业务的需求。”
经过蚂蚁金服业务场景的不断磨练，SOFA Mesh如今已经在蚂蚁金服多个场景中落地。据黄挺介绍，SOFA Mesh在蚂蚁金服内部更多的被应用于多语言支持，亦被应用于解决内部服务调用的安全以及在能力发布上的问题，此外也在规划解决异构体系的通信问题，在蚂蚁金服业务中发挥着越来越关键的作用。
Mesh的未来——Xmesh
作为一个新兴的技术框架，Service Mesh从2016年被提出来，去年迎来了蓬勃发展。不仅是蚂蚁金服，谷歌、IBM、华为等业界巨头已经参与到Service Mesh的研发之中，国内多家互联网和云计算企业也开始在Service Mesh进行验证和投入。
黄挺认为，2018年，随着云原生理念的进一步地被传播，以及 Kubernetes 等容器编排平台被更多的公司所采纳，Service Mesh 也必将在今年有更好蓬勃地发展。
“我们预计今年会有更多的公司在内部去实践Service Mesh，也非常期待在业界能够听到更多公司的Service Mesh的实践。从形态上，除了Service Mesh，也会逐步出现其他形式的Mesh，比如Message Mesh或者DB Mesh等等”，对于Service Mesh的未来，黄挺十分乐观。
而对于蚂蚁金服来说，其自研的SOFA Mesh会继续在内部更多场景下落地，用更多的场景去“磨练”SOFA Mesh。“未来我们也不排除在服务调用上之外的场景做 Mesh，在数据访问、消息通信上也用上Mesh的场景，以达到在基础设施上更加统一的目的”黄挺说。
据黄挺透露，蚂蚁金服目前也正在紧锣密鼓地准备SOFA Mesh的开源。SOFA Mesh的诞生结合了业界的先进理念和经验，而蚂蚁金服也希望将SOFA Mesh的成果反馈给社区，推动SOFA Mesh生态的良性发展。