多年來，我們一直使用各種工具，技術，架構模式和最佳實踐來構建軟件應用程序。顯然，由於各種原因，許多軟件應用程序在一段時間內會變成大型的複雜整體。整體軟件應用程序就像是一大團意大利麪，其組成模塊之間存在縱橫交錯的依賴關係。開發，部署和維護整體組件變得更加複雜，從而限制了開發團隊的敏捷性和競爭優勢。另外，讓我們不要破壞清除累積的任何技術債務的挑戰，因爲更改整體代碼的一部分可能會帶來破壞生產中工作軟件穩定性的連鎖影響。

多年來，諸如面向服務的體系結構（SOA）和微服務之類的體系結構模式已成爲Monoliths的替代方案。

SOA可以說是第一個架構模式，旨在通過將大型複雜的軟件應用程序分解爲子系統或“ 服務” 來解決典型的整體問題。所有這些服務都通過公共企業服務總線（ESB）進行通信。但是，這些子系統或服務實際上是中等大小的整體，因爲它們共享同一數據庫。同樣，越來越多的服務感知邏輯被添加到ESB中，並且成爲故障的單點。

由於諸如Amazon，Netflix，SoundCloud，Spotify等公司的大規模採用，微服務作爲一種架構模式已備受關注。它將大型軟件應用程序分解爲許多松耦合的微服務。每個微服務負責執行特定的離散任務，可以擁有自己的數據庫，並可以通過應用程序編程接口（API）與其他微服務通信，以解決大型複雜的業務問題。只要微服務能夠運行，每個微服務都可以獨立開發，部署和維護，而不會違反一組定義明確的API（稱爲與其他微服務通信的合同）。

微服務架構的優勢是什麼？

發展敏捷度

隨着大型複雜軟件應用程序分解爲許多小型微服務，每個微服務可以由小型“ 一個比薩餅”或“ 兩個比薩餅”團隊獨立開發。只要服務邊界得到明確定義，並且不確保違約，團隊可以獨立計劃，構建，部署和維護其微服務。團隊對變化更加敏感。

技術堆棧獨立

在典型的整體中，組成模塊具有“ 編譯或構建依賴項 ”，並共享“ 庫 ”功能。一個模塊中的任何更改都會觸發整個軟件應用程序的編譯和/或鏈接。因此，從根本上暗示並要求標準化技術棧（例如編程語言，數據庫等）以開發整體軟件應用程序。

相反，微服務可以作爲小型獨立應用程序進行開發，部署和維護，而無需與其他微服務進行任何編譯或構建依賴關係。它與其他微服務的依賴關係通過定義明確的API或合同進行處理。這意味着可以通過選擇最適合實現其功能的任何技術堆棧（編程語言，數據庫等）來開發每種微服務，而無需採用更加標準化，一刀切的方法。

管理技術債務更容易

讓我們說，我們發現一種微服務並沒有在生產中縱向擴展。我們可以通過修改該微服務代碼的特定實現部分來定位並解決該問題。或者，我們可以選擇使用最適合滿足垂直擴展目標的不同技術堆棧重寫微服務。無論採用哪種方法，只要消費者與微服務部門簽訂合同，開發團隊就可以自由地更改實現，而不會影響更大的系統。

改進的故障隔離

如果發生錯誤，整個整體應用程序可能會崩潰並破壞正常業務（BAU）。但是，微服務體系結構提供了改進的故障隔離功能，因此在一項服務中發生錯誤的情況下，整個應用程序不一定會停止運行。修復錯誤後，只能針對相應的服務部署該錯誤，而不必重新部署整個應用程序。

例如，在一個典型的電子商務應用程序中，讓我們說“ 產品評論服務 ”關閉了；結果，用戶將無法閱讀產品評論或撰寫新評論。但這不會影響其他服務，例如“ 產品目錄管理服務 ”，“ 訂單管理服務 ”等；因此，用戶仍然可以搜索，將產品添加到購物車並進行結賬。

擴展熱服務

開發後，微服務可以彼此獨立部署。它有助於識別“熱服務”並進行設計以獨立於整個應用程序進行擴展。類似的，微服務架構實現了對不同服務的自動擴展，從而實現了寶貴計算資源的最佳利用。相反，由於某些模塊處於休眠狀態，因此整個應用程序仍在運行，因此獨佔會佔用計算資源。

微服務架構的侷限性是什麼？

如果不仔細設計，微服務架構也會變得複雜。因此，必須考慮某些設計原則和實踐。

微服務的邊界

在定義微服務的邊界時，我們需要小心。它們既不應該成爲整體，也不應該太小而導致交換大量的API調用，阻塞網絡並降低整個應用程序的性能。域驅動設計有助於定義邊界。此外，請擴展羅伯特·馬丁·C（Robert Martin C）的“ 單一責任原則 ”，其中指出：“ 將因相同原因而改變的事物聚集在一起，而將因不同原因而改變的事物分開聚集 ”。

構建和部署

一旦定義了邊界，就應該由一個團隊來構建微服務，該團隊可以決定最佳技術堆棧以實現其功能。微服務之間的依賴關係是通過定義良好的API或合同定義的。理想情況下，只要遵守合同，它們就應該運行良好。但是，理想情況與實際情況相去甚遠。API或合同以不同API版本的形式不斷發展，並且可能導致應用程序崩潰。因此，必須使用任何可用的CI服務器（例如Jenkins）設置CI / CD管道，以運行自動化測試用例並將這些服務獨立部署到不同的環境（集成，QA，分段，生產等）中。

監控和記錄

微服務本質上是分佈式的，單個服務的監視和日誌記錄可能是一個挑戰。遍歷每個服務實例的日誌並找出單個錯誤是很困難的。因此，實施通用的“ 日誌和統計信息聚合服務 ”以從控制面板集中監視和控制所有微服務非常有意義。

微服務架構和敏捷軟件開發有很多共同點

正如與單片架構相比經常定義微服務架構一樣，敏捷軟件開發方法通過使用較小的工作增量，頻繁的迭代和原型製作作爲與用戶協作的方式，消除了大規模軟件開發的開銷和風險。

具有持續交付，DevOps文化和微服務架構的敏捷軟件開發都受到一組共同目標的約束-在保持高水平軟件質量和系統可用性的同時，儘可能響應客戶需求；換句話說–要敏捷。

您是否使用微服務架構構建了軟件應用程序？您是否已將大型整體分解爲許多微服務？如果是這樣，請在評論中分享您的挑戰和最佳實踐。