《企业微服务架构设计方案》由会员分享，可在线阅读，更多相关《企业微服务架构设计方案（16页珍藏版）》请在金锄头文库上搜索。
1、企业微效劳架构设计方案ZeroCIceGrid、Spring Cloud、基于消息队列、Docker Swarm微效劳架构是当前很热门的一个概念， 它不是凭空产生的， 是技术进展的必定结果。虽然微效劳架构没有公认的技术标准和标准草案，但业界已经有一些很有影响力的开源微效劳架构平台，架构师可以依据公司的技术实力并结合工程的特点来选择某个适宜的微效劳架构平台， 以此稳妥地实施工程的微效劳化改造或开发进程。本文盘点了四种常用的微效劳架构方案，分别是 ZeroCIceGrid、Spring Cloud 、基于消息队列与 Docker Swarm。16ZeroCIceGrid 微效劳架构ZeroCIce
2、Grid 作为一种微效劳架构，它基于 RPC 框架进展而来，具有良好的性能与分布式力量，如下所示是它的整体示意图。IceGrid具备微效劳架构的如下明显特征。首先，微效劳架构需要一个集中的效劳注册中心，以及某种效劳觉察机制。IceGrid效劳注册承受 XML 文件来定义， 其效劳注册中心就是 IceRegistry ， 这是一个独立的进程， 并且供给了 HA 高可用机制；对应的效劳觉察机制就是命名查询效劳，即 LocatorService 供给的 API ， 可以依据效劳名查询对应的效劳实例可用地址。其次，微效劳架构中的每个微效劳通常会被部署为一个独立的进程，当无状态效劳时，一般会由多个独立进
3、程供给效劳。对应在 IceGrid 里， 一个 IceBox 就是一个单独的进程， 当一个 IceBox 只封装一个 Servant 时， 就是一个典型的微效劳进程了。然后，微效劳架构中通常都需要内嵌某种负载均衡机制。在 IceGrid 里是通过客户端 API 内嵌的负载均衡算法实现的，相对于承受中间件 Proxy 转发流量的方式，IceGrid 的做法更加高效，但增加了平台开发的工作量与难度，由于承受各种语言的客户端都需要实现一遍负载均衡的算法规律。最终，一个好的微效劳架构平台应当简化和便利应用部署。我们看到 IceGrid 供给了 grid.xml 来描述与定义一个基于微效劳架构的 App
4、lication，一个命令行工具一键部署这个 Application，还供给了公布二进制程序的关心工具icepatch2。以下图显示 icepatch2 的工作机制，icepatch2server 类似于 FTP Sever，用于存放要公布到每个 Node 上的二进制代码与配置文件，而位于每个 Node 上的 icepatch2client 那么从 icepatch2server 上拉取文件，这个过程中承受了压缩传输及差量传输等高级特性，以削减不必要的文件传输过程。客观地评价， 在 Docker 技术之前，icepatch2 这套做法还是很先进与完备的，也大大削减了分布式集群下微效劳系统的运维
5、工作量。假设基于 IceGrid 开发系统，那么通常有三种典型的技术方案，以下图呈现了这三种技术方案。其中方案一是比较符合传统 Java Web 工程的一种渐进改造方案， Spring Boot 里只有Controller 组件而没有数据访问层与 Service 对象， 这些 Controller 组件通过 Ice RPC 方式调用部署在 IceGrid 里的远程的 Ice 微效劳，面对前端包装为 REST 效劳。此方案的整体思路清楚， 分工明确。Leader 在开源工程中给出了这种方式的一个根本框架以供参考： s:/github /MyCATApache/mycat-ice 。方案二与方案三
6、那么比较适合前端 JavaScript 力量强的团队， 比方很擅长 Node.js 的团队可以考虑方案二， 即用 JavaScript 来替代 Spring Boot 实现 REST 效劳。主要做互联网App 的系统那么可以考虑方案三， 扫瞄器端的 JavaScript 以 HTML5 的 WebSocket 技术与 Ice Glacier2 直接通信， 整体高效灵敏。IceGrid 在 3.6 版本之后还增加了容器化的运行方式，即 Ice Node 与 Ice Registry 可以通过 Docker 容器的方式启动，这就简化了 IceGrid 在 Linux 上的部署。对于用 Java 编
7、写的 Ice 微效劳架构系统，我们还可以借助 Java 远程类加载机制，让每台Node 自动从某个远程 Server 下载指定的 Jar 包并加载相关的 Servant 类，从而实现类似 Docker Hub 的机制。以下图显示了前面提到 mycat-ice 开源工程时给出的具体实现方案。Spring Cloud 微效劳架构SpringCloud 是基于 SpringBoot 的一整套实现微效劳的框架， 因此它只能承受 Java 语言， 这是它与其他几个微效劳框架的最明显区分。SpringCloud 是一个包含了很多子工程的整体方案，其中由 Netflix 开发后来又并入 Spring Clo
8、ud的 Spring Cloud Netflix 是 SpringCloud 微效劳架构的核心工程， 即可以简洁地认为 SpringCloud 微效劳架构就是 Spring Cloud Netflix，后面我们用 Spring Cloud时假设不特意声明，就是指 Spring Cloud Netflix。首先，Spring Cloud 中的效劳注册中心是 Eureka 模块，它供给了一个效劳注册中心、效劳觉察的客户端，还有一个简洁的治理界面，全部效劳使用 Eureka 的效劳觉察客户端来将自己注册到 Eureka 中，如下所示为相关示意图，你会觉察它很像之前第 4 章中的某个图。那么 Spri
9、ng Cloud 是如何解决效劳的负载均衡问题的呢？由于 Spring Cloud 的微效劳接口主要是基于 REST 协议实现的，因此它承受了传统的 Proxy 机制。如以下图所示，Zuul 类似一个 Nginx 的效劳网关，全部客户端恳求都通过这个网关来访问后台的效劳。Zuul 从 Eureka 那里猎取效劳信息，自动完成路由规章的映射，无须手工配置，比方上图中的URL 路径/customer/*就被映射到 Customer 这个微效劳上。当 Zuul 转发恳求到某个指定的微效劳上时，会承受类似ZeroCIceGrid 的客户端负载均衡机制，被称为 Ribbon 组件，以下图给出了 Zuul
10、 与 Eureka 的关系及实现效劳负载均衡的示意图。如下所示是 Spring Cloud 微效劳架构平台的全景图。我们看到它很明显地继承了 Spring Framework 一贯的思路集大成！从图中来看，Spring Cloud微效劳架构平台集成了以下一些实际工程开发中常用的技术与功能模块。基于 Spring Security 的 OAuth 模块，解决效劳平安问题。供给组合效劳 Composite Services 的力量。电路断路器Hystrix ，实现对某些关键效劳接口的熔断保护功能，假设一个效劳没有响应 如超时或者网络连接故障 ， 那么 Hystrix可以在效劳消费方中重定向恳求到回
11、退方法 fallback method 。假设效劳重复失败， 那么 Hystrix会快速失败 例如直接调用内部的回退方法， 不再尝试调用效劳 ， 直到效劳重新恢复正常。监控用的 Dashboard ， 可以简化运维相关的开发工作量。总体来说，Spring Cloud 是替代 Dubbo 的一种好方案，虽然 Spring Cloud 是基于 REST 通信接口的微效劳架构， 而 Dubbo 以 RPC 通信为根底。对于性能要求不是很高的 Java 互联网业务平台， 承受 Spring Cloud 是一个门槛相对较低的解决方案。基于消息队列的微效劳架构除了标准的基于 RPC 通信以及类 RPC 的
12、通信如 Rest、SOAP 等的微效劳架构，还有基于消息队列通信的微效劳架构，这种架构下的微效劳承受发送消息Publish Message与监听消息Subscribe Message 的方式来实现彼此之间的交互。以下图是这种微效劳架构下各个组件之间的交互示意图，我们看到消息中间件是关键，它负责连通各个微效劳与 UI 组件，担当了整个系统互联互通的重任。基于消息队列的微效劳架构是全异步通信模式的一种设计，各个组件之间没有直接的耦合关系，也不存在效劳接口与效劳调用的说法，效劳之间通过消息来实现彼此的通信与业务流程的驱动，从这点来看，基于消息队列的微效劳架构格外接近 Actor 模型。实际上，分布式
13、的 Actor 模型也可以算作一种微效劳架构，并且在微效劳概念产生之前就已经存在很久了。下面是一个购物网站的微效劳设计示意图，我们看到它承受了基于消息队列的微效劳架构。网易的蜂巢平台就承受了基于消息队列的微效劳架构设计思路，如以下图所示，微效劳之间通过 RabbitMQ 传递消息，实现通信。与上面几种微效劳架构相比，基于消息队列的微效劳架构并不多，案例也相对较少，更多地表达为一种与业务相关的设计阅历，各家有各家的实现方式，缺乏公认的设计思路与参考架构，也没有形成一个知名的开源平台。因此，假设需要实施这种微效劳架构，那么根本上需要工程组自己从零开头去设计实现一个微效劳架构根底平台，其代价是本钱高
14、、风险大， 因此决策之前需要架构师“ 接地气” 地进展全盘思考与客观评价。Docker Swarm 微效劳架构DockerSwarm 其实是 Docker 公司“ 高仿” Google 开源的 Kubernetes微效劳架构平台的一个产品，但始终无法跟上对手的脚步，在业界始终缺乏影响力。2021 年公布 Docker1.12 时， Docker Swarm就被强行集成到了 Docker Engine中而不再作为单独的工具公布了，这类似当年微软推广 IE 扫瞄器的做法。不过即使这样，也难以掩盖 Docker Swarm 还没成名就已经陨落的事实。Docker Swarm 的最初目标是将一些独立的 Docker 主机变成一个集群，如以下图所示，我们通过简洁的 Docker命令行工具就能创立一个 Swarm 集群。后来随着 Kubernetes 微效劳架构平台越来越火，Docker 公司开头努力让 Swarm 向着 Kubernetes 的方向靠拢，即变成一个基于容器技术的微效劳平台
