架构解密从分布式到微服务：几种常见的微服务架构方案

几种常见的微服务架构方案

下面讲解几种常见的微服务架构方案。

ZeroC IceGrid微服务架构

ZeroC IceGrid是一种微服务架构， 由RPC架构发展而来，具有良好的性能与分布式能力，如下所示是它的整体示意图。

IceGrid具备微服务架构的如下明显特征。

首先，微服务架构需要-个集中的服务注册中心，以及某种服务发现机制。IceGrid 服务注册采用XML文件来定义，其服务注册中心就是Ice Registry, 这是一个独立的进程， 并且提供了HA高可用机制:对应的服务发现机制就是命名查询服务，即LocatorService提供的API，可以根据服务名查询对应的服务实例的可用地址。

其次，微服务架构中的每个微服务通常都被部署为一个独立的进程，在无状态服务时，一般会由多个独立进程提供服务。对应在IeeGrid里，一个IceBox就是一一个单独的进程，当一个IceBox只封装-一个 Servant时，就是一个典型的微服务进程了。

然后,在微服务架构中通常都需要内嵌某种负载均衡机制。在IceGrid里是通过客户端API内嵌的负载均衡算法实现的，相对于采用中间件Proxy 转发流量的方式，IceGrid 的做法更加高效，但增加了平台开发的工作量与难度，因为采用各种语言的客户端都需要实现一遍负载均衡的算法逻辑。

最后，一个好的微服务架构平台应该简化和方便应用部署。我们看到IceGrid 提供了grid.xml来描述与定义一个基于微服务架构的Aplication，一个命令行工具一键部署这个Application,还提供了发布二进制程序的辅助工具一icepatch2。下图显示了icepatch2 的工作机制，icepatch2server 类似于FTP Sever, 用于存放要发布到每个Node上的二进制代码与配置文件，位于每个Node上的icepatch2client 则从icepatch2server. 上拉取文件，在这个过程中采用了压缩传输及差量传输等高级特性，以减少不必要的文件传输过程。客观地说，在Docker技术之前，icepatch2 这套做法还是很先进与完备的，也大大减少了分布式集群下微服务系统的运维工作量。

如果基于 le Grid 开发系统 则通常有三种典型的技术方案，下图展示了这三种技术方案。

其中方案一 是比较符合传统Java Web项目的一种渐进改造方案，在Spring Boot 里只有Contoller组件而没有数据访问层与Service对象，这些Controller组件通过Ice RPC方式调用被部署在IceGrid中的远程Ice微服务，面向前端包装为REST服务。此方案的整体思路清晰，分工明确。

方案二与方案三则比较适合前端JavaScript能力强的团队，比如很擅长Node.js的团队可以考虑方案二，即用JavaScript来代替Spring Boot实现REST服务。主要做互联网App的系统则可以考虑方案三，浏览器端的JavaScript以HTML5的WebSocket技术与Ice Glacier2直接通信,整体高效敏捷。

IceGrid在3.6版本之后还增加了容器化的运行方式，即Ice Node 与Ice Registry 可以通过Docker容器的方式启动，这就简化了IceGrid 在Linux.上的部署。对于用Java编写的Ice微服务架构系统,我们还可以借助Java远程类加载机制，让每个Node都自动从某个远程HTTPServer下载指定的JAR文件并加载相关的Servant类，从而实现类似于Docker Hub的机制。

SpringCloud微服务架构

Spring Cloud是基于Spring Boot的一.整套实现微服务的框架，因此它只能采用Java,这是它与其他几个微服务架构的明显区别。Spring Cloud 是-一个包含了很多子项目的整体方案，其中由Netlix开发后来又并入Spring Cloud的Spring Cloud Netlix是Spring Cloud微服务架构的核心项目，即可以简单地认为Spring Cloud 微服务架构就是Spring Cloud Netlix, 后面我们用Spring Cloud时如果不特意声明，就是指Spring Cloud Netflix。

首先，Spring Cloud中的服务注册中心是Eureka模块，它提供了-一个服务注册中心、服务发现的客户端，还有一个简单的管理界面，所有服务都使用Eureka的服务发现客户端来将自己注册到Eureka中，如下所示为相关示意图，你会发现它很像之前第4章中的某个图。

那么Spring Cloud是如何解决服务的负载均衡问题的呢?由于Spring Cloud的微服务接口主要是基于REST协议实现的，因此它采用了传统的HTTP Proxy 机制。如下图所示，Zuul 类似于一个Nginx服务网关，所有客户端请求都通过这个网关来访问后台的服务。

Zuul从Eureka那里获取服务信息，自动完成路由规则的映射，无须手工配置，比如上图中的URL路径/customer/*就被映射到Customer这个微服务上。当Zuul转发请求到某个指定的微服务上时，会采用类似于ZeroC IceGrid的客户端负载均衡机制，被称为Ribbon组件，如下所示为Zzuul与Eureka的关系及实现服务负载均衡的示意图。

如下所示是Spring Cloud 微服务架构平台的全景图。我们看到它很明显地继承了SpringFramework一贯的思路一集大成!

从图中来看，Spring Cloud微服务架构平台集成了以下项目开发中常用的技术与功能模块。

●基于Spring Security的OAuth模块，解决服务安全问题。

●提供组合服务(Composite Services) 的能力。

●电路断路器Hystrix,实现对某些关键服务接口的熔断保护功能，如果一 个服务没有响应(如超时或者网络连接故障),则Hytrix可以在服务消费方中重定向请求到回退方法( flbak method)。如果服务重复失败，则Hystrix 会快速失败(例如直接调用内部的回退方法，不再尝试调用服务)，直到服务重新恢复正常。

●监控用的 Dashboard,可以减少运维相关的开发工作量。

总体来说，Spring Cloud是代替Dubbo的一种好方案，Spring Cloud是基于REST通信接口的微服:务架构，而Dubbo以RPC通信为基础。对于性能要求不是很高的Java互联网业务平台，采用Spring Cloud是-一个门槛相对较低的解决方案。

基于消息队列的微服务架构

除了标准的基于RPC通信(以及类RPC的通信如HTTP REST、SOAP等)的微服务架构，还有基于消息队列通信的微服务架构，这种架构下的微服务采用发送消息(Publish Message)与监听消息(Subscribe Message) 的方式来实现彼此之间的交互。下图是这种微服务架构下各个组件之间的交互示意图，我们看到消息中间件是关键，它负责连通各个微服务与UI组件，承担了整个系统互联互通的重任。

基于消息队列的微服务架构是全异步通信模式的一种设计， 各个组件之间没有直接的耦合关系，也不存在服务接口与服务调用的说法，服务之间通过消息来实现彼此的通信与业务流程的驱动，从这点来看，基于消息队列的微服务架构非常接近Actor模型。实际上，分布式的Actor模型也可以算作一种微服务架构，并且在微服务概念产生之前就已经存在很久了。下面是一个购物网站的微服务设计示意图，我们看到它采用了基于消息队列的微服务架构。

网易的蜂巢平台就采用了基于消息队列的微服务架构设计思路，如下图所示，微服务之间通过RabitMQ传递消息，实现通信。

与上面几种微服务架构相比，基于消息队列的微服务架构并不多，案例也相对较少,更多地体现为一种与业务相关的设计经验，各家有各家的实现方式，缺乏公认的设计思路与参考架构，也没有形成-一个知名的开源平台。如果需要实施这种微服务架构，则基本上需要项目组自己已从零开始设计- -个微服务架构基础平台， 其代价是成本高、风险大，在决策之前需要架构师“接地气”地进行全盘思考与客观评价。

Docker Swarm微服务架构

Docker Swarm (后简称Swarm)其实是Docker公司“高仿”Kubernetes微服务架构平台的一个产 品，在业界始终缺乏影响力。2016年发布Docker 1.12时, Swarm就被集成到Docker Engine中而不再作为单独的工具发布了。

Swarmn的最初目标是将一些独立的Docker主机变成一个集群，如下图所示，我们通过简单的Docker命令行工具就能创建一个 Swarm集群。

随着Kubermetes微服务架构平台应用越来越广泛，Docker 公司开始努力让Swarm向着Kubernetes的方向靠拢，即变成一个基于容器技术的微服务平台。下面给 出了Swarm集群的结构图。

我们从上图中看到，在一个Swarm集群中有两种角色的节点。

●Swarm Manager: 负责集群的管理、集群状态的维持及调度任务(Task) 到工作节点(Swarm Node)上等。

●Swarm Node:承载运行在Swarm集群中的容器实例，每个Node都主动汇报在其上运行的任务(Task) 并维持同步状态。

Docker Compose是一个官方编排项目，提供了一个YAML格式的文件，用于描述一个容器化的分布式应用，并且提供了相应的工具来实现一键部署的功能。下图给出了两节点的Couchbase集群对应的YAML文件定义，此Couchbase集群随后被部署到了Swarm集群中的两个Node节点上。