年薪60W架構師詳細解讀微服務架構與領域驅動設計應用實踐

本篇文章一共分爲三個部分，分別是微服務架構的演進過程、具體實踐微服務的應用技術和領域驅動設計的意識轉變。微服務架構已經滲透到互聯網應用的方方面面，而領域驅動設計也逐漸被業界所接收。

1、微服務架構的演進過程

微服務架構幾乎都是從 ALL IN ONE 的單體架構演進而來，中間又經歷了分佈式架構、面向服務架構的演進過程。

 

單體架構每每以煙筒式方式發展，每每存在兩個主要問題：中心化和耦合度高。所謂中心化，就是數據集中存儲在單個數據庫中，業務系統集中部署在單臺服務器上，經過集羣部署方式提供服務能力，然而中心化的問題，也就是單點問題。而耦合度高，主要是指其中一個功能模塊升級，其它的模塊都得一塊兒升級。這裏要說明下，模塊依賴度高不是單體架構的錯，是由於原本架構可能就沒有設計好，可是，在實際場景中，隨着快速迭代開發，研發換了一波又一波，產品走了一茬又一茬，不免系統架構腐化嚴重。

看到了單體架構的諸多問題，系統開始經過按功能或模塊進行拆分，拆分紅多個獨立的子系統，系統間經過 RPC、MQ 方式調用，由此逐漸演變爲分佈式的服務架構。分佈式服務架構主要經過服務化和層次化進行解耦拆分，《架構整潔之道》書中提到一點，系統能夠降解爲策略和層次，而架構設計就是把相同的策略分到同一個組件中，反之，分屬於不一樣的組件。因此，架構設計能夠經過分層設計，由高層次服務調用低層次服務，低層次服務經過接口向上提供服務，以實現系統之間的解耦。也正是在這一階段，單體架構一會兒被拆分紅幾個或幾十個系統。

可是隨着架構的發展，問題又接踵而來，在沒有作好邊界的劃分以前，系統拆分的服務每每是鬆散的。正如《架構整潔之道》所講：軟件架構設計自己就是一門劃分邊界的藝術。因此，不少系統在這一階段，又每每進行了服務內聚和去層次化的演變過程。所謂服務內聚，就是以領域驅動設計爲原則，從新界定領域邊界，對模塊進行服務整合，對系統進行合併。而去層次化，則是去除服務層次高低之分，按服務調用最優鏈路提供服務請求，下降深度，以此保證系統的穩定性能。

2、具體實踐微服務的應用技術

系統如何從 0 到 1，從 1 到 2，從 2 到 100，在具體實踐微服務的過程並不容易。首先，考慮的第一個問題是：微服務是什麼？其實，微服務是一個動做：拆。說到拆，就涉及到兩個問題，第一，怎麼拆？第二，拆到什麼程度。

第一個問題，關於怎麼拆，須要關注兩個層面，一是發版速度，如商品、交易、促銷等不一樣領域的迭代速度和開發速度是不一致的，因此，應該拆分到不一樣的領域，不然，就可能耦合在一塊兒，A 上線 B 必須跟着一塊兒上，這可能就應該合併到一塊兒。另外一個是能源協同，每一個系統後面對應不一樣的研發團隊，一個項目每每須要幾個團隊分工協做，那麼系統拆分必然致使團隊協做的成本，因此拆分系統一樣也是拆分團隊，要考慮協做溝通所帶來的成本。

第二個問題，拆到什麼程度。其實，已經有不少人對微服務進行了定義，其中我認爲最重要的兩點：一是微服務或一組微服務，應該是一套獨立部署運行的服務，二是微服務所依賴的數據資源應該是彼此間相互獨立隔離部署的。

其實，拆只是實踐微服務的開始，要搭建總體的微服務框架還要進行四部曲：拆、服務化、高可用、隔離。

 

1，服務拆分

微服務講究拆分，那麼多微纔是微，以及，怎麼纔是比較合理的拆分。在架構設計領域，有一個你們都在講的著名定律：康爲定律，能夠理解爲：一個系統架構的組織關係是和團隊的組織關係相匹配的。如交易系統會對應一個交易系統的研發團隊，商品系統會對應一個商品系統的研發團隊，這種職責明確的組織結構會使得系統開發更高效。

 

（圖片來自網絡）

《將來架構》一書中講過一個 AKF 立方體模型，從三個緯度講述功能拆分、水平擴展、數據分區所產生的複雜度，若是隻有一個系統，單臺部署，單點存儲，那麼它就應該只是一個點，由於隨着量級的增大，系統在每一個緯度不斷延長，逐漸成爲一個龐大的立方體。

 

（圖片來自網絡）

拆分能夠分爲系統拆分、功能拆分和讀寫拆分。如一個單體系統中，按照用戶的交互場景看，門戶首頁能夠拆分爲前臺系統，類目、商品、搜索等功能能夠拆分到商品中心，訂單、結算、發票等功能則能夠拆分到交易中心，這就是簡單的系統拆分和功能拆分。而有些功能較爲特殊，如商詳頁，在讀取時須要聚合讀取，因此又能夠進行讀寫拆分。

2，服務化

微服務首先須要有微服務基礎設施，沒有微服務基礎設施，實踐微服務就是一場災難。以 SOA 落地方式爲例，SOA 落地方式主要有：分佈式服務化和集中式管理（ESB），分佈式服務化的技術手段有 dubbo 或 spring cloud 等等，必須有整套的如服務發現、服務訂閱、服務監控、服務追蹤、服務日誌等微服務基礎設置，才能進行微服務架構。不能簡單隻有 p2p 的服務調用就開始服務化，那是不現實的。

3，服務治理

當服務拆分的設計方案確認完畢，而服務化的基礎設施也部署到位，那麼系統每每一會兒就會忽然發佈出成百上千個服務接口，就像一個網絡同樣，每一個服務或微服務就像網中的一個節點，彼此之間關聯和聯繫。可是，服務網絡應該被設計成爲一個有向無環圖，不然，就是一團麻。如開始的時候，只是 A 調用 B，但隨着業務發展，須要修改，可是由於對 A 不瞭解，就加個環節 B 調用 A，如此造成了環形調用，不只邏輯複雜了，還下降了穩定和性能。

 

這裏的服務治理不是講中間件團隊的服務治理，如超時優化、啓動優化等等，而是做爲應用平臺對服務的治理。服務治理又分爲三個階段：服務梳理、服務界定和服務編排。所謂服務梳理就是梳理系統對外開放的服務化接口，包括服務的 provider 和 consumer，以及服務分組、動態路由等依賴的梳理，而後對拆散的服務進行歸類、界定，肯定服務領域從屬性，依據領域模型從新界定服務邊界，最後經過服務遷移、切換，對同一領域的服務接口進行服務整合，提供統一的服務出口，實現服務編排。

爲何要進行服務治理？那先來看看不進行服務治理的壞處。

 

微服務化拆分必然會在初期產生代碼處處拷貝，沒有一套代碼，必然會形成複雜的擴散，如一樣語意的 A、B 兩個接口，若是 A 接口存在性能問題須要加緩存，那麼 B 接口也會存在一樣的問題，並須要一樣的改造，這樣複雜度就會處處蔓延，同時也沒法實現統一的服務層架構，還有，若是一樣語意或類似語意的接口太多，那麼接口就是混亂的，沒法實現有限接口的治理，若是系統出了問題，可能很難定位問題。業務邏輯是依賴於數據的，若是接口是混亂的，那麼慢 SQL 等質量差的 SQL 就沒法進行有效收口改造，一樣就更加難以實現數據庫拆分和解耦。綜上，服務治理的過程就是從無序到有序的過程。

總結一下看從拆分到服務化的過程，就是將原來一個總體的服務打碎，碎成一塊一塊的零碎服務，而後再對服務從新歸類、整合，造成一個一個新領域的、獨立的服務。如單體架構就像一個宏偉的城堡，若是相對其中一個點進行調整和改造，那麼可能面臨着牽一髮而動全身的風險，

 

微服務化就是以一系列小的服務去支撐一個應用的方法論。簡明扼要的說，就是：分而治之。

4，服務高可用

服務拆分並服務化以後，是否是就完事了，不！真正的微服務實踐纔剛剛開始，簡單提供了一個接口，是沒有意義的，它必須具有高可用、高性能、高併發的三高特性，尤以高可用最爲重要。保障服務高可用的方法有不少，如數據異構、多級緩存、超時與重試、熔斷、異步併發、降級、限流、消息隊列、壓測與預案等。

 

重點說下數據異構，所謂數據異構，就是將經過順序消費或併發消費的方式，訂閱 MySQL 數據庫的 binlog，而後經過消息，如 Kafka 等 MQ 方式，異地存儲到緩存或其它數據源中，如 Redis、Elasticsearch 等。數據異構如今被普通使用，實現數據聚合，造成數據閉環。

在進行數據異構的過程當中，須要關注幾個關鍵點，一是 CAP 原則，即強一致性每每被捨棄，而採用最終一致性的設計。二是緩存，緩存在微服務架構中，不能被當成銀彈來使用，使用緩存必須正視的問題有：熱點緩存 & 大 Value 緩存、緩存穿透等問題。三是消息，消息如今還存在的問題有：延遲問題、消息的不穩定性（如丟消息）、消息的不肯定性（如 timeout）、消息補償、柔性事務等問題。而這些是微服務高可用架構實踐中，不能不面對的問題。

5，服務隔離

隔離也是服務拆分的一種，爲何單獨講？由於服務拆分、服務化、服務治理和服務高可用都是在事前或事中能夠作的，然而，有些系統已經成了某個樣子，那麼咱們接收時，首先能作到的就是迅速對系統進行隔離，保證業務之間不互相影響，具體實踐包括：進程線程隔離、集羣/機房隔離、讀寫隔離、動靜隔離、爬蟲/熱點隔離等。

3、領域驅動設計的意識轉變

從單體架構開始，到分佈式架構設計、微服務架構，再到如今領域驅動設計，做爲實踐微服務的架構師，思想上又有什麼變化？

我以爲，程序員都是很悶騷的，但每一個程序員內心都住一個大俠，金庸《笑傲江湖》裏有氣宗和劍宗之分，什麼是劍宗，我理解就像是劍招、招數，如 spring、spring boot、spring cloud，還有 tomcat、netty、serviceless 等，這些技術、中間件、框架等就像腳手架同樣能夠幫助咱們提升效率，可是，咱們是否須要出現一個新技術就學習一個技術呢？而這就讓我想到了氣宗，它就像是經過對內在規律的掌握，打通任督二脈，實現融會貫通，正如《九陽神功》所說：他強任他強，清風拂山崗，我自一口真氣足。如 Kakfa、Flink、Hbase 等分區可用性保障的設計思想都是基於 BigTable 的分區複製策略。

正是重心由外到內的轉變，讓我認知到，如今系統架構的發展，不少系統架構的複雜度，已經不是簡簡單單經過引入一些新技術或框架，就能下降系統複雜的。它須要大大的提早對風險、問題、隱患的預知，作到未雨綢繆。《從零開始學架構》書中提到：架構設計的發展歷程就是在於下降軟件系統複雜的歷程。

《架構整潔之道》書中提到：一個軟件系統存在的意義，是系統用來賺錢或省錢的那部分代碼，那纔是整個系統的皇冠明珠。因此，當拿到一個需求的時候，首先考慮的是要解決什麼問題，它的問題域是什麼，而不是先考慮用哪一種技術去實現或解決這個問題，這是本末倒置的處理方法。

從領域驅動設計的角度來看，需求首先是問題域，屬於業務邊界的事情，梳理了解要實現什麼功能和需求，而後在外延到工做邊界，確認團隊合做的方式，由於不少需求均可能須要跨團隊合做的，最後纔會到應用邊界，即技術實現的解決問題領域。

 

上圖是一個典型的洋蔥頭模型，它的思想就是闡述了從內到外的思考過程。而後，現實工做中，常常有人從外往內去考慮問題，從我過往的經歷舉例，一次是數據異構的方案，以前是採用 Storm，後來 flink 開始流行，我就將業務切換到了 flink，可是對於 flink 的調優不到位，從而影響了系統穩定性，還有一次是以前搜索用 solr，後來 es 開始流行，就像切到 es，可是 es 和 solr 兩套搜索引擎的搜索排序結果是不同的，最後，咱們只能強姦了業務。其實，這都是不太對的。《架構整潔之道》也提到：良好的架構設計應該儘量地容許用戶推遲和延後決定採用什麼框架、數據庫、Web 服務以及其餘與環境相關的工具。

理解領域驅動設計，需求或問題它開始於一個領域意願，由領域專家和交付團隊一塊兒，輸出統一語言和領域知識，統一語言能夠是敏捷看板，由於一個團隊是由產品、運營、研發、測試組成的，彼此之間是基於統一語言進行溝通的，而後定義領域邊界，區分核心領域、普通領域、支持領域，其中核心領域就是由核心團隊開發的，支持領域能夠是外包等實現的，在經過映射上下文，確認限界上下文，最終確認系統應用邊界。

 

（圖片來自網絡）

採用領域驅動設計的六邊形架構繪製了一張交易系統的領域邊界圖，不一樣顏色代表不一樣領域，U/D 表明上游和下游。這個圖還不算完整，由於領域業務邏輯是要爲端服務的，而經過對領域的梳理，能夠通用的支持不少端。即表達爲領域有界，端無界。最終，每一個限界上下文便是微服務。

 

4、總結

其實，每一個系統的微服務架構演進道路各不相同，因此，實踐微服務不能一板一眼原封照抄，而是要根據本身的業務特徵，合理的裁剪，找到合適落地方案。總結一句話，那就是：因需而變。雖然微服務的路徑是不同的，但方向是相同的。再次回顧微服務的架構演進歷程，你會發現，從單體架構開始，進行拆分，造成微服務以後，又由於各類這樣的緣由，不少微服務架構又在進行合併，如今領域驅動設計來了，又開始從新拆分。真可謂：話說天下大勢，分久必合，合久必分。

若有侵權請告知刪除

文章中涉及到的技術點我都分享在Java架構社區 142019080 裏，錄製成視頻供你們免費下載，但願能夠幫助在這個行 業發展的朋友和童鞋們，在論壇博客等地方少花些時間找資料，把有限的時間，真正花在學習上，因此我把這些資料， 分享出來。相信對於已經工做和遇到技術瓶頸或者寫博客碼友，在這份資料中必定都有你須要的內容