作者：王清培(Plen wang)
滬江 公共業務平臺 應用架構師
轉載至滬江技術學院微信公衆號
背景介紹
最近一段時間公共業務平臺在進行大面積的重構，對原來的技術棧進行遷移，逐漸往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、四色原型等輔助你來分析、設計，會工程化、科學化很多。
其實架構做了久了大家會發現一個潛規則，就是有時候方案沒有明顯的對與錯，而是說服力的問題。你的方案是否經得起推敲，經得起別人的提問，能否回答別人的疑慮。
所以當你將這些應用技術瞭然於胸之後，你大可不必說出來，而是稍加轉換下就可以慢慢影響你的架構方向。
總結
由於時間關係，我有很多技術點沒有展開，主要是爲了考慮閱讀時間問題，我們將不間斷的分享重構過程中遇到的一系列問題。這其中會包括運用新技術，同時也會包括對以往經典問題的反思。
希望這篇文章能夠讓你對微服務有一個不一樣的認識，主要是知道他位於整個技術棧的什麼位置，這有點抽象，但是軟件本身不就是抽象中抽象，設計中設計嗎，軟件開發不就是在創造世界嗎。
軟件開發是一個綜合性的問題，我們無法用戰術層面的技術來解決戰略層面的問題，也無法用戰略層面的技術來解決戰術層面的問題。是技術就一定有適用場景，只有搞清楚某個技術的來龍去脈纔可能避免濫用。
最後，雖然文章不算太長，但是文章中包含的技術面還是比較廣的，要想搞清楚，需要花點時間逐個研究一番才能把這些串起來，形成綜合的技術體系。謝謝。