2019-10-26 微服务之ServiceMesh

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

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

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

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

1、三种服务发现模式：

服务发现和负载均衡并不是新问题，业界已经探索和总结出常用模式，其核心为代理（Proxy）以及代理在架构中所处位置。

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

模式一：传统集中式代理

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

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

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

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

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

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

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

2、Service Mesh(网络服务)

        Service Mesh又称为服务网格，本质上就是我们前面介绍过的模式三。之所为称之为服务网格是因为按照模式三的结构，每个主机上同时运行了业务逻辑代码和代理，此时这个代理被形象地称之为SideCar（业务代码进程相当于主驾驶，共享一个代理相当于边车），服务之间通过SideCar发现和调用目标服务，从而形成服务之间的一种网络状依赖关系，然后通过独立部署的一种称之为控制平面（ControlPlane）的独立组件来集中配置这种依赖调用关系以及进行路由流量调拨等操作，如果此时我们把主机和业务逻辑从视觉图上剥离，就会出现一种网络状的架构，服务网格由此得名。