整体应用程序的性能约束

有多种原因可以选择更改系统的体系结构。 运营敏捷性、成本、可伸缩性和性能只是在确定系统体系结构方面发挥作用的一些因素。 在我们的示例中，我们更仔细地了解性能如何成为无人机交付系统的因素。

随着 Fabrikam 无人机交付业务的增长，系统负载增加。 当前体系结构在负载下紧张。 Fabrikam 希望提供更好的灵活性，以扩大应用程序的规模，这是当前整体架构所无法实现的。 提高应用程序的可伸缩性是 Fabrikam 考虑将其应用程序移动到微服务体系结构的驱动程序之一。

缩放单体应用 vs. 微服务

微服务体系结构的主要优势之一是扩展功能增加。 由于服务是分开的，因此随着负载的增加，更容易单独扩展每个服务。

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

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

在微服务架构中，由于每个服务都是独立的，因此我们可以独立于其他服务扩展 API。 这种安排提高了效率，因为我们不需要消耗不必要的服务的资源。

无人机配送单体应用体系结构面临的挑战

该包服务已被确定为业务的关键部件，并且最初是单体应用的一部分。 随着负载的增加，客户对其的依赖程度急剧增加，性能会受到负面影响。 为了解决这一情况，Fabrikam 专门成立了一个开发团队，完全掌握这部分业务。 团队计划开发并迭代此服务，并承担包服务的所有方面的全部责任。

由于包服务位于单体架构中，团队无法独立运作。 它们必须依赖于共享数据和数据结构。 他们也无法根据需要快速迭代。 除了性能和可伸缩性问题之外，此服务还被确定为微服务的主要候选项。

让我们进一步了解 Fabrikam 如何分析和分解其应用程序，以利用微服务体系结构。