建站
咨詢
售后
建站咨詢
新聞中心
作者：王清培(Plen wang)
滬江 公共業(yè)務平臺 應用架構師
轉載至滬江技術學院微信公眾號
背景介紹
最近一段時間公共業(yè)務平臺在進行大面積的重構，對原來的技術棧進行遷移，逐漸往Java、Go、Node.js等開源、自由為主的技術體系中過度。
雖然這主要是替換技術框架，但也是我們應用系統(tǒng)進行重新設計、業(yè)務流程重新梳理的一個好機會，我們將利用這次機會來重構之前發(fā)現(xiàn)的一些問題。
Martin Fowler大師《重構》一書中有說過一句話，大概意思就是，“每次對原有系統(tǒng)進行修改調整的時候是一個非常好的重構契機?！?/p>
對一個正在運行良好的系統(tǒng)進行重構機會不多，這種需要對系統(tǒng)進行適當?shù)男薷幕蛘哒{整的時候，可以借機重構。如果總是不抓住這樣難得的重構機會，就意味著積累的技術債務永遠償還不了，最后頻繁的破窗效應、墨菲定律。我們正視前行的道路上欠下的技術債務，把握恰當?shù)臅r機及時償還，這樣才有可能不會因為技術包袱影響系統(tǒng)建設，影響業(yè)務發(fā)展。這些在George Fairbanks 大師的《恰如其分的軟件架構》一書中講解的很深刻，最重要的一條就是“風險驅動”的架構設計原則，一定要先識別出風險，針對風險排好優(yōu)先級及時重構解決。
我們還面臨著一個大的問題就是，需要一邊支持業(yè)務高速發(fā)展一邊進行系統(tǒng)重構，更要命的是還需要支持各業(yè)務線進行各種大促活動，配合進行核心交易系統(tǒng)壓測等等，可想而知這種壓力還是不小。
而且我們是滬江集團的公共業(yè)務平臺，我們是服務于滬江集團所有業(yè)務線，包括B2C業(yè)務（滬江網(wǎng)校）、直播業(yè)務（CCtalk）、外部訂單業(yè)務（開放平臺）、UGC（滬江問答）、批量導入訂單（TPS峰值較高）等核心業(yè)務。
大家可能對傳統(tǒng)電商的業(yè)務比較了解，但是對教育行業(yè)的類電商業(yè)務可能不是很了解，兩者之間大的一個區(qū)別就是在商品的標準化上。教育是以服務為主，不是一個簡單的買賣商品的過程，而是一個智能推薦的過程，所有的商品都是需要基于用戶之前的學習數(shù)據(jù)來動態(tài)生成，也就是說，公共業(yè)務平臺的商品系統(tǒng)中的商品是動態(tài)變化的，沒有固定屬性的商品，商品的屬性一直隨著數(shù)據(jù)積累在進化。
這就帶來一個巨大的挑戰(zhàn)，因為一旦不是基于一個固定標準的商品來進行交易系統(tǒng)、商品系統(tǒng)、營銷系統(tǒng)、商戶清結算系統(tǒng)等核心系統(tǒng)設計時會面臨著一個極大的抽象難度，必須建立起一套龐大且可以落地的抽象模型出來，足以容納那些變化萬千的業(yè)務模式。這方面的系統(tǒng)建設還沒有太多成熟的模式可以參考，這是一個考驗你綜合技術能力的時候，光有一個“具體”的技術是解決不了這種問題域的。
這個背景介紹主要是為了能夠與讀者達成一個基本技術討論的上下文環(huán)境，目的是為了在講解本文主題的時候大家在一個頻道上，這樣才不會浪費大家寶貴的時間。
通過背景介紹，至少我們達成以下共識，我們正在做系統(tǒng)重構，業(yè)務主要是提供服務型商品，背后需要很多智能化的支持，同時我們是平臺型的系統(tǒng)，所以我們會陸續(xù)面臨平臺型系統(tǒng)所碰到的所有問題。
本文僅僅代表個人對應用架構、軟件工程的一些獨立思考的總結。
微服務怎么來的
把一個業(yè)務系統(tǒng)設計好，這本身所面對的問題域就是偏業(yè)務分析、業(yè)務設計。大部分的時間都是在根據(jù)對業(yè)務的理解來進行抽象建模，搞清楚邊界，站在一個較高的角度看待問題。（這在架構設計領域常被稱為“上帝視角”）
受當下比較熱的技術之一微服務影響，大家都在談論我們要打造微服務架構。當我們都沉迷在微服務的技術中時，會主觀的傾向性的用微服務來輔助你的系統(tǒng)建模，也就是將微服務的方法論提升到了系統(tǒng)分析的戰(zhàn)略層面，這將直接決定了系統(tǒng)架構建設的方向。
所以由此我花了點時間反思了微服務，我們必須徹底的看清楚它的來龍去脈，這樣才能把它用在合適的地方。要想搞清楚微服務是什么并不簡單，需要很多證據(jù)和線索，來幫助你辯證、推理你的判斷。
微服務的提出者是本章前面提到的Martin Fowler，他是世界軟件大師，Thoughtworks首席科學家，著作頗多。如果你讀過他的一系列經(jīng)典書籍的話，你應該知道他是“軟件”大師，他不是類似“JAVA并發(fā)”大師Doug Lea，他們是不同領域的大師，所解決的問題域是不同的。確定這一點很重要，這可以讓你明白微服務是由誰提出的，提出來用來解決什么類型問題域，這是重要的線索之一。
Martin Fowler與太多東西有關系，他與Robert C.Martin是我們在應用系統(tǒng)建設領域接觸最多的大師，Robert C.Martin《敏捷軟件開發(fā)-原則、模式與實踐》榮獲Jolt大獎。還有一位大師不得不提，《UML與模式應用》作者Craig Larman，他的GRASP也是經(jīng)典中的經(jīng)典，不可錯過，絕對是武裝你應用架構能力的重要武器。
如果你是一名應用系統(tǒng)領域建設從業(yè)者，你應該不會錯過大師們的經(jīng)典。他們三個大師都會經(jīng)常性的出現(xiàn)在一些經(jīng)典書籍的推薦序中，如，在Craig Larman的《UML與模式應用》的推薦序中，第一個就是Martin Fowler。
《UML和模式應用（原書第3版）》的結構和重點建立在作者多年教授和培訓成千上萬學生掌握OOA/D的經(jīng)驗之上，它提供了一個精煉的、已證明的和高效率的掌握OOA/D的學習方法。
“人們經(jīng)常問我，介紹OO設計的圖書是哪一本。讀過《UML和模式應用（原書第3版）》之后，我毫無保留地選擇了它。”
——Martin Fowler，《UML Distilled》和《Refactoring》的作者
還有很多為了解決軟件復雜性而作出努力的大師，像Peter code建模大師，他發(fā)明了彩色建模，讓我們能夠用不變的方式勾勒、描繪出任何復雜的領域，像“實體”、“角色”、“描述”、“時刻時段”，他的著作《彩色UML建?！贩浅＝?jīng)典。此書里的一個經(jīng)典分析方法就是：“某個角色的對象，在某個時間里、某個場景下做了某件事情，觸發(fā)了某種事件（event）”。
比如：會員等級Level1的用戶plen，2017年5月10號上午10:30分、在滬江網(wǎng)校的商城里購買了新版雅思7分沖刺【5月班】課程，觸發(fā)了創(chuàng)建訂單事件。
當你掌握了這種巧妙的方法之后你會喜歡上業(yè)務分析。一般人不會意識到“行為”是跟著角色走的，而是下意識的認為行為是跟著對象走的。請仔細揣摩這句話，看你能否搞清楚，這是系統(tǒng)分析中典型的問題，“職責分配”，這也是應用系統(tǒng)架構中的致命環(huán)節(jié)。
提示：你只有在公司才具有打開公司商業(yè)文件的權利，你只有在家里才可以和家人很親密。
這里面隱含的意思就是，“角色”賦予你的行為，你只有是公司的“員工”角色的時候才可以進行公司商業(yè)文件的瀏覽權限。你只有是“爸爸”或者“老公”又或者“兒子”的時候才可以和家人親密無間。在大街上摟摟抱抱的總是不太和諧，問題就在這里。你在大街上所扮演的角色是一個國家的公民，是有具體的行為準則的。所以角色決定了你的行為。
還有DDD（領域驅動設計）之父Eric Evans，DDD基本上是現(xiàn)代應用系統(tǒng)架構中必不可少的技術之一，包括阿里巴巴都在越來越多的運用DDD設計復雜的業(yè)務系統(tǒng)（你可以通過他們的招聘JD中發(fā)現(xiàn)）。DDD通過將問題域進行了設計抽象、通過將一個龐大的問題域如何進行子域的劃分，又如何識別出這些子域的立體關系，而不是上下關系，識別出落地的限界上下文，上下文的邊界交互模式，領域事件的影響、事件追溯（Event sourcing）等等。DDD里面明確了幾個重要的東西，“戰(zhàn)略模式”、“戰(zhàn)術模式”、“問題域”，當我們進行系統(tǒng)分析和建模的時候是運用戰(zhàn)略模式的時候。大多數(shù)時候我們錯誤的使用了戰(zhàn)術模式來解決戰(zhàn)略問題，你無法用戰(zhàn)術層面的技術解決戰(zhàn)略層面的問題。
DDD里面有很多突破性的技術，比較有意思的“事件驅動”、“事件溯源(event sourcing)”。
DDD強化實體，實體與實體之間的協(xié)作是通過event觸發(fā)，這里又與actor模型類似，每個actor即是一個獨立的微對象。
而在micro service里 服務盡可能小，服務之間也在強調事件驅動，SOA里也在提EDA架構。
問題的關鍵還是event怎么來，event都是特定domain的，event不會無故產生。所以得用DDD來解決event的抽象問題。
大家可能對event sourcing不是太了解，但是如果你對redis的AOF持久化了解的話，就大差不離了，redis也通過對key的操作形成一系列的event，然后通過key event來追溯數(shù)據(jù)的生命周期。
還有一些建模界的大師，像SOA大師，Thomas Erl，也是著作頗豐，他的書里有很多用SOA來建模企業(yè)整體信息架構的思路，所以SOA不純粹是一個RPC，他是代表一整套技術落地框架。
到此，你可能會好奇，這些與微服務有啥關系。先別急著下結論，這些都是用來搞清楚微服務是什么的重要線索。
我們是什么，工程師，而不是發(fā)明或者科研人員，工程師講究嚴謹、追溯、分析、看歷史、看未來、找規(guī)律，需要找到證據(jù)來證明我們的推理，而不是人云亦云，要不然沒有說服力，沒有獨立思考能力，在實施的時候要么都對要么都錯，無法進行思維的碰撞。
Martin Fowler、Eric Evans 這兩位大師就我個人而言意味著應用軟件開發(fā)界最高領袖和方向盤（這是個人信仰、和崇拜，誰讓我是他們的粉絲），Martin Fowler 的《企業(yè)應用架構模式》是軟件分層架構的思想最開始的地方。Eric Evans 是個偉大的突破者，正在征服軟件復雜性問題，《領域驅動設計—軟件核心復雜性應對之道》是我讀過的眾多書籍中感觸大，最讓人深思的書。
經(jīng)過上面的分析和追溯，我想表達的是這樣的一個構思導圖：（圖1）
上圖中從最左邊開始，一直到最右邊，是我在學習應用系統(tǒng)架構過程中總結出的一個大概技術發(fā)展或者是相互影響的關系。這些東西模糊著看，在歷史上發(fā)生的事情邊界并不總是那么明顯清晰，都有互相影響的作用。此圖主要是圍繞著一些本人學習過程中收集的一些技術影響力比較高的人來敘述，并不一定完全正確，能表達我們分析的思路即可。為了只是能將這些東西串起來推理微服務的由來。
圖的最右邊是Martin Fowler提出微服務的時候，看到這幅圖的時候你應該能大致的明白，其實微服務的提出者是用它來解決什么問題的，這里還不能完全對微服務的由來下個結論，因為還有一部分內容我們沒有分析。這里還有一個有力的證據(jù)可以證明，目前微服務書籍里評分最高的就是Thought Works公司技術專家編寫的《微服務設計》由圖靈出版社引進國內出版。在仔細看下書的目錄你會驚訝的發(fā)現(xiàn)微服務的落地需要DDD來輔助的，這起碼在建模階段是需要借助DDD強大的戰(zhàn)略模式來支撐的。所以，這里也證明了，微服務不是簡單的指將服務盡可能的拆小，然后一個RPC框架搞定了。這太粗糙了，無法落地的，會有一系列問題出現(xiàn)，比如，分布式事務問題、數(shù)據(jù)生命周期問題、數(shù)據(jù)延遲問題、抽象混亂問題等。抽象的工作做不好，落地的時候就會比較混亂，不易于擴展：（圖2）
如果用TOGAF的框架來劃分企業(yè)整體架構體系的話，至少微服務的技術棧在應用架構層是有明確的技術應用的，而不是全指系統(tǒng)架構層的某個具體的技術，如，docker、RabbitMQ、RPC之類的中間件。
如果大家仔細思考過你所學的應用技術在整個軟件工程的生命線上的發(fā)展關系時，你應該能發(fā)現(xiàn)一個規(guī)律，就是任何一個方法論的出現(xiàn)都會有兩個層面的東西，“識別問題域對問題域進行建?！钡姆椒?，最后才會談“如何落地的事情”。這是兩個大的層面問題需要解決，戰(zhàn)略層面、戰(zhàn)術層面。
所以技術都要用兩個層面來看，具體講就是分析、設計、建模，落地實施方法。這其中包括如下幾個比較重量級的技術體系，TOGAF 企業(yè)信息架構框架、DDD 領域驅動設計、SOA 面向服務架構、GRASP 通用軟件職責設計模式、彩色建?！纳湍Ｊ?。GRASP主要是輔助職責設計，四色原型主要是捕捉實體的事件發(fā)生序列，不會讓你丟失關鍵業(yè)務場景。
這些技術、方法論、模式并不是純粹的理論，而是有很多比較精妙的思想在里面，我們看下上述中他們是怎么劃分兩個層面來看問題的：（圖3）
學習搞懂這些模式，都是希望能夠讓我們不僅正確的做事，還需要做正確的事情。這些軟件大師不是在重復造輪子，而是軟件工程界一直有太多問題需要解決，而且問題是源源不斷的出現(xiàn)。
那么這些應用技術到底位于整個技術棧的什么位置，其實整個技術棧用分層來看，比較好理解：（圖4）
現(xiàn)在技術體系基本上分為三大類，應用架構、系統(tǒng)架構、中間件架構，當然還有運維架構、數(shù)據(jù)架構，后兩者跟我們文章主題關系不是很大，這里暫且先不談。這些在美國著名的TOGAT架構框架技術體系中講解的比較清楚，可以適當參考。 我不打算羅列太多技術概念，只想表達微服務這個技術是在應用技術棧范疇，跟其他的應用技術一樣都是具有系統(tǒng)分析、建模的能力，并不是一個純粹的框架或技術，而是一個綜合性的架構模式。
微服務是進化出來的
由此可以得出一個結論，微服務是進化出來的。其實縱觀軟件研發(fā)中的所有技術，大多都是進化出來的，很少突然出現(xiàn)一個跟之前所有技術不想關的技術。只不過理論性的知識容易被忽視，大多的技術人員喜歡直奔主題，動手敲敲就是一個微服務，其實只是運用了微服務技術體系中的部分技術。
我們一直有這樣的困擾，計算機領域的知識學習一直有一個難點就是：“解釋一個概念需要用另外幾個概念來解釋，但是解釋另外幾個概念還需要其他概念來解釋”，這不就是計算機領域的發(fā)展規(guī)律嗎。所以我們都在講究聚焦領域，每個領域都是深不見底，都有他的知識體系，都有他的技術棧。
由于時間關系，我并沒有把所有的線索和證據(jù)都羅列出來，其實還有很多東西都是和微服務有關系的，至少說微服務都是需要借鑒這些東西落地，比如，微服務中提到了服務的集成和編排，這些東西在SOA、DDD中都存在，很難說這是微服務的東西還是SOA、DDD的。所以都是互相借鑒和參考，再進一步演化，慢慢的就進化出一些具有代表性的技術概念。
微服務不是銀彈
當我們搞清楚了微服務是什么之后，就有助于我們進行運用了。首先可以肯定的是，微服務不是銀彈，他解決不了所有問題，之前存在的問題依然存在。當我們想要盡可能的使用微服務架構時，那么我們緊接著就要回答別人提出的一系列在SOA架構中同樣存在的問題，就要搞清楚如何回答別人提出的服務邊界怎么劃分問題，如果有GRASP、四色原型等輔助你來分析、設計，會工程化、科學化很多。
其實架構做了久了大家會發(fā)現(xiàn)一個潛規(guī)則，就是有時候方案沒有明顯的對與錯，而是說服力的問題。你的方案是否經(jīng)得起推敲，經(jīng)得起別人的提問，能否回答別人的疑慮。
所以當你將這些應用技術了然于胸之后，你大可不必說出來，而是稍加轉換下就可以慢慢影響你的架構方向。
總結
由于時間關系，我有很多技術點沒有展開，主要是為了考慮閱讀時間問題，我們將不間斷的分享重構過程中遇到的一系列問題。這其中會包括運用新技術，同時也會包括對以往經(jīng)典問題的反思。
希望這篇文章能夠讓你對微服務有一個不一樣的認識，主要是知道他位于整個技術棧的什么位置，這有點抽象，但是軟件本身不就是抽象中抽象，設計中設計嗎，軟件開發(fā)不就是在創(chuàng)造世界嗎。
軟件開發(fā)是一個綜合性的問題，我們無法用戰(zhàn)術層面的技術來解決戰(zhàn)略層面的問題，也無法用戰(zhàn)略層面的技術來解決戰(zhàn)術層面的問題。是技術就一定有適用場景，只有搞清楚某個技術的來龍去脈才可能避免濫用。
最后，雖然文章不算太長，但是文章中包含的技術面還是比較廣的，要想搞清楚，需要花點時間逐個研究一番才能把這些串起來，形成綜合的技術體系。謝謝。
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。
新聞標題：淺談微服務的來龍去脈-創(chuàng)新互聯(lián)
文章網(wǎng)址：http://www.dlmjj.cn/article/doeocj.html
