活动主持人

个人签名

169篇博客

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

活动主持人2019-10-30 14:07

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

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

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落地应用的难题,通过先进的微服务、中台架构获取新的发展动能,还能实现技术栈的统一,降低企业应用中台的成本。