ServiceMesh(服务网格)

Posted 2020-11-25 wangyu19900123

今年，ServiceMesh(服务网格)概念在社区里头非常火，有人提出2018年是ServiceMesh年，还有人提出ServiceMesh是下一代的微服务架构基础。作为架构师，如果你现在还不了解ServiceMesh的话，是否感觉有点落伍了？那么到底什么是ServiceMesh？它诞生的背景是什么？它解决什么问题？企业是否适合引入ServiceMesh？根据近年在一线互联网企业的实践和思考，从个人视角出发，我为大家一一解答这些问题。

微服务架构的核心技术问题

在业务规模化和研发效能提升等因素的驱动下，从单块应用向微服务架构的转型(如下图所示)，已经成为很多企业(尤其是互联网企业)数字化转型的趋势。

 

 

图片发自简书App

 

 

在微服务模式下，企业内部服务少则几个到几十个，多则上百个，每个服务一般都以集群方式部署，这时自然产生两个问题(如下图所示)：

 

 

图片发自简书App

一、服务发现：服务的消费方(Consumer)如何发现服务的提供方(Provider)？

二、负载均衡：服务的消费方如何以某种负载均衡策略访问集群中的服务提供方实例？

作为架构师，如果你理解了这两个问题，可以说就理解了微服务架构在技术上的最核心问题。

三种服务发现模式

服务发现和负载均衡并不是新问题，业界其实已经探索和总结出一些常用的模式，这些模式的核心其实是代理(Proxy，如下图所以)，以及代理在架构中所处的位置，

 

 

图片发自简书App

 

在服务消费方和服务提供方之间增加一层代理，由代理负责服务发现和负载均衡功能，消费方通过代理间接访问目标服务。根据代理在架构上所处的位置不同，当前业界主要有三种不同的服务发现模式：

模式一：传统集中式代理

 

 

图片发自简书App

 

 

 

这是最简单和传统做法，在服务消费者和生产者之间，代理作为独立一层集中部署，由独立团队(一般是运维或框架)负责治理和运维。常用的集中式代理有硬件负载均衡器(如F5)，或者软件负载均衡器(如nginx)，F5(4层负载)+Nginx(7层负载)这种软硬结合两层代理也是业内常见做法，兼顾配置的灵活性(Nginx比F5易于配置)。

这种方式通常在DNS域名服务器的配合下实现服务发现，服务注册(建立服务域名和IP地址之间的映射关系)一般由运维人员在代理上手工配置，服务消费方仅依赖服务域名，这个域名指向代理，由代理解析目标地址并做负载均衡和调用。

国外知名电商网站eBay，虽然体量巨大，但其内部的服务发现机制仍然是基于这种传统的集中代理模式，国内公司如携程，也是采用这种模式。

模式二：客户端嵌入式代理

 

 

 

图片发自简书App

 

这是很多互联网公司比较流行的一种做法，代理(包括服务发现和负载均衡逻辑)以客户库的形式嵌入在应用程序中。这种模式一般需要独立的服务注册中心组件配合，服务启动时自动注册到注册中心并定期报心跳，客户端代理则发现服务并做负载均衡。

Netflix开源的Eureka(注册中心)[附录1]和Ribbon(客户端代理)[附录2]是这种模式的典型案例，国内阿里开源的Dubbo也是采用这种模式。

模式三：主机独立进程代理

这种做法是上面两种模式的一个折中，代理既不是独立集中部署，也不嵌入在客户应用程序中，而是作为独立进程部署在每一个主机上，一个主机上的多个消费者应用可以共用这个代理，实现服务发现和负载均衡，如下图所示。这个模式一般也需要独立的服务注册中心组件配合，作用同模式二。

 

 

图片发自简书App

 

 

Airbnb的SmartStack[附录3]是这种模式早期实践产品，国内公司唯品会对这种模式也有探索和实践。

三种服务发现模式的比较

上面介绍的三种服务发现模式各有优劣，没有绝对的好坏，可以认为是三种不同的架构风格，在不同的公司都有成功实践。下表总结三种服务发现模式的优劣比较，业界案例和适用场景建议，供架构师选型参考：

 

 

图片发自简书App

服务网格ServiceMesh

所谓的ServiceMesh，其实本质上就是上面提到的模式三~主机独立进程模式，这个模式其实并不新鲜，业界(国外的Airbnb和国内的唯品会等)早有实践，那么为什么现在这个概念又流行起来了呢？我认为主要原因如下：

上述模式一和二有一些固有缺陷，模式一相对比较重，有单点问题和性能问题；模式二则有客户端复杂，支持多语言困难，无法集中治理的问题。模式三是模式一和二的折中，弥补了两者的不足，它是纯分布式的，没有单点问题，性能也OK，应用语言栈无关，可以集中治理。

微服务化、多语言和容器化发展的趋势，企业迫切需要一种轻量级的服务发现机制，ServiceMesh正是迎合这种趋势诞生，当然这还和一些大厂(如Google/IBM等)的背后推动有关。

模式三(ServiceMesh)也被形象称为边车(Sidecar)模式，如下图，早期有一些摩托车，除了主驾驶位，还带一个边车位，可以额外坐一个人。在模式三中，业务代码进程(相当于主驾驶)共享一个代理(相当于边车)，代理除了负责服务发现和负载均衡，还负责动态路由、容错限流、监控度量和安全日志等功能，这些功能是具体业务无关的，属于跨横切面关注点(Cross-Cutting Concerns)范畴。

作者：HelloWide
链接：https://www.jianshu.com/p/27a742e349f7
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。