华为多年实践：ServiceComb在Service Mesh的探索与思考

内容来源： 2018 年 6 月 27 日，华为微服务架构师田晓亮在“LC3微服务Workshop | 深入解读ServiceComb”进行《ServiceComb的ServiceMesh思考及在华为云的实践》的演讲分享。IT 大咖说作为独家视频合作方，经主办方和讲者审阅授权发布。

阅读字数： 3606 | 10分钟阅读

观看嘉宾演讲视频及PPT ，请点击：t.cn/E2vZBkB

摘要

我们今天围绕三个主题来讲，首先会讲一下Service Mesh在华为多年的实践，另外会介绍一些实践的方法，最后会介绍几个案例来带大家看一下，我们是怎么在实践中帮助企业在生产环境中使用Service Mesh。

实际上我们在做微服务的时候，整个演进的过程中要解决很多微服务架构带来的复杂的问题。我个人曾实现过一个 Go 版本的微服务开源框架，这个框架有大概2万行左右的代码，并交付给业务使用，这个过程耗时非常长，实际上一般的公司是没有这个实力去交付的，另外可能还需要一些时间去让开发者去适应框架。

对此的另一种解决方案是使用Service Mesh，这是一个网络模型，不同于开发框架在应用层和应用耦合在一起，以解决微服务的复杂问题。Service Mesh是在TCP IP之上提供代理的方式和Application解耦，然后帮你去做发现、熔断、限流、监控等事情，这些都是在五层协议来做的。

其实可以这样看待，过去的Application是跑在tcp ip之上，现在这些服务跑在Service Mesh服务网络之上，而且这个过程不需要对原有代码进行一点修改。

实际上华为内部很早就已经有了非常多的实践。13年的时候实现了微服务开发平台中的IR组件，它是在每一个节点上有一个内部路由，这个节点上所有的Application由平台部署，部署进去之后由有一个叫RouterAgent组件将APP注册到zookeeper上，同时RouterAgent会刷新IR中的路由表，这样的就可以做发现了。

Application之间的所有通信呢都是通过Router来进行的，但是它是由nginx实现的，所以有几个缺点。首先一旦节点挂了之后，节点上的所有Application即进不来也出不去，通信就都没有了。另外扩展性受到一定局限，语言生态不像Go语言 Java 那么好。

我们在15年的时候又做了一个叫sidecar的组件，这也是一个大框架下的组件。它的原理其实已经和现在的Service Mesh非常像了，利用了kubernetes的一个pod下可以又多个容器的能力，一个container是承载业务，另外一个container就是sidecar。所有服务的请求都要通过sidecar进行发送接收，一般来说这些Service都是HTTP的service。sidecar其实也有自己的一些缺点，比如说它是Java开发的，大家都知道，java虚拟机是非常的占用资源的，现在每个微服务都要起一个虚拟机，总的来说不够清亮，所以sidecar其实不符合Service Mesh的最佳实践。

Mesher

后来我们用Go语言重写了Mesher组件，因为当时我们听到了这个概念之后，认为可以根据他的理论来实现一个我们自己的组件，然后我们就用了go语言去写。那么好处是什么？首先它的性能极高，而且占用资源非常小，非常符合Service Mesh的标准，因为它不会占用你的数据中心很多的资源。

可以看到上图中，Mesher在一个pod里边和服务跑在一起，它在内部支撑了很多的微服务的特性，比如发现、垄断、负载均衡、动态配置。它还会帮你维护健康，最后做发现的时候，是基于本地缓存。

上图是Mesher的详细架构。上面的那块是一个控制面板，支持多种的生态，-ServiceComb、Istio、Zipkin等，它和目前比较火的ECU平台最大的一个不同点，就是能够支持异构的基础设施，不会绑定kubernetes，还可以部署在说有云、Bare metal、VM上面。

注册发现

这个是我们注册发现的设计，它是做了两个抽象，一个叫注册器，一个叫服务发现。这样做的好处是能够支持客户端注册发现，也就是说当你没有像kubernetes这样的平台的时候，可以进行自注册。自行注册到Service Center上面，然后通过Service Discovery去做发现。当使用类似于ECU这样的平台的时候，由于它们会帮你自动维护生命周期，所以这个时候就不需要再去自注册或者维护心跳了，此时可以选择只运行一个Service Discovery来适配这个平台，这样就非常灵活了。

基于微服务元数据的路由管理

在Service Discovery之上会有一层统一的缓存模型，基于它们可以做非常丰富的路由管理。流量进来后会首先判断这次请求的特征，从请求中可以知道要访问的目标服务是什么，这里最关键的一个点就是你的服务名是什么，最后通过服务名来查远程或本地的路由表，决定service name的对所对应的metadata是什么，然后根据这些元数据去自己的本地缓存中查出真实的service instance列表，最后进行访问。

多协议支持

对于多协议支持我们抽象了一个Invocation，通过Invocation可以把不同的协议接入到统一的模型当中，并且享有同样的治理能力，比如路由管理、限流、监控，这些功能呢都被集成到Handler Chain里，Handler Chain处理的就是Invocation对象。而真实在网络间进行传输的还是协议的以及和协议相兼容的数据包。

ServiceComb Service Center架构严禁

这是我们后来推进的Service Center的架构演进，首先我们抽象了一个Adaptor层去适配不同的注册发现，怎么做实际上是由于数据中心会越来越大，并且我们认为任何一种云其实它都都是不可靠的。所以后来我们搭建了自己的私有云的中心，然后做了混合云，推进Service Centere架构演进也是希望它能够支持多云。除了这个价值之外，它还可以支持异构，比如把VM和K8S进行混编，能够让你在一个地方看到所有的数据中心以及所有异构设施中的微服务。

一站式解决方案

这个是我们的一个一站式解决方案，基于ServiceComb解决方案，Mesher，go chassis等组件,支持java，go语言编程框架和多语言接入，让你使用统一的管理平台进行管理。

Istio生态

我们的另一个策略是在开源方面拥抱Istio生态，和别的地方不同的，我们会把go chassis开发框架接入到Istio当中，这样做的一个好处就是可以提升服务的整体性能。因为实际上Service Mesh的方案，由于是一个服务代理，所以说所有的请求数据都会有一个从用户到内核，再从内核到用户的过程，整个过程都是要乘二的，所以性能其实是会有降低，一些对性能很敏感的用户，可能会倾向于使用侵入框架。而Istio正好提供Service Mesh方案，所以我们把go chassis带入到Istio中，同时把Mixer也带进去，成为一个数据面的替换方案。

用户案例

这个我们的其中一个用户的案例，当时他们内部的有一个用 PHP 写的楼宇管理系统，核心的业务就是管理大楼的一些设备和服务人员。当时他们在内部实践的时候，觉得这个单体服务其实挺好的，所以想做成一个SaaS服务拿出去卖。

但是单体安装的整个过程是非常复杂的，所有他们的对服务进行了拆分，拆分之后每个服务都跑在Mesher之上，通过华为的注册中心进行注册发现，此时就有了弹性伸缩的能力。当有一个新的用户来的时候，只需要用统一的镜像去拉新的container就可以了。这整个从改造到上线的过程，实际上只用了一个月，速度还是是非常快的。

Mesher技术路线图

这个是Mesher的技术路线，实际上我们17年11月份的时候就发布了国内第一款商用级别的Service Mesh，基于我们过去的微服务经验，以及几年前做的类似Service Mesh的工作。后续我们又进行了一些迭代，在这一年的迭代中还同时帮助多家企业把Service Mesh带到生产中。

今年比较大的一个特性是支持了GRPC协议，以及帮助用户快速的把Mesher带到自己的k8s环境当中。未来我们要做的主要是和 SQL 和开源社区的对接。

以上为今天的分享内容，谢谢大家！