轉載:https://mp.weixin.qq.com/s?__biz=MzI5MDEzMzg5Nw==&mid=2660392863&idx=1&sn=d27ebf7a5d07883aeeaf886f0817eaa4&mpshare=1&scene=1&srcid=1102wGWkJZVowb6w8ct0pL8r&key=1c2aaa2ef4c83e3a8de3f466e25369f07ad9c18fd750733af170e83e52e18f218572d8217d6a72e19280f5cd18b381af0bcbad582d86ac189615b394677eee6b94efd41ecf97ccc4512cbf6574c5665d&ascene=0&uin=Mjg1MTA5MDE2MA%3D%3D&devicetype=iMac+MacBookAir7%2C2+OSX+OSX+10.12.2+build(16C67)&version=12020010&nettype=WIFI&fontScale=100&pass_ticket=Kz5tL1pmeMZc2KovEyw4GAK6hUnF9rt1%2Bs8rI3o2vACZRDxovIWpFJMLt6m6Unio

大家好，今天分享的是“基於微服務架構的技術實踐”，標題有點土，希望內容對大家有用。這個是我上週在CSDN北京沙龍上分享的內容的改版，加入了一些設計部分，才見了一些理念部分和自身平臺的具體內容，篇幅稍長，我們儘快進入主題。

內容分了三節，重點是第二部分，包括架構選型參考、6個關鍵模組設計、以及通用的概念模型、部署模型圖等。

·· ·

對微服務的認識

先進入第一部分：包括兩塊內容，說說歷史，說說問題。

微服務的說法由來已久，但真真風靡起來是2012年martin flower提出的，但為什麼現在大家一談微服務就容易吵吵呢，因為martin flower給了給多參考原則，但並沒有給出最佳實踐，是的現在大家一討論就會說應該按什麼什麼拆分，應該怎麼考慮互動與安全等等。

不妨我們先從企業應用架構來看看，微服務與原來有什麼區別：

第一個就不說了，第二個垂直架構，典型的比如SSH框架，幫大家考慮了模組化、MVC等，但並沒有考慮服務化。第三個是分散式架構，以SOA為代表的這類技術已經熱了很多年，現在也是企業架構的主體支撐部分。而第四個以微服務架構為支撐的技術雖然在一些先進企業或網際網路公司已經運用，但從生態上來看，還有很長一段時間要走。

所以會有了下面的這些爭吵：

曾經被人問的最多的就是，微服務應該按什麼拆分，以前會和別人說DDD，說康威，現在更多是不想回答了，因為怎麼說都有理，怎麼說也都有實際難以解決的問題。

再比如，微服務讓開發變得更簡單，是完全無依據的。這個往往建立在你已經把

·· ·

微服務架構實踐

回到今天的主體第二部分：

包括了技術和架構參考，平臺主要架構設計，以及關鍵的模組設計。

參考1：平臺品質屬性，這個圖大家應該不陌生，是在說一個平臺或者模組的設計，很難把各個維度面面俱到，往往是有取捨的支援，圖中“+”代表可同時享用，而“-”代表會有衝    突，著名的CAP原理其實也是這個意思。

參考2：擴充套件立方體，這個是在說平臺提升擴充套件性的幾個維度，X軸是通過克隆的方式，Y軸是通過業務功能拆分的方式，Z軸是資料拆分的方式。這個在系統設計中是一個進階參考，但在設計之初儘量要考慮清楚一定時間段裡，採用哪種模式作為預設方式。

參考3：Heroku的12Factor，這個以前提過，這些因素為系統的CloudNative目標考慮，讓雲上雲下得到同樣的體驗。

參考4：谷歌的優秀框架Borg，谷歌內部的管理排程核心，支撐著谷歌上萬臺機器及業務的執行，這個雖然是不開源的，但其設計思路和架構是很容易被找到和學習的。參考這個的原因是谷歌本身內部就是容器與微服務架構的生產運用，是一個真正大規模的實踐參考。

基於上述的參考等，我們驗證過上述的技術棧，用於支撐微服務架構，當然這裡面已經有不少被我們放棄了，上圖是從物件型別（橫向）和功能要求（縱向）給技術做了一些羅列，也是我們平臺使用的開源圖譜，大家有興趣可基於某幾個來探討。

緊接著我們開始嘗試微服務支撐平臺研發，因為前面的誤區提到了，微服務其實對支撐（開發、部署、運維等）平臺的要求比傳統更高了，所以這個正是我們的市場定位之一。

·· ·

在做的過程中，我簡單總結：有3個思考和6個關鍵設計，這裡其實篇幅考慮，省略了很多，比如自動化測試、比如一體化監控、比如安全控制等，後面應該會有同事往一些聚焦的話題分享。

思考1：我們要一個相容企業情況的模型，比如說：

有些企業會考慮生產上VM，開發測試上容器；

有些企業需要開發測試預發上線四套環境，有些只要兩套：

有些企業環境間要求完全隔離，有些只要邏輯隔離；

有些企業要求對接下層資源池，有些則完全沒有資源池的概念；

那概念模型上我們怎麼辦？上圖是一個片段，核心是業務執行及namespace，我們認為下層無論資源有沒有池化，都需要加一層Namespace的管理，這個管理有很多目標，比如隔離，再比如池化。

然後緊接著是pod，這個概念參考了kubernetes，在微服務執行時，一直強調一個業務的獨立性，比如一個業務，其應用及資料庫是繫結的，那我們認為這種就是一個pod（豌豆莢），體現的是一個獨立業務（服務）。

再從pod往下（一個pod無論內部如何，一般是跑在一臺宿主機的，業務內部儘量本地呼叫），pod可以包括多個程序，也可以包含多個容器，也就是上圖的pod與process的關係

再接著pod要求是叢集的，所以一個pod可以有多個副本，也就是上圖的pod與replication的關係。

最終業務要能對外提供能力，類似一個叢集對外的統一發布地址，也就是上圖的service的概念，service是外部的訪問入口，並擁有一定的敷在分發能力。

這張圖其實是一個詳細的對於概念模型實際執行的部署架構圖，這裡我就不展開講了，有興趣可以結合上一張圖一起看。

思考2：設計原則現在人人都會提，但微服務架構裡，我覺得最重要的幾個原則是這些：

隔離失敗：微服務架構下，相互間的通訊越來越多，不像單塊架構那樣，要壞一起壞，如何不受別人影響，以及自己不破壞別人，是要考慮的重點。

寬進嚴出：男總老拿Unix的設計來批我，這個其實就是其中一項重要原則，運用到微服務上，每個微服務要足夠寬容，讓更多人，更多方法可以接入，但返回的結果一定要嚴謹，要對別人負責。

PDCA：微服務下要以服務為級別快速迭代，迭代的依據是什麼，要能夠收集的來自上下游的足夠反饋。

MVP：畢竟前面提到了，微服務架構的最佳實踐太少，不要試圖一上來就做大而全的東西，一步一步走。

思考3：資料是最有效的依據，現在支撐微服務框架的開源技術很多，太多，用一個東西要有對比，要對比就要有測試資料，不是隻有資料。

···

接著我們談談關鍵的設計（這裡列了6個）

關鍵1：遮蔽異構環境，尤其像我們這種公有云和私有云同時發展的，要考慮各類環境（VM、容器、KVM、XEN、EXSI、NAS、SAN、CEPH、GlusterFS、SDN），這個也沒什麼特別的好辦法，就是看經驗，能力積累，架構一致。

關鍵2：微服務的隔離與互通，拿跑在容器裡舉例，互通要求的是“可達、快速可達、安全並快速可達”。一個微服務內部可採用本地方式，微服務之間採用service地址（無論內部怎麼漂移伸縮，對外地址不變），當然外部分為大叢集的微服務，以及乙太網的客戶端，對於公網上的，採用宿主機埠映射出去是個可選方式，當然要結合底層硬體基礎設施，比如阿里還有EIP之類。

同樣是關鍵2裡的：隔離，隔離有邏輯有物理，大家可結合實際需要來選擇，從宿主機隔離，到Namespace隔離，到建立邏輯子網，以及內部的iptables策略配置等。

關鍵3：微服務伸縮與漂移，上圖裡萬年不變的公式。以漂移為例子，漂移有很多觸發可能，有因為故障的，有基於優化考慮的，像優化這種，就要求定義很多維度，結合對微服務的監控打分加權。

同樣是關鍵3，要求的兩個基礎能力，第一是對於微服務點線面結合的監控，第二是監控資料的儲存分析（微服務散落各地，要彙總合併，要能串接分析）

關鍵4：微服務的升級與回退，既然要求快速迭代，那平臺設計上需要考慮：

釋出要原子化，可編排。

標籤設計，讓每個動作、每個狀態、每個資源都可以標識。

狀態設計，部署是原子化的操作，而內部的狀態設計同樣重要，可結合狀態做掛起、喚醒等諸多操作。

版本規範，這個無論是微服務還是傳統的都很重要。

路由能力，微服務這種快速迭代釋出，伴隨試錯試對，快速變更，灰度等，對流量的出入動態性要求很高。

同樣是關鍵4，這個其實是個有動態效果的圖，這沒貼上來有點怪，就不贅述了。

關鍵5：前面的原則裡大家是否還記得提到了隔離失敗，就是這個東西來做的，股市要熔斷，微服務同樣要，而熔斷器的設計參考了標準的三態設計，預設關閉，調用出錯率到一定程度半開，半開時，允許一部分流量繼續，如果一定時間還是出錯（這個時間結合MTTR），就全開；

同時還有一個關鍵，就是上下游呼叫時，拿上游來說，對於不同微服務的呼叫，本身要採用不同執行緒池，防止影響。

關鍵6：微服務註冊於發現，和上期的APIGateway不一樣，這個更多是微服務之間的，通過服務的註冊，支撐最終的客戶端和服務端叢集模式，客戶端叢集類似Dubbo，服務端類似傳統Ngnix；不同於dubbo或motan，註冊中心我們用etcd實現。

···

總結與展望

接著就是第三部分了：我們現在已經在客戶那邊做一些私有云下的微服務架構實施，同時對今天的分享做個總結。

跑出去實施才發現，你認為的往往真不是你認為的，客戶傳統服務也希望擁有微服務的管理能力（比如持續釋出、熔斷與升級），那需要怎麼做；客戶的很多小工具都希望在新架構中同樣發揮作用，比如像指令碼管理這種，那怎麼與平臺結合。這個一言難盡，建議安排的同學是不是後面我們可以安排分享一些客戶案例。

我們在微服務支撐平臺的實踐過程中，有些經驗各位可參考：

尤其最後一條，前些天從餓了嗎的架構師那邊學習，發現跟開源這件事情，真的是個持續過程，用開源不是簡單的使用開源，而是如何cover開源。

總結下，今天分享（時間關係做了一部分片子的裁剪），從架構演進及認知誤區開始，講了我們的參考架構，我們的微服務支撐平臺的概念模型和關鍵設計，最後做了簡單的實施問題描述和平臺時間總結。

最後如果大家對微服務有興趣，可以看看圖靈出版的《微服務設計》這本書，也可以持續關注我們，分享的同時，我們年底也會以書的形式呈現給各位，謝謝！

關於作者：

顧偉

現任普元資訊主任架構師。長期致力於IT技術研究、產品設計與開發、架構諮詢等工作，擅長Web、OSGI、CI/CD、服務治理、雲端計算等領域技術。對DevOps、自動化運維、微服務架構有著濃厚的興趣。

關於EAII

EAII（Enterprise Architecture Innovation Institute）企業架構創新研究院，致力於軟體架構創新與實踐，加速企業數字化轉型