不為微服務(wù)架構(gòu)而架構(gòu)
“之所以采用微服務(wù)架構(gòu)，是因為相對SOA單體架構(gòu)而言，微服務(wù)這種組件化、松耦合、自治、去中心化的架構(gòu)，更靈活、敏捷，更能滿足業(yè)務(wù)需求。” 朗致集團數(shù)字化效能總經(jīng)理屠文珂，在SACC大會期間接受筆者采訪時表示，沒有一家企業(yè)，專門為微服務(wù)架構(gòu)而建架構(gòu)，而是由業(yè)務(wù)驅(qū)動技術(shù)落地的產(chǎn)物。
基于前后端徹底分離思想，前端是企業(yè)自己一整套的大前端體系，服務(wù)端以微服務(wù)進行具體的服務(wù)工程的切分，然后提供一系列API接口，通過網(wǎng)關(guān)統(tǒng)一對外提供服務(wù)。無論是安卓、iOS、 PC、小程序還是各種瀏覽器，應(yīng)用程序只開發(fā)一次就可以部署到所有的終端。
值得一提的是，微服務(wù)并非醫(yī)藥類企業(yè)專屬，互聯(lián)網(wǎng)、金融、游戲等具有快速迭代和交付需求的場景，都是微服務(wù)的重要應(yīng)用領(lǐng)域，具有廣泛的應(yīng)用前景。對于大多數(shù)企業(yè)而言，微服務(wù)在提高開發(fā)效率、提高系統(tǒng)的可維護性、可擴展性、可用性和可靠性方面，都具有顯著優(yōu)勢。當企業(yè)把一個大型單體架構(gòu)拆成各個小的顆粒的時候，會提升企業(yè)應(yīng)對市場變化的能力，對業(yè)務(wù)需求變化達到天或者小時級別的響應(yīng)。而不再像之前一樣，一個應(yīng)用版本開發(fā)下來，幾個月才能上線。所以，從技術(shù)應(yīng)用角度來看，微服務(wù)是一個通用型架構(gòu)，沒有特別嚴格的界限去圈定，哪些業(yè)務(wù)適合使用微服務(wù)，哪些業(yè)務(wù)不適合。微服務(wù)的本質(zhì)是，通過更合理的分工合作機制，去開發(fā)各種各樣的軟件，以供業(yè)務(wù)人員去使用。
微服務(wù)具體的實踐路徑有兩個：一、采用Dubbo、SpringCloud等開源微服務(wù)框架來構(gòu)建系統(tǒng)；二、采用自研技術(shù)路線來構(gòu)建微服務(wù)體系。不管采用哪種技術(shù)路線，最終的目的是簡化服務(wù)架構(gòu)，降低服務(wù)顆粒。當然，業(yè)務(wù)拆分過程中，也要注意很多關(guān)鍵點，如果拆分顆粒度過于精細，節(jié)點過多，會對運維帶來極大挑戰(zhàn)，導(dǎo)致企業(yè)沒有辦法進行管理。
謹防微服務(wù)橫跨“陷阱”
在實際微服務(wù)架構(gòu)落地過程中，會遇到各種各樣的問題，本質(zhì)上都可以歸結(jié)為是海量模塊之間的協(xié)作問題。如何真正做到微服務(wù)的分拆，又不相互影響，不發(fā)生實際的耦合？這是一個值得業(yè)界深思的話題！
“當系統(tǒng)拆分了200個微服務(wù)，其中超過1/3的微服務(wù)，都要調(diào)用超過50個其他微服務(wù)。微服務(wù)的初衷是當需求變更時，少數(shù)服務(wù)做調(diào)整即可滿足需求，而上述實際情況造成了實質(zhì)性的微服務(wù)耦合。” 屠文珂發(fā)現(xiàn)，微服務(wù)拆分的復(fù)雜度隨著服務(wù)數(shù)量的增多而呈現(xiàn)幾何級倍數(shù)增長。并且，這種狀況不是某一家企業(yè)的問題，在朗致集團每年面試的3000+程序員中，落入此陷阱的技術(shù)團隊為100%。
既然微服務(wù)無法避免耦合，落地的結(jié)果與初衷嚴重不符，當初為什么還要拆開？這其實是微服務(wù)橫跨帶來的缺陷！
在解決“橫跨缺陷”之前，我們先看看微服務(wù)發(fā)展歷史。微服務(wù)是由Peter Rodgers、James Lewis、Martin Flower、Chris Richardson等等一系列架構(gòu)專家，在2005年左右提出并構(gòu)建的一整套理論體系。比如：Chris Richardson在《Building Microservices Inter-Process Communication In A Microservices Architecture》論文中，闡述了采用IPC（進程間通訊）的方式，實現(xiàn)各個服務(wù)間的協(xié)同和互相調(diào)用，這一理論奠定了當前微服務(wù)的理論基礎(chǔ)，之后的Dubbo、SpringCloud、Soul框架都符合這一理論。
微服務(wù)的根本問題就是出在“理論”上，就像很多程序員，直到寫完代碼后才發(fā)現(xiàn)，之前的架構(gòu)設(shè)計存在缺陷，不得不把整個架構(gòu)推翻重來。說白了，只要理論沒有在最后一公里落地到實踐，這套理論就存在出問題的可能。所以，微服務(wù)的發(fā)展脈絡(luò)是，從最終的實踐出發(fā)，一路向上找原因，反推之前理論存在哪些瑕疵。
那么，微服務(wù)的“瑕疵”是什么？顯然是沒有控制住復(fù)雜度！如果我們用聯(lián)線服務(wù)之間調(diào)用關(guān)系的復(fù)雜度來表示微服務(wù)關(guān)系，可以發(fā)現(xiàn)服務(wù)簡單的時候沒有任何問題。2個微服務(wù)的聯(lián)線數(shù)量是1；3個微服務(wù)的聯(lián)線數(shù)量是3；4個微服務(wù)的聯(lián)線數(shù)量是6……總結(jié)出來一個公式就是n（n-1）/2，也就是說復(fù)雜度會隨著n的平方而增減，即隨著微服務(wù)數(shù)量而呈幾何級數(shù)的增長，這就是一種復(fù)雜度失控。進程間通訊不是隨意的，是嚴格受限的場景。
如果跨服務(wù)進行通訊，讀可以，一個服務(wù)可以調(diào)用其它服務(wù)的讀，但不可以調(diào)用另一個服務(wù)的寫接口。也就是說，理論科學(xué)家在IPC中描述的各種服務(wù)之間互相調(diào)用的方法，都只是理論上的可行性，最終落地才發(fā)現(xiàn)不行。實戰(zhàn)通過血的教訓(xùn)總結(jié)出：跨微服務(wù)之間可以調(diào)用讀接口，但嚴格限制調(diào)用寫接口。
用系統(tǒng)事件解決問題
在業(yè)界，對于微服務(wù)橫跨問題有過激勵的爭吵。Bob大叔在《架構(gòu)整潔之道》中，就對微服務(wù)架構(gòu)提出了非常嚴厲的抨擊，但是他的觀點只停留在對“微服務(wù)劃分的邊界不合理”這個階段。
事實上，Bob大叔的想法過于理想，他對架構(gòu)師提出了神一樣的要求——能準確預(yù)知未來，決策當下。換言之，從邊界角度考慮微服務(wù)劃分，最終導(dǎo)致整個架構(gòu)根本無法落地。但是，如果找到正確的方法，即便微服務(wù)劃分不科學(xué)、不合理，也能夠正常解耦協(xié)作，只有做到這一點才算是真正解決了問題。
所謂“陽光之下無新鮮事”，其實微服務(wù)遇到的問題，早在計算機應(yīng)用發(fā)展進程中就已經(jīng)解決了。以操作系統(tǒng)為例，是海量級別模塊的互相協(xié)作 ，并且是非耦合的。具體是什么操作的呢？很多人可能沒有追蹤過：在windows下點擊一個按鈕，windows會發(fā)起超過50個系統(tǒng)事件，而借助操作系統(tǒng)內(nèi)部的系統(tǒng)事件，windows可以準確描述具體場景時的行為，各模塊主動響應(yīng)各自負責(zé)的事件，完成自己的功能職責(zé)，進而達成了海量模塊間的非耦合協(xié)作。
軟件工程師前輩們的智慧，同樣適用于微服務(wù)場景。微服務(wù)理論最大的改進是，對IPC進行嚴格限制，嚴格限制跨微服務(wù)調(diào)用寫接口。多服務(wù)聯(lián)合寫場景，借助經(jīng)典智慧模擬操作系統(tǒng)消息體系，構(gòu)建業(yè)務(wù)事件體系。各個微服務(wù)控制翻轉(zhuǎn)——你不要調(diào)用我，我主動響應(yīng)系統(tǒng)事件去做我應(yīng)該做的事情，各個微服務(wù)主動響應(yīng)事件，而不是被其它服務(wù)調(diào)用，這就是解決問題的核心原則。
以具體的醫(yī)藥行業(yè)業(yè)務(wù)場景為例：如果某個業(yè)務(wù)員要離職，系統(tǒng)需要干多少事情？首先，要取消業(yè)務(wù)員的職責(zé)，要作廢行政認證信息，移出行政組織，然后作廢業(yè)務(wù)員認證信息，將此業(yè)務(wù)員移出業(yè)務(wù)組織，取消業(yè)務(wù)員與客戶綁定關(guān)系，收回授予業(yè)務(wù)員的所有銷售權(quán)，下架業(yè)務(wù)員上架的所有商品，所有與業(yè)務(wù)員的商品全部失效，沒有例外。一個貌似很簡單的離職場景，會有無數(shù)的功能擴展，沒有極限。因為，醫(yī)藥行業(yè)的業(yè)務(wù)實在太過復(fù)雜，并且在今天以及未來，在業(yè)務(wù)員離職這個節(jié)點，業(yè)務(wù)的邏輯有可能無限調(diào)整，做為開發(fā)人員要時刻擁抱變化，滿足業(yè)務(wù)端提出的各種需求。
如果采用服務(wù)間調(diào)用，會在統(tǒng)一用戶中心調(diào)用各模塊的API。然而，隨著業(yè)務(wù)的擴展，寫一個離職功能的人要寫無窮無盡的代碼，解決各種各樣的問題，包括分布式事務(wù)邏輯，前后的次序等等。而基于系統(tǒng)事件解決問題的思路，業(yè)務(wù)員離職時，統(tǒng)一用戶中心負責(zé)取消業(yè)務(wù)員角色，只要干這一件事就可以了。當這個事情完成的時候，系統(tǒng)向全局廣播一個新的業(yè)務(wù)事件，就是業(yè)務(wù)員離職，其它的所有服務(wù)主動響應(yīng)這個事件。認證中心微服務(wù)主動負責(zé)取消行業(yè)業(yè)務(wù)認證，CRM負責(zé)取消業(yè)務(wù)員和客戶的綁定，規(guī)則引擎負責(zé)收回業(yè)務(wù)員銷售權(quán)，商品管理負責(zé)下架業(yè)務(wù)員所有商品。通過這樣的方式，實現(xiàn)這樣一個復(fù)雜業(yè)務(wù)的控制，以及復(fù)雜任務(wù)在全系統(tǒng)各個微服務(wù)職責(zé)的分解和協(xié)同。
“軟件系統(tǒng)的瓶頸不在服務(wù)端，而在數(shù)據(jù)庫。” 屠文珂強調(diào)，企業(yè)要想做好微服務(wù)，還有一個關(guān)鍵點也很重要，那就是一定要選擇好數(shù)據(jù)庫，通過適合自己的數(shù)據(jù)離散策略去做分庫，然后再考慮表結(jié)構(gòu)如何設(shè)計，盡可能使全局數(shù)據(jù)不存在冗余性，否則各個獨立的服務(wù)非常容易出現(xiàn)數(shù)據(jù)錯亂的狀況。
在微服務(wù)落地過程中，通常會產(chǎn)生一個誤區(qū)，很多團隊會把數(shù)據(jù)庫也按照各自的服務(wù)拆分，在數(shù)據(jù)庫層也做各自的獨立化處理。直到開發(fā)末期的時候才發(fā)現(xiàn)，數(shù)據(jù)不僅有拆的需求，還有聚合的需求，不得已再匆匆忙忙做聚合設(shè)計，這樣會產(chǎn)生100%的冗余，這樣程序員在寫代碼的時候，經(jīng)常會把數(shù)據(jù)寫錯。換言之，由于數(shù)據(jù)庫底層沒有控制好，在顆粒度以及冗余設(shè)計方面存在問題，導(dǎo)致程序員要付出更大的代價來處理數(shù)據(jù)冗余問題。
小結(jié)：
任何架構(gòu)都不是十全十美，微服務(wù)架構(gòu)也一樣，但它之所以成為主流趨勢，是因為更具備技術(shù)優(yōu)勢的獨特性。為了滿足業(yè)務(wù)的實時性要求，每年都有大量開發(fā)人員選擇微服務(wù)架構(gòu)，但大多都會陷入微服務(wù)橫跨陷阱。朗致集團給出的策略是，在整個方案、架構(gòu)和代碼實踐層級實現(xiàn)對程序員的層層減負，負責(zé)此超級復(fù)雜業(yè)務(wù)功能的程序員就再也不用擔(dān)心寫錯代碼被領(lǐng)導(dǎo)批評了，真正從架構(gòu)上做到不累心，不出錯，進而全面提高開發(fā)效率。
