什么是 Service Mesh
Service Mesh 是一个基础设施层,用于处理服务间通信。云原生应用有着复杂的服务拓扑,Service Mesh 保证请求可以在这些拓扑中可靠地穿梭。
在实际应用当中,Service Mesh 通常是由一系列轻量级的网络代理组成的,它们与应用程序部署在一起,但应用程序不需要知道它们的存在。
Service Mesh 是位于 TCP / IP 之上的抽象层的网络模型。 它假设底层的 L3/L4 网络存在并且能够从点到点传送字节。
它也假定这个网络和环境的其他方面一样是不可靠的,因此 Service Mesh 也必须具备处理网络故障的能力。
在某些方面,Service Mesh 有点类似 TCP/IP。TCP 对网络端点间传输字节的机制进行了抽象,而 Service Mesh 则是对服务节点间请求的路由机制进行了抽象。
房多多在2018年Q3的时候已经完成大部分服务容器化,房多多容器化的网络方案主要是 overlay 和 macvlan,overlay 网络提供给 nodejs 服务使用,macvlan 主要给 Java 服务使用。
关于 macvlan 网络性能的测试可以参照网上的一些论文,一般来说,macvlan 网络可以达到物理网络 95% 以上的性能。
我们把 Dubbo 服务挂在 macvlan 的网络下实现 Dubbo 服务与原有虚拟机服务的互联互通。
在把 Dubbo 服务容器化的过程中,发现 Dubbo 对容器的支持并不好,获取网卡 IP 的逻辑也有问题,在多块网卡的容器中,Dubbo 框架经常会随机的获取 IP。官方提供了一个使用环境变量告诉框架要注册的 IP 的方案:
这个方案并不是很优雅,需要每个服务都维护一个环境变量用于告诉框架需要注册的 IP,所以我们采用了只挂载 macvlan 网络的方案。
既然 Dubbo服务都挂载到 macvlan 网络了,有些服务同时提供 HTTP 和 Dubbo服务,如何实现对 HTTP 服务的代理就成了我们考虑的问题,这时候 Service Mesh 进入了我们的视野。
此外,由于此时大部分流量的负载均衡还依赖 Nginx 转发,在 appid 400+ 的背景下,运维团队和业务团队迫切的需要更高效的方案来解决配置管理和沟通成本的问题,构建房多多 Service Mesh 体系就显得尤为重要,Envoy 是一个成熟稳定的项目,也能够满足近期的需求,在现阶段我们并没有人力去动 Envoy,所以我们直接使用了 Envoy。
为了使 Service Mesh 支持 overlay 网络和 macvlan 网络,我们把 Envoy 的一块网卡挂载在 macvlan 网络中,另一块网卡挂载在 overlay 网络中,这样 Envoy 就成为内部网关服务,托管内部调用流量。
xds 服务主要功能是给数据平面提供服务的集群配置、路由配置等信息,并且需要实现微服务架构中降级和限流的配置功能。
由于历史原因,还有相当多的业务无法从 VM 迁移到容器,需要有一个同时兼容容器和 VM 的数据平面服务,目前 xds 服务的支持的功能如下:
在房多多,Service Mesh 体系的建设大幅提高了研发效率,节省了大量维护配置所花费的时间,降低了人为配置产生 bug 的可能性,研发流程的改进如下图:
同时也降低了框架开发成本和业务改动的成本,每次推动业务升级框架都需要比较长的一段时间,业务无法及时用上新框架的功能,多种框架版本也加重运维负担,Service Mesh 帮我们解决了很多痛点。
得益于云原生架构,Service Mesh 可以使用云原生的基础设施,基础设施能力的改进可以直接赋能业务,而不像传统的框架一样,基础设施的升级和改进无法提高传统框架的服务能力。
房多多的 Service Mesh 还处于初级阶段,后面可以做的事情还有很多,比如蓝绿发布,类似 API 网关的 API 版本部署,配置镜像等。