1. 微服務的原則
- 圍繞業務概念建模，經驗表明，圍繞業務的限界上下文定義的接口，比圍繞技術概念定義的接口更穩定。
- 擁抱自動化文化，微服務包含太多複雜性的東西，比如我們不得不管理大量的服務。所以最好的方式是在前期花費一定的時間構建支持微服務的工具；還有自動化的測試，部署腳本等等，能夠幫我們做大多數耗時間的事情。
- 隱藏內部實現細節，爲了使一個服務獨立於其他服務，最大化獨自演化的能力。限界上下文建模在這方面可以提供幫助。服務還應該隱藏它們的數據庫，以避免陷入數據耦合。在可能的情況下選擇支持通用技術的API，這能讓你自由選擇使用不同的技術棧。
- 可獨立部署，通過採用單服務單主機模式，可以減少部署引發的副作用。考慮使用藍/綠部署或金絲雀部署技術。
- 隔離失敗，我們得考慮下游服務可能發生失敗的情況，否則系統會遭受災難性的故障。所以請記住“反脆弱的方式”，比如正確設置超時，瞭解何時及如何使用艙壁和斷路器。
2. 什麼時候不應該使用微服務
- 第一個建議是，你越不瞭解一個領域，爲服務找到合適的上下文就越難。前面說過，服務的界限劃分錯誤，可能會導致不得不頻繁的更改服務間的協作，這種成本很高。所以在劃分服務之前，第一件事情是花一些時間瞭解系統是做什麼的，然後嘗試識別出清晰的模塊邊界。如果是一個全新的業務領域，請首先考慮構建單塊系統，穩定以後再拆分。
3. 最後的贈言
微服務架構給我們帶來更多的選擇，也需要我們做更多的決策。所以，我們避免不了在某些決策上犯錯，所以請儘量所以決策影響範圍，這裏的思想是擁抱演進式架構。
每個組織構建的微服務都是獨一無二的，不要去追尋所謂的標準，最好把他們當做參考。我們的系統需要逐步改變和演進，以適應我們的業務，在任何時候我們的業務都能夠正常且具有一定效率的進行，就可以說明我們的系統是穩定而有效的。