微服務學習歸納
寫在最前
照例嘮幾句，從《程式碼整潔之道》就認識了Martin，也拜讀他的部落格，從他提起微服務就一直挺有興趣，沒能抽出時間來實戰寫一個練手專案，今年開年後終於各種雜事都告一段落，開始慢慢啃書啃博文就商城題材寫一個專案。專案丟github寫了一半，又要生活所迫找工作，在這裡先對之前學習的內容做一下歸納總結。
概念
微服務架構有別於傳統架構將所有功能放在一個解決方案中釋出，它將功能分解成一系列鬆耦合的服務，這些服務通過某種協議進行互相協作完成原單體架構下的業務功能，提供了更靈活的佈署模式，更容易擴充套件，降低開發運維複雜度。所以微服務的核心理念是分治。
微服務架構將應用功能分而治之，使得架構上有如下優點：1.鬆耦合：降低系統內部重構變動對使用者的影響。2.抽象：改變某個服務的資料只依賴該服務的介面，每個服務對資料有絕對控制權，方便對資料進行控制。3.獨立和更高的可用性：各個服務可以分開打包釋出，獨立上下線，不影響其他服務。
當然微服務也有部分缺點，比如說：1.分散式事務問題：使用者請求業務涉及多個微服務保障一致性，比如說下單涉及到訂單、商品是否可用、庫存是否充足等。2.全能物件難以拆解：訂單就是一個涉及多方的物件。3.系統更復雜：加大了學習難度和服務編排治理，依賴較大的服務一旦掛了會造成系統雪崩。
微服務拆分原則
我把拆分規則作為一個重點板塊來歸納，因為這是微服務架構中最重要的一點，一旦沒能遵守規則拆分，最後只會成為套了一份微服務殼子的單體系統集合。一般地，我們遵循兩條原則（出自《敏捷軟體開發：原則、模式與實踐》）：1.單一職責原則：原文中指一個類應該只有一個職責，不應該有更多改變類形態的原因。推理到微服務中就是微服務應該有且只有一個職責，以免造成業務之間的高耦合使業務改變時埋下不穩定因素。2.共同封閉原則：共同封閉原文是指一個變化如果對一個封閉包產生變化，則將對該包所有的類產生影響，而不影響其他包。歸納到微服務就是，我們應該將業務上聯絡緊密、會因為同一個原因改變的服務放在一個微服務。總結下來就是將業務關聯較高的服務放在一起，除此之外全部拆分。比如說在某些應用可以根據業務將使用者服務放在一起，但是應用中如果有使用者服務關聯不緊密的情況也可以拆分使用者服務、拆分為登入註冊服務等。
微服務基本構成
微服務架構一般會有以下幾種非功能性微服務：
1.服務治理微服務，用以服務發現、服務註冊、服務治理等。
2.服務統一入口：用以統一轉發到各個服務的統一入口
3.許可權管理服務：用以管理微服務對外介面的許可權驗證
4.效能監控服務：用以監控各個微服務的健康度
除了以上還有一些非功能性微服務，這裡就不一一列舉了。
微服務和SOA對比
SOA是面向服務的架構，通常是鬆耦合的，它將服務進行拆分，通過ESB進行互動和訊息呼叫，一般地，還是整個專案級別拆分，大家用的還是相同的開發語言、資料庫。
微服務則是在SOA基礎上升華，每個服務都是獨立並存的，它可以是不同開發語言、不同資料庫只需要遵守同一個互動協議就可以進行互相呼叫。
寫在最後
對微服務的概念理解還是比較淺薄，可能從實踐專案上更能學到東西吧，我會繼續寫那個github的練手專案的。學習微服務的過程中，我參考Martin Fawler的博文、《Spring Cloud 微服務架構開發實戰》等資料，都是非常好的學習資料。