接着上篇文章分享的四個基本最佳實踐，《六種常用的微服務架構設計模式 創建微服務模式的基本最佳實踐（下篇）》文章來了，小編將爲您介紹其餘的四個基本最佳實踐。
五、監控
對於一個足夠複雜的基礎設施，可見性是有必要的。微服務從業者很難理解，在他們的軟件系統中嵌入一個有效的監控解決方案是至關重要的，而且也很難說這種方案不應該是任何優秀的應用程序的默認狀態。理想狀態下，無需更改應用程序代碼就可以測試軟件，但是遵循基本實踐（例如，將日誌記錄爲STDOUT/STDERR的事件流）可以更容易在適當的位置建立監控基礎設施。當然，這隻成功了一半，另外還需要更好地理解這些監控數據。關於如何有效地設計監視器和管理這些監控基礎設施的話題在本文中將不進行擴展討論，但是關於這個話題有許多具體的相關文章，比如James Turnbull的《監控的藝術》。
六、減小批處理
在精益生產中，我們瞭解到，減少批量方面的重要性。微服務作爲一組模式很明顯利用了這種方法：使用的服務單元越小，每個服務單元的操作就越簡單。當然，您擁有的服務單元越多，與之對應的，其管理就越複雜。
然而，即使不採用微服務模式，您也可以通過更頻繁、更少量地進行更改來減少部署單元的大小。即使在將更改部署到一個單體應用中時，實施更小、更頻繁的更改所附帶的操作規程也是有價值的。
七、容器化
使用容器來構建、隔離和管理部署單元通常是有用的，即使將這應用於單體架構軟件，效果也是如此。通過數據表明，使用容器不會帶來性能或安全方面的開銷，因此推薦使用Docker作爲部署的基本單元很容易。更好的一點是，微服務模式通常需要容器化技術，因此採用容器是爲使用微服務做好準備的一個良好步驟。
八、關注領域驅動設計
由於其對微服務架構的高適用性，領域驅動設計得到了新的普及。雖然，根據過往經驗，在大規模的微服務環境中，過度使用DDD（領域驅動設計）可能會分散注意力，但是領域驅動設計提出的實踐方法具有很高的價值，並且在一般情況下，這種實踐具有很大的應用價值，這一點是毋庸置疑的。此外，領域驅動設計可能更適合於單體模式的設計，而不是微服務模式，因此，在您的軟件中採用領域思維將是有益的，並且如果您需要進行更改時，這種思維將爲向微服務的過渡鋪平道路。
總結：建立適合您組織的微服務模式
既然您已經閱讀了不同的微服務模式，那麼評估哪種模式最適合您的組織就很重要了。它可以是一個，也可以是一個集合，或者您可能決定繼續使用一個單體架構。
重要的是要記住，微服務並不是解決所有問題的靈丹妙藥。它是一種設計用來克服障礙的架構，如果正確部署，將產生特定的預期結果。
在這裏討論的六種常用設計模式將如何演變，以及軟件將如何興起來簡化這種高度複雜方法的挑戰，這些都還有待觀察。然而，很明顯，許多企業將轉向採用微服務模式，我們希望通過提供這些模式的一些定義，可以幫助這些組織避免許多最明顯和痛苦的錯誤。
關於靈長科技
靈長科技自主開發的智能連接和數據集成平臺CEAMS，是爲Node.js技術生態中的API和微服務應用開發者量身定做的微服務應用開發，以及API運維管理系統。將系統連接、數據集成、業務邏輯全部通過鬆耦合集成於一體的開發平臺。系統的目標客戶主要是系統和數據集成開發者。開發者利用CEAMS系統，可以通過統一的規範模式，快速地與各類IT系統，數據庫，雲計算服務和智能設備高效對接，平臺不僅幫助開發者簡化了許多與底層設備對接的複雜操作，並基於提供大量的自動化工具。CEAMS系統已在國內包括省級政務雲平臺等多個IT項目中得到成功應用，並在單個項目中支持數十位開發者同時在線開發和管理自身的後臺微服務應用。目前，CEAMS系統已開放免費下載使用，感興趣的用戶可以點擊下方鏈接
https://www.apemesh.com/cn/download
瞭解有關靈長科技產品的更多信息或者與我們聯繫（email: [email protected], 企業QQ技術支持羣：618450152）。 目前我們也在招聘Node.js全棧工程師，歡迎有興趣的朋友們聯繫小編，向我們瞭解。
未經同意，本文禁止轉載或摘編。