微服务架构模式

微服务架构须要考虑的问题

首先搞清楚，集群是个物理形态，分布式是个工做方式，web

分布式是指将不一样的业务分布在不一样的地方。分布式是以缩短单个任务的执行时间来提高效率的，而集群则是经过提升单位时间内执行的任务数来提高效率。数据库

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成后端

固然分布式确定属于微服务。设计模式

微服务的设计是为了避免由于某个模块的升级和BUG影响现有的系统业务。微服务与分布式的细微差异是，微服务的应用不必定是分散在多个服务器上，他也能够是同一个服务器。缓存

分布式和微服的架构很类似，只是部署的方式不同而已。安全

首先微服务，或者说分布式要遵循CAP服务器

一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）网络

 

一、服务间的调用架构

二、服务的注册发现并发

三、服务的容错（高可用）

四、数据调用及传输

五、API Gateway

六、服务的部署

 

定义

架构为了解耦，实际开发的方式采用分布式系统开发，围绕业务领域，业务领域定义了边界，DDD领域驱动设计，来建立组件应用，这些应用能够进行独立的开发，管理和迭代。在分散的组件当中使用云架构和平台式部署，管理和服务功能，使产品交付的更快

本质

用一些功能比较明确，业务比较精炼的服务去解决更大、更实际的问题。

微服务这个概念在2012年提出来的

与传统架构的区别

系统架构遵循三个标准

一、提升敏捷性：及时响应业务需求，促进迭代

二、提高用户的体验：减小用户流失

三、下降成本：下降增长产品、客户或者业务方案的成本

传统开发模式

和微服务相比，这种模式称为单体开发

全部的功能打包在一个WAR包里，基本没有外部依赖（除了容器），部署在一个JavaEE容器（Tomcat，JBoss，WebLogic）里，包含DO/DAO，Service，UI等全部的逻辑

优势：

一、开发简单，集中式管理

二、基本不会重复开发

三、功能都在本地，没有分布式调用的消耗（网络请求，rpc框架）

缺点：

一、效率低：开发都在一个服务当中，冲突问题难以解决

二、维护难：代码耦合度高

三、不灵活：构建时间长，小的修改影响整个服务

四、稳定性差，高可用差：一个问题致使整个大的服务不可用

五、扩展性弱：没法知足高并发下的需求

微服务架构

目的是为了解决敏捷开发和快速迭代的过程

服务之间还有相互调用和同步事务

微服务特征

一、一系列的独立服务共同组成系统

二、单独部署，跑在本身的进程中

三、每一个服务单独开发

四、分布式管理

五、强隔离性

标准

一、分布式服务组成的系统

二、按照业务，进行划分，而不是技术划分（领域驱动设计DDD）

三、自动化运维（DevOps）

四、高度容错性

五、快速迭代

微服务要解决的问题

一、这么多服务，客户端如何访问？

二、服务与服务之间如何通讯？

三、服务如何治理？

四、服务挂了怎么办？

 

解决

一、当客户端多ip问题，或者移动端（APP），那么APP更新，只有20%的人更新，剩下80%不更新，那就出现访问问题，这时候须要API Gateway管理，API的域名能够保持不变。

首先几个概念

Route（路由）：这是网关的基本构建块。它由一个ID，一个目标URI，一级断言和一组过滤器定义。若是断言为真，则路由匹配。

Predicate（断言）：输入类型是一个ServerWebExchange。咱们可使用它来匹配来自HTTP请求的任何内容，例如headers或参数

Filter（过滤器）：Gateway中的Filter分为两种类型，分别是Gateway Filter和Global Filter。过滤器会对请求和响应进行修改和处理。

网关的功能

一、请求接入：做为全部的API接口服务请求的接入点

二、业务聚合：做为全部后端业务服务的聚合点

三、中介策略：实现安全、验证、路由、过滤、流控等策略、

四、统一管理：对全部API服务和策略进行统一管理

二、对于内部通讯，RPC通讯，最大的好处就是传输效率高，能够进行压缩（序列化），那么就有解压（反序列化）

对外就是REST（也须要序列化和反序列化），这里须要两次序列化和两次反序列化，多一次将对象序列化转Json，再序列化Json，并且对象还大

对于微服务当中最主要的问题，各个服务之间的通讯是最重要的，那么要解决的就是服务之间数据传输的过程，一是数据传输的速率，二是数据传输的安全性，对于内部服务通讯，也就是内网通讯，保证长链接以及传输的数据包比较小，不建议大对象数据的传输经过rpc进行，对外使用http，也就是在不一样的局域网，那么这种防火墙也只有字符串才能进行无状态传输，而rpc是二进制数据，就不能进行跨局域网传输

 

对于各个服务是独立部署在机器上，那么出现的问题就是要服务注册与发现，要保证各个服务的ip注册和后期调用对应服务的发现

这里能够根据实际业务场景去选用合适的服务注册发现的技术选型，由于对于微服务要保证的就是高可用，从始至终都要保证网络抖动和丢包的可能性，那么就要保证全部通讯都要有本身重试机制，也就是消费端必定都要作幂等的措施

三、那么服务注册与发现，这里必定有全部服务的注册IP列表

 

聚合器微服务设计模式

最简单的设计模式

 

聚合器调用多个服务实现应用程序所需的功能。它能够是一个简单的web页面，将检索到数据进行处理展现。它能够是一个更高层次的组合微服务，对检索到的数据增长业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。另外，每一个服务都有本身的缓存和数据库。若是聚合器是一个组合服务，那么也有本身的缓存和数据库。聚合器能够沿X轴和Z轴独立扩展。

代理微服务设计模式

聚合模式的一个变种。

 

在这种状况下，客户端并不聚合数据，但会根据业务需求的差异调用不一样的微服务。代理仅仅委派请求，也能够进行数据转换

代理不一样与聚合的点是能够转发到对应的服务

链式微服务设计模式

这种模式在接受到请求后会产生一个通过合并的响应

 

在该状况下，service A接收到请求后会与service B进行通讯，一样 B C也会相互通讯，全部服务都使用同步消息传递。在整个链式调用完成以前，客户端一直阻塞。所以，服务调用链不宜过长，以避免客户端长时间等待。

分支微服务设计模式

基于聚合器模式扩展，能够同时调用两个服务

数据共享设计模式

这时候可能C、D服务共用分支模式，可能将优惠券和优惠券详情两个服务

异步消息传递设计模式

使用MQ实现各个服务之间的调用