微服务发展看Service Mesh，Service Mesh发展看落地经验

前言：当前，微服务改造正在许多企业当中如火如荼地进行，然而，微服务改造带来许多新问题成了进一步发展的障碍，在这一背景下，Service Mesh应运而生，Service Mesh将是微服务进一步发展的关键，从实际出发，时速云基于自研技术克服了落地应用的许多障碍，此时咱们才发现，容器技术的进一步发展中，技术已不最关键的，落地经验才是。

2013年，有一个叫Docker的容器技术忽然火了起来，2015年先后，在大众创业、万众创新的号召下，企业服务市场涌现出了多家容器创业公司，创业失败是大几率事件，而今，这些基于容器的创业公司，有的已经消失，有的慢慢的一步步走来，可能没人能预想到容器生态是今天这般繁荣景象，但至少2015年的一些未知如今已经有了肯定答案。

基于容器技术的微服务大行其道

首先，容器技术确实如人们想象中的那样有突破性，就如当时所说的，是继虚拟化以后的又一大创新技术。虚拟化和容器确实是替代的关系，愈来愈多的应用是直接部署在裸机服务器而不是虚拟化架构之上。

更重要的是，企业验证了容器技术的可用性和稳定性，有动力也有决心对应用作微服务化改造。

2020年，时速云技术总监张寿红在谈到技术与应用发展时表示，现在基于容器技术的PaaS平台已经很是成熟，企业已经基本无障碍地快速部署上PaaS平台，许多企业正在使用容器应用，而且正在对现有应用作微服务化改造。

企业之因此热衷于构建微服务架构，主要是由于，没有微服务架构以前的单体应用时代，应用的每次变动都很是困难，可谓是牵一发动全身。而微服务架构能为每个微服务独立开发、部署、升级，进行弹性伸缩，它会使得应用的升级在局部完成迭代更新，不会对总体应用形成影响。这就是微服务的魅力所在。

微服务的出现也带来了许多新的问题，Service Mesh正是为了解决它带来的新问题而生的，Service Mesh是企业落地微服务架构的关键，有了Service Mesh，企业才能放心大胆地用上微服务，能够说，Service Mesh是摆在全部容器创业公司面前的，继企业PaaS平台以后的第二大考题。

微服务带来的新问题

微服务改造就是将原来一个个单体应用拆分为若干个微服务，优点很明显，带来的问题也很是显而易见。

从管理的角度看。当微服务数量特别多的时候，架构会变得很是复杂，更重要的是，当一个微服务出现问题可能会影响到许多其它微服务。随之而来的是，如此复杂的架构下，故障排查从何作起？如何快速定位故障点呢？

从安全的角度看，当微服务从单体应用拆分以后，原来在一个进程里的调用至少会分散到两个进程里去，在一个进程里的调用没有安全问题，但拆开后的调用可能会跨网络、跨系统甚至跨数据中心来调用，带来很大的安全隐患。

Service Mesh本质上是一张负责微服务之间通讯的网络，它是服务间的一个通信层，它自己不与应用代码耦合，并且还能捕获到底层环境的动态变化并做出调整。Service Mesh无需程序员关注它，让程序员只须要关注自身业务代码就好了，这就是Service Mes存在的意义。

从本质上来讲，没有Service Mesh的话，微服务也能正常工做，此前的微服务框架间的通信采用SDK的方案，这一方案有较大侵入性，说白了，就是须要写应用程序代码的程序员关注到它，与Service Mesh相比，高下立判。

微服务框架的技术流派

早期，业内主流的Service Mesh方案是用Linkyard来实现的，但Linkyard只有数据面的能力，然后，Istio出现后提出了控制平面的概念，为的是让服务治理的策略配置进行统一控制，这一思想奠基了Service Mesh的架构基础，也就是控制平面和数据平面两部分。

Istio不只架构先进，并且背后还有IBM以及谷歌这样的业内巨头的大力支持，因而很快就成了业内标准，几年前，在谷歌的力推下Kubernetes（K8s）不久便一统江湖同样了，巨头的技术影响力可见一斑。

严格来讲，Istio实现的是控制平面，但缺乏数据平面，后来，Istio默认的数据面是使用Envoy来作的。本觉得Istio和Envoy的组合将是大多数选择，但张寿红则表示，时速云在控制平面用的是Istio，而数据平面用的是自研的一套方案。

这样选择是有缘由的，在张寿红看来，虽然Envoy在稳定性和性能方面表现还不错，但它最大的问题是在于维护成本高，考虑到在企业落地微服务架构时常常须要作许多定制化的开发，因此，直接拿Envoy来用是不行的，须要在Envoy基础上作许多开发。

但问题是，Envoy是用C++开发的，而云原生领域绝对主流的开发语言是Go语言，考虑到维护成本的问题，时速云最后选择了自研之路。其实，Go语言工程师的成本也很高，但当绝大多数都是由Go语言来完成，而少部分由C++语言来完成的话，确实比较别扭。

Service Mesh落地难的问题

Service Mesh是一个提及来比较美好，但并不容易落地的技术方案，目前来看，国内在生产环境中Service Mesh的落地案例一直很是少，在张寿红看来，主要缘由在于由国际巨头主导的技术方案在中国企业落地时出现了水土不服，国内企业使用的通讯协议以及服务的部署形态与国际其余地区有所不一样，须要部署落地时候有针对性地加入一些功能。

常见的尴尬是，许多企业在针对Service Mesh作技术验证时，系统运行的很顺畅，但真到落地的时候，则会发现困难重重，这些问题致使Service Mesh在国内落地困难的尴尬，如何化解这些尴尬呢？

时速云做为国内Service Mesh落地方案经验颇多的一家，指出了三点。

首先是要加强方案的易用性，张寿红介绍说，加强易用性是大势所趋，Istio也意识到了易用性的重要性，最近更新的Istio新版本也着重加强了易用性。而在将来，则是会考虑作一些自动化运维的能力，以此强化易用性。

其次是针对特定场景的能力，现有架构，好比Istio主要是针对容器化部署场景开发的，但实际上企业里有容器化应用，同时也有许多在虚拟机环境，这须要Service Mesh方案能具有异构部署的能力，企业内部环境其实很是复杂，这要求有较高的适用性。

优化性能，因为Service Mesh须要用到一层代理，不可避免的会形成性能损耗，用户对于Service Mesh的性能有顾虑也是一大阻碍因素，用户不但愿性能损耗影响业务。张寿红表示，性能优化也只能一步一步来，经过数据平面和控制平面下手。

时速云在方案上着眼于三个要注意的点，在实际落地中，更多靠自研能力将Service Mesh方案集成到用户现有的架构中，对接用户原有的日志、监控等各类系统，这对于定制化开发的能力要求很高。

技术已不是竞争壁垒，落地经验才是

在谈到友商的竞争差别时，张寿红表示，从根本上来说，同类厂商在技术上的差别性很小，主要差别体如今实际落地的案例和经验上，而时速云是目前国内少数有一些落地经验的一家。

从张寿红的介绍中了解到，金融行业用户在容器方面的探索走的比较靠前，金融行业用户正在将大量的负载从虚拟化平台迁移到容器平台上，这为基于Service Mesh的微服务架构落地打下了很好的基础。

以你们保险为例，先是采用了时速云的PaaS平台，而在今年，你们保险上线了新平台，在内部构件了技术中台，背后的支撑架构就是时速云的Service Mesh， 据了解，你们保险目前在生产环境上线了大约几千个微服务。

你们保险性能是你们保险很是看重的方面之一，在上线到生产环境前，时速云的Service Mesh通过了严格的性能和稳定性测试，以几万级别的负载量测试，最后只实际部署几千个微服务，足见金融用户的谨慎，但也刚好反映出用户对于Service Mesh自己的承认。

像你们保险这样，先上容器云PaaS平台，然后在此基础上上线Service Mesh是比较常见的实施路径。事实上，容器云PaaS平台是微服务架构的基础，目前业内的容器云PaaS平台自己各方面已经很是的成熟，并且，企业也很是承认容器云PaaS平台的实际做用，也都会将其视为容器化改造的第一步。

尽管有了容器云PaaS平台的基础，但仍要Service Mesh解决许多对接原有系统的需求，好在时速云采用了自研的策略，在面对有许多历史负担用户时候，能处理各类复杂的、非业内标准的协议，知足大型企业的需求。而那些复用开源社区Istio + Envoy的方案则更适合没有历史负担的中小企业用户。

结语

现在的容器云PaaS已是送分题，而Service Mesh才是拉分题，而Service Mesh最核心的竞争力就是通过实际验证，具有生产环境上线的能力。Service Mesh关系重大，业务上的全部调动都要通过Service Mesh，因此，在上线前，必需要通过长期的测试验证，时速云与友商最大的不一样在于此，而如今，时速云已经度过了这一阶段。