整合型架構與微型服務架構有什麼區別？

整合型應用程式通常包含用戶端 UI、資料庫和伺服器端應用程式。開發人員在單一程式碼庫上建置所有這些模組。

另一方面，在分散式架構中，每項微型服務都可以完成單一功能或業務邏輯。微型服務不是在同一程式碼庫中交換資料，而是使用 API 進行通訊。

接下來，我們討論兩者之間的更多差異。

閱讀有關 API 的內容 »

開發過程

整合型應用程式更容易開始使用，因為不需要太多的前期規劃。您可以視需要開始使用，並不斷新增程式碼模組。然而，隨著時間的推移，應用程式可能會變得複雜且難以更新或變更。

微型服務架構在開始之前需要更多的規劃和設計。開發人員必須確定可獨立工作的不同功能，並規劃一致的 API。不過，初始協調可讓程式碼維護更高效。您可以更快地做出變更並找到錯誤。程式碼重用性也隨著時間的推移而增加。

部署

部署整合型應用程式比部署微型服務更直接。開發人員在單一環境安裝整個應用程式的程式碼庫和相依項。 

相較之下，部署微型服務型應用程式更為複雜，因為每項微型服務都是可獨立部署的軟體套件。開發人員通常會在部署微型服務之前將其容器化。容器會封裝微型服務的程式碼及相關相依項，以實現平台獨立性。

閱讀有關容器化的資訊 »

偵錯

偵錯是一項軟體程序，可識別導致應用程式行為異常的編碼錯誤。對整合型架構偵錯時，開發人員可在相同的程式設計環境中追蹤資料移動，或檢查程式碼行為。同時，要在微型服務架構中識別編碼問題，需要查看多項鬆耦合的個別服務。 

對微型服務應用程式偵錯可能更具挑戰性，因為可能有多個開發人員負責許多微型服務。例如，偵錯可能需要團隊成員之間協調性測試、討論和意見回饋，這需要更多的時間和資源。 

修改

在整合型應用程式一個部分的小變更，由於緊密耦合的編碼而會影響多項軟體功能。此外，當開發人員對整合型應用程式引入新的變更時，他們必須在伺服器上重新測試並重新部署整個系統。

相較之下，微型服務方法更具靈活性。更容易對應用程式做出變更。開發人員不用修改所有服務，而是只變更特定功能。他們也可以獨立部署特定服務。這種方法對於持續部署工作流程很有幫助，開發人員可在不影響系統穩定性的情況下進行頻繁的小變更。 

擴展

整合型應用程式在擴展時面臨多項挑戰。整合型架構包含單一程式碼庫中的所有功能，因此，整個應用程式必須隨著需求的變化而擴展。例如，如果應用程式的效能因通訊功能遇到流量突增而降低，則您必須增加運算資源來容納整個整合型應用程式。這會導致資源浪費，因為並非應用程式的所有部分都處於尖峰容量。

同時，微型服務架構支援分散式系統。在分散式系統中，每個軟體元件會接收自己的運算資源。這些資源可根據目前的容量和預測的需求來獨立擴展。舉例來說，您可將更多資源分配給地理位置服務，而不是整個系統。

無論是整合型架構，還是微型服務架構，都能協助開發人員採用不同的方法來建置應用程式。重要的是，要了解微型服務不會降低應用程式的複雜性。而微型服務結構揭示了基礎複雜性，並允許開發人員更有效地建置、管理和擴展大型應用程式。

當您在開發微型服務架構或整合型架構之間做出決定時，可以考慮以下因素。

應用程式規模

在設計簡單的應用程式或原型時，整合型方法更適合。由於整合型應用程式使用單一程式碼庫和架構，因此開發人員可在不整合多項服務的情況下建置軟體。微型服務應用程式可能需要大量的時間和設計工作，這並不能證明非常小型專案的成本和效益。 

同時，微型服務架構對於建置複雜的系統更好。它為您的團隊提供強大的程式設計基礎，並提供各項支援，讓他們能夠靈活地新增更多功能。例如，Netflix 使用 AWS Lambda 來擴展其串流基礎設施，以及節省開發時間。

閱讀 Netflix 如何使用 Lambda »

團隊能力

儘管具有靈活性，但使用微型服務進行開發需要不同的知識集和設計思維。與整合型應用程式不同，微型服務開發需要了解雲端架構、API、容器化，以及現代雲端應用程式專屬的其他專業知識。此外，對於不了解分散式架構的開發人員來說，對微型服務進行疑難排解可能極具挑戰性。 

基礎架構

整合型應用程式可在單一伺服器上執行，但微型服務應用程式可從雲端環境獲益更多。雖然可以從單一伺服器執行微型服務，但開發人員通常會與雲端服務提供者一起託管微型服務，以協助確保可擴展性、容錯能力和高可用性。

您需要配備適當的基礎設施，才能開始使用微型服務。您還需要更多精力來設定微型服務的工具和工作流程，但它們對於建置複雜且可擴展的應用程式來說是比較好的選擇。

類別	整合型架構	微型服務架構
設計	具有多個互相依存函數的單一程式碼庫。	具有自主功能的獨立軟體元件，可使用 API 相互通訊。
開發	開始時只需較少的規劃，但越來越複雜，難以理解和維護。	一開始需要較多的規劃和基礎設施，但隨著時間的推移更容易管理和維護。
部署	整個應用程式部署為單一實體。	每個微型服務都是獨立的軟體實體，需要個別的容器化部署。
偵錯	追蹤相同環境中的程式碼路徑。	需要進階偵錯工具，來追蹤多項微型服務之間的資料交換。
修改	小的變更會帶來更大的風險，因為它們會影響整個程式碼庫。	您可在不影響整個應用程式的情況下修改個別微型服務。
擴展	即使只有某些功能區域的需求增加，您也必須擴展整個應用程式。	您可以視需要調整個別微型服務，以節省整體擴展成本。
投資	較低的前期投資，但會持續增加成本和維護工作。	需要額外的時間和成本投資，以建立所需的基礎設施並培養團隊能力。然而，長期的成本節省、維護性和適應性更好。