不為微服務(wù)架構(gòu)而架構(gòu)

　　“之所以采用微服務(wù)架構(gòu)，是因?yàn)橄鄬?duì)SOA單體架構(gòu)而言，微服務(wù)這種組件化、松耦合、自治、去中心化的架構(gòu)，更靈活、敏捷，更能滿(mǎn)足業(yè)務(wù)需求。” 朗致集團(tuán)數(shù)字化效能總經(jīng)理屠文珂，在SACC大會(huì)期間接受筆者采訪時(shí)表示，沒(méi)有一家企業(yè)，專(zhuān)門(mén)為微服務(wù)架構(gòu)而建架構(gòu)，而是由業(yè)務(wù)驅(qū)動(dòng)技術(shù)落地的產(chǎn)物。

　　基于前后端徹底分離思想，前端是企業(yè)自己一整套的大前端體系，服務(wù)端以微服務(wù)進(jìn)行具體的服務(wù)工程的切分，然后提供一系列API接口，通過(guò)網(wǎng)關(guān)統(tǒng)一對(duì)外提供服務(wù)。無(wú)論是安卓、iOS、 PC、小程序還是各種瀏覽器，應(yīng)用程序只開(kāi)發(fā)一次就可以部署到所有的終端。

　　值得一提的是，微服務(wù)并非醫(yī)藥類(lèi)企業(yè)專(zhuān)屬，互聯(lián)網(wǎng)、金融、游戲等具有快速迭代和交付需求的場(chǎng)景，都是微服務(wù)的重要應(yīng)用領(lǐng)域，具有廣泛的應(yīng)用前景。對(duì)于大多數(shù)企業(yè)而言，微服務(wù)在提高開(kāi)發(fā)效率、提高系統(tǒng)的可維護(hù)性、可擴(kuò)展性、可用性和可靠性方面，都具有顯著優(yōu)勢(shì)。當(dāng)企業(yè)把一個(gè)大型單體架構(gòu)拆成各個(gè)小的顆粒的時(shí)候，會(huì)提升企業(yè)應(yīng)對(duì)市場(chǎng)變化的能力，對(duì)業(yè)務(wù)需求變化達(dá)到天或者小時(shí)級(jí)別的響應(yīng)。而不再像之前一樣，一個(gè)應(yīng)用版本開(kāi)發(fā)下來(lái)，幾個(gè)月才能上線(xiàn)。所以，從技術(shù)應(yīng)用角度來(lái)看，微服務(wù)是一個(gè)通用型架構(gòu)，沒(méi)有特別嚴(yán)格的界限去圈定，哪些業(yè)務(wù)適合使用微服務(wù)，哪些業(yè)務(wù)不適合。微服務(wù)的本質(zhì)是，通過(guò)更合理的分工合作機(jī)制，去開(kāi)發(fā)各種各樣的軟件，以供業(yè)務(wù)人員去使用。

　　微服務(wù)具體的實(shí)踐路徑有兩個(gè)：一、采用Dubbo、SpringCloud等開(kāi)源微服務(wù)框架來(lái)構(gòu)建系統(tǒng)；二、采用自研技術(shù)路線(xiàn)來(lái)構(gòu)建微服務(wù)體系。不管采用哪種技術(shù)路線(xiàn)，最終的目的是簡(jiǎn)化服務(wù)架構(gòu)，降低服務(wù)顆粒。當(dāng)然，業(yè)務(wù)拆分過(guò)程中，也要注意很多關(guān)鍵點(diǎn)，如果拆分顆粒度過(guò)于精細(xì)，節(jié)點(diǎn)過(guò)多，會(huì)對(duì)運(yùn)維帶來(lái)極大挑戰(zhàn)，導(dǎo)致企業(yè)沒(méi)有辦法進(jìn)行管理。

　　謹(jǐn)防微服務(wù)橫跨“陷阱”

　　在實(shí)際微服務(wù)架構(gòu)落地過(guò)程中，會(huì)遇到各種各樣的問(wèn)題，本質(zhì)上都可以歸結(jié)為是海量模塊之間的協(xié)作問(wèn)題。如何真正做到微服務(wù)的分拆，又不相互影響，不發(fā)生實(shí)際的耦合？這是一個(gè)值得業(yè)界深思的話(huà)題！

　　“當(dāng)系統(tǒng)拆分了200個(gè)微服務(wù)，其中超過(guò)1/3的微服務(wù)，都要調(diào)用超過(guò)50個(gè)其他微服務(wù)。微服務(wù)的初衷是當(dāng)需求變更時(shí)，少數(shù)服務(wù)做調(diào)整即可滿(mǎn)足需求，而上述實(shí)際情況造成了實(shí)質(zhì)性的微服務(wù)耦合。” 屠文珂發(fā)現(xiàn)，微服務(wù)拆分的復(fù)雜度隨著服務(wù)數(shù)量的增多而呈現(xiàn)幾何級(jí)倍數(shù)增長(zhǎng)。并且，這種狀況不是某一家企業(yè)的問(wèn)題，在朗致集團(tuán)每年面試的3000+程序員中，落入此陷阱的技術(shù)團(tuán)隊(duì)為100%。

　　既然微服務(wù)無(wú)法避免耦合，落地的結(jié)果與初衷嚴(yán)重不符，當(dāng)初為什么還要拆開(kāi)？這其實(shí)是微服務(wù)橫跨帶來(lái)的缺陷！

　　在解決“橫跨缺陷”之前，我們先看看微服務(wù)發(fā)展歷史。微服務(wù)是由Peter Rodgers、James Lewis、Martin Flower、Chris Richardson等等一系列架構(gòu)專(zhuān)家，在2005年左右提出并構(gòu)建的一整套理論體系。比如：Chris Richardson在《Building Microservices Inter-Process Communication In A Microservices Architecture》論文中，闡述了采用IPC（進(jìn)程間通訊）的方式，實(shí)現(xiàn)各個(gè)服務(wù)間的協(xié)同和互相調(diào)用，這一理論奠定了當(dāng)前微服務(wù)的理論基礎(chǔ)，之后的Dubbo、SpringCloud、Soul框架都符合這一理論。

　　微服務(wù)的根本問(wèn)題就是出在“理論”上，就像很多程序員，直到寫(xiě)完代碼后才發(fā)現(xiàn)，之前的架構(gòu)設(shè)計(jì)存在缺陷，不得不把整個(gè)架構(gòu)推翻重來(lái)。說(shuō)白了，只要理論沒(méi)有在最后一公里落地到實(shí)踐，這套理論就存在出問(wèn)題的可能。所以，微服務(wù)的發(fā)展脈絡(luò)是，從最終的實(shí)踐出發(fā)，一路向上找原因，反推之前理論存在哪些瑕疵。

　　那么，微服務(wù)的“瑕疵”是什么？顯然是沒(méi)有控制住復(fù)雜度！如果我們用聯(lián)線(xiàn)服務(wù)之間調(diào)用關(guān)系的復(fù)雜度來(lái)表示微服務(wù)關(guān)系，可以發(fā)現(xiàn)服務(wù)簡(jiǎn)單的時(shí)候沒(méi)有任何問(wèn)題。2個(gè)微服務(wù)的聯(lián)線(xiàn)數(shù)量是1；3個(gè)微服務(wù)的聯(lián)線(xiàn)數(shù)量是3；4個(gè)微服務(wù)的聯(lián)線(xiàn)數(shù)量是6……總結(jié)出來(lái)一個(gè)公式就是n（n-1）/2，也就是說(shuō)復(fù)雜度會(huì)隨著n的平方而增減，即隨著微服務(wù)數(shù)量而呈幾何級(jí)數(shù)的增長(zhǎng)，這就是一種復(fù)雜度失控。進(jìn)程間通訊不是隨意的，是嚴(yán)格受限的場(chǎng)景。

　　如果跨服務(wù)進(jìn)行通訊，讀可以，一個(gè)服務(wù)可以調(diào)用其它服務(wù)的讀，但不可以調(diào)用另一個(gè)服務(wù)的寫(xiě)接口。也就是說(shuō)，理論科學(xué)家在IPC中描述的各種服務(wù)之間互相調(diào)用的方法，都只是理論上的可行性，最終落地才發(fā)現(xiàn)不行。實(shí)戰(zhàn)通過(guò)血的教訓(xùn)總結(jié)出：跨微服務(wù)之間可以調(diào)用讀接口，但嚴(yán)格限制調(diào)用寫(xiě)接口。

　　用系統(tǒng)事件解決問(wèn)題

　　在業(yè)界，對(duì)于微服務(wù)橫跨問(wèn)題有過(guò)激勵(lì)的爭(zhēng)吵。Bob大叔在《架構(gòu)整潔之道》中，就對(duì)微服務(wù)架構(gòu)提出了非常嚴(yán)厲的抨擊，但是他的觀點(diǎn)只停留在對(duì)“微服務(wù)劃分的邊界不合理”這個(gè)階段。

　　事實(shí)上，Bob大叔的想法過(guò)于理想，他對(duì)架構(gòu)師提出了神一樣的要求——能準(zhǔn)確預(yù)知未來(lái)，決策當(dāng)下。換言之，從邊界角度考慮微服務(wù)劃分，最終導(dǎo)致整個(gè)架構(gòu)根本無(wú)法落地。但是，如果找到正確的方法，即便微服務(wù)劃分不科學(xué)、不合理，也能夠正常解耦協(xié)作，只有做到這一點(diǎn)才算是真正解決了問(wèn)題。

　　所謂“陽(yáng)光之下無(wú)新鮮事”，其實(shí)微服務(wù)遇到的問(wèn)題，早在計(jì)算機(jī)應(yīng)用發(fā)展進(jìn)程中就已經(jīng)解決了。以操作系統(tǒng)為例，是海量級(jí)別模塊的互相協(xié)作 ，并且是非耦合的。具體是什么操作的呢？很多人可能沒(méi)有追蹤過(guò)：在windows下點(diǎn)擊一個(gè)按鈕，windows會(huì)發(fā)起超過(guò)50個(gè)系統(tǒng)事件，而借助操作系統(tǒng)內(nèi)部的系統(tǒng)事件，windows可以準(zhǔn)確描述具體場(chǎng)景時(shí)的行為，各模塊主動(dòng)響應(yīng)各自負(fù)責(zé)的事件，完成自己的功能職責(zé)，進(jìn)而達(dá)成了海量模塊間的非耦合協(xié)作。

　　軟件工程師前輩們的智慧，同樣適用于微服務(wù)場(chǎng)景。微服務(wù)理論最大的改進(jìn)是，對(duì)IPC進(jìn)行嚴(yán)格限制，嚴(yán)格限制跨微服務(wù)調(diào)用寫(xiě)接口。多服務(wù)聯(lián)合寫(xiě)場(chǎng)景，借助經(jīng)典智慧模擬操作系統(tǒng)消息體系，構(gòu)建業(yè)務(wù)事件體系。各個(gè)微服務(wù)控制翻轉(zhuǎn)——你不要調(diào)用我，我主動(dòng)響應(yīng)系統(tǒng)事件去做我應(yīng)該做的事情，各個(gè)微服務(wù)主動(dòng)響應(yīng)事件，而不是被其它服務(wù)調(diào)用，這就是解決問(wèn)題的核心原則。

　　以具體的醫(yī)藥行業(yè)業(yè)務(wù)場(chǎng)景為例：如果某個(gè)業(yè)務(wù)員要離職，系統(tǒng)需要干多少事情？首先，要取消業(yè)務(wù)員的職責(zé)，要作廢行政認(rèn)證信息，移出行政組織，然后作廢業(yè)務(wù)員認(rèn)證信息，將此業(yè)務(wù)員移出業(yè)務(wù)組織，取消業(yè)務(wù)員與客戶(hù)綁定關(guān)系，收回授予業(yè)務(wù)員的所有銷(xiāo)售權(quán)，下架業(yè)務(wù)員上架的所有商品，所有與業(yè)務(wù)員的商品全部失效，沒(méi)有例外。一個(gè)貌似很簡(jiǎn)單的離職場(chǎng)景，會(huì)有無(wú)數(shù)的功能擴(kuò)展，沒(méi)有極限。因?yàn)�，醫(yī)藥行業(yè)的業(yè)務(wù)實(shí)在太過(guò)復(fù)雜，并且在今天以及未來(lái)，在業(yè)務(wù)員離職這個(gè)節(jié)點(diǎn)，業(yè)務(wù)的邏輯有可能無(wú)限調(diào)整，做為開(kāi)發(fā)人員要時(shí)刻擁抱變化，滿(mǎn)足業(yè)務(wù)端提出的各種需求。

　　如果采用服務(wù)間調(diào)用，會(huì)在統(tǒng)一用戶(hù)中心調(diào)用各模塊的API。然而，隨著業(yè)務(wù)的擴(kuò)展，寫(xiě)一個(gè)離職功能的人要寫(xiě)無(wú)窮無(wú)盡的代碼，解決各種各樣的問(wèn)題，包括分布式事務(wù)邏輯，前后的次序等等。而基于系統(tǒng)事件解決問(wèn)題的思路，業(yè)務(wù)員離職時(shí)，統(tǒng)一用戶(hù)中心負(fù)責(zé)取消業(yè)務(wù)員角色，只要干這一件事就可以了。當(dāng)這個(gè)事情完成的時(shí)候，系統(tǒng)向全局廣播一個(gè)新的業(yè)務(wù)事件，就是業(yè)務(wù)員離職，其它的所有服務(wù)主動(dòng)響應(yīng)這個(gè)事件。認(rèn)證中心微服務(wù)主動(dòng)負(fù)責(zé)取消行業(yè)業(yè)務(wù)認(rèn)證，CRM負(fù)責(zé)取消業(yè)務(wù)員和客戶(hù)的綁定，規(guī)則引擎負(fù)責(zé)收回業(yè)務(wù)員銷(xiāo)售權(quán)，商品管理負(fù)責(zé)下架業(yè)務(wù)員所有商品。通過(guò)這樣的方式，實(shí)現(xiàn)這樣一個(gè)復(fù)雜業(yè)務(wù)的控制，以及復(fù)雜任務(wù)在全系統(tǒng)各個(gè)微服務(wù)職責(zé)的分解和協(xié)同。

　　“軟件系統(tǒng)的瓶頸不在服務(wù)端，而在數(shù)據(jù)庫(kù)。” 屠文珂強(qiáng)調(diào)，企業(yè)要想做好微服務(wù)，還有一個(gè)關(guān)鍵點(diǎn)也很重要，那就是一定要選擇好數(shù)據(jù)庫(kù)，通過(guò)適合自己的數(shù)據(jù)離散策略去做分庫(kù)，然后再考慮表結(jié)構(gòu)如何設(shè)計(jì)，盡可能使全局?jǐn)?shù)據(jù)不存在冗余性，否則各個(gè)獨(dú)立的服務(wù)非常容易出現(xiàn)數(shù)據(jù)錯(cuò)亂的狀況。

　　在微服務(wù)落地過(guò)程中，通常會(huì)產(chǎn)生一個(gè)誤區(qū)，很多團(tuán)隊(duì)會(huì)把數(shù)據(jù)庫(kù)也按照各自的服務(wù)拆分，在數(shù)據(jù)庫(kù)層也做各自的獨(dú)立化處理。直到開(kāi)發(fā)末期的時(shí)候才發(fā)現(xiàn)，數(shù)據(jù)不僅有拆的需求，還有聚合的需求，不得已再匆匆忙忙做聚合設(shè)計(jì)，這樣會(huì)產(chǎn)生100%的冗余，這樣程序員在寫(xiě)代碼的時(shí)候，經(jīng)常會(huì)把數(shù)據(jù)寫(xiě)錯(cuò)。換言之，由于數(shù)據(jù)庫(kù)底層沒(méi)有控制好，在顆粒度以及冗余設(shè)計(jì)方面存在問(wèn)題，導(dǎo)致程序員要付出更大的代價(jià)來(lái)處理數(shù)據(jù)冗余問(wèn)題。

　　小結(jié)：

　　任何架構(gòu)都不是十全十美，微服務(wù)架構(gòu)也一樣，但它之所以成為主流趨勢(shì)，是因?yàn)楦�具備技術(shù)優(yōu)勢(shì)的獨(dú)特性。為了滿(mǎn)足業(yè)務(wù)的實(shí)時(shí)性要求，每年都有大量開(kāi)發(fā)人員選擇微服務(wù)架構(gòu)，但大多都會(huì)陷入微服務(wù)橫跨陷阱。朗致集團(tuán)給出的策略是，在整個(gè)方案、架構(gòu)和代碼實(shí)踐層級(jí)實(shí)現(xiàn)對(duì)程序員的層層減負(fù)，負(fù)責(zé)此超級(jí)復(fù)雜業(yè)務(wù)功能的程序員就再也不用擔(dān)心寫(xiě)錯(cuò)代碼被領(lǐng)導(dǎo)批評(píng)了，真正從架構(gòu)上做到不累心，不出錯(cuò)，進(jìn)而全面提高開(kāi)發(fā)效率。