微服务架构的构件原创
扼杀者模式
它们是传统、庞大的单体应用。扼杀者模式为此而生。这种模式会创建两个独立的应用，一同运行在同样的 URI 空间中。随着时间点的推移，新的重构了的应用会扼杀或者替换掉原有应用，最后就可以关掉单体应用了。这种模式分为 转换、共存 和 终结 三个步骤
单体你继续运营者, 我慢慢把你替换掉
舱壁模式
这个模式把应用的元素隔离开来，这样一个失败之后，其它的还能继续工作。这个模式可以类比船体结构，因此被称为舱壁。根据消费者的负载以及可用性要求，把服务分割为不同的群。这种设计能够对故障进行隔离，即使遇到故障，也能为部分消费者提供服务
注： 舱壁模式（Bulkhead）隔离了每个工作负载或服务的关键资源，如连接池、内存和 CPU，使用舱壁避免了单个工作负载（或服务）消耗掉所有资源，从而导致其他服务出现故障的场景，这种模式主要是通过防止由一个服务引起的级联故障来增加系统的弹性（舱壁模式降低依赖服务对整个系统的影响，保护有限的资源不被耗尽，增加了系统得到弹性）
Sidecar 模式
这种模式把应用的组件部署到一个不同的容器中，从而更好地完成隔离和封装。这种模式让应用能够把多种组件和技术整合在一起。这种模式的情况很像摩托车的挎斗，因此被称为 Sidecar，Sidecar 附着在主应用上，并且为主应用提供支持能力。Sidecar 还和主应用共享同样的生命周期，它的创建和销毁都是和主应用同步进行的。Sidecar 模式有时也被称为 Sidekick 模式
栗子: 我在开发中需要做日志收集, 我可以给你的业务而外加装 日志收集等等, 就像吃鸡的3轮摩托一样, 而外的座位就是加装过来的,丢了也没事,不影响业务.
集成模式
API 网关模式
应用被分解成更小的微服务之后，就会出现一些待解决的问题
- 如何处理来自不同渠道的不同微服务的调用
- 如何处理不同的协议
- 不同消费者可能需要不同格式的响应
API 网关就是用来处理这类问题的
- API 网关是所有微服务调用的单一入口
- 可以作为代理服务器，将特定请求路由到特定微服务
- 可以把调用结果进行聚合，发回给消费者
- 可以为每种类型的客户端创建细粒度的 API
- 还能转化请求和响应的协议
- 可以代微服务进行认证、鉴权的工作
聚合模式
业务功能被分拆为多个更小的代码段之后，如何把各个微服务返回的数据进行整合就是个问题了。这种责任不应该抛给消费者自行解决。聚合模式可以解决这种问题，这种模式的关键是如何把多个不同服务的响应数据进行聚合，然后将最终响应发回给消费者。可以用两种方式来完成任务：
- 用一个复合微服务调用所有必须的微服务，把数据拼装成合适的结果发回给客户端
- 用 API 网关把请求拆分为对多个微服务的调用，然后聚合返回结果发回给客户端
如果这一过程中有业务逻辑，推荐使用复合微服务的方式。其它情况下，API 网关是个好方法
前台-中台-后台 中外就是聚合模式
代理模式
对外的 API 网关
对内的 API 网关
这种 API 网关只会使用 API 网关开放微服务。例如一个 API 网关有三个 API 模块：
- 移动 API： 为手机客户端提供 API
- 浏览器 API： 为浏览器中运行的 JavaScript 应用提供 API
- 公共 API： 为第三方开发者提供的 API
大范围栗子: 小程序用一套API, APP用一套API, 网页用一套API
小范围栗子: 按照功能去划分API
路由网关模式
这种 API 网关负责对请求进行路由。它通过将请求路由给特定服务的方式来完成 API 调用。当它接到请求的时候，会根据请求在路由表中查找合适的服务。举个例子来说，路由表可能会将一个 HTTP 方法和路径映射为服务的 HTTP URL。这种能力和 NGINX 等服务器的反向代理功能一致
链式微服务模式
有的微服务会有多种依赖，例如销售服务依赖于产品和订单服务。链式微服务模式能够为请求提供合并的结果，微服务 1 收到的请求会向后传递给微服务 2 和微服务 3。所有这些服务都是同步调用
A调用B调用C
客户端分解模式
说白了就是前后分离的开发模式
数据库模式
在微服务中定义数据库架构，需要考虑几个要点：
- 服务必须松耦合。可以独立的被开发、部署以及扩缩容
- 业务事务可能需跨越多个服务
- 有的业务事务需要查询隶属于多个服务的多种数据
- 数据库必须能够被复制或者共享从而满足规模要求
- 不同服务有不同的数据存储需求
服务独占数据库
为了满足上述要素，每个服务必须拥有各自的数据库；数据库必须被特定服务所独占。对这些独占数据是不能直接访问的，只能通过微服务 API 进行数据访问。例如关系型数据库来说，可以用服务专属的数据表、专属结构或者专属数据库
服务共享数据库
微服务领域的理想情况就是每个服务都独占数据库。那么共享数据库就是反模式的。但是在单体应用拆分为微服务的过程中可就没那么容易了。后面的阶段中，可以转向每个服务独占数据库的模式。共享数据库并不理想，但是在迁移过程中是有用的。多数人会认为这不符合微服务需求，但是对于既有应用，这是一个好的拆分起点。绿地应用就不该这样了
命令查询隔离
命令和查询的隔离 (CQRS)，一旦实现了服务独占数据的模式，就有了拼接多个服务的数据的需要。CQRS 把应用分成两部分 —— 命令和查询
命令端用来处理创建、更新和删除
查询端用物化视图来处理查询
事件源模式会为任何数据变更创建事件。物化视图订阅事件流，以此来保持更新。事件源模式的典型用法就是根据数据来管理应用程序的当前状态。例如传统的增删改查模型是从存储读取数据的。这其中存在锁定数据的需要，通常要用事务来解决
就是,读取是读取的服务,写是写的服务
事件源模式
也就是异步通讯,每一次事件都走消息队列
Saga 模式
简单的说就是 去中心化和中心化两种感觉
一种主动请求(主动),一种订阅请求(被动)
观察模型
日志聚合
日志聚合针对的是包含多个服务的应用。请求经常会跨越多个服务实例。每个服务实例都生成标准格式的日志文件。我们需要一个中央日志服务，把各个服务实例的日志聚合起来。用户可以对日志进行搜索和分析。可以对日志系统进行配置，如果出现了特定信息，就触发告警。例如 PCF 的日志聚合器会从 PCF 的每个组件（router、controller、diego 等）和应用中搜集日志。AWS 的 Cloud Watch 也做了同样的事情
性能指标
微服务架构下服务数量会急剧增加，就需要提高监控的重视程度，在问题发生时，才能及时的发送警报。需要有一个度量服务来收集各种统计信息。应用提供的报告和告警都应该发送给这个服务。聚合指标有两种模型：
推： 服务把指标推送给监控服务，例如 NewRelic、AppDynamics
拉： 监控服务自行拉取指标数据，例如 Prometheus
分布式追踪
微服务架构下，请求经常会跨越多个服务。每个服务又要用一个或多个操作，调用多个服务来处理请求。要对请求进行端到端的跟踪，有个跟踪 ID 会非常有帮助。可以用下列方法来引入事务 ID 从而解决这一问题：
- 为每个外部请求分配一个唯一的外部请求 ID
- 把外部请求的 ID 传递到所有服务
- 在所有日志信息中输出这一外部的请求 ID
健康检查
实现了微服务架构之后，微服务自身可能出现无法处理业务的情况。每个服务都需要有一个端点，用来检查应用的健康情况。这个 API 可以检查主机的状态、到其它服务、基础设施的连接情况，以及一些别的逻辑
跨领域模式
外部化配置
服务通常会调用其它服务以及数据库。多个环境中，例如开发、测试、生产等，端点地址或者一些配置属性可能不同。这些属性中的任何变动都可能需要服务的重新构建和部署。为了这种情况，建议使用外部配置，例如 URL 和登录凭据。应用应该在启动时或者随时载入配置
就像nocas的配置中心
服务发现模式
就像是 Eureka Nocas 等等服务中心
熔断模式
大家都懂熔断器, 阿里的Sentinel、 netflix的 Hystrix
蓝绿部署模式
在微服务架构中，一个应用会由多个服务构成，如果停掉所有服务，部署一个增强版本，停机时间会对业务造成很大影响。同样回滚过程也会是一个噩梦。蓝绿部署模式避免了这种问题。蓝绿部署的策略能够降低或免除服务的停机时间。这种策略同时运行两个一致的生产环境，用这种方式来解决问题。假设绿色是现存的服务实例，而蓝色是新版本。任何时间里，只有一个环境是在线的，这个在线环境会处理所有生产通信。所有的云平台都提供了蓝绿部署的支持
