整合型應用程式的效能條件約束
您可能會選擇變更系統架構的原因很多。 作業靈活度、成本、延展性和效能只是決定系統架構中扮演角色的一些因素。 在我們的範例中，我們進一步瞭解效能如何成為無人機遞送系統的一個因素。
隨著 Fabrikam 無人機交付業務的增長，系統負載增加。 目前的架構在負載下很緊張。 Fabrikam 想要在調整目前整合型架構中無法使用的應用程式時提供更好的彈性。 改善應用程式的延展性是 Fabrikam 查看將其應用程式移至微服務架構的其中一個驅動程式。
調整整合型與微服務
微服務架構的主要優點之一是增加調整功能。 因為服務會分開，所以隨著負載增加，個別調整每個服務會比較容易。
我們可以看到無人機遞送系統中的功能差異。 使用整合型架構時，所有服務都會包含在應用程式的單一實例內。 他們會向客戶公開 API 介面，以提交和管理傳遞要求。 當客戶要求增加時，系統上的負載會增加。 需要配置更多資源給系統，以避免對用戶體驗造成負面影響。
在整合型架構中，個別調整此服務也需要調整其他服務的資源，因為它們包含在每個應用程式實例內。 這種安排效率不佳，因為其他服務的負載可能最少，而且不需要額外的資源使用率。
在微服務架構中，因為每個服務都是分開的，因此我們可以獨立於其他服務來調整 API。 這種安排會增加效率，因為我們不需要取用不必要的服務資源。
無人機交付整合型架構的挑戰
套件服務已識別為業務的重要部分，且原本是整合型的一部分。 客戶會大幅增加對它的依賴，而且當此負載增加時，效能會受到負面影響。 為了解決這種情況，Fabrikam 專門負責開發小組，完全掌控這部分業務。 小組計劃開發並反覆運算此服務，並完全負責套件服務的所有層面。
因為套件服務位於整合型中，因此小組無法自主運作。 它們必須依賴共用數據和數據結構。 他們也無法視需要快速反覆運算。 除了效能和延展性問題，此服務會識別為微服務的主要候選專案。
讓我們進一步瞭解 Fabrikam 如何分析和分解其應用程式，以利用微服務架構。