談輕量服務總線

上次談數據集中化和拆分的時候談到了輕量總線的問題，在這里再對輕量總線的思考做一個簡單的說明。首先來看下對于一個ESB總線本身的模型簡化，如下圖:



在這種ESB總線模式下，通過inbound 和 outbound pipeline會做大量的的工作。包括訪問控制，流程控制，協議轉換和適配，日志logging等。這些插件本身是可插拔的配置，有些是對消息頭信息的簡單處理，有些是需要對消息體信息進行處理。除掉這部分內容，剩下的包括了服務代理，數據處理，服務輕量編排，路由功能等，這些也是核心的ESB功能。

從消費方發(fā)起一起服務請求調用，整個過程可以簡化為首先是通過inbound pipeline進行訪問控制，流量控制，進行協議的轉換，對輸入的信息進行l(wèi)og記錄。然后進行實際處理環(huán)節(jié)，包括proxy service的解包，數據的處理和轉換，路由分發(fā)；然后進入到提供方實際的服務調用，服務調用完成后對于返回的服務調用信息再進行相關的協議轉換和日志記錄處理，最終返回結果給服務消費方。

在這個過程中，可以看到整個服務調用數據流都需要在總線上運行和傳輸，一個是數據量本身很大，一個是每次數據適配和解析都可能是一次性能消耗。針對全新規(guī)劃的系統(tǒng)建設可以看到，不會有太多的遺留系統(tǒng)適配和協議轉換問題，在ESB總線上也不會處理太多的數據映射處理和轉換工作。同時流量控制本身也不是必須的功能要求。因此對于簡單的總線，其核心功能重點將放在代理服務，路由，日志記錄，訪問控制四個核心內容上。

對于上述四個核心內容的實現，基本可以參考上面的ESB總線模型進一步簡化，那總線的瓶頸可能受到的最大影響就是日志記錄這塊，在這塊初步的思路就是日志記錄是接JMS+MQ，對于總線接收到的日志記錄進行異步持久化處理，這樣日志記錄的瓶頸和性能問題可以減輕。

以上問題都考慮后，是否還可以對總線模型做簡化，總線更加重要的是統(tǒng)一服務目錄庫（proxy service)的提供，服務鑒權和路由功能。如果僅僅考慮這些功能，那么整個消息流是否一定要走在服務總線上？基于這個思路，可以看到在輕量總線上可以進一步考慮控制流和消息流的進一步分離，如下圖：



在這種場景下，消費方對服務的調用由原來的一次調用轉換為兩次，首先第一次調用傳入相關的消費方系統(tǒng)，請求地址，和消息頭信息。對于總線根據這些信息進行服務鑒權，流量控制，根據proxy找到具體的原始服務提供地址，在這個地方中還涉及到路由。這些內容都處理完成后，根據拿到的目標端信息和控制令牌等信息發(fā)起對目標端的直接調用。目標服務提供端也可能涉及到需要和總線交互進行相關的鑒權操作，完成后返回數據信息給服務消費方。

在整個過程中，服務總線上不承載具體的消息數據流，也不會對消息流進行協議轉換或數據映射處理等。重點還是實現統(tǒng)一的服務目錄庫，對服務進行訪問控制和鑒權，根據消息頭參數對目標端進行路由等。由于不承載具體的消息數據流，服務總線將很輕，即使在大并發(fā)量和大數據量下也不會出現較大的瓶頸。這種總線模式將適合類似技術服務，DaaS數據庫服務，數據服務等大量數據傳輸的場景。

在這種模式下，可能會出現一個新的問題，即對于服務消費方往往需要兩次調用才能夠實現。對于這個問題很簡單，我們可以考慮實現了一個前置的輕量ESB服務代理包，在ESB服務代理包中對兩次調用過程進行封裝，以簡化應用對服務的消費。