本文節(jié)選自本人參與編寫(xiě)的《金融企業(yè)數(shù)字化中臺(tái)》一書(shū)婶希，感興趣的朋友請(qǐng)自行查找榕暇。
要ESB還是要網(wǎng)關(guān)？喻杈？彤枢？
在互聯(lián)網(wǎng)技術(shù)的引領(lǐng)下，微服務(wù)架構(gòu)得以流行筒饰，對(duì)于服務(wù)集成相關(guān)工作缴啡，首當(dāng)其沖就是由網(wǎng)關(guān)（API Gateway ）負(fù)責(zé)。乍一看貌似沒(méi)有ESB什么事兒瓷们，實(shí)則不然业栅，金融企業(yè)IT建設(shè)起步早、規(guī)模大谬晕，數(shù)以百計(jì)的業(yè)務(wù)系統(tǒng)在運(yùn)行碘裕，而且金融企業(yè)IT架構(gòu)本身就是分布式的架構(gòu)，也完全沒(méi)有必要全部使用微服務(wù)相關(guān)技術(shù)棧全面改造攒钳，因此提全面微服務(wù)化那就是紙上談兵帮孔。我們必須承認(rèn)ESB在金融企業(yè)應(yīng)用系統(tǒng)間的服務(wù)樞紐地位牢不可破，仍將持續(xù)發(fā)揮著重要的作用不撑。是ESB曾經(jīng)接過(guò)了EAI的槍文兢，把系統(tǒng)間通過(guò)EAI Hub 和Agent數(shù)據(jù)集成的方式，轉(zhuǎn)向了面向服務(wù)的標(biāo)準(zhǔn)化集成方式燎孟。金融企業(yè)內(nèi)部的核心系統(tǒng)禽作、管理系統(tǒng)尸昧、渠道類系統(tǒng)之間仍存在這技術(shù)和協(xié)議的差異揩页，正是因?yàn)樵赟OA時(shí)代實(shí)施了ESB，系統(tǒng)間服務(wù)集成才得以統(tǒng)一成基于HTTP+XML協(xié)議的Web Service標(biāo)準(zhǔn)烹俗，變得標(biāo)準(zhǔn)化爆侣、規(guī)范化和可治理。
但我們通過(guò)這段從數(shù)據(jù)到服務(wù)集成的歷史幢妄，更能夠認(rèn)識(shí)到企業(yè)和用戶多年來(lái)不斷變化和發(fā)展的需求兔仰。在已有業(yè)務(wù)系統(tǒng)之間服務(wù)打通仍是ESB的核心任務(wù)。面對(duì)新一代數(shù)字化轉(zhuǎn)型中的業(yè)務(wù)的需求蕉鸳，需要能夠圍繞一個(gè)簡(jiǎn)單乎赴，靈活的標(biāo)準(zhǔn)協(xié)議對(duì)所有新應(yīng)用進(jìn)行連接忍法，相對(duì)而言Web Service協(xié)議略顯沉重，ESB由于其集中式樞紐的地位榕吼，快速響應(yīng)變更對(duì)于它來(lái)說(shuō)也不是很合適饿序。輕量，快速響應(yīng)變化且可配置的敏捷集成執(zhí)行能力對(duì)于數(shù)字化企業(yè)至關(guān)重要羹蚣≡剑互聯(lián)網(wǎng)類的業(yè)務(wù)率先開(kāi)始采用微服務(wù)的技術(shù)棧建設(shè)，那么這就是API Gateway 網(wǎng)關(guān)的用武之地了顽素，網(wǎng)關(guān)需要精心設(shè)計(jì)為數(shù)字業(yè)務(wù)轉(zhuǎn)型加速咽弦，需要讓?xiě)?yīng)用集成更簡(jiǎn)單。網(wǎng)關(guān)使用了更輕量級(jí)的HTTP協(xié)議和RESTful 風(fēng)格的API胁出，可以更方便的打通移動(dòng)端型型、物聯(lián)網(wǎng)設(shè)備、云服務(wù)等等多渠道的應(yīng)用划鸽。
因此我們的結(jié)論是输莺，在數(shù)字化轉(zhuǎn)型時(shí)代，在金融企業(yè)中 ESB 與API Gateway是共存的裸诽，都是IT系統(tǒng)之間的服務(wù)集成平臺(tái)嫂用。ESB作為系統(tǒng)之間的服務(wù)集成的樞紐，網(wǎng)關(guān)則在微服務(wù)架構(gòu)體系的業(yè)務(wù)領(lǐng)域內(nèi)部進(jìn)行系統(tǒng)之間集成通信丈冬。不論是ESB還是網(wǎng)關(guān)嘱函，作為服務(wù)集成平臺(tái)的建設(shè)來(lái)說(shuō)，重點(diǎn)應(yīng)該關(guān)注的內(nèi)容包含：身份驗(yàn)證埂蕊、權(quán)限管控往弓、服務(wù)路由能力增強(qiáng)等方面。復(fù)雜的服務(wù)組裝蓄氧、數(shù)據(jù)函似、協(xié)議轉(zhuǎn)換工作通常需要編碼開(kāi)發(fā)，靈活度低喉童，容易產(chǎn)生故障撇寞，不建議在服務(wù)集成平臺(tái)中實(shí)施，這類工作建議交給負(fù)責(zé)交易流應(yīng)用實(shí)施的平臺(tái)負(fù)責(zé)堂氯。下面我們首先從身份驗(yàn)證說(shuō)起蔑担。
服務(wù)集成平臺(tái)應(yīng)該負(fù)責(zé)身份驗(yàn)證
服務(wù)集成平臺(tái)作為業(yè)務(wù)系統(tǒng)的API入口，當(dāng)其面向外網(wǎng)的訪問(wèn)者時(shí)服務(wù)集成平臺(tái)還是內(nèi)外網(wǎng)的分界咽白，訪問(wèn)令牌驗(yàn)證理應(yīng)由服務(wù)集成平臺(tái)負(fù)責(zé)啤握，不應(yīng)該將令牌驗(yàn)證的事情交給服務(wù)提供者，這樣既能避免未經(jīng)驗(yàn)證的請(qǐng)求進(jìn)入內(nèi)網(wǎng)晶框，又能夠簡(jiǎn)化服務(wù)提供端的代碼排抬，服務(wù)提供端無(wú)需處理不同類型客戶端的驗(yàn)證懂从。
身份驗(yàn)證方案分析
服務(wù)集成平臺(tái)驗(yàn)證訪問(wèn)令牌有兩種方案：服務(wù)集成平臺(tái)委托認(rèn)證服務(wù)驗(yàn)證、服務(wù)集成平臺(tái)直接驗(yàn)證蹲蒲，說(shuō)明如下：
- 方案一莫绣、服務(wù)集成平臺(tái)委托授權(quán)服務(wù)驗(yàn)證：每次收到請(qǐng)求后，服務(wù)集成平臺(tái)均將訪問(wèn)令牌發(fā)送到認(rèn)證服務(wù)進(jìn)行認(rèn)證悠鞍，認(rèn)證通過(guò)后才允許繼續(xù)訪問(wèn)对室。
上圖為網(wǎng)關(guān)作為服務(wù)集成平臺(tái)時(shí)，委托IAM進(jìn)行身份令牌校驗(yàn)的示意圖咖祭，說(shuō)明如下：
- 客戶端成功認(rèn)證后掩宜，使用UUID類型的訪問(wèn)令牌調(diào)用服務(wù)集成平臺(tái)上的服務(wù)
- 由于UUID類型令牌不包含客戶端的信息，服務(wù)集成平臺(tái)需要委托認(rèn)證服務(wù)校驗(yàn)令牌
- 令牌檢查合法后么翰，將請(qǐng)求路由到服務(wù)提供者
- 應(yīng)用中也無(wú)法解析令牌牺汤，需要根據(jù)UUID令牌到認(rèn)證服務(wù)中獲取用戶信息
- 方案二(推薦)、服務(wù)集成平臺(tái)直接驗(yàn)證身份：要求服務(wù)集成平臺(tái)能識(shí)別認(rèn)證服務(wù)頒發(fā)的令牌浩嫌，這種模式推薦用 JWT令牌檐迟，服務(wù)集成平臺(tái)需要具備解析校驗(yàn)JWT加密的訪問(wèn)令牌的能力。
上圖為網(wǎng)關(guān)作為服務(wù)集成平臺(tái)時(shí)码耐，自身負(fù)責(zé)令牌校驗(yàn)的示意圖追迟，說(shuō)明如下：
- 客戶端成功認(rèn)證后，使用JWT令牌調(diào)用服務(wù)集成平臺(tái)上的服務(wù)
- 服務(wù)集成平臺(tái)自己直接解密JWT令牌進(jìn)行校驗(yàn)
- 令牌檢查合法后骚腥，將請(qǐng)求路由到服務(wù)提供者
- 應(yīng)用受到請(qǐng)求后敦间，如果需要更多權(quán)限信息，如果可以根據(jù)Token去權(quán)限管理服務(wù)獲取權(quán)限信息(非必須步驟束铭，需要時(shí)添加)廓块。
上述兩方案中，方案一的令牌是無(wú)業(yè)務(wù)含義的身份標(biāo)識(shí)字符串契沫，每次收到請(qǐng)求服務(wù)集成平臺(tái)都去認(rèn)證服務(wù)器認(rèn)證带猴，對(duì)認(rèn)證服務(wù)的性能壓力較大。方案二中IAM頒發(fā)的令牌中包含部分客戶端或用戶信息懈万，使用JWT加密拴清，認(rèn)證服務(wù)將驗(yàn)證方式或SDK提供給了負(fù)責(zé)認(rèn)證的服務(wù)集成平臺(tái)。對(duì)于認(rèn)證服務(wù)器來(lái)說(shuō)钞速，減少了每次請(qǐng)求令牌認(rèn)證帶來(lái)的通信次數(shù)贷掖，負(fù)擔(dān)變輕了嫡秕。
推薦采用方案二實(shí)現(xiàn)令牌檢查渴语，需要注意的是方案二中的JWT令牌中僅包含必要的信息即可，不要放太多的角色權(quán)限信息昆咽。后續(xù)功能中需要額外的信息時(shí)驾凶，可以根據(jù)令牌再去認(rèn)證服務(wù)中獲取牙甫。如果令牌中存放了很多的權(quán)限數(shù)據(jù)，一旦后臺(tái)的授權(quán)數(shù)據(jù)發(fā)生變化调违，令牌中的權(quán)限數(shù)據(jù)與實(shí)際認(rèn)證服務(wù)的權(quán)限會(huì)存在不一致的問(wèn)題窟哺，只能強(qiáng)制用戶下線重新登錄。
JWT令牌是防篡改的技肩，但并不加密且轨，如需要存儲(chǔ)到瀏覽器存儲(chǔ)中，建議采用JWT+JWE方式進(jìn)行令牌加密虚婿。令牌中存放必要少量數(shù)據(jù)即可旋奢，避免濫用。多數(shù)服務(wù)器通常會(huì)對(duì)Http header然痊、cookie長(zhǎng)度做限制至朗。
系統(tǒng)內(nèi)部應(yīng)用之間服務(wù)建議直通，無(wú)需經(jīng)過(guò)服務(wù)集成平臺(tái)
服務(wù)集成平臺(tái)應(yīng)該由獨(dú)立團(tuán)隊(duì)負(fù)責(zé)運(yùn)維管理剧浸，否則對(duì)于單個(gè)系統(tǒng)來(lái)說(shuō)多維護(hù)一組服務(wù)集成服務(wù)過(guò)于繁瑣锹引。API變更發(fā)布、內(nèi)部聯(lián)調(diào)驗(yàn)證還得跨團(tuán)隊(duì)協(xié)調(diào)實(shí)在不可行唆香。推薦系統(tǒng)內(nèi)直通不經(jīng)過(guò)服務(wù)集成平臺(tái)嫌变，而跨系統(tǒng)訪問(wèn)必須走服務(wù)集成平臺(tái)。要做到這一點(diǎn)躬它，應(yīng)用也需要識(shí)別請(qǐng)求來(lái)源初澎，進(jìn)行客戶端認(rèn)證虑凛，這種認(rèn)證方案沒(méi)必要太復(fù)雜碑宴，應(yīng)用只應(yīng)該允許信任的服務(wù)集成平臺(tái)和系統(tǒng)內(nèi)部應(yīng)用程序訪問(wèn)其服務(wù)桑谍，不允許系統(tǒng)外部請(qǐng)求繞過(guò)服務(wù)集成平臺(tái)直接調(diào)用锣披，因此增热，需要在服務(wù)集成平臺(tái)和系統(tǒng)內(nèi)部應(yīng)用之間這個(gè)小范圍內(nèi)建立信任胧辽，常見(jiàn)方案有兩種：
- 方案一邑商，系統(tǒng)保密令牌：系統(tǒng)內(nèi)的應(yīng)用在發(fā)布接口到務(wù)集成平臺(tái)時(shí)摄咆，提供一個(gè)系統(tǒng)內(nèi)部共享的令牌給服務(wù)集成平臺(tái)和系統(tǒng)內(nèi)所有應(yīng)用凡蚜，接收到請(qǐng)求時(shí)檢查請(qǐng)求頭中是否包含當(dāng)前系統(tǒng)的專屬令牌， 如果包含當(dāng)前系統(tǒng)專屬令牌吭从，那么就允許訪問(wèn)朝蜘，否則就拒絕
- 方案二，系統(tǒng)內(nèi)保密令牌+務(wù)集成平臺(tái)令牌單獨(dú)認(rèn)證：系統(tǒng)內(nèi)用保密令牌交互就是方案一涩金，方案二中重點(diǎn)是內(nèi)部令牌不共享給服務(wù)集成平臺(tái)谱醇，避免跨團(tuán)隊(duì)的令牌泄密。服務(wù)集成平臺(tái)用公私鑰證書(shū)簽名方式與域內(nèi)系統(tǒng)建立信任步做，由服務(wù)集成平臺(tái)生成公私鑰證書(shū)枣抱，頒發(fā)公鑰給各個(gè)系統(tǒng)，服務(wù)集成平臺(tái)調(diào)用服務(wù)提供者時(shí)辆床，請(qǐng)求頭中帶上用私鑰簽名的“服務(wù)集成平臺(tái)專屬令牌”佳晶，應(yīng)用收到請(qǐng)求以后用服務(wù)集成平臺(tái)提供的公鑰驗(yàn)證其令牌。
方案一優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單讼载，缺點(diǎn)是安全級(jí)別略低轿秧，常見(jiàn)的企業(yè)架構(gòu)中，服務(wù)集成平臺(tái)和業(yè)務(wù)系統(tǒng)會(huì)是不同團(tuán)隊(duì)甚至不同的廠商負(fù)責(zé)開(kāi)發(fā)維護(hù)咨堤，內(nèi)部令牌共享給了其他團(tuán)隊(duì)負(fù)責(zé)的服務(wù)集成平臺(tái)菇篡，存在一定的風(fēng)險(xiǎn)。方案二相比方案一略復(fù)雜一點(diǎn)一喘，安全性更高驱还，系統(tǒng)內(nèi)互通用系統(tǒng)專屬保密令牌，系統(tǒng)和服務(wù)集成平臺(tái)認(rèn)證使用了服務(wù)集成平臺(tái)提供的安全令牌檢查凸克。兩種方案可根據(jù)實(shí)際需求選擇议蟆。
服務(wù)集成平臺(tái)應(yīng)該對(duì)API進(jìn)行權(quán)限管控
我們先來(lái)看三個(gè)問(wèn)題：
- 通過(guò)認(rèn)證的API客戶端能夠訪問(wèn)服務(wù)集成平臺(tái)開(kāi)放的所有API嗎？
- 通過(guò)認(rèn)證的用戶能夠調(diào)用所有API嗎萎战？
- 通過(guò)認(rèn)證的用戶允許調(diào)用修改訂單的接口咐容，那么他能修改所有人的訂單嗎？
很顯然絕大多數(shù)場(chǎng)景下上述三個(gè)問(wèn)題答案都是"不能"蚂维。在絕大多數(shù)業(yè)務(wù)場(chǎng)景中除了對(duì)訪問(wèn)者的身份認(rèn)證之外戳粒，我們還需要再進(jìn)一步控制權(quán)限。
API Key與身份認(rèn)證結(jié)合管控
如果訪問(wèn)者是API客戶端時(shí)虫啥，API調(diào)用的權(quán)限需由服務(wù)集成平臺(tái)進(jìn)行控制蔚约。建議采用“消費(fèi)者先訂閱一組API，訂閱成功后才允許訪問(wèn)”的授權(quán)模式涂籽，服務(wù)集成平臺(tái)應(yīng)該僅允許API客戶端訪問(wèn)其訂閱過(guò)的API 苹祟。 具體實(shí)現(xiàn)方法就是絕大多數(shù)服務(wù)集成平臺(tái)都會(huì)提供的基于API Key控制API訪問(wèn)的方式。需要注意的是，僅使用API key的訪問(wèn)控制是不夠的苔咪。API Key是在服務(wù)集成平臺(tái)訂閱API時(shí)生成的一串唯一編號(hào)，并不具備識(shí)別客戶端身份的能力柳骄。就好比以前買火車票是不實(shí)名的团赏，誰(shuí)拿到火車票，都可以乘坐對(duì)應(yīng)車次耐薯√蚯澹火車票實(shí)名制之后，首先需要核驗(yàn)身份證曲初，核驗(yàn)通過(guò)后才能購(gòu)票乘車体谒。如果證票不符，則不允許乘車臼婆。
將客戶端認(rèn)證和API Key配合進(jìn)行訪問(wèn)認(rèn)證和權(quán)限校驗(yàn)才是個(gè)更安全的方案抒痒。
上圖為網(wǎng)關(guān)作為服務(wù)集成平臺(tái)時(shí)，訪問(wèn)令牌結(jié)合API Key的認(rèn)證鑒權(quán)示意圖颁褂，說(shuō)明如下：
- 客戶端1獲取了API Key 但其沒(méi)有合法的訪問(wèn)令牌故响，如果不允許匿名訪問(wèn)，則網(wǎng)關(guān)會(huì)拒絕客戶端1訪問(wèn)颁独，返回錯(cuò)誤碼401表示客戶端未通過(guò)認(rèn)證彩届；
- 客戶端2擁有了合法的訪問(wèn)令牌，但其API Key不合法誓酒，網(wǎng)關(guān)在客戶端2認(rèn)證檢查通過(guò)后樟蠕，檢查API Key，發(fā)現(xiàn)其權(quán)限不足靠柑，則返回錯(cuò)誤碼403表示客戶端的權(quán)限不足寨辩；
- 客戶端3擁有合法的客戶端訪問(wèn)令牌和API Key訪問(wèn)網(wǎng)關(guān)上的服務(wù)，網(wǎng)關(guān)認(rèn)證歼冰、鑒權(quán)通過(guò)之后捣染，將請(qǐng)求路由到實(shí)際的服務(wù)提供端，最終發(fā)回正常響應(yīng)數(shù)據(jù)停巷。
用戶權(quán)限服務(wù)集成平臺(tái)管不管耍攘？
用戶訪問(wèn)的功能權(quán)限或數(shù)據(jù)權(quán)限不建議交給服務(wù)集成平臺(tái)管控，原因是服務(wù)集成平臺(tái)僅能支持基于API Path授權(quán)畔勤，而實(shí)際需要控制的用戶權(quán)限有很多蕾各，如菜單、功能庆揪、數(shù)據(jù)等式曲。如果由服務(wù)集成平臺(tái)控制用戶權(quán)限，管少了不滿足需求，管多了就要耦合太多應(yīng)用數(shù)據(jù)吝羞±忌耍跨團(tuán)隊(duì)直接溝通協(xié)調(diào)、問(wèn)題定位等分工責(zé)任也難界定钧排。
因此推薦用戶權(quán)限由業(yè)務(wù)應(yīng)用自行管控敦腔。每個(gè)業(yè)務(wù)系統(tǒng)內(nèi)部如果需要控制用戶權(quán)限，可以將系統(tǒng)內(nèi)部的權(quán)限在統(tǒng)一權(quán)限管理服務(wù)中配置恨溜。應(yīng)用從權(quán)限中心獲取數(shù)據(jù)進(jìn)行用戶權(quán)限控制符衔。如沒(méi)有權(quán)限中心，也可以由應(yīng)用自身維護(hù)權(quán)限數(shù)據(jù)糟袁。對(duì)于權(quán)限管理是業(yè)務(wù)系統(tǒng)自治還是集中管控判族，一般根據(jù)企業(yè)自身的需求特點(diǎn)決定即可。
服務(wù)集成平臺(tái)應(yīng)提供更強(qiáng)大的請(qǐng)求路由能力
服務(wù)集成平臺(tái)要能夠融入到微服務(wù)生態(tài)中
建設(shè)服務(wù)集成平臺(tái)要考慮的就是能夠融入微服務(wù)生態(tài)中项戴。與微服務(wù)基礎(chǔ)服務(wù)中的注冊(cè)中心形帮、配置中心、監(jiān)控中心周叮、日志中心等基礎(chǔ)組件集成沃缘，能夠大大加強(qiáng)服務(wù)集成平臺(tái)的服務(wù)治理、路由则吟、運(yùn)維等能力槐臀。
- 服務(wù)集成平臺(tái)與注冊(cè)中心集成：服務(wù)集成平臺(tái)能夠通過(guò)注冊(cè)中心獲取應(yīng)用的實(shí)例信息，比如應(yīng)用A有幾個(gè)集群組氓仲？每個(gè)集群組中有哪些實(shí)例進(jìn)程水慨。讓服務(wù)集成平臺(tái)的路由、負(fù)載等等相關(guān)能力更強(qiáng)大敬扛。
- 服務(wù)集成平臺(tái)與配置中心集成：服務(wù)集成平臺(tái)能夠通過(guò)配置中心在線動(dòng)態(tài)修改配置晰洒，自動(dòng)同步到服務(wù)集成平臺(tái)，結(jié)合配置熱更新能力啥箭，服務(wù)集成平臺(tái)就可以做到不停機(jī)修改和調(diào)整相關(guān)的控制策略谍珊。更加靈活快速的響應(yīng)變更。
- 服務(wù)集成平臺(tái)與監(jiān)控中心急侥、日志中心集成：服務(wù)集成平臺(tái)本身也是分布式部署的砌滞，可能不同渠道、不同業(yè)務(wù)域坏怪、甚至不同類型的客戶端都會(huì)部署服務(wù)集成平臺(tái)集群贝润，集成了監(jiān)控中心、日志中心后铝宵，分布式部署的服務(wù)集成平臺(tái)也可以做到統(tǒng)一的監(jiān)控和服務(wù)跟蹤打掘，在享受分布式架構(gòu)好處的同時(shí)华畏，還能有聚合監(jiān)控的體驗(yàn)。
服務(wù)集成平臺(tái)要支持應(yīng)用分組路由（版本控制尊蚁、灰度發(fā)布）
基于可靠性亡笑、性能方面考慮，通常一個(gè)服務(wù)提供者應(yīng)用會(huì)以集群形式對(duì)外提供服務(wù)横朋。隨著快速響業(yè)務(wù)應(yīng)變化的需求越來(lái)越多仑乌，應(yīng)用通常會(huì)進(jìn)行多版本并行迭代快速交付。比如說(shuō)叶撒，某個(gè)應(yīng)用在生產(chǎn)系統(tǒng)同時(shí)運(yùn)行了兩個(gè)集群绝骚，也就是說(shuō)同樣一個(gè)AppId 對(duì)應(yīng)的多個(gè)進(jìn)程實(shí)例耐版，實(shí)際上再注冊(cè)中心中劃分為兩個(gè)組祠够，一組為之前上線運(yùn)行的穩(wěn)定版，另一組為新上線的版本粪牲。這種場(chǎng)景下古瓤，就要求服務(wù)集成平臺(tái)能夠支持對(duì)同一個(gè)AppId進(jìn)行分組路由，不同組的應(yīng)用API對(duì)應(yīng)的版本不同腺阳。這個(gè)場(chǎng)景就是我們常說(shuō)的通過(guò)服務(wù)集成平臺(tái)進(jìn)行API的版本控制落君，服務(wù)集成平臺(tái)支持了應(yīng)用分組路由的能力，也就意味著支持了應(yīng)用灰度發(fā)布亭引。
服務(wù)集成平臺(tái)要支持動(dòng)態(tài)負(fù)載均衡
一個(gè)服務(wù)提供者應(yīng)用集群中會(huì)存在多個(gè)進(jìn)程實(shí)例绎速，這些進(jìn)程實(shí)例會(huì)與注冊(cè)中心通訊，報(bào)告自身的健康狀況焙蚓。而服務(wù)集成平臺(tái)則須支持通過(guò)注冊(cè)中心獲取應(yīng)用的實(shí)例列表信息纹冤，用以在服務(wù)路由過(guò)程中的負(fù)載均衡調(diào)用。借助了注冊(cè)中心的能力购公，集群內(nèi)的應(yīng)用實(shí)例增加或減少萌京，服務(wù)集成平臺(tái)均可在段時(shí)間內(nèi)獲悉，因此這種模式下宏浩，服務(wù)集成平臺(tái)對(duì)應(yīng)用的動(dòng)態(tài)負(fù)載均衡也能夠很好的支持知残。
對(duì)于負(fù)載均衡策略服務(wù)集成平臺(tái)應(yīng)該支持常見(jiàn)的幾種，如：輪循比庄、隨機(jī)求妹、哈希、一致性哈希佳窑、權(quán)重比例等扒最，還需要提供良好的擴(kuò)展能力用以針對(duì)企業(yè)應(yīng)用的特點(diǎn)進(jìn)行擴(kuò)展。
服務(wù)集成平臺(tái)要具備熔斷华嘹、降級(jí)吧趣、限流能力
服務(wù)熔斷、降級(jí)、限流等概念均是從可用性和可靠性出發(fā)强挫，為了防止系統(tǒng)崩潰而采用的一些保護(hù)性手段岔霸。對(duì)于服務(wù)消費(fèi)端的體驗(yàn)是類似的，都是部分服務(wù)暫時(shí)不可用俯渤。不同的是這三者的觸發(fā)時(shí)機(jī)有所不同呆细。分別說(shuō)明如下：
服務(wù)熔斷：這個(gè)概念就出自電力設(shè)備保護(hù)的保險(xiǎn)絲，顧名思義八匠，服務(wù)熔斷是指在應(yīng)用集群內(nèi)絮爷，如果某個(gè)應(yīng)用發(fā)生了故障，則將其熔斷梨树，即：負(fù)載均衡時(shí)將其排除在可用列表之外坑夯。服務(wù)集成平臺(tái)自身內(nèi)部應(yīng)該包含客戶端路由的能力，一旦調(diào)用某個(gè)應(yīng)用發(fā)生故障抡四，應(yīng)該隨機(jī)記錄在案柜蜈，短期內(nèi)將故障應(yīng)用實(shí)例排除在路由目標(biāo)范圍之外，待其恢復(fù)之后指巡，再次啟用淑履。這種熔斷策略是被動(dòng)觸發(fā)的，能夠有效的防止因?yàn)閱吸c(diǎn)故障引發(fā)的連鎖反應(yīng)藻雪，甚至雪崩秘噪。
服務(wù)降級(jí)：與熔斷不同的是，服務(wù)降級(jí)是在服務(wù)集成平臺(tái)判斷當(dāng)前運(yùn)行負(fù)載過(guò)高時(shí)勉耀，預(yù)防性的將一些優(yōu)先級(jí)低的非核心服務(wù)調(diào)用請(qǐng)求主動(dòng)舍棄指煎，避免服務(wù)提供端壓力過(guò)大導(dǎo)致崩潰。
服務(wù)限流：限流是針對(duì)服務(wù)消費(fèi)者請(qǐng)求的限制手段瑰排，通彻嵋基于API訪問(wèn)次數(shù)的計(jì)量結(jié)果進(jìn)行控制。靜態(tài)限流模式類似流量套餐椭住，如：按請(qǐng)求數(shù)量計(jì)費(fèi)的模式崇渗，套餐限制一天內(nèi)調(diào)用某一組API的次數(shù)不超過(guò)1000次，超過(guò)后服務(wù)集成平臺(tái)就會(huì)阻止消費(fèi)端的調(diào)用請(qǐng)求京郑。動(dòng)態(tài)限流模式可以跟服務(wù)降級(jí)類似宅广，在運(yùn)行負(fù)載高的時(shí)候，限制拒絕優(yōu)先級(jí)低的客戶端請(qǐng)求些举，將主通道讓路給核心和重要業(yè)務(wù)運(yùn)行跟狱。
轉(zhuǎn)載本文需注明出處：網(wǎng)關(guān)（API Gateway）與ESB之爭(zhēng)
