前言
今天寫篇文章討論下傳統(tǒng)ESB和主流分布式服務(wù)框架的差異和自己對(duì)他們的思考兆衅，也為大家對(duì)不同服務(wù)框架的選型提供一些建議。10多年前SOA的理念已經(jīng)在業(yè)界非常風(fēng)行鹃答，其中以傳統(tǒng)軟件廠商提出的以ESB實(shí)現(xiàn)SOA的方案為主流底靠，這也是為什么幾乎所有傳統(tǒng)企業(yè)的客戶都認(rèn)為ESB是SOA理念的最佳實(shí)踐囚灼，甚至是唯一的實(shí)現(xiàn)鳖眼，這是一種"中心化"服務(wù)框架黑毅。
隨著互聯(lián)網(wǎng)架構(gòu)和技術(shù)的普及，很多人都已經(jīng)對(duì)互聯(lián)網(wǎng)公司的典型架構(gòu)和技術(shù)有了比較多的了解钦讳，其中在服務(wù)化框架領(lǐng)域矿瘦，互聯(lián)網(wǎng)公司流行一種去中心化的服務(wù)框架，本章將從理論和實(shí)戰(zhàn)的角度對(duì)這兩種架構(gòu)進(jìn)行對(duì)比愿卒。
之前缚去，有一部分人認(rèn)為"去中心化"不是SOA架構(gòu)，為此我們一起回顧下SOA的主要特性：
- 面向服務(wù)的分布式計(jì)算
- 服務(wù)間松散耦合
- 支持服務(wù)的組裝
- 服務(wù)注冊(cè)和自動(dòng)發(fā)現(xiàn)
- 以服務(wù)契約方式定義服務(wù)交互方式
可以看到掘猿，SOA并沒有定義出一定是基于ESB總線的方式病游，而在互聯(lián)網(wǎng)行業(yè)中興起的"去中心化"分布式服務(wù)框架同樣遵循了以上對(duì)SOA架構(gòu)的特征定義。所以接下來(lái)討論的"中心化"和"去中心化"服務(wù)框架均是SOA的實(shí)現(xiàn)方式稠通，并不是兩套體系。
首先我想表達(dá)的觀點(diǎn)是买猖，這兩套SOA的架構(gòu)并沒有優(yōu)劣之分改橘，很多互聯(lián)網(wǎng)公司最終選擇"去中心化"服務(wù)架構(gòu)作為整個(gè)公司統(tǒng)一的服務(wù)框架并不代表"去中心化"服務(wù)框架是"中心化"服務(wù)框架的升級(jí)版，而基于這兩套架構(gòu)解決企業(yè)的根本訴求是完全不同的.
ESB模式的"中心化"服務(wù)架構(gòu)的根本訴求
回顧2004年左右業(yè)界提出SOA理念的背景玉控，正是大型軟件公司已經(jīng)發(fā)現(xiàn)飞主，越來(lái)越多的企業(yè)在多年的IT建設(shè)過程中，逐漸構(gòu)建了越來(lái)越多的IT系統(tǒng)，這些IT系統(tǒng)無(wú)不例外都是采用"煙囪式"系統(tǒng)建設(shè)模式而建立的碌识，使得企業(yè)內(nèi)的各種系統(tǒng)紛繁林立碾篡，這些系統(tǒng)有的是購(gòu)買商用套件，有的是自主研發(fā)筏餐，有的是找外部的行業(yè)解決方案提供商基于需求定制開發(fā)开泽，最終的結(jié)果就是各個(gè)系統(tǒng)所采用技術(shù)平臺(tái)、框架魁瞪、開發(fā)語(yǔ)言各異穆律。
隨著企業(yè)業(yè)務(wù)的發(fā)展，需要實(shí)現(xiàn)這些系統(tǒng)間交互時(shí)导俘，SOA的架構(gòu)相比通過系統(tǒng)間點(diǎn)對(duì)點(diǎn)直接互通的模式峦耘，很好的避免了因?yàn)榉?wù)提供者服務(wù)接口的變化需要調(diào)整此服務(wù)的服務(wù)調(diào)用者都進(jìn)行修改的現(xiàn)象，而只需在ESB上進(jìn)行一次調(diào)整旅薄，便實(shí)現(xiàn)了對(duì)服務(wù)接口變化帶來(lái)影響的隔離辅髓。ESB架構(gòu)降低了系統(tǒng)間的耦合，更方便少梁、高效地實(shí)現(xiàn)了對(duì)新系統(tǒng)的集成利朵，同時(shí)也在服務(wù)負(fù)載均衡、服務(wù)管控等方面提供了相比點(diǎn)對(duì)點(diǎn)模式更專業(yè)的能力猎莲。
所以當(dāng)SOA理念一提出绍弟，得到了企業(yè)客戶的一致青睞，希望通過SOA項(xiàng)目實(shí)現(xiàn)各系統(tǒng)間更有效的互聯(lián)互通著洼。在這樣需求的驅(qū)動(dòng)下樟遣，各大軟件廠商紛紛推出了自己的SOA產(chǎn)品，無(wú)一例外均是使用了ESB方式身笤。在ESB這樣一個(gè)中心服務(wù)總線上豹悬，提供了諸如對(duì)各種技術(shù)接口（httpsocket、jms液荸、jdbc等）的適配接入瞻佛、數(shù)據(jù)格式轉(zhuǎn)換、數(shù)據(jù)裁剪娇钱、服務(wù)請(qǐng)求路由等功能伤柄。核心目的是讓企業(yè)客戶能基于這些SOA的產(chǎn)品實(shí)現(xiàn)系統(tǒng)間的互聯(lián)互通，同時(shí)提高開發(fā)集成效率文搂，更快地實(shí)現(xiàn)SOA項(xiàng)目的落地适刀。
所以，在這樣一個(gè)需求背景下煤蹭，ESB的方式成為這一時(shí)期SOA實(shí)現(xiàn)的主流笔喉，而這一種架構(gòu)解決的根本訴求是實(shí)現(xiàn)易構(gòu)系統(tǒng)之間的交互取视。
"去中心化"分布式服務(wù)架構(gòu)解決的問題
互聯(lián)網(wǎng)行業(yè)中發(fā)源的"去中心化"服務(wù)框架是由互聯(lián)網(wǎng)業(yè)務(wù)的特性決定的，因?yàn)橛脩羧后w是整個(gè)互聯(lián)網(wǎng)公眾常挚，所以系統(tǒng)架構(gòu)設(shè)計(jì)人員首先要解決的事系統(tǒng)擴(kuò)展性問題作谭，然后才是更快地進(jìn)行業(yè)務(wù)響應(yīng)、更好地支持業(yè)務(wù)創(chuàng)新等奄毡。一個(gè)互聯(lián)網(wǎng)平臺(tái)的業(yè)務(wù)發(fā)展的再好折欠，一旦有更多的用戶訪問后，這個(gè)平臺(tái)如果沒法再進(jìn)行擴(kuò)展的話秧倾，這將給平臺(tái)帶來(lái)災(zāi)難性的后果怨酝。這就是為什么今天幾乎所有互聯(lián)網(wǎng)公司均基于"去中心化"分布式服務(wù)框架建設(shè)系統(tǒng)，其根本原因就在于擴(kuò)展性是首要的那先。
所以"去中心化"分布式服務(wù)框架除了對(duì)于SOA特性的實(shí)現(xiàn)和滿足外农猬，相比"中心化"服務(wù)架構(gòu)最重要的不同就是服務(wù)提供者和服務(wù)調(diào)用者之間在進(jìn)行服務(wù)交互時(shí)無(wú)需通過任何服務(wù)路由中介，避免因?yàn)?中心點(diǎn)"帶來(lái)平臺(tái)能力難以擴(kuò)展問題售淡，以及潛在的"雪崩"影響斤葱。而對(duì)于不同技術(shù)接口的支持、數(shù)據(jù)格式轉(zhuǎn)換揖闸、服務(wù)動(dòng)態(tài)路由等功能就沒有在"去中心化"的平臺(tái)中有所體現(xiàn)揍堕，更多情況是依靠服務(wù)應(yīng)用的編寫來(lái)滿足這樣的需求。
也有人提出這樣的疑問汤纸，"去中心化"的服務(wù)交互方式很像IT技術(shù)發(fā)展早期通過系統(tǒng)間"點(diǎn)對(duì)點(diǎn)"打通的方式實(shí)現(xiàn)不同系統(tǒng)間的集成衩茸，ESB的出現(xiàn)很好的解決了這種系統(tǒng)集成帶來(lái)的各種弊端，新的"去中心化"服務(wù)框架在某種程度上是否是一種倒退贮泞？其實(shí)忽略了"去中心化"服務(wù)框架一般是運(yùn)行在企業(yè)內(nèi)部網(wǎng)絡(luò)楞慈，基于統(tǒng)一的技術(shù)接口和標(biāo)準(zhǔn)、網(wǎng)絡(luò)協(xié)議啃擦、規(guī)范進(jìn)行交互囊蓝，已使服務(wù)的交互效率最高，又因?yàn)槭且苑?wù)契約先行的方式進(jìn)行了服務(wù)接口功能的約定令蛉，在某種程度上很好的保障了服務(wù)接口和穩(wěn)定性聚霜，所以大大降低了服務(wù)接口和穩(wěn)定性，所以大大降低了因?yàn)榉?wù)接口發(fā)生變化給服務(wù)調(diào)用者帶來(lái)的影響珠叔；同時(shí)"去中心化"服務(wù)框架中輔以多版本支持蝎宇、負(fù)載均衡的支持，從本質(zhì)上屏蔽掉了之前"點(diǎn)對(duì)點(diǎn)"模式下的各種系統(tǒng)穩(wěn)定性問題运杭。
那么為什么"中心化"服務(wù)框架不適合于互聯(lián)網(wǎng)場(chǎng)景呢夫啊？接下來(lái)我們拋開兩種架構(gòu)所提供的平臺(tái)功能，僅從當(dāng)企業(yè)的業(yè)務(wù)進(jìn)行了服務(wù)化之后辆憔，兩種架構(gòu)給業(yè)務(wù)帶來(lái)的影響進(jìn)行對(duì)比撇眯。
- 服務(wù)調(diào)用方式的不同帶來(lái)業(yè)務(wù)的響應(yīng)和擴(kuò)展成本
傳統(tǒng)ESB的服務(wù)調(diào)用方式是，每一次服務(wù)的調(diào)用者要向服務(wù)提供者進(jìn)行服務(wù)交互請(qǐng)求時(shí)都必須通過中心的ESB來(lái)進(jìn)行路由虱咧。
每一次服務(wù)交互的線路都需要5步熊榛，有4次網(wǎng)絡(luò)通訊：
服務(wù)調(diào)用者-> ESB接受服務(wù)請(qǐng)求->服務(wù)提供者（服務(wù)處理） ->ESB返回結(jié)果->服務(wù)調(diào)用者接受服務(wù)返回
經(jīng)過服務(wù)總線路由過的服務(wù)交互，共出現(xiàn)4次網(wǎng)絡(luò)會(huì)話創(chuàng)建和數(shù)據(jù)傳輸腕巡，而"去中心化"服務(wù)架構(gòu)中服務(wù)交互玄坦，一次服務(wù)的調(diào)用只有兩次網(wǎng)絡(luò)會(huì)話創(chuàng)建和數(shù)據(jù)傳輸，在網(wǎng)絡(luò)上的開銷整整減少了一半绘沉。
當(dāng)整個(gè)平臺(tái)或企業(yè)內(nèi)的應(yīng)用都是基于服務(wù)化架構(gòu)建設(shè)的時(shí)候煎楣，一次網(wǎng)頁(yè)上的點(diǎn)擊請(qǐng)求就不會(huì)像之前那樣，所有的代碼邏輯都在一個(gè)應(yīng)用實(shí)例中就能完全處理车伞，而需要通過調(diào)用多個(gè)遠(yuǎn)程的服務(wù)來(lái)完成整個(gè)業(yè)務(wù)請(qǐng)求的處理择懂。例如在京東頁(yè)面點(diǎn)擊立即下單按鈕進(jìn)行下單請(qǐng)求時(shí)，后段調(diào)用了200多個(gè)服務(wù)另玖，也就是一次頁(yè)面的請(qǐng)求產(chǎn)生了后段上百個(gè)不同服務(wù)器間的服務(wù)交互困曙。如果是總線架構(gòu)，每次請(qǐng)求逗逼直接交互的方式要多一倍的網(wǎng)絡(luò)開銷谦去，那么我們就很難體驗(yàn)到毫秒級(jí)的創(chuàng)建訂單慷丽。
從邏輯上看，所有服務(wù)調(diào)用都通過服務(wù)總線鳄哭，服務(wù)總線的訪問和計(jì)算壓力都會(huì)非常大要糊。所有的企業(yè)服務(wù)總線產(chǎn)品也都可采用集群部署的方式進(jìn)行壓力的分擔(dān)，實(shí)現(xiàn)服務(wù)路由能力的線性擴(kuò)展妆丘，因?yàn)橐话闫髽I(yè)服務(wù)總線包含的功能非常多锄俄，比如服務(wù)發(fā)現(xiàn)、注冊(cè)飘痛、路由珊膜、協(xié)議轉(zhuǎn)換、接口監(jiān)聽等功能宣脉，使得企業(yè)服務(wù)總線一般對(duì)服務(wù)器的要求都比較高车柠，所以每一次企業(yè)服務(wù)總線的擴(kuò)容升級(jí)都會(huì)帶來(lái)在軟件授權(quán)和硬件資源上不小的投入。
另一方面塑猖，企業(yè)所有的業(yè)務(wù)都是通過服務(wù)總線的方式竹祷，則服務(wù)調(diào)用量比較大，所需的網(wǎng)絡(luò)帶寬要求非常高羊苟，甚至?xí)霈F(xiàn)超過目前網(wǎng)絡(luò)設(shè)備的能力范圍塑陵，企業(yè)需要在網(wǎng)絡(luò)上投入更大的成本。如果按如今大型互聯(lián)網(wǎng)公司每天高達(dá)上千億次的服務(wù)調(diào)用蜡励，采用服務(wù)總線的方式令花，那在網(wǎng)絡(luò)設(shè)備上的資源投入將會(huì)是一個(gè)天文數(shù)字阻桅。
- 雪崩效應(yīng)束縛了中心化服務(wù)框架的擴(kuò)展能力
上面只是從用戶體驗(yàn)、平臺(tái)擴(kuò)展性和網(wǎng)絡(luò)成本來(lái)討論"去中心化"相比于"中心化"服務(wù)框架的優(yōu)勢(shì)兼都，但這海不是今天很多企業(yè)客戶或互聯(lián)網(wǎng)企業(yè)不選擇"中心化"服務(wù)框架的最重要原因嫂沉，根本原因則是"中心化"架構(gòu)可能給平臺(tái)帶來(lái)災(zāi)難性的雪崩效應(yīng)。
基于企業(yè)服務(wù)總線構(gòu)建的服務(wù)體系扮碧，會(huì)成為企業(yè)服務(wù)調(diào)度的核心樞紐趟章，當(dāng)前很多企業(yè)還指示將企業(yè)服務(wù)總線用于企業(yè)內(nèi)部系統(tǒng)間的互聯(lián)，但隨著互聯(lián)網(wǎng)轉(zhuǎn)型浪潮的到來(lái)慎王，會(huì)有越來(lái)越多的業(yè)務(wù)是面向互聯(lián)網(wǎng)公眾的蚓土。簡(jiǎn)單說，不管是因?yàn)槠髽I(yè)業(yè)務(wù)規(guī)模自身的發(fā)展還是外部環(huán)境的變化赖淤，一旦有更多的服務(wù)調(diào)用和交互的場(chǎng)景蜀漆，傳統(tǒng)企業(yè)服務(wù)總線的架構(gòu)就暴露出"硬傷"。
更多的服務(wù)調(diào)用給企業(yè)服務(wù)總線帶來(lái)了更多的服務(wù)路由壓力漫蛔，這時(shí)必然會(huì)采用集群部署的方式嗜愈，對(duì)這些服務(wù)請(qǐng)求提供負(fù)載均衡和高可用性的保障。但是在這個(gè)表面看來(lái)萬(wàn)無(wú)一失的架構(gòu)中莽龟，卻隱藏著巨大的風(fēng)險(xiǎn)蠕嫁。
假設(shè)安服務(wù)訪問的峰值估算出了所需的企業(yè)服務(wù)總線的集群數(shù)量約是10臺(tái)。當(dāng)達(dá)到訪問峰值時(shí)毯盈，每個(gè)企業(yè)服務(wù)總線的負(fù)載將會(huì)達(dá)到80%以上剃毒。日常運(yùn)行沒問題，但是當(dāng)突發(fā)交易峰值或有可能因?yàn)橐粋€(gè)應(yīng)用對(duì)某個(gè)服務(wù)產(chǎn)生了不規(guī)范調(diào)用或者是有問題的服務(wù)提供者造成服務(wù)所在的企業(yè)服務(wù)總線實(shí)例節(jié)點(diǎn)出現(xiàn)異常搂赋，就有可能是一臺(tái)服務(wù)器故障赘阀。這就會(huì)導(dǎo)致服務(wù)路由壓力落在了剩下的9臺(tái)服務(wù)器上，這樣每臺(tái)機(jī)器分擔(dān)的壓力很有可能超過最大負(fù)載脑奠，導(dǎo)致其他機(jī)器出現(xiàn)連鎖崩潰的概率大增基公，這時(shí)就不會(huì)一臺(tái)臺(tái)出問題，而是會(huì)一起被沖垮宋欺，整個(gè)企業(yè)服務(wù)總線集群全軍覆沒轰豆，這就是典型的雪崩。
而企業(yè)服務(wù)總線一旦遇到上面這樣的集群癱瘓后齿诞，故障恢復(fù)是很麻煩酸休，花費(fèi)的時(shí)間也很漫長(zhǎng)，讓10臺(tái)服務(wù)器全部重啟起來(lái)祷杈，起碼要花費(fèi)半個(gè)小時(shí)以上斑司。而"去中心化”的服務(wù)框架則可以避免因?yàn)閭€(gè)別問題波及整個(gè)平臺(tái)的業(yè)務(wù)受影響，最多也就是部分服務(wù)出現(xiàn)問題但汞，就算出現(xiàn)問題時(shí)也更容易定位問題和故障恢復(fù)宿刮。
總結(jié)
綜上所述互站，正因?yàn)檠┍佬?yīng)的隱患存在，在某種程度上其實(shí)是束縛了"中心化"服務(wù)框架的平臺(tái)擴(kuò)展能力糙置，也就是行鎖增加"中心"點(diǎn)企業(yè)服務(wù)總線的實(shí)例等節(jié)點(diǎn)數(shù)量云茸，并不能線性擴(kuò)展平臺(tái)的服務(wù)能力是目。正因?yàn)槿绱税梗壳昂芏嗷ヂ?lián)網(wǎng)公司都選擇"去中心化"的服務(wù)框架作為平臺(tái)分布式服務(wù)框架。目前主流的springcloud套件和dubbo+zk就是大家目前用的比較多的分布式服務(wù)框架懊纳，這篇文章詳細(xì)的講解了下ESB和分布式服務(wù)分別適用的場(chǎng)景和解決的問題揉抵，大家可以按照這樣的標(biāo)準(zhǔn)去選擇適合自己公司的服務(wù)框架。
