建设中台，五板斧铲除Service Mesh落地拦路虎

本文由作者授权网易云发布，未经许可，请勿转载！

作者：裴斐，网易杭州研究院云计算技术部资深架构师

前文《 要想业务中台建得快，最好用Service Mesh来带》介绍了Service Mesh对于企业在线业务中台建设的意义，以及实施Service Mesh的可行技术方案。但我们知道，基础技术的完整，不等于企业能够顺利推进应用。从落地的角度来看，Service Mesh目前主要还存在四个方面的问题。

第一个是 部署环境。因为Istio是和Kubernetes高度亲和的，从开始很多版本都是希望用户把微服务绑在容器上面。然而有的应用可能是在虚拟机上或者物理机上的，没有办法很快迁到容器上，因而企业在选型的时候需要注意：如果业务没有办法一下子迁移到容器环境，在非容器环境上面能不能做？

第二个是 注册中心。因为服务之间的发现是刚需，已经实施微服务拆分的企业往往很快就引入了注册中心。如果整个微服务的架构迁移到Service Mesh上面，以前的注册中心要不要动？怎么接入到新的Service Mesh体系里面，甚至从老的注册中心迁到新的上面？老的跟新的同时存在，需要互相发现的时候，要如何处理？这些都是需要考虑的，因为服务之间如果没有办法发现，就没什么用了。

第三个是 服务调用配置，采用服务名还是IP？轻舟团队在做微服务化的时候，碰到过一个典型的问题，我们规范得比较好，使用服务名调用，Envoy也天然支持这种方式，但在有的业务，服务用IP直接调，这种情况下也要考虑怎么做。

最后是 性能问题，我们能不能真正规避，或者说优化掉这些性能问题？

这四大问题，都是我们应用Service Mesh框架必须铲除的“拦路虎”。

网易轻舟落地Service Mesh的“五板斧”

网易轻舟团队很早就认识到了Service Mesh架构的先进性，并开始探索Service Mesh在网易业务场景中的应用，例如轻舟团队与严选团队合作，基于轻舟实现了严选第二代Service Mesh的重大升级。在这些实践中，轻舟团队也积累了不少经验，最典型的要点是如下“五板斧”。

第一板斧，是解决部署环境的问题。轻舟在Istio支持容器的基础上，对其进行了 容器&非容器混合部署的支持。

如图，左边是基于Kubernetes容器化的环境，Istio那套东西是没有任何问题的；但在右边，涉及到了非容器的场景，Istio遇到了问题。轻舟提供了这样的优化方案：每一个物理机或者是虚拟机上面有一个Envoy实现的Sidecar。


我们解决最主要的问题，当物理机上面的一个服务名调出来以后，要知道它是不是已经在Service Mesh体系里面了。我们实现了一个DNS，微服务的调用首先会通过这个DNS查询服务名，如果注册中心里面已经注册过相应的服务名，则认为该服务已经在Service Mesh体系里面。如果是 http://163yun.com这样一些不在注册范围内的，还是走以前的方式，这样就打通容器跟非容器混合部署的Service Mesh结构。

当然，这个方案也会涉及到注册中心的对接，包括Envoy生命周期管理。因为在容器里面它管理数据面或者是代理，是有一套保障性的方式的。在虚拟机或者物理机上，轻舟同样也会做一些相关的工作。

第二板斧， 支持老注册中心服务的互相发现。在Istio里面的服务默认是注册到Kubernetes的，在服务发现的时候跟传统的方式有很大的不同，传统的方式是SDK作为一个客户端去注册中心拉取所有服务的数据信息，在Pilot组件里面，是由服务端、控制端去对接Kubernetes或者是其他注册中心，然后通过gRPC双向连接去下发Envoy Sidecar上面。但Pilot提供了一个MCP扩展机制，可以对其他注册中心进行扩展，不管是Eureka还是Consul或者是ZooKeeper，轻舟都完成了对应的实现。这意味着，后续不管是采用Kubernetes的注册中心，还是继续用之前构建的其他注册中心，都可以通过这个扩展机制来扩展。


第三板斧是 服务调用的配置，Istio本身支持服务名调用，轻舟团队也做了IP调用支持。

如下图，网易严选所有的服务调用都是通过IP实现的，我们做了一个适配，当我拿到IP的时候，不管是控制面还是数据面，做一些监听器的下发——之前服务调用是指向本地的一个端口，我们对这个端口进行监听，然后适配到服务名调用的体系下面。我们对Envoy进行了扩展，首先控制面把对应的端口下发到数据面Envoy上面，后者在收到请求以后重写到80端口，就是正常Service Mesh通过域名走的方式，这个调整以后，严选所有的服务之间的调用无需把IP方式改成服务名的方式就完成了平滑迁移，业务无需改造。（严选Service Mesh相关实践详见： 从Consul+Nginx到Istio，网易严选Service Mesh架构的持续演进）


第四板斧是 性能优化，主要有两方面，一是将Mixer组件的功能下沉到Sidecar实现，二是轻舟有一个网络团队，专门优化Sidecar网络路径。目前的优化成果，借助自研网络组件sockops，在容器网络下面，通过两边都有Sidecar的模式，它的QPS可以提升20%左右；而采用主机网络的时候，QPS提升可能会更高，达到20%-30%。

第五板斧是 基于Service Mesh技术栈的下一代的API网关。

Service Mesh的落地必然涉及到网格外系统和网格内系统的互通，高性能、高可用的API网关的重要性由此凸显。Envoy组件逐渐成为微服务业界数据面事实标准 ，我们选型Envoy作为下一代微服务API网关的组件选型，不仅因为其丰富的功能和强大的性能，技术栈上也可以做到跟轻舟Service Mesh统一，即数据面Envoy与控制面Istio，在未来微服务技术演进上，真正意义上做到服务框架与API网关技术栈统一，降低了微服务技术栈的整体研发维护成本。

如下图，右下角是Service Mesh互相调用的结构，管理南北向流量的API网关以Envoy组件实现，，并通过自定义的扩展机制实现一些扩展。控制面则统一由Pilot进行管理，Pilot主要负责实现与Sidecar双向连接、服务发现、配置转换等功能。


Pilot在实现Envoy基础控制面基础上，还可以扩展对接企业已有的管理平台，或直接使用轻舟的网关控制台或者是Service Mesh的控制台。按照轻舟微服务整体规划，不管是Service Mesh还是API网关，都可以在数据面和控制面做到技术栈的统一，不管是维护，还是系统对接，能力都是比较完整的。

小结

Service Mesh的引入，让企业得以突破传统微服务框架的限制，建成专用微服务基础设施，解决业务中台建设的主要技术难题，实现异构应用的整合，以及无侵入的服务治理。

上述“五板斧”，从系统兼容，到性能保证，到开发运维成本，可以确保企业平滑迁移到Service Mesh架构，不会拒虎进狼，引入新的技术难题。有了这五板斧，企业不仅可以破解Service Mesh落地应用的难题，通过先进的微服务、中台架构获取新的发展动能，还能实现技术栈的统一，降低企业应用中台的成本。