DockOne微信分享（二零二）：房多多Service Mesh实践

【编者的话】随着微服务数量越来越多，给业务开发团队的增加了沟通和维护的成本，为了解决这一的痛点，我们关注到了Service Mesh技术，本次分享主要介绍房多多在Service Mesh中的一些经历和过程，以及在工程效率方面的一些感悟。

概述和需求背景

房多多国内领先的经纪人直卖平台，目前房多多APP和多多卖房APP的后端服务主要运行在自建的IDC机房。2018年之前，我们的服务都是运行在VM上，也同时基本上完成了基于Dubbo的微服务改造，目前的语言技术栈主要有：Java、Node.js、Golang。相对于其他公司而言，技术栈不是特别分散，这给我们服务容器化带来了极大的便利。

我们在2018年Q3的时候已经完成大部分服务容器化，此时我们的微服务数量已经超过400个了，在沟通和维护上的成本很高。因为我们后端服务是主要是基于Dubbo的，跟前端直接的交互还是通过http的方式，在没有上Service Mesh之前，http请求都是经过Nginx转发的。维护Nginx的配置文件是一个工作量大且重复性高的事情，运维团队和业务团队迫切的需要更高效的方案来解决配置管理和沟通成本的问题，构建房多多Service Mesh体系就显得尤为重要。Envoy是一个成熟稳定的项目，也能够满足近期的需求，在现阶段我们并没有人力去动Envoy，所以我们直接使用了Envoy做Service Mesh的数据平面，关于控制平面这块，在调研了一些方案之后，我们采用了自研的方案。

整体平台架构

我们的容器平台整体是基于物理机的，除了调度节点是用的虚拟机以外，所有的工作节点都是使用物理机。之前我们的虚拟化方案是用的Xenserver，Xenserver对高版本的内核支持并不好，会时不时的出现自动虚拟机关机的bug，所以我们在工作节点上只使用物理机以保障业务的稳定和高效。

我们的业务主要工作在自建IDC机房，公有云只有少量的灾备服务。因为是自建机房，相比较公有云而言，自建机房使用Macvlan是一个比较好的方案。我们预先划分了几个20位地址的子网，每个子网内配置一些物理机，通过集中式的IP管理服务去管理物理机和容器的IP。相比较bridge网络，Macvlan网络有着非常接近物理网络的性能，尤其是在大流量场景下性能出色，下面一张图显示了性能对比：

我们把Envoy作为两个网络之间的连接桥，这么做的好处在于可以控制流量都经过负载均衡器，便于集中管理以及对流量做分析。看到这里，肯定有疑问是为什么不使用Sidecar的方式部署Envoy。关于Sidecar我的考虑是，在现有的业务场景下，集中部署的维护成本更低且性能满足需求，也相对来说比较简单。我们在2018年Q4已经完成主要业务http2接入，目前来看，我们的网站速度应该是同行业中最快的，大家可以体验一下， https://m.fangdd.com 。

如何解决虚拟机业务和容器业务的并存问题

我们原有的架构大量使用了虚拟机，迁移虚拟机上面的服务是一个漫长的过程，当前阶段还需要解决业务的并存问题，我们自己开发了Envoy对应的配置集中管理服务，同时支持虚拟机服务和容器服务。

控制平面服务主要基于data-plane-api开发，功能上主要是给数据平面提供服务的集群配置、路由配置等信息，并且需要实现微服务架构中降级和限流的配置功能。容器内部的集群数据主要依赖DNSRR实现，而虚拟机上的服务，我们在CMDB上存有AppID和机器的对应关系，很容器生成集群配置数据。

由于历史原因，还有相当多的业务无法从VM迁移到容器，需要有一个同时兼容容器和VM的数据平面服务，目前XDS服务的支持的功能如下：

• 集群数据来源同时包括容器内部DNS和外部CMDB中的VM数据
• 支持多个 vhost 配置
• 支持路由配置
• 支持速率控制和网关错误重试

应用开发流程变化

初步建设起Service Mesh体系之后，理论上业务开发只需要开发一个单体服务，在服务间互相调用的过程中，只需要知道服务名即可互相调用，这就很像把所有服务都看做一个微服务一样，所以我们的业务开发流程发生了以下变化：

同时也降低了框架开发成本和业务改动的成本，每次推动业务升级框架都需要比较长的一段时间，业务无法及时用上新框架的功能，多种框架版本也加重运维负担，Service Mesh帮我们解决了很多痛点。同时再加上我们的网关层建设，我们上线一个新服务几乎是零配置成本的。

• 代理层实现服务发现，对于开发而言只需要开发一个单机的应用，降低框架开发成本
• 降级和限流都在代理层实现，规则灵活，方便修改策略
• 框架功能的升级无需依赖业务

SOA和Service Mesh的对比与取舍

在我们的Service Mesh实践中，增加了链路的请求长度，并且服务的链路越长，链路请求的放大效应会越明显，这就带来了一些性能上面的担忧。毫无疑问，Mesh层本身的业务逻辑开销是不大，但是在网络传输和内存复制上的性能消耗在一定程度上会影响链路的性能，Envoy也在探索相关的方案来优化网络传输性能，如Bpfilter和VPP，减少用户态和内核态的内存拷贝。在可定制性层面，SOA能做的事情也相对较多，可以实现很多hack的需求。

在我们现有的业务场景下，Service Mesh主要还是解决前后端的微服务对接问题，当做前后端服务的连接桥梁。但不可否认的是，Service Mesh带来研发效率的提升，在现有的场景下的价值远大于性能上的损失。在大多数的场景下，维护业务框架需要比较大的人力成本，很多团队都没有全职的人去维护业务框架。此外，推动业务框架的更新和升级也相对来说成本较高，这也是我们考虑的一个重要方面。

总结

得益于云原生架构，Service Mesh可以使用云原生的基础设施，基础设施能力的改进可以直接赋能业务，而不像传统的框架一样，基础设施的升级和改进无法提高传统框架的服务能力。房多多的Service Mesh还处于初级阶段，后面还将继续探索。

Q&A

Q：容器和微服务的区别以及它们的关联性、应用场景、客户群体、带来的价值？

A：微服务的应用场景主要是解决降低单个服务体积，满足业务的快速开发需求。容器可以说是微服务的载体，容器方面还是运维关注的比较多，带来的标准化流程和环境的提升对整个研发团队都有很大的作用。

Q：软件实现 Service Mesh，Istio？

A：我们目前只使用了Envoy，Istio也做过一些选型的调研，不是很符合我们现在的业务场景和业务需求，我们在之后的实践中会考虑使用一部分Istio的功能。

Q：实施过程当中有使用到Istio吗？有定制一些Mixer适配器吗？

A：目前还没有用，之后会考虑是用Istio中的pilot，我们目前在流量的控制的精细程度上面还欠缺，粒度还很粗。

Q：请问，实现微服务过程中有没有考虑分布式跟踪和分布式？

A：Service Mesh层可以做到简单的分布式追踪，比如可以做到基于请求的追踪，Envoy可以把trace数据接入Zipkin这样的trace系统，但是更细粒度的trace目前还做不到。

Q：不论是使用都会产生大量的配置（yaml），尤其是Envoy/Istio，系统中会有大量零散的配置文件，维护困难，还有版本管理，有什么很好的维护实践经验吗？谢谢。

A：是的，据我所知有些团队会使用ConfigMap来管理配置，我们做了一个配置的集中管理服务，从CMDB和DNS定时的抓取数据，数据会存在数据库里面，也会存一定量的副本用于配置回退，这个地方还是要结合你们现在其他配套系统的建设来看看怎么做比较好的。

Q：有没有遇到过Envoy被oom kill的情况，你们是如何处理的？

A：这个我有碰到过一次，之前我们在对Envoy做测试的时候，发现Envoy总会尽可能的占满CGroup的内存大小，这个之前在使用TLS的情况下碰到的比较多。但是目前我们内部服务间使用TLS的情况并不多，所以后续这个问题就没有继续跟进了。

Q：性化方案有哪些？

A：之前文章中有提到过，对于http服务可以全量接入http2，http2的长连接和多路复用对于一般的业务来说升是很明显的，我们在全量接入http2之后，网站的响应时间几乎下降了50%。另外还可以在底层的依赖上面做一些优化，比如底层的libc库，以及尽可能的减少基础镜像的大小，我们基本上所有业务都使用了alpine，这样可以保证发布性能和速度在一个很好的水平上。

Q：还是有一个服务治理/配置管理的问题请教，比如CPU，内存，这种资源request，在dev，test，staging，prod环境均不同，那么我们在编写Kubernetes配置的时候不同环境会不同，比如测试环境的replics数跟CPU需求就很低，生产就很高，另外这个配置在不同环境是多个还是一个呢？谢谢。

A：我们现在会在CMDB里面维护这些配置数据，一般来说在新建项目的时候，我们就会要求业务线评估一下这个业务需要的资源，比如你说到的test和staging环境这种，我们默认会给一个很低的需求，比如1c1g这样的，而且replication也会默认设置为1，除非业务有特殊的需求，然后我们去根据配置的数据去生成yaml格式为配置。

配置在数据存储的形式上是多个，但是在对业务展示上，尽量让业务感觉到是一个数据，这样也能使每个环境都规范起来，跟生产环境尽可能保持一致，这个对测试的好处还是很大的。

Q：你们目前的项目中，大量的微服务，以及调度层，瓶颈和容灾是如何处理的？

A：由于我们的业务类型还是B端业务为主，流量的峰值是可以预估的，很少会出现突发的大流量的情况，我们一般都预留了1倍的容量用于临时的扩容。容灾和调度的话我们主要还是尽可能的隔离工作节点和调度节点，以及大量使用物理机集群，从我们的使用体验上来看，物理机的稳定性还是很不错的。

Q：如何用Jenkins自动完成Kubernetes部署？

A：自动部署这块我们有完善的发布系统，如果单纯只要实现Jenkins自动完成Kubernetes的话，Jenkins可以直接调用Kubernetes的API，这个网上有挺多资料的，你可以找找看。

Q：Service Mesh比传统的微服务治理好在哪里？

A：降低框架开发成本、代理规则灵活，方便修改策略、框架功能的升级无需依赖业务，最大的好处我觉得就是可以降低框架开发成本。

Q：我理解房多多目前的Mesh方案没有给每个微服务配一个Envoy作为Sidecar，而是使用一组Enovy并自研了xDS的配置发布管理系统，对吗？我想请问backend微服务之间的请求现在是怎么走的呢？谢谢。

A：是的，刚刚文章中说了，我们后端SOA服务还是基于Dubbo的，这块目前我们还没有做改动，之后的话我们的初步构想会通过Sidecar的方式把这些Dubbo服务都接入到Mesh里面来。我们目前的Envoy也是会充当网关的角色。

以上内容根据2019年2月21日晚微信群分享内容整理。分享人 杜雅林，房多多平台 工具 负责人，负责容器平台、发布系统、Service Mesh相关功能开发 。DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesd，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。