談輕量服務(wù)總線
加入技術(shù)交流群
在這種ESB總線模式下，通過inbound 和 outbound pipeline會做大量的的工作。包括訪問控制，流程控制，協(xié)議轉(zhuǎn)換和適配，日志logging等。這些插件本身是可插拔的配置，有些是對消息頭信息的簡單處理，有些是需要對消息體信息進行處理。除掉這部分內(nèi)容，剩下的包括了服務(wù)代理，數(shù)據(jù)處理，服務(wù)輕量編排，路由功能等，這些也是核心的ESB功能。
從消費方發(fā)起一起服務(wù)請求調(diào)用，整個過程可以簡化為首先是通過inbound pipeline進行訪問控制，流量控制，進行協(xié)議的轉(zhuǎn)換，對輸入的信息進行l(wèi)og記錄。然后進行實際處理環(huán)節(jié)，包括proxy service的解包，數(shù)據(jù)的處理和轉(zhuǎn)換，路由分發(fā)；然后進入到提供方實際的服務(wù)調(diào)用，服務(wù)調(diào)用完成后對于返回的服務(wù)調(diào)用信息再進行相關(guān)的協(xié)議轉(zhuǎn)換和日志記錄處理，最終返回結(jié)果給服務(wù)消費方。
在這個過程中，可以看到整個服務(wù)調(diào)用數(shù)據(jù)流都需要在總線上運行和傳輸，一個是數(shù)據(jù)量本身很大，一個是每次數(shù)據(jù)適配和解析都可能是一次性能消耗。針對全新規(guī)劃的系統(tǒng)建設(shè)可以看到，不會有太多的遺留系統(tǒng)適配和協(xié)議轉(zhuǎn)換問題，在ESB總線上也不會處理太多的數(shù)據(jù)映射處理和轉(zhuǎn)換工作。同時流量控制本身也不是必須的功能要求。因此對于簡單的總線，其核心功能重點將放在代理服務(wù)，路由，日志記錄，訪問控制四個核心內(nèi)容上。
對于上述四個核心內(nèi)容的實現(xiàn)，基本可以參考上面的ESB總線模型進一步簡化，那總線的瓶頸可能受到的最大影響就是日志記錄這塊，在這塊初步的思路就是日志記錄是接JMS+MQ，對于總線接收到的日志記錄進行異步持久化處理，這樣日志記錄的瓶頸和性能問題可以減輕。
以上問題都考慮后，是否還可以對總線模型做簡化，總線更加重要的是統(tǒng)一服務(wù)目錄庫（proxy service)的提供，服務(wù)鑒權(quán)和路由功能。如果僅僅考慮這些功能，那么整個消息流是否一定要走在服務(wù)總線上？基于這個思路，可以看到在輕量總線上可以進一步考慮控制流和消息流的進一步分離，如下圖：
在這種場景下，消費方對服務(wù)的調(diào)用由原來的一次調(diào)用轉(zhuǎn)換為兩次，首先第一次調(diào)用傳入相關(guān)的消費方系統(tǒng)，請求地址，和消息頭信息。對于總線根據(jù)這些信息進行服務(wù)鑒權(quán)，流量控制，根據(jù)proxy找到具體的原始服務(wù)提供地址，在這個地方中還涉及到路由。這些內(nèi)容都處理完成后，根據(jù)拿到的目標(biāo)端信息和控制令牌等信息發(fā)起對目標(biāo)端的直接調(diào)用。目標(biāo)服務(wù)提供端也可能涉及到需要和總線交互進行相關(guān)的鑒權(quán)操作，完成后返回數(shù)據(jù)信息給服務(wù)消費方。
在整個過程中，服務(wù)總線上不承載具體的消息數(shù)據(jù)流，也不會對消息流進行協(xié)議轉(zhuǎn)換或數(shù)據(jù)映射處理等。重點還是實現(xiàn)統(tǒng)一的服務(wù)目錄庫，對服務(wù)進行訪問控制和鑒權(quán)，根據(jù)消息頭參數(shù)對目標(biāo)端進行路由等。由于不承載具體的消息數(shù)據(jù)流，服務(wù)總線將很輕，即使在大并發(fā)量和大數(shù)據(jù)量下也不會出現(xiàn)較大的瓶頸。這種總線模式將適合類似技術(shù)服務(wù)，DaaS數(shù)據(jù)庫服務(wù)，數(shù)據(jù)服務(wù)等大量數(shù)據(jù)傳輸?shù)膱鼍啊?br />
在這種模式下，可能會出現(xiàn)一個新的問題，即對于服務(wù)消費方往往需要兩次調(diào)用才能夠?qū)崿F(xiàn)。對于這個問題很簡單，我們可以考慮實現(xiàn)了一個前置的輕量ESB服務(wù)代理包，在ESB服務(wù)代理包中對兩次調(diào)用過程進行封裝，以簡化應(yīng)用對服務(wù)的消費。
評論