整合型應用程式的效能限制
您可能會因為各種原因，而選擇變更系統的架構。 在決定系統架構時，作業靈活性、成本、擴充性和效能都只是其中的一些因素。 在我們的範例中，我們會深入探討效能為何是無人機遞送系統考量的因素。
隨著 Fabrikam 無人機遞送業務的成長，系統負載也會增加。 目前的架構已不太能處理這些負載。 Fabrikam 想要為應用程式調整提供目前整合型應用程式所無法提供的較佳彈性。 改善應用程式的延展性是 Fabrikam 將應用程式移動到微服務架構時會考量的其中一個動機。
調整整合型與微服務
微服務架構的其中一個主要優點是改善規模調整功能。 由於服務是分開的，所以當在每個服務的負載增加時，個別擴展每個服務會較為容易。
我們可以在無人機遞送系統中看見此功能性差異。 在整合型架構中，所有服務都包含在應用程式的單一執行個體內。 他們會向客戶公開 API 介面，讓客戶提交和管理遞送要求。 隨著客戶要求的增加，系統上的負載也會增加。 系統上將需要配置更多資源，以避免對使用者體驗產生負面影響。
在整合型架構中，個別縮放此服務也需要縮放其他服務的資源，因為它們都包含在每個應用程式執行個體內。 這種做法的效率不佳，因為其他服務的負載可能很小，且不需要額外的資源使用率。
在微服務架構中，由於每個服務都是分開的，因此我們可以獨立於其他服務，調整 API 的規模。 這會提高我們的效率，因為我們不需要取用不必要服務的資源。
無人機遞送整合型架構的挑戰
包裹服務一直以來都被視為業務的關鍵部分，且原先是整合型架構的一部分。 客戶已大幅增加他們對這個服務的依賴程度，且隨著此負載的增加，也對效能產生負面影響。 為了解決這個情況，Fabrikam 設立了專屬的開發小組，並讓他們完全控制這一部分的業務。 該小組打算開發這個服務並對其進行逐一查看，且會單獨負責包裹服務的所有層面。
由於包裹服務位於整合型應用程式中，這使得該小組無法自主運作。 他們必須仰賴共用的資料和資料結構。 他們也無法以其所需的速度進行逐一查看。 加上效能和延展性問題，這項服務因此是微服務的最佳候選項目。
讓我們進一步地觀察 Fabrikam 如何分析和分解他們的應用程式，利用微服務架構。