整体应用程序的性能约束

选择更改系统的体系结构的原因有很多。操作灵活性、成本、可伸缩性和性能只是在确定系统体系结构时发挥作用的部分因素。在我们的示例中，我们将详细了解性能如何成为无人机交付系统的影响因素。

随着 Fabrikam 无人机交付业务的增长，系统负载也随之增加。当前的体系结构在负载下已经不堪重负。 Fabrikam 希望在缩放应用程序方面提供更好的灵活性，这在当前的整体架构中是无法实现的。提高应用程序的可伸缩性是 Fabrikam 将其应用程序迁移到微服务体系结构时看重的其中一个驱动因素。

缩放整体式 vs. 微服务

微服务体系结构的一个主要优点是改进了缩放功能。由于服务是分开的，因此在服务间的负载增加时，分别缩放每个服务会更容易。

我们可以在无人机交付系统中看到这种功能方面的差异。在整体体系结构中，所有服务都包含在应用程序的单个实例中。它们向客户公开用于提交和管理交付请求的 API 接口。随着客户请求增加，系统上的负载也会随之增加。需要为系统分配更多的资源，以避免对用户体验产生负面影响。

在整体体系结构中，单独缩放此服务还需要缩放其他服务的资源，因为它们包含在每个应用程序实例中。这种安排效率很低，因为其他服务的负载可能很小，不需要利用额外的资源。

在微服务体系结构中，由于每个服务都是独立的，因此可独立于其他服务缩放 API。这种安排可提高效率，因为不需要使用不必要服务的资源。

包服务已被标识为业务的关键部分，并且最初是整体架构的一部分。客户对其依赖性已大大提高，在此负载增加时，性能会受到负面影响。为解决这种情况，Fabrikam 专门组建了一个开发团队，该团队对此部分业务拥有完全控制权。该团队计划开发和迭代此服务，并将独自负责包服务的所有方面。

由于包服务在整体中，所以团队不能自主地操作。他们必须依赖于共享数据和数据结构。并且他们也不能按需要快速循环访问。对于性能和可伸缩性问题，此服务被认为是微服务的最佳候选项。

我们来详细了解 Fabrikam 如何分析和分解其应用程序，以充分利用微服务体系结构。