整合型和微服務架構
Fabrikam 已將其新的無人機服務整合到其現有的應用程式。 他們發現此解決方案並不是適用於其應用程式的良好長期計畫。 現有系統是整合型架構，但這究竟是什麼意思？
什麼是整合型架構？
整合型架構是一種將應用程式所有元件共置於單一單位中的架構。 此單元通常會限制在應用程式的單一執行階段執行個體中。 傳統型應用程式通常由 Web 介面、服務層和資料層組成。 在整合型架構中，這些層會在應用程式的執行個體上合併。
整合型架構通常是適合小型應用程式的解決方案，但隨著應用程式的成長，這種架構可能會變得相當不便。 一開始的小型應用程式可能很快就會變成一套複雜系統，並難以擴展、部署和創新。
所有服務都包含在單一單位內。 這種安排會隨著業務的成長，以及隨之增長的系統負載，而帶來各種挑戰。 其中一些挑戰如下：
- 難以獨立調整服務規模。
- 隨著程式碼基底的成長，開發和管理部署都將會變得相當複雜，並使發行和實作新功能的速度變慢。
- 結構會與單一技術堆疊繫結，這會限制在新平台和 SDK 上的創新。
- 更新資料結構描述可能會越來越困難。
這些挑戰可藉由考慮替代架構 (例如微服務架構) 來處理。
什麼是微服務架構？
微服務架構由獨立且鬆散結合的小型服務組成。 每個服務都可以獨立部署和擴展。
微服務夠小，只要一小組開發人員即可進行撰寫和維護。 因為服務可以獨立部署，小組無需重建和重新部署整個應用程式，便可以更新現有服務。
每個服務通常會負責自己的資料。 由於其資料結構是隔離的，因此對資料結構的升級或變更都不會相依於其他服務。 對資料的要求通常會透過 API 處理，並提供妥善定義且一致的存取模型。 內部實作詳細資料會對服務取用者隱藏。
因為每個服務都是獨立的，所以它們可以利用不同的技術堆疊、架構和 SDK。 在倚賴 REST 呼叫進行服務對服務通訊時，服務經常會使用妥善定義的 API，而非遠端程序呼叫 (RPC) 或其他自訂通訊方法。
微服務架構不受技術影響，但您通常會看到用於其實作的容器或無伺服器技術。 我們經常使用持續部署和持續整合 (CI/CD) 來增加開發活動的速度和品質。
微服務架構的優點
為什麼要選擇微服務架構？ 微服務架構有幾個主要優點：
- 靈活度
- 小型程式碼、小型小組
- 混用技術
- 復原
- 延展性
- 資料隔離
靈活度
因為微服務為獨自部署，所以可更輕鬆地管理錯誤 (bug) 修正和功能版本。 您可以逕自更新服務，而不必重新部署整個應用程式，並於發生錯誤時復原更新。 在許多傳統應用程式中，如果在應用程式的某個部分找到錯誤，這可能會封鎖整個發行程序。 如此一來，便必須先等候整合、測試及發行錯誤修正，才能推出新功能。
小型程式碼、小型小組
微服務應小到讓單一功能小組可加以建置、測試及部署。 小型程式碼基底比較容易了解。 在大型的整合型應用程式中，程式碼相依性通常會隨時間而變得紊亂。 新增功能必須觸及多處的程式碼。 微服務架構不會共用程式碼或資料存放區，因而降低相依性。 這可讓您更輕鬆地新增功能。
小型小組規模也可提升更大的靈活度。 「兩個披薩規則」表示小組應該夠小，只要兩個比薩就可以餵飽小組。 很明顯地，這不是精確的計量，且需視小組的胃口而定！ 但重點是大型群組的生產力可能較低，因為通訊速度較慢、管理額外負荷會增加，而且靈活度會降低。
混用技術
小組可以挑選最適合其服務使用的技術。 他們可以視需要混合使用技術堆疊。 每個小組可以獨立開發支援其服務的技術。 這樣的獨立性，讓服務可以使用不同的開發語言、雲端服務、SDK 等。 小組可以針對其服務挑選最佳選項，同時將對服務取用者的任何外部影響降至最低。
復原
如果有個別微服務無法使用，只要有任何上游微服務是設計用來正確地處理錯誤 (例如，藉由實作線路中斷)，就不會中斷整個應用程式。 對於您的使用者或服務取用者來說，這能提供應用程式持續使用體驗上的優點。
延展性
微服務架構可讓每個微服務獨立於其他服務進行調整。 您可以擴充需要更多資源的子系統，而不需擴充整個應用程式。 這種安排能改善應用程式的整體效能。 它也能協助將成本降到最低。 您可以僅針對需要資源的服務新增更多資源，而不是擴充整個應用程式。
資料隔離
微服務架構可提升資料結構描述更新的執行能力，因為只有單一微服務受到影響。 在整合型應用程式中，更新結構描述可能相當困難。 應用程式不同的部分可能都會觸及相同的資料，這使得對結構描述進行任何變更都具風險。 在微服務架構中，您可以在使 API 介面保持不變的情況下更新結構描述。 無論基礎資料架構為何，服務取用者都能獲得相同的體驗。
微服務架構的潛在挑戰
微服務架構有許多好處，但並非萬能。 微服務架構本身具有一些挑戰：
- 簡化
- 開發與測試
- 缺乏控管
- 網路壅塞與延遲
- 資料完整性
- 管理
- 版本管理
- 技能
簡化
微服務應用程式的變動組件數量比同等單體式應用程式的還多。 每個服務會更為簡單，但是系統整個會變得更複雜。 搭配服務探索、協調流程和自動化工具，您可能要在整體應用程式中管理更多項目。
開發與測試
在撰寫需仰賴其他相依服務的小型服務時，必須使用不同於撰寫傳統整合型或分層式應用程式的方法。 現有工具的設計不一定適合處理服務相依性。 跨服務界限進行重構會很困難。 測試服務相依性也會很困難，尤其是當應用程式的演變速度很快時。
缺乏控管
微服務的非集中式建置方法有其優點，卻也可能導致問題發生。 您最終可能會有很多不同的語言和架構，而讓應用程式變得難以維護。 備有某些適用於全部專案的標準，而不要過度限制小組的彈性，這樣的做法可能會有幫助。 建立統一標準的需求特別適用於跨領域功能，例如記錄與計量。
網路壅塞與延遲
使用許多小型且細微的服務可能會導致服務之間需要更多通訊。 如果服務相依性鏈結太長 (例如，服務 A 呼叫 B，B 再呼叫 C...)，這些網路呼叫的額外延遲可能會成為問題。 請小心設計您的 API。 請避免對話過度的 API、考慮使用序列化格式，並找找看有沒有地方可以使用非同步的通訊模式。
資料完整性
每個微服務都需負責維持自己的資料持續性。 因此，維持資料一致性會成為挑戰。 可能的話，請採用最終一致性。 您也可能陷入重複資料和擴張資料架構的窘境。 這種情況可能會增加原始儲存體成本，以及服務和資料重複造成的資料平台服務成本。
管理
若要成功運用微服務，就必須有成熟的 DevOps 文化。 在服務之間建立關聯式記錄會非常困難。 一般而言，記錄必須將多個服務呼叫相互關聯到單一使用者作業。
版本管理
服務的更新不得打斷與其相依的服務。 多個服務有可能在同一時間一起更新。 在未謹慎設計的情況下，便可能發生回溯相容性或往後相容性問題。 如果服務延後採用新的 API 版本，可能會增加舊版 API 所需的資源和維護。
技能
微服務是高度分散的系統。 這些分散式系統通常需要不同的技能以進行適當開發、管理和維護。 請謹慎評估小組是否有技能和經驗能夠成功。 讓小組擁有充分的時間與規劃，以完善相關技能。
何時應該要選擇微服務架構？
根據此背景資訊，微服務架構最適用於哪些情況？
- 需要高發行速度的大型應用程式。
- 需要高度擴充性的複雜應用程式。
- 具有豐富領域或許多子領域的應用程式。
- 由小型開發小組所組成的組織。