课程链接:https://www.itwangzi.cn/2540.html
本文介绍了主流的常见微服务模型。
微服务可以对企业产生积极的影响。因此，了解如何处理微服务架构、一些微服务设计模式以及一个微服务架构的一些总体目标或设计原则是很有价值的。以下是微服务架构方案中值得考虑的四个目标。
1.降低成本:MSA将降低设计、实施和维护IT服务的总体成本。
2.加速发布:MSA将加速服务从想法到部署的落地。
3.增强灵活性:MSA将增强我们服务网络的灵活性。
4.打开可见性:MSA支持为服务和网络提供更好的可见性。
您需要了解构建微服务架构背后的几个设计原则:
可扩展性、可用性、韧性、灵活性、独立性、自主性、分散治理、故障隔离、自动组装和通过DevOps持续交付
听听上面的原则。你实施的解决方案或系统在投入实践的同时，也会带来一些挑战和问题。这些问题在很多解决方案中也很常见。这些问题可以通过使用正确和匹配的设计模式来克服。服务有一些设计模式，大致可以分为五类。每个类都包含许多特定的设计模式。下图显示了这些设计模式。
分解模式
按业务职能细分
说白了，微服务就是应用单一责任原则，将服务转化为松耦合。可以根据业务功能进行细分。定义与业务功能相对应的服务。业务是业务架构建模中的一个概念。这是一个企业为了创造价值而不得不做的事情。业务功能通常对应于一个业务对象，例如:
订单管理对订单负责，客户管理对客户负责。
按问题子域分解
将一个应用按照其业务功能进行分解，可能是一个好的开始，但你最终会遇到所谓的“神级”，很难再进行分解。这些类在多个服务中是通用的。在域驱动设计中，可以定义一些与子域对应的服务。DDD称应用程序的问题空也就是业务为领域。一个域由多个子域组成。每个子域对应于服务的不同部分。
子域可以分为以下几类:
核心——业务的核心竞争力，也是应用程序最有价值的部分。
支持-与业务相关，但不是核心竞争力。这些可以在内部实施，也可以外包。
通用——不特定于业务，理想情况下可以使用现成的软件来实现。
订单管理的子域包括:
产品目录服务
库存管理服务
订单管理服务
分销管理服务
根据事务/两阶段提交模式。
您可以通过事务分解服务。然后，系统中会有多个事务。事务协调器是分布式事务处理的重要参与者之一。分布式事务包括两个步骤:
准备阶段——在这个阶段，事务的所有参与者都准备好提交并通知协调者他们已经准备好完成事务。
或者提交或回滚阶段——在这个阶段，事务协调器向所有参与者发出提交或回滚命令。
2PC的问题是与单个微服务的运行时间相比，它相当慢。即使这些微服务运行在同一个网络中，它们之间的事务协调也确实会拖慢系统速度，所以这种方式通常不适合高负载的情况。
陌生人模式
以上我们看到的三种设计模式都是用来分解绿场应用的，但往往我们80%的工作都是针对灰场应用的，都是一些大的单个应用。
陌生人模式可以解决这样的问题。它将创建两个独立的应用程序，在同一个URI 空中并行运行。随着时间的推移，直到最后，新重构的应用会“杀死”或者取代原来的应用。此时，可以关闭旧的单个应用程序。扼杀应用程序的步骤是转换、共存和淘汰:
转型——用现代方法创造一个平行的全新网站。
共存-让现有的网站保持一段时间。将对现有网站的访问重定向到新网站，从而逐步实现所需的功能。
消除-从现有网站中删除旧功能。
隔间模式
让一个应用程序的元素与池相对隔离，这样其他应用程序才能继续正常工作。这种模式被称为“划分”，因为它类似于船体的划分。根据用户负载和可用性要求，服务实例被分成不同的组。这种设计有助于隔离故障，并允许用户即使在故障期间也能为一些用户维持服务。
边车模式
该模式将应用程序的组件部署到单独的处理器容器中，以提供隔离和封装。它还允许应用程序由不同的组件和技术组成。这种模式被称为边车模式，因为它类似于连接到摩托车的边车。在这种模式下，sidecar将连接到父应用程序，并为该应用程序提供功能支持。Sidecar也与父应用程序共享相同的生命周期，并且与父应用程序一起创建和退出。Sidecar模式有时被称为sidekick模式，这是我们在文章中列出的最后一个分解模式。
集成模式
网关模式
当一个应用被分解成几个更小的微服务时，这里会有一些问题需要解决:
不同渠道对多个微服务有多次调用。
需要处理不同类型的协议。
不同的消费者可能需要不同的响应格式。
API有助于解决微服务实现带来的很多问题，不仅仅是上面提到的那些。
网关是任何微服务呼叫的单一入口点。
它可以用作代理服务，将请求路由到相关的微服务。
它可以将结果汇总并发送给消费者。
该解决方案可以为每种特定类型的客户端创建细粒度的API。
它还可以转换协议请求并对其做出响应。
它还可以负责微服务的认证/授权。
聚合器模式
将业务功能分解成几个更小的逻辑代码段后，就需要考虑如何协调各个服务返回的数据。你不能把这个责任留给消费者。
聚合器模式有助于解决这个问题。它讨论了如何聚合来自不同服务的数据，然后将最终响应发送给消费者。有两种方法可以实现这一点:
1.一个复合微服务会调用所有需要的微服务，合并数据，然后转换合成数据再发回。
2.一个API网关还可以将请求划分成多个微服务，然后在发送给消费者之前汇总数据。
如果想应用一些业务逻辑，建议选择复合微服务。此外，API gateway作为这一问题的解决方案已经成为事实上的标准。
代理模式
对于API gateway，我们只用它来暴露我们的微服务。通过API gateway的引入，我们可以得到一些API级别的功能，比如安全、API分类等。在本例中，API网关有三个API模块:
1.移动API，实现FTGO移动客户端的API 2和浏览器的API，浏览器中运行的Javascript应用的API 3和公共API，实现第三方开发者需要的一些API。
网关路由模式
API负责路由请求。API网关通过将请求路由到相应的服务来实现一些API操作。当API网关接收到请求时，它查询路由映射，该映射指定将请求路由到哪个服务。路由映射可以将HTTP方法和路径映射到服务的HTTP URL。这和NGINX之类的Web服务器提供的反向代理功能是一样的。
链式微服务模式
单个服务或微服务将具有多级依赖关系。比如销售的微服务，靠产品微服务，靠订单微服务。链式微服务设计模式将帮助您提供组合请求结果。此外，搜索微信官方账号前端技术选择后台回复“大礼包”即可获得惊喜礼包。
微服务-1收到请求后，该请求将与微服务-2通信，也可能与微服务-3通信。所有这些服务都是同步调用。
分支模式
一个微服务可能需要从包括其他微服务在内的多个来源获取数据。分支微服务模式是聚合器和链设计模式的混合，允许同时处理来自两个或更多微服务的请求/响应。被调用的微服务可以是微服务链。分支模式也可以根据你的业务需求调用不同的微服务链或者单个链。
客户端UI合成模式
当通过分解业务功能/子域来开发服务时，负责用户体验的服务必须从多个微服务中提取数据。在一个单一的世界中，过去只有一个从UI到后端服务的调用，后端服务将检索所有数据，然后刷新/提交UI页面。然而，现在不同了。
对于微服务，我们必须把UI设计成一个框架，有多个面板/区域的屏幕/页面。每个板块都会调用一个单独的后端微服务来提取数据。
AngularJS和ReactJS等框架可以帮助我们轻松实现这一点。这些屏幕被称为单页应用程序。
每个团队开发一个客户端UI组件，例如AngularJS指令，它实现其服务的页面/屏幕区域。UI团队负责通过组合几个特定服务的UI组件来实现构建页面/屏幕的页面框架。
数据库模式
在为微服务定义数据库架构时，我们需要考虑以下几点:
1.服务必须松散耦合。以便它们可以独立开发、部署和扩展。
2.业务事务可能会强制多个服务保持不变。
3.一些业务交易需要查询多个服务的数据。
4.出于可伸缩性的考虑，数据库有时必须是可复制和可共享的。
5.不同的服务有不同的数据存储要求。
每个服务一个数据库。
为了解决上述问题，必须为每个微服务设计一个数据库。它必须专用于这项服务。应该只能通过微服务的API访问。其他服务不能直接访问它。例如，对于关系数据库，我们可以为每个服务使用单独的专用表，为每个服务使用单独的数据库模式，或者为每个服务使用单独的数据库服务器。
在服务之间共享数据库
我们已经说过，在微服务中，为每个服务分配一个单独的数据库是一个理想的解决方案。采用共享数据库是微服务中的一种反模式。但是，如果应用程序是单个应用程序，并试图将其拆分为微服务，那么反规范化就不那么容易了。
在后期，我们可以切换到每个服务一个数据库的模式，直到我们完全实现这一点。在服务之间共享数据库并不理想，但对于上述情况来说，这是一个实用的解决方案。大多数人认为这是微服务的反模式，但对于灰色领域的应用程序，将应用程序分解成更小的逻辑部分是一个好的开始。值得一提的是，这不应应用于绿地应用。
命令和查询职责的分离
一旦每个服务被分配了一组单独的数据库，它将自然地产生查询需求，这需要组合来自多个服务的数据。然而，这是不可能的。CQRS建议将应用程序分为两部分——命令端和查询端。
命令端处理创建、更新和删除请求。
查询端使用物化视图处理查询部分。
这通常与事件驱动模式结合使用，只要有任何数据更改，就会创建相应的事件。通过订阅事件流，我们可以保持物化视图的更新。
事件驱动
大多数应用程序需要数据，典型的方法是应用程序需要维护当前状态。例如，在创建、读取、更新和删除的传统模型中，典型的数据流是从存储中读取数据。它还包含频繁使用事务来锁定数据的限制。
搜索微信微信官方账号:java后端编程，回复:Java获取信息。
事件驱动模式定义了一种处理由一系列事件驱动的数据操作的方法，每个事件都记录在一个只加存储中。应用程序代码向事件存储发送一系列事件。这些事件以命令的方式描述了对数据执行的每个操作，它们将被保存到事件存储中。每个事件代表一组数据更改。
这些事件将保存在充当记录系统的事件存储中。发布事件的事件存储的典型用途是在应用程序触发的某些操作改变实体的物化视图时维护它们，以及与外部系统集成。例如，系统可以维护用于填充UI部分的所有客户订单的物化视图。当应用程序添加新订单、添加或删除订单中的项目以及添加运输信息时，描述这些更改的事件将被处理并用于更新物化视图。下图显示了这种模式的概况。
传奇模式
厉害！接私活必备的n个开源项目！赶紧收起来。
当每个服务都有自己的数据库，并且一个业务事务跨越多个服务时，我们如何确保服务之间的数据一致性？每个请求都有一个补偿请求，当请求失败时将执行该请求。这可以通过两种方式实现:
编排——没有中央协调，每个服务将生成并监听另一个服务的事件，并决定是否应该采取措施。编排是一种方案，其中指定两个或更多的参与者。任何一方都无法控制另一方的流程，或者对这些流程没有任何可见性，并且无法协调他们的活动和流程来共享信息和价值。当有必要跨控制/可见性域进行协调时，请使用编排。参考一个简单的场景，您可以将编排视为类似于网络协议。它规定了各方之间可接受的请求和响应模式。鼠尾草图案
编排——一名编排者将负责saga的决策和业务逻辑排序。此时，您可以控制流程中的所有参与者。当它们都在一个控制域中时，您可以控制活动的流程。当然，这通常是当你被分配到一个拥有制定业务流程控制权的组织时。传奇-模式-编排
可观测性模型
日志聚合
考虑一个应用程序包含多个服务的用例。请求通常跨越多个服务实例。每个服务实例都以标准格式生成日志文件。我们需要一个集中的日志服务，它可以汇总每个服务实例的日志。
用户可以搜索和分析日志。他们可以配置在日志中出现某些消息时触发警报。例如，PCF有一个日志聚合器，它从应用程序端的PCF平台的每个组件收集日志。AWS云手表也是这么做的。
性能指标
当由于引入微服务架构而导致服务组成增加时，保持对事务的监控就显得尤为关键，这样就可以监控这些模式，当出现问题时就会发出警报。
此外，还需要测量服务来收集有关单个操作的统计信息。它应该汇总应用程序服务的指标数据，这些数据将用于报告和报警。这里有两个总结指标的模型:
push——服务将指标推送给指标服务，比如NewRelic和app dynamics Extraction——指标服务从服务中提取指标，比如Prometheus。
分布式链路跟踪
在微服务架构中，请求通常跨越多个服务。每个服务通过跨多个服务执行一个或多个操作来处理请求。进行故障排除时，拥有一个跟踪ID是很有帮助的，我们可以端到端地跟踪一个请求。
解决方案是引入一个事务ID。可以采用以下方法:
为每个外部请求分配一个唯一的外部请求ID，将外部请求ID传输到处理请求链接的所有服务，并将外部请求ID添加到所有日志消息中。
健康检查
实施微服务架构后，服务可能会启动但无法处理事务。每个服务都需要有一个API端点，可以用来检查应用程序的健康状况，比如/health。API应该检查主机的状态、与其他服务/基础设施的连接以及任何其他特定逻辑。
交叉关注模式
外部配置
一个服务通常调用其他服务和数据库。API端点的URL或一些配置属性对于每个环境可能是不同的，例如开发、质量保证、UAT、生产等。这些属性的任何更改都可能需要重新构建和重新部署服务。
为了避免修改代码，可以使用配置。将所有配置放在外面，包括端点URL和证书。应用程序应该在启动或运行时加载它们。应用程序可以在启动时访问或刷新这些文件，而无需重新启动服务器。
发现服务模式
当微服务出现时，我们需要解决一些调用服务的问题。
在容器技术的帮助下，IP地址可以动态地分配给服务实例。每次地址更改，消费者服务都中断，需要手动更改。
对于消费者服务，他们必须记住每个上游服务的URL，这就变成了紧耦合。
因此，有必要创建一个服务注册中心，它将保存每个生产者服务的元数据和每个服务的配置。服务实例在启动时应该在注册表中注册，但在关闭时应该注销。找到了两种类型的服务:
客户端:例如:网飞尤里卡服务器:例如:AWS ALB
保险丝模式
一个服务通常通过调用其他服务来检索数据，此时下游服务可能已经死亡。在这种情况下，有两个问题:首先，请求将继续到达暂停的服务，这将耗尽网络资源并降低性能。其次，用户体验会很差，不可预测。
消费者服务应该通过代理调用远程服务，代理的行为类似于电流断路器。当连续故障的数量超过阈值时，断路器将跳闸，并且在超时期间调用远程服务的所有尝试将立即失败。超时后，断路器将允许有限数量的测试请求通过。
如果这些请求成功，断路器将恢复正常运行。否则，如果出错，超时将重新计算。如果某些操作很有可能失败，采用这种模式有助于防止应用程序在失败后继续尝试调用远程服务或访问共享资源。
蓝色部署模式
使用微服务架构时，可以将一个应用拆分成许多微服务。如果我们停止所有服务，然后部署改进的版本，停机时间将相当长，并将影响业务。同样，回滚将是一场噩梦。蓝色部署模式可以避免这种情况。
实施蓝绿色部署策略可用于减少或消除停机时间。它通过运行两个相同的生产环境(蓝色和绿色)来实现这一目标。假设绿色是现有的活动实例，蓝色是应用程序的新版本。在任何时候，只有一个环境是活动的，它为所有生产流提供服务。所有云平台都提供了实施蓝绿部署的选项。
