編輯

共用方式為


微服務架構設計

Azure DevOps

微服務是一種熱門的架構樣式,可用來建置具有復原性、高度可調整、可獨立部署且能夠快速發展的應用程式。 但是,成功的微服務架構需要不同的方法來設計和建置應用程式。

微服務架構是由小型自主服務的集合所組成。 每個服務都是獨立的,而且應該在限定的內容內實作單一商務功能。 限定內容是企業內的自然部門,並提供定義域模型存在的明確界限。

微服務架構樣式的邏輯圖表。

什麼是微服務?

  • 微服務屬於小型、獨立且鬆散結合的服務。 開發人員的單一小型小組可以撰寫和維護服務。

  • 每項服務的程式碼基底各自分開,由小型的開發小組負責管理。

  • 服務可以獨立部署。 小組可以直接更新現有服務,而不需要重建和重新部署整個應用程式。

  • 服務會負責保存自己的數據或外部狀態。 這與傳統模型不同,其中個別的數據層會處理數據持續性。

  • 服務會使用定義完善的 API 彼此通訊。 每個服務的內部實作詳細資料都會對其他服務隱藏。

  • 支援多語言程式設計。 例如,服務不需要共用相同的技術堆疊、連結庫或架構。

除了服務本身之外,其他一些元件會出現在一般微服務架構中:

管理/協調流程。 此元件負責將服務放在節點上、識別失敗、跨節點重新平衡服務等等。 此元件通常是現成的技術,例如 Kubernetes,而不是自定義建置的專案。

API 閘道。 API 閘道是客戶端的進入點。 用戶端會呼叫 API 閘道,而不是直接呼叫服務,這會將呼叫轉送至後端的適當服務。

使用 API 閘道的優點包括:

  • 它會將客戶端與服務分離。 服務可以進行版本設定或重構,而不需要更新所有用戶端。

  • 服務可以使用不易用 Web 的傳訊通訊協定,例如 AMQP。

  • API 閘道可以執行其他交叉功能,例如驗證、記錄、SSL 終止和負載平衡。

  • 現用原則,例如節流、快取、轉換或驗證。

福利

  • 靈活度。 因為微服務為獨自部署,所以可更輕鬆地管理錯誤 (bug) 修正和功能版本。 您可以更新服務而不重新部署整個應用程式,並在發生問題時回復更新。 在許多傳統應用程式中,如果在應用程式的某個部分找到錯誤,這可能會封鎖整個發行程序。 新功能可能會擱置,等待 Bug 修正整合、測試和發布。

  • 小型、專注的團隊。 微服務應小到讓單一功能小組可加以建置、測試及部署。 小型小組大小可提升更大的靈活度。 大型小組的生產力往往較低,因為通訊速度較慢,管理額外負荷會增加,且靈活度會降低。

  • 小型程式代碼基底。 在整合型應用程式中,程式代碼相依性會隨著時間而變得糾纏的趨勢。 新增功能需要在很多地方接觸程序代碼。 微服務架構不會共用程式碼或資料存放區,因而降低相依性,並可讓您更輕鬆地新增功能。

  • 混合技術。 小組可以視情況使用混合的技術堆疊,以挑選出最適合其服務使用的技術。

  • 錯誤隔離。 如果個別微服務變得無法使用,只要任何上游微服務都設計成正確處理錯誤,它就不會中斷整個應用程式。 例如,您可以實 作斷路器模式,也可以設計解決方案,讓微服務使用 異步傳訊模式彼此通訊。

  • 延展性。 服務可以獨立調整,讓您相應放大需要更多資源的子系統,而不需要相應放大整個應用程式。 使用 Kubernetes 之類的協調器,您可以將較高的服務密度封裝到單一主機,以更有效率地利用資源。

  • 資料隔離。 執行架構更新會更容易,因為只有單一微服務受到影響。 在整合型應用程式中,架構更新可能會變得非常具有挑戰性,因為應用程式的不同部分可能會觸碰相同的數據,而對架構有風險的任何變更。

挑戰

微服務的優點不會免費取得。 以下是開始微服務架構之前要考慮的一些挑戰。

  • 複雜度。 微服務應用程式的變動組件數量比同等單體式應用程式的還多。 每個服務會更為簡單,但是系統整個會變得更複雜。

  • 開發和測試。 撰寫依賴其他相依服務的小型服務,需要不同於撰寫傳統整合型或分層式應用程式的方法。 現有工具的設計不一定適合處理服務相依性。 跨服務界限進行重構會很困難。 測試服務相依性也會很困難,尤其是當應用程式的演變速度很快時。

  • 缺乏治理。 微服務的非集中式建置方法有其優點,卻也可能導致問題發生。 您最終可能會有很多不同的語言和架構,而讓應用程式變得難以維護。 備有某些適用於全部專案的標準,而不要過度限制小組的彈性,這樣的做法可能會有幫助。 這特別適用於跨領域功能,例如記錄。

  • 網路壅塞和延遲。 使用許多小型且細微的服務可能會導致服務之間需要更多通訊。 此外,如果服務相依性鏈結變得太長(服務 A 呼叫 B,它會呼叫 C...),額外的延遲可能會變成問題。 您將必須謹慎地設計 API。 避免過度閒聊的 API、考慮串行化格式,並尋找使用異步通訊模式的位置,例如 佇列型負載撫平

  • 資料完整性。 每個微服務負責維持自己的資料持續性。 因此,維持資料一致性會成為挑戰。 可能的話,請採用最終一致性。

  • 管理。 想要成功運用微服務,就必須有成熟的 DevOps 文化。 在服務之間建立關聯式記錄會非常困難。 一般而言,記錄必須將多個服務呼叫相互關聯到單一使用者作業。

  • 版本控制。 服務的更新不得打斷與其相依的服務。 多個服務有可能在同一時間一起更新,因此若未謹慎設計,便可能發生回溯相容性或往後相容性問題。

  • 技能集。 微服務是高度分散的系統。 請謹慎評估小組是否有技能和經驗能夠成功。

建置微服務架構的程式

此處列出的文章提供結構化方法來設計、建置及操作微服務架構。

定義域分析。 若要避免在設計微服務時發生一些常見的陷阱,請使用領域分析來定義您的微服務界限。 執行下列步驟:

  1. 使用領域分析來建立微服務的模型。
  2. 使用戰術 DDD 設計微服務
  3. 識別微服務界限

設計服務。 微服務需要不同的方法來設計和建置應用程式。 如需詳細資訊,請參閱 設計微服務架構

在生產環境中運作。 由於微服務架構是分散式的,因此您必須有健全的部署和監視作業。

Azure 的微服務參考架構