前言：当前，微服务改造正在许多企业当中如火如荼地进行，然而，微服务改造带来许多新问题成了进一步发展的障碍，在这一背景下，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 Mesh存在的意义。
从本质上来说，没有Service Mesh的话，微服务也能正常工作，此前的微服务框架间的通讯采用SDK的方案，这一方案有较大侵入性，说白了，就是需要写应用程序代码的程序员关注到它，与Service Mesh相比，高下立判。
微服务框架的技术流派
早期，业内主流的Service Mesh方案是用Linkerd来实现的，但Linkerd只有数据面的能力，而后，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，所以，在上线前，必须要经过长期的测试验证，时速云与友商最大的不同在于此，而现在，时速云已经度过了这一阶段。
