多研究些架構，少談些框架（1） -- 論微服務架構的核心概念

微服務架構和SOA區別

微服務如今辣麼火，業界流行的對比的卻都是所謂的Monolithic單體應用，而大量的系統在十幾年前都是已是分佈式系統了，那麼微服務做爲新的理念和原來的分佈式系統，或者說SOA（面向服務架構）是什麼區別呢？
咱們先看相同點：

• 須要Registry，實現動態的服務註冊發現機制；
• 須要考慮分佈式下面的事務一致性，CAP原則下，兩段式提交不能保證性能，事務補償機制須要考慮；
• 同步調用仍是異步消息傳遞，如何保證消息可靠性？SOA由ESB來集成全部的消息；
• 都須要統一的Gateway來匯聚、編排接口，實現統一認證機制，對外提供APP使用的RESTful接口；
• 一樣的要關注如何再分佈式下定位系統問題，如何作日誌跟蹤，就像咱們電信領域作了十幾年的信令跟蹤的功能；

那麼差異在哪？

• 是持續集成、持續部署？對於CI、CD（持續集成、持續部署），這自己和敏捷、DevOps是交織在一塊兒的，我認爲這更傾向於軟件工程的領域而不是微服務技術自己；
• 使用不一樣的通信協議是否是區別？微服務的標杆通信協議是RESTful，而傳統的SOA通常是SOAP，不過目前來講採用輕量級的RPC框架Dubbo、Thrift、gRPC很是多，在Spring Cloud中也有Feign框架將標準RESTful轉爲代碼的API這種仿RPC的行爲，這些通信協議不該該是區分微服務架構和SOA的核心差異；
• 是流行的基於容器框架仍是虛擬機爲主？Docker和虛擬機仍是物理機都是架構實現的一種方式，不是核心區別；

微服務架構的精髓在切分

• 服務的切分上有比較大的區別，SOA本來是以一種「集成」技術出現的，不少技術方案是將原有企業內部服務封裝爲一個獨立進程，這樣新的業務開發就可重用這些服務，這些服務極可能是相似供應鏈、CRM這樣的很是大的顆粒；而微服務這個「微」，就說明了他在切分上有講究，不妥協。無數的案例證實，若是你的切分是錯誤的，那麼你得不到微服務承諾的「低耦合、升級不影響、可靠性高」之類的優點，而會比使用Monolithic有更多的麻煩。
• 不拆分存儲的微服務是僞服務：在實踐中，咱們經常見到一種架構，後端存儲是所有和在一個數據庫中，僅僅把前端的業務邏輯拆分到不一樣的服務進程中，本質上和一個Monolithic同樣，只是把模塊之間的進程內調用改成進程間調用，這種切分不可取，違反了分佈式第一原則，模塊耦合沒有解決，性能卻受到了影響。

分佈式設計第一原則 -- 「不要分佈你的對象」

• 微服務的「Micro」這個詞並非越小越好，而是相對SOA那種粗粒度的服務，咱們須要更小更合適的粒度，這種Micro不是無限制的小。

若是咱們將兩路（同步）通訊與小/微服務結合使用，並根據好比「1個類=1個服務」的原則，那麼咱們實際上回到了使用Corba、J2EE和分佈式對象的20世紀90年代。遺憾的是，新生代的開發人員沒有使用分佈式對象的經驗，所以也就沒有認識到這個主意多麼糟糕，他們正試圖重複歷史，只是此次使用了新技術，好比用HTTP取代了RMI或IIOP。

微服務和Domain Driven Design

一個簡單的圖書管理系統確定無需微服務架構。既然採用了微服務架構，那麼面對的問題空間必然是比較宏大，好比整個電商、CRM。

如何拆解服務呢？
使用什麼樣的方法拆解服務？業界流行1個類=1個服務、1個方法=1個服務、2 Pizza團隊、2周能重寫完成等方法，可是這些都缺少實施基礎。咱們必須從一些軟件設計方法中尋找，面向對象和設計模式適用的問題空間是一個模塊，而函數式編程的理念更多的是在代碼層面的微觀上起做用。
Eric Evans 的《領域驅動設計》這本書對微服務架構有很大借鑑意義，這本書提出了一個能將一個大問題空間拆解分爲領域和實體之間的關係和行爲的技術。目前來講，這是一個最合理的解決拆分問題的方案，透過限界上下文（Bounded Context，下文簡稱爲BC）這個概念，咱們能將實現細節封裝起來，讓BC都可以實現SRP（單一職責）原則。而每一個微服務正是BC在實際世界的物理映射，符合BC思路的微服務互相獨立鬆耦合。

微服務架構是一件好事，逼着你們關注設計軟件的合理性，若是原來在Monolithic中領域分析、面向對象設計作很差，換微服務會把這個問題成倍的放大

以電商中的訂單和商品兩個領域舉例，按照DDD拆解，他們應該是兩個獨立的限界上下文，可是訂單中確定是包含商品的，若是貿然拆爲兩個BC，查詢、調用關係就耦合在一塊兒了，甚至有了麻煩的分佈式事務的問題，這個關聯如何拆解？BC理論認爲在不一樣的BC中，即便是一個術語，他的關注點也不同，在商品BC中，關注的是屬性、規格、詳情等等（實際上商品BC這個領域有價格、庫存、促銷等等，把他做爲單獨一個BC也是不合理的，這裏爲了簡化例子，你們先認爲商品BC就是商品基礎信息）， 而在訂單BC中更關注商品的庫存、價格。因此在實際編碼設計中，訂單服務每每將關注的商品名稱、價格等等屬性冗餘在訂單中，這個設計解脫了和商品BC的強關聯，兩個BC能夠獨立提供服務，獨立數據存儲

小結
微服務架構首先要關注的不是RPC/ServiceDiscovery/Circuit Breaker這些概念，也不是Eureka/Docker/SpringCloud/Zipkin這些技術框架，而是服務的邊界、職責劃分，劃分錯誤就會陷入大量的服務間的相互調用和分佈式事務中，這種狀況微服務帶來的不是便利而是麻煩。
DDD給咱們帶來了合理的劃分手段，可是DDD的概念衆多，晦澀難以理解，如何抓住重點，合理的運用到微服務架構中呢？
我認爲以下的幾個架構思想是重中之重

• 充血模型
• 事件驅動​下面兩篇將爲你們詳細介紹這兩個設計思路