杜雅林 分布式实验室

随着微服务数量越来越多，给业务开发团队的增加了沟通和维护的成本，为了解决这一的痛点，我们关注到了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还处于初级阶段，后面还将继续探索。