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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　小結：

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