服务⽹格Istio之微服务架构设计模式
微服务架构的构件原创
扼杀者模式
它们是传统、庞⼤的单体应⽤。扼杀者模式为此⽽⽣。这种模式会创建两个独⽴的应⽤，⼀同运⾏在同样的 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
蓝绿部署模式
在微服务架构中，⼀个应⽤会由多个服务构成，如果停掉所有服务，部署⼀个增强版本，停机时间会对业务造成很⼤影响。同样回滚过程也会是⼀个噩梦。蓝绿部署模式避免了这种问题。蓝绿部署的策略能够降低或免除服务的停机时间。这种策略同时运⾏两个⼀致的⽣产环境，⽤这种⽅式来解决问题。假设绿⾊是现存的服务实例，⽽蓝⾊是新版本。任何时间⾥，只有⼀个环境是在线的，这个在线环境会处理所有⽣产通信。所有的云平台都提供了蓝绿部署的⽀持

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。