微服務是一種熱門的架構樣式，可用來建置具有復原性、高度可調整、可獨立部署且能夠快速發展的應用程式。 但是，成功的微服務架構需要不同的方法來設計和建置應用程式。
微服務架構是由小型自主服務的集合所組成。 每個服務都是獨立的，而且應該在限定的內容內實作單一商務功能。 限定內容是企業內的自然部門，並提供定義域模型存在的明確界限。
什麼是微服務？
微服務屬於小型、獨立且鬆散結合的服務。 開發人員的單一小型小組可以撰寫和維護服務。
每項服務的程式碼基底各自分開，由小型的開發小組負責管理。
服務可以獨立部署。 小組可以直接更新現有服務，而不需要重建和重新部署整個應用程式。
服務會負責保存自己的數據或外部狀態。 這與傳統模型不同，其中個別的數據層會處理數據持續性。
服務會使用定義完善的 API 彼此通訊。 每個服務的內部實作詳細資料都會對其他服務隱藏。
支援多語言程式設計。 例如，服務不需要共用相同的技術堆疊、連結庫或架構。
除了服務本身之外，其他一些元件會出現在一般微服務架構中：
管理/協調流程。 此元件負責將服務放在節點上、識別失敗、跨節點重新平衡服務等等。 此元件通常是現成的技術，例如 Kubernetes，而不是自定義建置的專案。
API 閘道。 API 閘道是客戶端的進入點。 用戶端會呼叫 API 閘道，而不是直接呼叫服務，這會將呼叫轉送至後端的適當服務。
使用 API 閘道的優點包括：
它會將客戶端與服務分離。 服務可以進行版本設定或重構，而不需要更新所有用戶端。
服務可以使用不易用 Web 的傳訊通訊協定，例如 AMQP。
API 閘道可以執行其他交叉功能，例如驗證、記錄、SSL 終止和負載平衡。
現用原則，例如節流、快取、轉換或驗證。
福利
靈活度。 因為微服務為獨自部署，所以可更輕鬆地管理錯誤 (bug) 修正和功能版本。 您可以更新服務而不重新部署整個應用程式，並在發生問題時回復更新。 在許多傳統應用程式中，如果在應用程式的某個部分找到錯誤，這可能會封鎖整個發行程序。 新功能可能會擱置，等待 Bug 修正整合、測試和發布。
小型、專注的團隊。 微服務應小到讓單一功能小組可加以建置、測試及部署。 小型小組大小可提升更大的靈活度。 大型小組的生產力往往較低，因為通訊速度較慢，管理額外負荷會增加，且靈活度會降低。
小型程式代碼基底。 在整合型應用程式中，程式代碼相依性會隨著時間而變得糾纏的趨勢。 新增功能需要在很多地方接觸程序代碼。 微服務架構不會共用程式碼或資料存放區，因而降低相依性，並可讓您更輕鬆地新增功能。
混合技術。 小組可以視情況使用混合的技術堆疊，以挑選出最適合其服務使用的技術。
錯誤隔離。 如果個別微服務變得無法使用，只要任何上游微服務都設計成正確處理錯誤，它就不會中斷整個應用程式。 例如，您可以實 作斷路器模式，也可以設計解決方案，讓微服務使用 異步傳訊模式彼此通訊。
延展性。 服務可以獨立調整，讓您相應放大需要更多資源的子系統，而不需要相應放大整個應用程式。 使用 Kubernetes 之類的協調器，您可以將較高的服務密度封裝到單一主機，以更有效率地利用資源。
資料隔離。 執行架構更新會更容易，因為只有單一微服務受到影響。 在整合型應用程式中，架構更新可能會變得非常具有挑戰性，因為應用程式的不同部分可能會觸碰相同的數據，而對架構有風險的任何變更。
挑戰
微服務的優點不會免費取得。 以下是開始微服務架構之前要考慮的一些挑戰。
複雜度。 微服務應用程式的變動組件數量比同等單體式應用程式的還多。 每個服務會更為簡單，但是系統整個會變得更複雜。
開發和測試。 撰寫依賴其他相依服務的小型服務，需要不同於撰寫傳統整合型或分層式應用程式的方法。 現有工具的設計不一定適合處理服務相依性。 跨服務界限進行重構會很困難。 測試服務相依性也會很困難，尤其是當應用程式的演變速度很快時。
缺乏治理。 微服務的非集中式建置方法有其優點，卻也可能導致問題發生。 您最終可能會有很多不同的語言和架構，而讓應用程式變得難以維護。 備有某些適用於全部專案的標準，而不要過度限制小組的彈性，這樣的做法可能會有幫助。 這特別適用於跨領域功能，例如記錄。
網路壅塞和延遲。 使用許多小型且細微的服務可能會導致服務之間需要更多通訊。 此外，如果服務相依性鏈結變得太長（服務 A 呼叫 B，它會呼叫 C...），額外的延遲可能會變成問題。 您將必須謹慎地設計 API。 避免過度閒聊的 API、考慮串行化格式，並尋找使用異步通訊模式的位置，例如 佇列型負載撫平。
資料完整性。 每個微服務負責維持自己的資料持續性。 因此，維持資料一致性會成為挑戰。 可能的話，請採用最終一致性。
管理。 想要成功運用微服務，就必須有成熟的 DevOps 文化。 在服務之間建立關聯式記錄會非常困難。 一般而言，記錄必須將多個服務呼叫相互關聯到單一使用者作業。
版本控制。 服務的更新不得打斷與其相依的服務。 多個服務有可能在同一時間一起更新，因此若未謹慎設計，便可能發生回溯相容性或往後相容性問題。
技能集。 微服務是高度分散的系統。 請謹慎評估小組是否有技能和經驗能夠成功。
建置微服務架構的程式
此處列出的文章提供結構化方法來設計、建置及操作微服務架構。
定義域分析。 若要避免在設計微服務時發生一些常見的陷阱，請使用領域分析來定義您的微服務界限。 執行下列步驟:
設計服務。 微服務需要不同的方法來設計和建置應用程式。 如需詳細資訊，請參閱 設計微服務架構。
在生產環境中運作。 由於微服務架構是分散式的，因此您必須有健全的部署和監視作業。