微服務架構-介紹

之前在某年會的有大神提到微服務系統架構，最近還滿受到大家的關注，在好奇心作祟下買了建構微服務：設計細微化的系統這本來閱讀，如果想更進一步了解微服務，還滿推薦這本的，裡面介紹微服務的優缺點及如何建造微服務架構，包含如何設計、導入、系統重構拆解、部署、測試和監控等等的相關實務經驗。

什麼是微服務?

微服務是一種系統架構，是有一群獨立自主運作的小型應用服務，而小型服務之間透過API方式進行溝通，以協同合作方式組合出大型應用服務，在Martin Fowler的這一篇文章有詳細的說明。

圖來自於: http://martinfowler.com/articles/microservices.html

優勢

• 可提升軟體交付頻率，意味著新的功能可更快的上線。在微服務架構中軟體的變更，只會影響到本身的模組，較不會影響到另一個不相關的系統模組，且可以很獨立的控制部署週期。在龐大系統(Monolithic system)，無論內部如何的模組化，各個模組還是在同一個系統，在大型身軀下會降低系統交付速度和提高其風險，例如當你的系統的程式碼越大時，就會感覺到系統建置時間(Build time)會越來越長。

• 可自主性。可針對系統的需求或效能考量，選擇合適的技術和工具，可避免選擇一體適用的做法，像是可以選擇合適的開發語言或Database技術來使用。

• 可利用性。藉由重複使用來開發不同的裝置平台例如 Web、Mobile 和各種應用平台，避免重複造輪子。

• 可擴展性。可針對特別服務進行擴充，不需要像Monolithic system做整個擴充。

• 可隔離姓。如果某服務發生異常，而異常並未有其他連鎖反應，那麼可根據業務來區隔問題，以優雅降級(graceful degradation)方式，維持其餘系統的運作。如果是Monolithic system系統，就有可能整個系統掛點。

缺點及面臨問題

• 測試方式變為更為複雜。

• 微服務之間的資料交換，如何處理分散式交易(distributed transaction)是一個問題，當交易失敗時候，後續如何應對?

• 採用分散式資料庫時，會面臨到CAP定理困境。

• 如何管理各個微服務所採用技術架構，不過Docker虛擬化技術出現，似乎可以解決此問題。

• 系統業務切割範圍要多大還是多細微，此面臨到微服務的優勢和分散式系統的複雜度，如何在這之間取的平衡。採取單一設計原則(Single Responsibility Principle)是非常強而有力的設計理念，如果將系統架構切割成微服務，將相關責任集合起來，將不相關的責任分離，當然去定義好職責也不是一件簡單的事情。

總結

微服務並不是能萬吃的系統架構，因具有分散式所帶來的複雜度是需要去克服又有高度實作難度，如果要從Monolithic system 要演進成微服務系統，必須要有完善的CI(Continuous Integration)、CD (Continous Delivery)、虛擬化技術和系統監控，才較享有微服務獨立自主性的優勢。

PS 小弟第一次寫文章，有錯誤請指證