[译] 微服务的设计模式，整理出这份8万字Java性能优化实战解析

解决

聚集器模式有助于解决此问题。它讨论了如何聚合来自不同服务的数据，然后将最终响应发送给消费者。这可以通过两种方式完成：

1.复合微服务将调用所有必需的微服务，合并数据，并在发送回数据之前对其进行转换。

2.API网关还可以将请求划分为多个微服务并聚合数据，然后再将其发送给使用者。

如果要应用任何业务逻辑，建议选择复合微服务。否则，API网关是已建立的解决方案。

客户端UI组合模式

问题

通过分解业务功能/子域来开发服务时，负责用户体验的服务必须从多个微服务中提取数据。在整体应用中，从UI到后端服务只有一次调用，以检索所有数据并刷新/提交UI页面。但是，现在不一样了。我们需要了解如何去做。

解决

对于微服务，必须将UI设计为具有屏幕/页面的多个部分/区域的框架。每个部分都将调用单个后端微服务以提取数据。这称为组成特定于服务的UI组件。诸如AngularJS和ReactJS之类的框架可以轻松地做到这一点。这些屏幕称为单页应用程序（SPA）。这使应用程序可以刷新屏幕的特定区域而不是刷新整个页面。

数据库模式

---

每个服务一个数据库

问题

如何定义微服务的数据库体系结构存在一个问题。以下是要解决的问题：

1.服务必须松散耦合。它们可以独立开发，部署和扩展。

2.业务事务可能会强制跨越多个服务的不变量。

3.一些业务事务需要查询多个服务拥有的数据。

4.有时必须复制数据库并对其进行分片以进行扩展。

5.不同的服务具有不同的数据存储要求。

解决

为了解决上述问题，必须为每个微服务设计一个数据库。它必须仅对该服务专用。只能由微服务API访问它。其他服务无法直接访问它。例如，对于关系数据库，我们可以使用每个服务一个专用表，每个服务一个schema或每个服务一个数据库服务器。每个微服务应具有一个单独的数据库ID，以便可以给予单独的访问权限以设置障碍并防止其使用其他服务表。

每个服务共享数据库

问题

我们已经讨论了每个服务一个数据库是微服务的理想选择，当应用程序是未开发的并且要使用DDD开发时，这是可能的。但是，如果应用程序是一个整体并且试图闯入微服务，那么非规范化就不那么容易了。在那种情况下合适的架构是什么？

解决

每个服务共享数据库不是理想的选择，但这是上述情况的可行解决方案。大多数人认为这是微服务的反模式，但对于棕色应用程序来说，这是将应用程序分解成较小逻辑部分的一个很好的开始。这不适用于未开发的应用程序。在这种模式下，一个数据库可以与一个以上的微服务对齐，但是必须限制为最大2-3个微服务，否则伸缩，自治和独立性将难以执行。

命令查询职责隔离（CQRS）

问题

一旦我们实现了每个服务的数据库，就需要进行查询，这需要来自多个服务的联合数据-这是不可能的。那么，我们如何在微服务架构中实现查询？

解决

CQRS建议将应用程序分为两部分-命令端和查询端。命令行处理创建，更新和删除请求。查询端通过使用实例化视图来处理查询部分。通常将事件源模式与它一起使用来为任何数据更改创建事件。通过订阅事件流，可以使实例化视图保持更新。

saga模式

问题

当每个服务都有自己的数据库并且一个业务事务跨越多个服务时，我们如何确保各个服务之间的数据一致性？例如，对于客户有信用额度的电子商务应用程序，该应用程序必须确保新订单不会超过客户的信用额度。由于订单和客户位于不同的数据库中，因此应用程序不能简单地使用本地ACID事务。

解决

Saga代表由几个子请求组成的高级业务流程，每个子请求在单个服务中更新数据。每个请求都有一个补偿请求，该请求在请求失败时执行。它可以通过两种方式实现：

1.Choreography-如果没有中央协调，则每个服务都会产生并侦听另一个服务的事件，并决定是否应采取措施。

2.Orchestration-协调员（对象）负责传奇的决策和业务逻辑排序。

可观察性模式

---

日志汇总

问题

考虑一个用例，其中一个应用程序由在多台计算机上运行的多个服务实例组成。请求通常跨越多个服务实例。每个服务实例均以标准化格式生成日志文件。我们如何通过日志了解特定请求的应用程序行为？

解决

我们需要一个集中式日志记录服务，该服务可以汇总每个服务实例的日志。用户可以搜索和分析日志。他们可以配置在某些消息出现在日志中时触发的警报。例如，PCF确实具有Loggeregator，它从PCF平台的每个组件（路由器，控制器，diego等）收集日志，并附带应用程序。 AWS Cloud Watch也这样做。

性能指标

问题

当服务组合由于微服务架构而增加时，密切关注事务至关重要，以便可以监控模式并在发生问题时发送警报。我们应该如何收集指标以监视应用程序性能？

解决

需要度量服务来收集有关单个操作的统计信息。它应该聚合提供报告和警报的应用程序服务的指标。有两种用于汇总指标的模型：

1.推送-服务将指标推送到指标服务，例如NewRelic，AppDynamics

2.提取-指标服务从服务中提取指标，例如普罗米修斯

分布式跟踪

问题

在微服务架构中，请求通常跨越多个服务。每个服务通过跨多个服务执行一个或多个操作来处​​理请求。然后，我们如何跟踪端到端的请求以解决问题？

解决

我们需要一项服务

💡为每个外部请求分配一个唯一的外部请求ID。

💡将外部请求ID传递给所有服务。

💡在所有日志消息中包括外部请求ID。

💡记录有关请求和在集中式服务中处理外部请求时执行的操作的信息（例如开始时间，结束时间）。

Spring Cloud Slueth与Zipkin服务器一起是常见的实现。

健康检查

问题

实施微服务架构后，服务可能会启动但无法处理事务。在这种情况下，如何确保请求不会发送到那些失败的实例？用负载均衡模式实现。

解决

每个服务都需要有一个端点，可用于检查应用程序的运行状况，例如/health。该API应该可以检查主机的状态，与其他服务/基础结构的连接以及任何特定的逻辑。

Spring Boot Actuator确实实现了/health端点，并且该实现也可以自定义。

Cross-Cutting Concern（横切关注）模式

---

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）

起的朋友，同时减轻大家的负担。**
[外链图片转存中…(img-yqGVua9U-1710846819492)]
[外链图片转存中…(img-Ntrdm6w4-1710846819493)]
[外链图片转存中…(img-F7g86IRG-1710846819493)]

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）
[外链图片转存中…(img-0OILhomj-1710846819493)]