微服務(wù)作為架構(gòu)風(fēng)格幾乎成為云時代企業(yè)級應(yīng)用的事實標(biāo)準(zhǔn)，構(gòu)成微服務(wù)的技術(shù)元素本身卻并非革命性?？缙脚_的分布式通信框架、地址無關(guān)的服務(wù)注冊與發(fā)現(xiàn)、智能路由與編排等技術(shù)早已在CORBA、SOA時代實現(xiàn)了一遍又一遍，我們不禁好奇，微服務(wù)有什么不同？本文是對企業(yè)分布式應(yīng)用的一次回顧，與前微服務(wù)時代相比，我們究竟在哪些領(lǐng)域吸取了教訓(xùn)，哪些方面持續(xù)搞砸。

我們在重新界定抽象邊界上取得了進(jìn)展...

架構(gòu)的關(guān)鍵在于構(gòu)造合理的封裝抽象。良好的抽象構(gòu)造如進(jìn)程，由操作系統(tǒng)接管CPU調(diào)度、內(nèi)存地址空間分配和I/O，程序員的心智從此解放，得以聚焦在業(yè)務(wù)邏輯上。糟糕的抽象往往引向萬丈深淵，大量精力被浪費在抽象泄露帶來的問題上。

在分布式系統(tǒng)中我們關(guān)注組件、組件間的通信以及伴隨的工程實踐，微服務(wù)在企業(yè)應(yīng)用的上下文中就技術(shù)約束和業(yè)務(wù)價值間達(dá)成了更好的平衡點。

RPC？不，是API！

讓我們從組件間的通信開始，最初人們認(rèn)為這只是需要被解決的技術(shù)要素。

（圖片來自：維基百科）

關(guān)于如何實現(xiàn)跨平臺的分布式通信，30年前誕生的CORBA架構(gòu)在今天來看仍然非常漂亮：通過定義IDL/ORB/API我們可以將內(nèi)存對象任意分布于網(wǎng)絡(luò)中。只要共享IDL，對象可以由C++/Java等不同的語言實現(xiàn)，其互相調(diào)用就像本地方法一樣簡單。然而實踐經(jīng)驗告訴我們，分布式系統(tǒng)總是會出現(xiàn)本地調(diào)用不會發(fā)生的各種問題：網(wǎng)絡(luò)的開銷、傳輸?shù)难舆t、消息的超時和丟包、遠(yuǎn)端系統(tǒng)的崩潰……物理世界的技術(shù)約束是無法被忽略的，我們沒有辦法把分布式調(diào)用抽象成簡單的本地方法。因此Martin Fowler在他的<企業(yè)應(yīng)用架構(gòu)模式>里提出了著名分布式對象第一定律：“不要分布式你的對象”。相反，你應(yīng)該把盡可能多的操作置于進(jìn)程之內(nèi)，通過replicate整個應(yīng)用的方式來實現(xiàn)系統(tǒng)的scale。

由分析師們發(fā)起的SOA運動從另一個角度看待這個問題，Web Service應(yīng)該是對企業(yè)資產(chǎn)和業(yè)務(wù)能力的封裝。我們開始站在更高的維度，遠(yuǎn)過程調(diào)用不再只是技術(shù)意義上的集成。WSDL不僅是通信調(diào)用的接口，更是服務(wù)間的契約；UDDI不僅是服務(wù)描述、發(fā)現(xiàn)、集成的中心，更是企業(yè)業(yè)務(wù)與服務(wù)的黃頁。WS-*在廠商的裹挾下發(fā)展成包羅萬象，卻也沒幾個人能掌握。開發(fā)者們抱怨花了太多時間寫冗余的XML制定所謂的規(guī)范，WSDL生成的客戶端也將不同服務(wù)耦合在一起。是否有更加輕量敏捷的方式，讓我們快點開始寫第一行生產(chǎn)代碼？

于是我們看到REST的興起。起初是作為反叛，用更加輕量級的方式(http+json)使用Web。然后我們發(fā)現(xiàn)'企業(yè)級'應(yīng)用并非需要ESB這樣昂貴的專有中間件，由'消費級'技術(shù)組成的萬維網(wǎng)是世界上最大規(guī)模的分布式網(wǎng)絡(luò)，我們應(yīng)該向其學(xué)習(xí)如何構(gòu)建健壯、可演化的系統(tǒng)。Roy Fielding那篇論文所提出的無狀態(tài)、可緩存等特征已經(jīng)深入人心，而狹義上的REST API(基于資源的URI、HTTP動詞和狀態(tài)碼的標(biāo)準(zhǔn)接口)也成為API設(shè)計的最佳實踐。

既然API和網(wǎng)站一樣都是基于通用Web技術(shù)，API是否可以像網(wǎng)站一樣作為產(chǎn)品提供呢(APIs as product)？于是越來越多的企業(yè)開始將自己的業(yè)務(wù)能力封裝成API，提供給消費者，隨之而來的是更彈性的商業(yè)應(yīng)用和更靈活的計費方式。很多組織也著手構(gòu)建自己的API市場，把內(nèi)部IT能力整合、復(fù)用，并為孵化外部產(chǎn)品做準(zhǔn)備。API已經(jīng)成為商業(yè)價值主張的一部分。

我們從聚焦實現(xiàn)細(xì)節(jié)的rpc出發(fā)，來到了更具價值導(dǎo)向的REST API。即使構(gòu)建內(nèi)部系統(tǒng)，以消費者驅(qū)動的方式，也總是能幫助我們設(shè)計出更加松耦合和易于演進(jìn)的API。

技術(shù)組件？不，是業(yè)務(wù)服務(wù)！

編程語言中的組件構(gòu)造(如Java中的jar, C#中的dll)是軟件架構(gòu)師們封裝可復(fù)用單元的最常用武器。組件作為理論上的最小部署單元，在工程實踐中卻并不容易獨立變更。一般應(yīng)用程序需要講多個組件打包成一個部署單元(如war包)，鏈接在內(nèi)存地址中進(jìn)行調(diào)用。對單個組件的熱更新往往對組件間耦合和對象狀態(tài)管理有很高的要求，重新部署整個應(yīng)用一般是默認(rèn)選項。以進(jìn)程為邊界構(gòu)建可獨立部署的服務(wù)成為架構(gòu)師的另一項選擇。

早期的服務(wù)只是單純的技術(shù)構(gòu)件，大多數(shù)組織從純粹的技術(shù)實現(xiàn)角度考慮服務(wù)的劃分。SOA的推動者們指出企業(yè)的信息資產(chǎn)應(yīng)該被復(fù)用，信息孤島應(yīng)該被打通。通過將不同的服務(wù)編排組合，我們應(yīng)該能夠?qū)崿F(xiàn)IT對業(yè)務(wù)更加靈活的支撐。

（圖片來自：0SOA in practice, Nicolai Josuttism, 2009）

SOA的服務(wù)建模一般采用業(yè)務(wù)流程驅(qū)動的方式。一個典型的SOA設(shè)計是由業(yè)務(wù)分析師自頂向下地對企業(yè)現(xiàn)有業(yè)務(wù)流程進(jìn)行分析，通過BPM引擎對流程進(jìn)行建模，向下分解成組合服務(wù)，并進(jìn)一步拆分成數(shù)據(jù)訪問服務(wù)(很多可憐的SOA實現(xiàn)中數(shù)據(jù)的訪問被拆分成不同的讀服務(wù)和寫服務(wù))。然而這帶來的問題是，服務(wù)跟服務(wù)間的耦合非常嚴(yán)重。當(dāng)我的業(yè)務(wù)發(fā)生了變化，可能會需要修改很多不同的服務(wù)，涉及到多個團(tuán)隊的溝通和協(xié)調(diào)。在運行時層面，服務(wù)器間的通信非常頻繁，用戶在界面上的一次點擊按鈕，對應(yīng)的后臺多層服務(wù)間的級聯(lián)通信。這給系統(tǒng)性能和穩(wěn)定性也帶來了巨大的挑戰(zhàn)。SOA式的服務(wù)建模從分析型思維出發(fā)，卻往往低估了分布式系統(tǒng)和跨團(tuán)隊協(xié)調(diào)的復(fù)雜度，導(dǎo)致服務(wù)拆分粒度過細(xì)。

微服務(wù)的名字常常讓人誤解，但實施正確的微服務(wù)粒度可能并不'微'。Martin Fowler與James Lewis在開創(chuàng)微服務(wù)定義的一文中已經(jīng)指出微服務(wù)應(yīng)該圍繞完整的業(yè)務(wù)能力。今天我們在做微服務(wù)設(shè)計時，常常利用領(lǐng)域驅(qū)動設(shè)計中的Bounded Context來進(jìn)行服務(wù)邊界的劃分。假設(shè)你的庫存管理是一個獨立的業(yè)務(wù)子域，針對庫存的維護(hù)和操作應(yīng)該被放到通過一個上下文和微服務(wù)中，由一個團(tuán)隊進(jìn)行開發(fā)維護(hù)。多數(shù)業(yè)務(wù)變更都發(fā)生在上下文內(nèi)部，不涉及跨團(tuán)隊協(xié)調(diào)。單個codebase內(nèi)的重構(gòu)和部署讓發(fā)布更加容易。維護(hù)庫存所需要的信息查詢的調(diào)用多發(fā)生在進(jìn)程內(nèi)，更好的性能，同時無需處理額外的一致性問題。

微服務(wù)的另一個特點在于Product over Project，這需要不同于傳統(tǒng)投資組合的預(yù)算管理與團(tuán)隊組建。傳統(tǒng)的項目制將預(yù)算分配在相對短期的服務(wù)開發(fā)過程中，項目團(tuán)隊關(guān)注的是如何將業(yè)務(wù)范圍(scope)實現(xiàn)，開發(fā)結(jié)束后服務(wù)轉(zhuǎn)交運維團(tuán)隊進(jìn)行維護(hù)，項目團(tuán)隊則被解散進(jìn)行其他項目的開發(fā)。將微服務(wù)作為產(chǎn)品運營則需要建立業(yè)務(wù)結(jié)果導(dǎo)向的穩(wěn)定產(chǎn)品團(tuán)隊。服務(wù)的設(shè)計不只聚焦于當(dāng)下需求，更需要考慮價值定位和產(chǎn)品愿景。工程團(tuán)隊則需要思考如何用有限成本支撐非線性的業(yè)務(wù)接入增長。

（圖片來自：Enterprise Architecture as Strategy, Ross et al, 2006）

如今我們對服務(wù)的定義已經(jīng)超越了技術(shù)組件，領(lǐng)先的組織已經(jīng)在嘗試將design thinking, business operating model應(yīng)用到微服務(wù)設(shè)計中。

解耦服務(wù)就足夠了嗎？我們需要去中心化一切！

即使有了設(shè)計合理的服務(wù)于API，我們?nèi)匀恍枰c之匹配的工程實踐才能將其順利實施。

今天仍有很多企業(yè)使用集中式的應(yīng)用服務(wù)器部署應(yīng)用：開發(fā)團(tuán)隊將軟件包構(gòu)建出來，再統(tǒng)一安裝到應(yīng)用服務(wù)器中。對應(yīng)用團(tuán)隊來說，這往往意味著漫長的反饋周期和痛苦的自動化。我們很早就推薦用Jetty這樣內(nèi)嵌式的應(yīng)用容器部署軟件，啟動更快，測試環(huán)境更接近生產(chǎn)。one Tomcat per VM的部署方式雖然運行時開銷較大，卻是前容器時代隔離性最好的服務(wù)部署模式。Docker將這個實踐更進(jìn)一步，除了更輕量級的隔離，我們第一次可以將軟件和所依賴的環(huán)境本身打包成版本化的artifact，徹底統(tǒng)一開發(fā)和生產(chǎn)環(huán)境。容器技術(shù)的成熟讓我們可以將部署去中心化，開發(fā)團(tuán)隊可以獨立部署一個服務(wù)。

數(shù)據(jù)庫耦合是影響服務(wù)獨立變更的另一重要因素。相比代碼構(gòu)成的應(yīng)用軟件，數(shù)據(jù)庫schema更加難以變動。因為難以測試、難以兼顧性能優(yōu)化和耦合的發(fā)布周期等因素，服務(wù)間以數(shù)據(jù)庫集成成為臭名昭著的反模式。服務(wù)間的集成應(yīng)該依賴封裝好的顯示接口，而不是數(shù)據(jù)庫這種實現(xiàn)細(xì)節(jié)。我們應(yīng)該在兼顧數(shù)據(jù)一致性的情況下，為每個微服務(wù)分配獨立的db schema甚至db instance。如果說十年前數(shù)據(jù)幾乎等同于關(guān)系數(shù)據(jù)庫。如今數(shù) 據(jù)則可能呈現(xiàn)出各種形態(tài)：鍵值、文檔、時間序列、圖...我們完全可以采用更加合適的技術(shù)，以去中心化的方式進(jìn)行微服務(wù)的數(shù)據(jù)治理。

即使將這一切都解耦，如果將交給一個集中的團(tuán)隊去實施，很有可能最終還是得到一個耦合的架構(gòu)。這就是是著名的康威定律?？低筛嬖V我們“設(shè)計系統(tǒng)的架構(gòu)受制于產(chǎn)生這些設(shè)計的組織的溝通結(jié)構(gòu)”。但同樣我們可以將康威定律反轉(zhuǎn)應(yīng)用：如果你想達(dá)成一個目標(biāo)架構(gòu)，則必須對團(tuán)隊結(jié)構(gòu)進(jìn)行調(diào)整，使之和目標(biāo)架構(gòu)對齊。相比單體系統(tǒng)，微服務(wù)在運行時監(jiān)控和運維所帶來的挑戰(zhàn)更大。'you build it, you run it'的DevOps文化成為必須。監(jiān)控運維不再是Ops部門的事情，產(chǎn)品團(tuán)隊必須對微服務(wù)的整個生命周期負(fù)責(zé)。授權(quán)的去中心化自治團(tuán)隊是實施微服務(wù)的必要條件。

我們干得還不錯，但也在持續(xù)搞砸一些事情...

我們在很多方向的確取得了進(jìn)展。但即使在微服務(wù)時代，很多問題仍然在輪回發(fā)生著，似乎我們總是無法吸取歷史的教訓(xùn)。讓我們看一看那些揮之不去的反模式陰云。

一個例子是開發(fā)者對強類型RPC代碼生成的依戀。盡管歷史經(jīng)驗已經(jīng)證明同步的rpc無法為分布式通信提供足夠好的封裝，偽裝成本地方法調(diào)用的客戶端往往鼓勵程序員做出糟糕的接口設(shè)計：細(xì)粒度的頻繁調(diào)用、缺少緩存和容錯處理。IDL生成客戶端也會導(dǎo)致服務(wù)間耦合，每次變更接口都需要升級數(shù)個相關(guān)服務(wù)。如果用可演進(jìn)的REST API(如HATEOS)和tolerant reader模式，則可以優(yōu)雅地解決這個問題。然而新一代的開發(fā)者們還是經(jīng)?！爸匦隆卑l(fā)現(xiàn)rpc的這些能力并陷入依賴——更快的序列化反序列化、類型安全和來自IDE的智能提示、通過spec反向生成代碼...分布式計算先驅(qū)Vinoski不禁感嘆“開發(fā)人員的便利性是否真的勝過正確性，可擴展性，性能，關(guān)注點分離，可擴展性和意外復(fù)雜性?”

另一個揮之不去的陰影是ESB。ESB在將異構(gòu)的應(yīng)用wire在一起有著關(guān)鍵的作用。然而當(dāng)越來越多的職責(zé)被加入：數(shù)據(jù)報文的裁剪轉(zhuǎn)換、難以測試和版本控制的編排(orchection)邏輯、服務(wù)發(fā)現(xiàn)智能路由監(jiān)控治理分布式事務(wù)等All in One的solution將ESB變成了一個可怕的單點夢魘。所以微服務(wù)發(fā)出了“智能終端啞管道”的吶喊：我們只是需要一個不那么智能的代理處理可靠消息傳輸，將靈活的邏輯交給服務(wù)本身去編配(choreography)吧。

于是在典型的微服務(wù)架構(gòu)里，負(fù)載均衡、服務(wù)注冊發(fā)現(xiàn)、分布式追蹤等組件以Unix way的方式各司其職。然而在利益誘惑和特性競爭壓力之下，很多廠商不斷將更多的功能放進(jìn)他們的中間件，其中為代表的Overambitious API gateways儼然要重新實現(xiàn)占據(jù)中心的ESB。如果API gateway只是處理鑒權(quán)、限流等橫切層邏輯沒有問題，如果API gateway開始處理數(shù)據(jù)轉(zhuǎn)換和業(yè)務(wù)邏輯編排，你應(yīng)該提高警惕！

盡管行業(yè)在不斷發(fā)展，但很多時候人們?nèi)匀谎赜门f的思維，用新的技術(shù)去一遍遍重新實現(xiàn)這些舊的反模式。

如何更進(jìn)一步

你總是可以在技術(shù)雷達(dá)里追蹤微服務(wù)的state of art，如今這個領(lǐng)域的前沿方向是什么，Service Mesh, Chaos Engineering, 還是Observability as Code？然而歷史告訴我們，新的技術(shù)在解決一些問題的同時，也可能會產(chǎn)生新的問題。更糟糕的是，我們永遠(yuǎn)無法記住歷史，用新的工具更高效地重現(xiàn)舊日問題。

Technologies come and go, Principles stay forever。好在那些架構(gòu)和實踐背后的原則是經(jīng)久不變的。從操作系統(tǒng)到移動應(yīng)用都會需要高內(nèi)聚低耦合的架構(gòu)，任何軟件開發(fā)都需要版本控制、自動化構(gòu)建等實踐。謹(jǐn)記這些核心原則、謹(jǐn)記軟件被創(chuàng)造出來是為了解決有價值的問題，可以幫我們更好的借鑒歷史的經(jīng)驗，理解和采納新的技術(shù)。