在优锐课的学习分享中，讨论了关于微服务的许多设计模式的详细描述。
码了很多专业的相关知识， 分享给大家参考学习。
看到这里迷路的朋友们可以先看本文的上部分内容，这样思路更清晰！
微服务的设计模式（一）
客户端UI组合模式
通过分解业务功能/子域来开发服务时，负责用户体验的服务必须从多个微服务中提取数据。 在整体世界中，从UI到后端服务只有一次调用，以检索所有数据并刷新/提交UI页面。 但是，现在不一样了。 对于微服务，必须将UI设计为具有屏幕/页面的多个部分/区域的框架。 每个部分都将调用单个后端微服务以提取数据。 诸如AngularJS和ReactJS之类的框架可以轻松地做到这一点。 这些屏幕称为单页应用程序（SPA）。 每个团队都开发一个客户端UI组件，例如AngularJS指令，该组件实现其服务的页面/屏幕区域。 UI团队负责通过组合多个特定于服务的UI组件来实现构建页面/屏幕的页面框架。
数据库模式
在定义微服务的数据库架构时，我们需要考虑以下几点。
服务必须松散耦合。 它们可以独立开发，部署和扩展。
商业交易可能会强制涉及多个服务的不变式。
一些业务交易需要查询多个服务拥有的数据。
有时必须复制和共享数据库才能进行扩展。
不同的服务具有不同的数据存储要求。
每个服务的数据库
为了解决上述问题，必须为每个微服务设计一个数据库。 它必须仅对该服务专用。 只能由微服务API访问它。 其他服务无法直接访问它。 例如，对于关系数据库，我们可以使用每个服务专用表，每个服务架构或每个服务数据库服务器。
每个服务共享数据库
我们已经讨论了每个服务一个数据库是微服务的理想选择。 它是微服务的反模式。 但是，如果应用程序是一个整体并且试图闯入微服务，那么非规范化就不那么容易了。 在后面的阶段中，我们可以按服务模式转移到DB。 每个服务共享数据库不是理想的选择，但这是上述情况的可行解决方案。 大多数人认为这是微服务的反模式，但对于棕地应用程序，这是将应用程序分解成较小逻辑部分的一个很好的开始。 这不应应用于未开发的应用
命令查询职责隔离（CQRS）
一旦我们实现了每个服务的数据库，就需要进行查询，这需要来自多个服务的联合数据。 这是不可能的。 CQRS建议将应用程序分为两部分-命令侧和查询侧。
命令行处理创建，更新和删除请求。
查询端通过使用实例化视图来处理查询部分。
通常将事件源模式与它一起使用来为任何数据更改创建事件。 通过订阅事件流，可以使实例化视图保持更新。 事件源大多数应用程序都使用数据，典型的方法是使应用程序保持当前状态。 例如，在传统的创建，读取，更新和删除（CRUD）模型中，典型的数据处理是从存储中读取数据。 它包含经常使用事务锁定数据的限制。
事件来源模式
Event Sourcing模式[8]定义了一种方法，用于处理由一系列事件驱动的数据上的操作，每个事件都记录在仅追加存储中。应用程序代码向事件存储发送一系列事件，这些事件命令性地描述对数据执行的每个操作，并在事件存储中保留它们。每个事件代表一组数据更改（例如，AddedItemToOrder）。这些事件将保留在充当记录系统的事件存储中。事件存储发布的事件的典型用途是在应用程序中的动作更改实体时维护实体的实体化视图，以及与外部系统集成。例如，系统可以维护用于填充UI部分的所有客户订单的实例化视图。当应用程序添加新订单，添加或删除订单中的项目以及添加运输信息时，可以处理描述这些更改的事件并将其用于更新实例化视图。该图显示了该模式的概述。
事件采购模式[8]
传奇模式
当每个服务都有自己的数据库并且一个业务事务跨越多个服务时，我们如何确保各个服务之间的数据一致性？ 每个请求都有一个补偿请求，该请求在请求失败时执行。 它可以通过两种方式实现：
编排-如果没有中央协调，则每个服务都会生成并侦听另一个服务的事件，并决定是否应采取措施。编排是一种指定两个或多个参与方的方式。它们都无法控制对方的流程，或者对这些流程的任何可见性-都无法协调其活动和流程以共享信息和价值。当需要跨控制/可见性域进行协调时，请使用编排。在简单的场景中，你可以想到编排，就像网络协议一样。它规定了各方之间可接受的请求和响应模式。
传奇模式—编舞
编排-编排（对象）负责传奇的决策和业务逻辑排序。当你控制流程中的所有参与者时。当它们全部处于一个控制范围内时，你可以控制活动的流程。当然，这通常是当你指定将在你拥有控制权的一个组织内制定的业务流程时。
贤者模式—编排
可观察性模式
日志聚合考虑一个用例，其中一个应用程序包含多个服务。请求通常跨越多个服务实例。每个服务实例均以标准化格式生成日志文件。我们需要一个集中式日志记录服务，该服务可以汇总每个服务实例的日志。用户可以搜索和分析日志。他们可以配置在某些消息出现在日志中时触发的警报。例如，PCF确实具有Log Aggregator，它从PCF平台的每个组件（路由器，控制器，diego等）收集日志，并附带应用程序。 AWS Cloud Watch也这样做。性能指标当服务组合由于微服务体系结构而增加时，监视交易变得至关重要，以便可以监视模式并在发生问题时发送警报。需要度量服务来收集有关单个操作的统计信息。它应该聚合提供报告和警报的应用程序服务的指标。有两种用于汇总指标的模型：
推送-服务将指标推送到指标服务，例如NewRelic，AppDynamics。
Pull-指标服务从服务中提取指标，例如普罗米修斯。
分布式跟踪
在微服务架构中，请求通常跨越多个服务。 每个服务通过跨多个服务执行一个或多个操作来处理请求。 在进行故障排除时，值得拥有跟踪ID，但我们会端对端跟踪请求。 解决方案是引入交易ID。 可以采用跟随方式；
为每个外部请求分配唯一的外部请求ID。
将外部请求ID传递给所有服务。
在所有日志消息中包括外部request-id。
健康检查
实施微服务架构后，服务可能会启动但无法处理事务。 每个服务都需要具有一个可用于检查应用程序运行状况（例如运行状况）的终结点。 该API应该o检查主机的状态，与其他服务/基础结构的连接以及任何特定的逻辑
交叉切割关注模式
服务通常还会调用其他服务和数据库。 对于开发，质量检查，UAT，产品等每个环境，端点URL或某些配置属性可能会有所不同。 这些属性中的任何一个更改都可能需要重新构建和重新部署服务。 为避免代码修改，可以使用配置。 外部化所有配置，包括端点URL和凭据。 应用程序应该在启动时或运行时加载它们。 这些可以在启动时由应用程序访问，也可以在不重新启动服务器的情况下进行刷新。
服务发现模式
当微服务出现时，我们需要在调用服务方面解决一些问题。 使用容器技术，IP地址可以动态分配给服务实例。 每次地址更改时，消费者服务都会中断，需要手动更改。 消费者必须记住每个服务URL，并使其紧密耦合。 需要创建一个服务注册表，该注册表将保留每个生产者服务的元数据和每个规范的规范。 服务实例在启动时应注册到注册表，而在关闭时应注销。 服务发现有两种类型：
客户端：例如：Netflix Eureka。
服务器端：例如：AWS ALB。
服务发现[9]
断路器模式
一个服务通常调用其他服务来检索数据，并且下游服务可能会关闭。这样做有两个问题：首先，请求将继续进入服务中断状态，耗尽网络资源，并降低性能。其次，用户体验将是糟糕且不可预测的。消费者应通过代理来调用远程服务，该代理的行为与断路器相似。当连续的故障数超过阈值时，断路器会跳闸，并且在超时期间内，所有调用远程服务的尝试都会立即失败。超时到期后，断路器将允许有限数量的测试请求通过。如果这些请求成功，则断路器将恢复正常运行。否则，如果发生故障，则超时时间将再次开始。如果此操作很有可能失败，则此模式适用于防止应用程序尝试调用远程服务或访问共享资源。
断路器模式[10]
蓝绿色部署模式
使用微服务架构，一个应用程序可以具有许多微服务。 如果我们停止所有服务，然后部署增强版本，则停机时间将是巨大的，并可能影响业务。 同样，回滚将是一场噩梦。 蓝绿色部署模式可以避免这种情况。 可以实施蓝绿色部署策略以减少或消除停机时间。 它通过运行两个相同的生产环境Blue和Green来实现这一目标。 假设Green是现有的活动实例，Blue是该应用程序的新版本。 在任何时候，只有一个环境处于活动状态，该活动环境为所有生产流量提供服务。 所有云平台均提供用于实施蓝绿色部署的选项。
喜欢这篇文章的可以点个赞，欢迎大家留言评论，记得关注我，每天持续更新技术干货、职场趣事、海量面试资料等等
如果你对java技术很感兴趣也可以加入我的java学习群 V–（ddmsiqi）来交流学习，里面都是同行，验证【CSDN2】有资源共享。
不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！
