1.概论

1.1.历史

迄今为止，软件开发经历了如下几个阶段：

1. 单机
2. 分布式
3. 微服务

1.单机：

all in one 所有功能模块塞在一个工程中。

例如下面是一个单机的电商系统：

2.分布式：

将一个工程复制成多份，放到多个服务器上，组成服务器集群，再使用诸如Nginx的技术进行负载均衡。

例如下面是一个分布式的电商系统：

单纯的分布式集群存在的问题：

        1.从架构上来看各个功能模块之间依然存在很强的耦合性。修改单一模块时，任然需要对整个工程进行修改。

        2.但各功能模块使用的频率，面对的访问流量是不一样的，有的模块高可能需要更多资源，有的模块低可能不需要太多资源，而集群只是对资源进行了横向扩展，将整个工程（所有功能模块）一直复制粘贴，使得资源的分配粒度不够细，资源的利用率任不够高。

3.微服务：

马丁福勒于2014年在一篇文章中提出微服务架构，原文地址如下：

Microservices

微服务只是一个概念，目前业内还没有统一的标准。

微服务的概念大致如下：

将大系统划为一个个分开部署的小服务。小服务独立运行，采用轻量级的通信机制进行相互沟通、调用。

由于通信底层基本是采用面向API的http请求，模块之间只有数据交互，并无直接的代码调用，所以不同模块可以采用不同的编程语言来编写。

例如下面是是个微服务的电商系统：

1.2.两个核心问题

微服务架构的2个核心问题

服务发现，服务的消费方如何发现服务的提供方。

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

除以上两点外容错、监控等能力都属于架构的扩展能力。

以上两个问题的实现本质上其实都是使用代理：

        在服务消费者和服务提供者之间使用一个中间层来做代理，服务发现和负载均衡均由代理层来实现，消费者通过代理层来间接访问目标服务。

根据代理层实现细节的不同，当前主流的微服务架构分为三种模式：

1. 集中式
2. 客户端嵌入式
3. 主机独立进程

2.主流模式

2.1.集中式

代理层独立部署，使用软件负载均衡器（nginx）或硬件负载均衡器（F5）+DNS域名服务器来实现。目前采用该模式的有：eBay、携程。

2.2.客户端嵌入式

服务单独注册到注册中心当中，

服务发现能力、负载均衡能力嵌入到客户端中。

此模式是当前使用最多的模式，经典的实现有：

Netflix的eureka+ribbon

Alibaba的dubbo

2.3.主机独立进程

服务发现能力、负载均衡能力独立出来作为一个进程，部署在消费者所在的主机，该主机上的多个消费者可以共用一个代理。目前采用该模式的有：唯品会。

2.4.对比

三种模式各有优劣，不同的厂商选择了不同的架构，基于它们之上均有比较成功的实现。

模式 优点 缺点 适用场景 公司案例

集中式 运维简单、治理集中 面对大流量时会有性能瓶颈 各类公司其实都能用 eBay、携程

客户端嵌入式 面对大流量时性能好 客户端的实现较复杂、治理比价分散 中大规模公司、语言栈较统一 twitter finagle、阿里dubbo、新浪微博

主机独立进程式 折中方案 运维、部署比较麻烦 中大规模公司、运维能力强 唯品会

3.服务网格

ServiceMesh，服务网格，被视作”下一代技术“，但其本质就是主机独立进程这种架构。在三种模式中主机独立进程这种模式相对来说优点更多：

主机独立进程这种架构相比于集中式来说不存在单点问题、相对于客户端嵌入式来说，有语言无关性、相对具有可集中管理的特性。

相对集中指的是：

客户端嵌入式中服务发现能力和负载均衡能力是各个消费者客户端自己持有，比如eureka+ribbon这种模式，每个消费者客户端都是各自在代码层去通过注解、配置实现一套。

将服务发现能力和负载均衡能力独立出来以后，至少在同一个机器上多个应用都使用的是同一套，在该机器上相对而言具有了可管理性。

服务网格就是基于主机独立模式发展起来的理念。因为能力都独立出来在本机以进程的方式对应用进行支持，所以业务和能力之间可以完全解耦，在独立出来的进程中可以向其中无限添加能力来为本机的应用提供能力扩展。

总结起来就是说能力交给环境，业务专注于业务。很像”边车“：

 因此服务网格，ServiceMesh也叫边车模式（Sidecar）。

在服务网格中抽象出来的代理进程称为sidecar。