微服務化架構實踐感悟

從去年初開始接觸微服務架構的一些理念，然后到今年開始實施系統第四個大版本的架構升級決定采用這套架構理念。
最近關于微服務架構的討論還是多起來，因為國外一些著名互聯網公司（如：Amazon、Netflix 等）從實踐中摸索出了一套新的大型系統架構方法論，并取得了成功，樹立了很好的示范，然后這套方法論漸漸就被一些技術理論派
人士命名為微服務架構（Microservices）。

在微服務架構（Microservices）這個命名被正式提出來之前，我們做系統也有一套著名的思想理論，叫做面向服務架構（SOA）。
去年初我就寫過一篇文章 [《面向服務與微服務架構》]({% post_url 2014-04-26-面向服務與微服務架構 %}) 來闡述面向服務和微服務架構的關系，當時并沒有給出明確定義，只是有個模糊認知，而在近一年的實踐過程中兩者的關系越發清晰起來，
我們就從定義兩者的關系這里開始吧。

微服務（Microservices）與 面向服務（SOA）架構

You should instead think of microservices as a specific approach for SOA
in the same way that XP or Scrum are specific approaches for Agile software development.

</blockquote>

上面這段引用自 《Building Microservices》 一書，
通過過去一年的實踐認知，我對這個定義是認同的，面向服務架構（SOA）的概念已有十多年，它提出了一種架構設計思想，
但沒有給出標準參考實現，而早期企業軟件業界自己摸索了一套實踐方式 —— 企業服務總線（ESB）。
但歷史證明 ESB 的實現方案甚至在傳統企業軟件行業也未取得成功，Martin Fowler 說正是因為 ESB 當年搞砸了很多項目，
投入幾百萬美金，產出幾乎為 0，因此 SOA 這個概念也蒙上了不詳的標簽，所以當微服務架構出現時，
其擁護者開始拒絕使用包裹著失敗陰影的 SOA 這個標簽，而直接稱其為微服務架構（Microservices Architecture Style），
讓人以為是一套全新的架構思想，我也因此困惑了一段時間，但事實上它的本質依然是 SOA 的一種實現。
正如上面引文所說，就像早年流行的 XP（極限編程）和近年流行的 Scrum（好像沒有標準的中文說法）實際都是敏捷軟件開發思想
的具體實踐方法而已。

為什么選擇微服務架構

首先，當然是該套架構方法有著名的成功經驗才導致我去了解與學習它。
微服務架構中的 “微” 體現了其核心要素，即服務的微型化，就是每個服務微小到只需專注做好一件事。
這件事緊密圍繞業務領域，形成高度內聚的自治性。

以前我做過的一些大型應用系統，采用模塊化的分層式架構，所有的業務邏輯代碼最終會打進一個代碼庫中統一部署。
這種應用架構的問題是，全部開發人員會共享一個代碼庫，不同模塊的邊界模糊，實現高內聚、松耦合極其困難。
如果你接手過這類應用的遺留系統，嘗試去做重構改進時，肯定碰到過這類場景，改了一個地方好幾個其他模塊也需要同步改動，
模塊的邊界輕易被穿透，這種應用的架構有一個很形象的名字叫 “洋蔥架構”，洋蔥的特點就是一層又一層的粘連，
重構這樣的系統就像切洋蔥一樣讓人忍不住飆淚。

微服務架構強調 “微”，但之前有些采用了 SOA 服務化架構思想的系統會搞出很多胖服務來，一點也不微，這依然帶來耦合。
這一點只能依賴系統架構師的服務化建模能力了，但微服務架構強調每個服務一個進程，
使用進程為邊界來隔離代碼庫至少讓同一應用系統不同層次的開發人員享有自己完全自治的領地，每個微服務都有一個掌控者。
從某種程度上讓不小心做錯事，例如：跨出服務邊界的代碼耦合依賴，變得沒那么容易。

去年對我們應用系統的代碼行數做了個統計，有超過 40 萬行。
一個 20 人的團隊維護一個 40 萬行共享代碼庫的單一應用，在里面修改 bug 和添加功能都將十分困難。
有一篇文章 《程序員的成長和代碼行數的關系》 里提到大部分普通程序員成長生涯的瓶頸在 2 萬行代碼左右，
超過這個代碼行數的應用系統維護起來將倍感吃力，所以我們系統這兩年的高速發展膨脹，已讓團隊維護起來倍感吃力了。
所以我們想要把一個大系統拆分成許多不同的微服務，每個微服務的規模大小控制在一個普通程序員的舒適維護區能力范圍內。

微服務架構實施

把 1 個應用進程部署到 1 臺主機，部署復雜度是 1 x 1 = 1，我們有 200 臺主機，那么部署復雜度是 1 x 200 = 200。
把 1 個應用進程拆分成了 50 個微服務進程，則部署復雜度變成了 50 x 200 = 10000。
部署變得復雜和麻煩多了，同時監控的進程數也大幅增加，監控的復雜度也上升了很多。

所以實施微服務架構是有很高成本的，只有系統的規模到了一定程度才適合，這也是為什么微服務架構實踐誕生于大型互聯網公司。
微服務推崇一切自動化的文化，這也是因為其運維復雜度的乘數級飆升，
從開發之后的構建、測試、部署都需要一個高度自動化的環境來支撐才能有效降低邊際成本。

《Building Microservices》
一書對實施微服務架構有系統性的描述和很多業界案例的簡單引用描述，這里不展開講實施細節，那樣就太長了。
我們這里簡單總結下實施的要點：

1. 自動化文化與環境：自動構建、自動測試、自動部署。
2. 圍繞業務能力建模服務，松耦合、高內聚、暴露接口而隱藏實現細節。
3. 服務協作模型：中心化（樂隊模型：中心指揮）和去中心化（舞蹈模型：群舞自組織），各自場景不同。
4. 服務交互方式：RPC/REST/WS 技術很多但考慮統一。
5. 服務部署的獨立性、失敗隔離性、可監控性。
6. 服務流控：降級、限流
7. 服務恢復：多考慮故障發生如何快速恢復而非如何避免發生故障。
8. 服務發布：灰度。
9. 服務部署：一服務一主機模型，需要虛擬化(Hypervisor)、容器化(LXC, Docker)等技術支持，實現硬件資源隔離。
10. 服務配置：中心化配置服務支持
11. 康威定律：任何設計系統的組織，最終產生的設計等同于組織之內、之間的溝通結構。系統架構的設計符合組織溝通結構取得的收益最大。
12. 伯斯塔爾法則：服務健壯性原則 —— 發送時要保守，接收時要開放。
</ol>

自進化的微服務架構

早期人們把軟件開發和建筑學作類比，Architect 這個詞來就源于建筑學，但軟件產品和建筑物的性質完全不同。
建筑物本身一旦建成則幾無變化了，唯有老化后被替代了。
軟件系統會在其生命周期中不斷變化，唯一不變的就是變化，擁抱變化，需用進化的觀點看待架構演進。
與此類似的是城市，城市的演進發展總是漸進式的，我們不會在一座舊城旁建一座新城，然后把舊城的居民遷到新城然后再把舊城廢棄了。
但經常我們會用這樣的方法重寫一個新系統并替換掉舊系統，付出高昂的成本。

而微服務架構思路是不鼓勵這種方式的，系統的演進是通過局部的新增、改進或替換微服務來實現的。
而微服務本身的變化周期是不同步的，從整體上就形成了一種漸進式的、符合自然進化的系統演進道路。
所以 Architect（架構師）更像是城市規劃師而非建筑師，對軟件系統進行類似城市劃分區域的規劃。
從常識上我們知道把學校和住宅放在一個區域內是合理的，但如果再放一個垃圾處理廠則不合理。
學校和住宅就是提供兩種不同能力的服務，垃圾處理廠是另一種服務，但現實中軟件系統的規劃其實不像城市規劃那么有常識性，
這是架構師能力和經驗發揮作用的地方，前期規劃的不合理會在后期帶來維護成本的放大。

每個歷史悠久的城市都有各自不同的味道，城市中的人、時間、技術進步共同決定了今天城市的面貌。
微服務架構的妙處就在于它符合城市歷史演進規律，隨著人員變化、時間、技術改進而引發自然漸進式的進化。

微服務架構與架構師

架構師的一個角色是技術決策者，技術決策涉及很多權衡取舍（trade-off），而微服務架構給了架構師更多權衡取舍的空間。
每個微服務實現層面的技術決策更多由服務負責人決定，服務的分拆伴隨著決策權和責任的分拆，這也減輕了整體應用負責人的責任負擔。
架構師解放出來從整體和全局上將更加關注服務之間是如何交互，并確保能正確的監控系統全局的健康性。

分拆了服務實現的技術決策權，那何時又該適當的介入以避免服務實現不當危及整體系統的安全？
就像教孩子騎車，你無法代替它們去騎，你小心的看著他們騎的歪歪扭扭，擔心他們摔倒。
事實上，孩子騎車摔倒的次數比你擔心的要少，但如果每次快摔倒時都去扶住，那么他們也許永遠學不會騎車。
當孩子騎車失控時沖向了繁忙的馬路或要沖下路邊的深溝，那時才有必要介入去穩住他們。

架構師工作在抽象和具體兩個層面：

• 架構是一項技術工作，技術工作要服務于組織的戰略目標。
• 大量的工程實踐在每日的工作中不斷變化，而漸漸穩定的實踐方式被抽象提煉為一系列原則。
• 原則的普及帶來整體效率的提升和邊際成本的下降，以更有效的支持組織戰略目標的快速達成。
• 另外也要確保這些原則不是讓開發人員的生活變得更凄慘而是更美好。
• 跟蹤新技術發展確保能在合適的時候做出正確的取舍折衷。
• 讓開發人員理解某項技術決策的影響和制約以便最有效的執行，甚至在特定情形下深入到代碼的實現層面。
</ul>

文章開頭說了，這是我們實施系統的第四個大版本，而之前每一個大版本升級都是一次舊城倒新城的整體搬遷。
而微服務架構天然的自然進化屬性是否預示著這應該是最后一個大版本升級了？
微服務架構述說著沒有永恒的架構，只有進化的架構，但微服務架構不是銀彈，也沒有銀彈。

</div> </span>

來自：http://www.bubuko.com/infodetail-807473.html