淺談微服務的前因後果

淺談微服務的前因後果

• 背景介紹
• 微服務怎麼來的
• 微服務是進化出來的
• 微服務不是銀彈

做者：王清培(Plen wang)

滬江Java資深架構師

轉載至滬江技術學院微信公衆號

背景介紹

最近一段時間公共業務平臺在進行大面積的重構，對原來的技術棧進行遷移，逐漸往java、go、node.js等開源、自由爲主的技術體系中過分。

雖然這主要是替換技術框架，但也是咱們應用系統進行從新設計、業務流程從新梳理的一個好機會，咱們將利用此次機會來重構以前發現的一些問題。

Martin Fowler大師《重構》一書中有說過一句話，大概意思就是，「每次對原有系統進行修改調整的時候是一個很是好的重構契機。」

對一個正在運行良好的系統進行重構機會很少，只有這種須要對系統進行適當的修改或者調整的時候，恰好能夠藉機重構。由於你若是老是不抓住這樣可貴的重構機會長此以往，就意味着你以前積累的技術債務永遠償還不了，最後就是頻繁的破窗效應、墨菲定律。咱們正視前行的道路上欠下的技術債務，把握恰當的時機及時償還，這樣纔有可能不會由於技術包袱影響系統建設，影響業務發展。這些在George Fairbanks 大師的《恰如其分的軟件架構》一書中講解的很深入，最重要的一條就是「風險驅動」的架構設計原則，必定要先識別出風險，針對風險排好優先級及時重構解決。

咱們還面臨着一個最大的問題就是，須要一邊支持業務高速發展一邊進行系統重構，更要命的是還須要支持各業務線進行各類大促活動，配合進行核心交易系統壓測等等，可想而知這種壓力仍是不小。

並且咱們是滬江集團的公共業務平臺，咱們是服務於滬江集團全部業務線，包括B2C業務（滬江網校）、直播業務（CCtalk）、外部訂單業務（開放平臺）、UGC（滬江問答）、批量導入訂單（TPS峯值較高）等核心業務。

你們可能對傳統電商的業務比較瞭解，可是對教育行業的類電商業務可能不是很瞭解，二者之間最大的一個區別就是在商品的標準化上。教育是以服務爲主，不是一個簡單的買賣商品的過程，而是一個智能推薦的過程，全部的商品都是須要基於用戶以前的學習數據來動態生成，也就是說，公共業務平臺的商品系統中的商品是動態變化的，沒有固定屬性的商品，商品的屬性一直隨着數據積累在進化。

這就帶來一個巨大的挑戰，由於一旦不是基於一個固定標準的商品來進行交易系統、商品系統、營銷系統、商戶清結算系統等核心系統設計時會面臨着一個極大的抽象難度，必須創建起一套龐大且能夠落地的抽象模型出來，足以容納那些變化萬千的業務模式。這方面的系統建設尚未太多成熟的模式能夠參考，這是一個考驗你綜合技術能力的時候，光有一個「具體」的技術是解決不了這種問題域的。

這個背景介紹主要是爲了可以與讀者達成一個基本技術討論的上下文環境，目的是爲了在講解本文主題的時候你們在一個頻道上，這樣纔不會浪費你們寶貴的時間。

經過背景介紹，至少咱們達成如下共識，咱們正在作系統重構，業務主要是提供服務型商品，背後須要不少智能化的支持，同時咱們是平臺型的系統，因此咱們會陸續面臨平臺型系統所碰到的全部問題。

本文僅僅表明我的對應用架構、軟件工程的一些獨立思考的總結。

微服務怎麼來的

把一個業務系統設計好，這自己所面對的問題域就是偏業務分析、業務設計。大部分的時間都是在根據對業務的理解來進行抽象建模，搞清楚邊界，站在一個較高的角度看待問題。（這在架構設計領域常被稱爲「上帝視角」）

受當下比較熱的技術之一微服務影響，你們都在談論咱們要打造微服務架構。當咱們都沉迷在微服務的技術中時，會主觀的傾向性的用微服務來輔助你的系統建模，也就是將微服務的方法論提高到了系統分析的戰略層面，這將直接決定了系統架構建設的方向。

因此由此我花了點時間反思了微服務，咱們必須完全的看清楚它的前因後果，這樣才能把它用在合適的地方。要想搞清楚微服務是什麼並不簡單，須要不少證據和線索，來幫助你辯證、推理你的判斷。

微服務的提出者是本章前面提到的Martin Fowler，他是世界軟件大師，Thoughtworks首席科學家，著做頗多。若是你讀過他的一系列經典書籍的話，你應該知道他是「軟件」大師，他不是相似「JAVA併發」大師Doug Lea，他們是不一樣領域的大師，所解決的問題域是不一樣的。肯定這一點很重要，這可讓你明白微服務是由誰提出的，提出來用來解決什麼類型問題域，這是重要的線索之一。

Martin Fowler與太多東西有關係，他與Robert C.Martin是咱們在應用系統建設領域接觸最多的大師，Robert C.Martin《敏捷軟件開發-原則、模式與實踐》榮獲Jolt大獎。還有一位大師不得不提，《UML與模式應用》做者Craig Larman，他的GRASP也是經典中的經典，不可錯過，絕對是武裝你應用架構能力的重要武器。

若是你是一名應用系統領域建設從業者，你應該不會錯過大師們的經典。他們三個大師都會常常性的出如今一些經典書籍的推薦序中，如，在Craig Larman的《UML與模式應用》的推薦序中，第一個就是Martin Fowler。

《UML和模式應用（原書第3版）》的結構和重點創建在做者多年教授和培訓成千上萬學生掌握OOA/D的經驗之上，它提供了一個精煉的、已證實的和高效率的掌握OOA/D的學習方法。

　　「人們常常問我，介紹OO設計的圖書是哪一本。讀過《UML和模式應用（原書第3版）》以後，我毫無保留地選擇了它。」　

　　——Martin Fowler，《UML Distilled》和《Refactoring》的做者

還有不少爲了解決軟件複雜性而做出努力的大師，像Peter code建模大師，他發明了彩色建模，讓咱們可以用不變的方式勾勒、描繪出任何複雜的領域，像「實體」、「角色」、「描述」、「時刻時段」，他的著做《彩色UML建模》很是經典。此書裏的一個經典分析方法就是：「某個角色的對象，在某個時間裏、某個場景下作了某件事情，觸發了某種事件（event）」。

好比：會員等級Level1的用戶plen，2017年5月10號上午10:30分、在滬江網校的商城裏購買了新版雅思7分衝刺【5月班】課程，觸發了建立訂單事件。

當你掌握了這種巧妙的方法以後你會喜歡上業務分析。通常人不會意識到「行爲」是跟着角色走的，而是下意識的認爲行爲是跟着對象走的。請仔細揣摩這句話，看你可否搞清楚，這是系統分析中典型的問題，「職責分配」，這也是應用系統架構中的致命環節。

提示：你只有在公司才具備打開公司商業文件的權利，你只有在家裏才能夠和家人很親密。

這裏面隱含的意思就是，「角色」賦予你的行爲，你只有是公司的「員工」角色的時候才能夠進行公司商業文件的瀏覽權限。你只有是「爸爸」或者「老公」又或者「兒子」的時候才能夠和家人親密無間。在大街上摟摟抱抱的老是不太和諧，問題就在這裏。你在大街上所扮演的角色是一個國家的公民，是有具體的行爲準則的。因此角色決定了你的行爲。

還有DDD（領域驅動設計）之父Eric Evans，DDD基本上是現代應用系統架構中必不可少的技術之一，包括阿里巴巴都在愈來愈多的運用DDD設計複雜的業務系統（你能夠經過他們的招聘JD中發現）。DDD經過將問題域進行了設計抽象、經過將一個龐大的問題域如何進行子域的劃分，又如何識別出這些子域的立體關係，而不是上下關係，識別出落地的限界上下文，上下文的邊界交互模式，領域事件的影響、事件追溯（Event sourcing）等等。DDD裏面明確了幾個重要的東西，「戰略模式」、「戰術模式」、「問題域」，當咱們進行系統分析和建模的時候是運用戰略模式的時候。大多數時候咱們錯誤的使用了戰術模式來解決戰略問題，你沒法用戰術層面的技術解決戰略層面的問題。

DDD裏面有不少突破性的技術，比較有意思的「事件驅動」、「事件溯源(event sourcing)」。

DDD強化實體，實體與實體之間的協做是經過event觸發，這裏又與actor模型相似，每一個actor便是一個獨立的微對象。

而在micro service裏 服務儘量小，服務之間也在強調事件驅動，SOA裏也在提EDA架構。

問題的關鍵仍是event怎麼來，event都是特定domain的，event不會無端產生。因此得用DDD來解決event的抽象問題。

你們可能對event sourcing不是太瞭解，可是若是你對redis的AOF持久化了解的話，就大差不離了，redis也經過對key的操做造成一系列的event，而後經過key event來追溯數據的生命週期。

還有一些建模界的大師，像SOA大師，Thomas Erl，也是著做頗豐，他的書裏有不少用SOA來建模企業總體信息架構的思路，因此SOA不純粹是一個RPC，他是表明一整套技術落地框架。

到此，你可能會好奇，這些與微服務有啥關係。先別急着下結論，這些都是用來搞清楚微服務是什麼的重要線索。

咱們是什麼，工程師，而不是發明或者科研人員，工程師講究嚴謹、追溯、分析、看歷史、看將來、找規律，須要找到證據來證實咱們的推理，而不是人云亦云，要否則沒有說服力，沒有獨立思考能力，在實施的時候要麼都對要麼都錯，沒法進行思惟的碰撞。

Martin Fowler、Eric Evans 這兩位大師就我我的而言意味着應用軟件開發界最高領袖和方向盤（這是我的信仰、和崇拜，誰讓我是他們的粉絲），Martin Fowler 的《企業應用架構模式》是軟件分層架構的思想最開始的地方。Eric Evans 是個偉大的突破者，正在征服軟件複雜性問題，《領域驅動設計—軟件核心複雜性應對之道》是我讀過的衆多書籍中感觸最大，最讓人深思的書。

通過上面的分析和追溯，我想表達的是這樣的一個構思導圖：（圖1）

上圖中從最左邊開始，一直到最右邊，是我在學習應用系統架構過程當中總結出的一個大概技術發展或者是相互影響的關係。這些東西模糊着看，在歷史上發生的事情邊界並不老是那麼明顯清晰，都有互相影響的做用。此圖主要是圍繞着一些本人學習過程當中收集的一些技術影響力比較高的人來敘述，並不必定徹底正確，能表達咱們分析的思路便可。爲了只是能將這些東西串起來推理微服務的由來。

圖的最右邊是Martin Fowler提出微服務的時候，看到這幅圖的時候你應該能大體的明白，其實微服務的提出者是用它來解決什麼問題的，這裏還不能徹底對微服務的由來下個結論，由於還有一部份內容咱們沒有分析。這裏還有一個有力的證據能夠證實，目前微服務書籍裏評分最高的就是Thought Works公司技術專家編寫的《微服務設計》由圖靈出版社引進國內出版。在仔細看下書的目錄你會驚訝的發現微服務的落地須要DDD來輔助的，這起碼在建模階段是須要藉助DDD強大的戰略模式來支撐的。因此，這裏也證實了，微服務不是簡單的指將服務儘量的拆小，而後一個RPC框架搞定了。這太粗糙了，沒法落地的，會有一系列問題出現，好比，分佈式事務問題、數據生命週期問題、數據延遲問題、抽象混亂問題等。抽象的工做作很差，落地的時候就會比較混亂，不易於擴展：（圖2）

若是用TOGAF的框架來劃分企業總體架構體系的話，至少微服務的技術棧在應用架構層是有明確的技術應用的，而不是全指系統架構層的某個具體的技術，如，docker、RabbitMQ、RPC之類的中間件。

若是你們仔細思考過你所學的應用技術在整個軟件工程的生命線上的發展關係時，你應該能發現一個規律，就是任何一個方法論的出現都會有兩個層面的東西，「識別問題域對問題域進行建模」的方法，最後纔會談「如何落地的事情」。這是兩個大的層面問題須要解決，戰略層面、戰術層面。

因此技術都要用兩個層面來看，具體講就是分析、設計、建模，落地實施方法。這其中包括以下幾個比較重量級的技術體系，TOGAF 企業信息架構框架、DDD 領域驅動設計、SOA 面向服務架構、GRASP 通用軟件職責設計模式、彩色建模—四色原型模式。GRASP主要是輔助職責設計，四色原型主要是捕捉實體的事件發生序列，不會讓你丟失關鍵業務場景。

這些技術、方法論、模式並非純粹的理論，而是有不少比較精妙的思想在裏面，咱們看下上述中他們是怎麼劃分兩個層面來看問題的：（圖3）

學習搞懂這些模式，都是但願可以讓咱們不只正確的作事，還須要作正確的事情。這些軟件大師不是在重複造輪子，而是軟件工程界一直有太多問題須要解決，並且問題是源源不斷的出現。

那麼這些應用技術到底位於整個技術棧的什麼位置，其實整個技術棧用分層來看，比較好理解：（圖4）

如今技術體系基本上分爲三大類，應用架構、系統架構、中間件架構，固然還有運維架構、數據架構，後二者跟咱們文章主題關係不是很大，這裏暫且先不談。這些在美國著名的TOGAT架構框架技術體系中講解的比較清楚，能夠適當參考。
我不打算羅列太多技術概念，只想表達微服務這個技術是在應用技術棧範疇，跟其餘的應用技術同樣都是具備系統分析、建模的能力，並非一個純粹的框架或技術，而是一個綜合性的架構模式。

微服務是進化出來的

由此能夠得出一個結論，微服務是進化出來的。其實縱觀軟件研發中的全部技術，大多都是進化出來的，不多忽然出現一個跟以前全部技術不想關的技術。只不過理論性的知識容易被忽視，大多的技術人員喜歡直奔主題，動手敲敲就是一個微服務，其實只是運用了微服務技術體系中的部分技術。

咱們一直有這樣的困擾，計算機領域的知識學習一直有一個難點就是：「解釋一個概念須要用另外幾個概念來解釋，可是解釋另外幾個概念還須要其餘概念來解釋」，這不就是計算機領域的發展規律嗎。因此咱們都在講究聚焦領域，每一個領域都是深不見底，都有他的知識體系，都有他的技術棧。

因爲時間關係，我並無把全部的線索和證據都羅列出來，其實還有不少東西都是和微服務有關係的，至少說微服務都是須要借鑑這些東西落地，好比，微服務中提到了服務的集成和編排，這些東西在SOA、DDD中都存在，很難說這是微服務的東西仍是SOA、DDD的。因此都是互相借鑑和參考，再進一步演化，慢慢的就進化出一些具備表明性的技術概念。

微服務不是銀彈

當咱們搞清楚了微服務是什麼以後，就有助於咱們進行運用了。首先能夠確定的是，微服務不是銀彈，他解決不了全部問題，以前存在的問題依然存在。當咱們想要儘量的使用微服務架構時，那麼咱們緊接着就要回答別人提出的一系列在SOA架構中一樣存在的問題，就要搞清楚如何回答別人提出的服務邊界怎麼劃分問題，若是有GRASP、四色原型等輔助你來分析、設計，會工程化、科學化不少。

其實架構作了久了你們會發現一個潛規則，就是有時候方案沒有明顯的對與錯，而是說服力的問題。你的方案是否經得起推敲，經得起別人的提問，可否回答別人的疑慮。

因此當你將這些應用技術瞭然於胸以後，你大可沒必要說出來，而是稍加轉換下就能夠慢慢影響你的架構方向。

總結

因爲時間關係，我有不少技術點沒有展開，主要是爲了考慮閱讀時間問題，咱們將不間斷的分享重構過程當中遇到的一系列問題。這其中會包括運用新技術，同時也會包括對以往經典問題的反思。

但願這篇文章可以讓你對微服務有一個不同的認識，主要是知道他位於整個技術棧的什麼位置，這有點抽象，可是軟件自己不就是抽象中抽象，設計中設計嗎，軟件開發不就是在創造世界嗎。

軟件開發是一個綜合性的問題，咱們沒法用戰術層面的技術來解決戰略層面的問題，也沒法用戰略層面的技術來解決戰術層面的問題。是技術就必定有適用場景，只有搞清楚某個技術的前因後果纔可能避免濫用。

最後，雖然文章不算太長，可是文章中包含的技術面仍是比較廣的，要想搞清楚，須要花點時間逐個研究一番才能把這些串起來，造成綜合的技術體系。謝謝。