华为多年实践：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和开源社区的对接。

以上为今天的分享内容，谢谢你们！