公測與奧運同行,云服務總線CSB:“連”無邊界
摘要: 8月9日2016云棲大會北京峰會拉開帷幕,阿里中間件高級產品專家奕成帶來了“云服務總線CSB——‘連’無邊界”的重要演講。其中談及了服務互通開放典型問題,也介紹了企業業務能力API化,著重說明了云服務總線CSB的服務處理過程,最后概括了綜合場景。精彩不容錯過——
本文主要談及了服務互通開放典型問題,也介紹了企業業務能力API化,著重說明了云服務總線CSB的服務處理過程,最后概括了綜合場景。
以下為精彩內容整理:
云服務總線CSB與ESB有什么關系呢?CSB就是互聯網以及云計算場景下的企業服務總線,但重點不同,CSB真正要做的是能力開放平臺,無論是ESB還是CSB,它們都是要實現系統之間的服務互通。
服務互通開放典型問題
服務協議和接口差異:
舉個例子,如果用企業互聯網架構平臺 Apsara Aliware的“三駕馬車”(EDAS/DRDS/MQ)構建一個新系統,怎樣與原來的系統交互呢?兩個系統之間協議和接口形態可能很不一樣(同步異步、參數結構、報文格式)。從服務消費者的角度來說,想把某些東西為我所用,想要集成或者調用的東西是確定的,配置或者實現對應的適配器就好,這就是ESB的典型場景。而云服務總線CSB更多從服務提供者的角度來考慮,他的一個已有系統要對外開放服務,要面對的是更不確定更廣泛的服務消費用戶群,消費者應用的體量和類型可能是各式各樣的。那么,首先應該有一個方便的機制,使得在CSB上發布服務的時候不需要針對不同的消費方協議做不同的處理,而消費方應用也可以很方便地使用廣泛通用的、或者自己偏好的服務協議來調用這個服務;其次,還要讓服務發布者可以在CSB上設定開放出來的接口結構和原有接口的差異,做一定的變化、簡化、甚至屏蔽,不單是參數個數和列表結構上的不同,也包括參數內容格式的轉換,即通常所謂的報文轉換。
網絡防火墻限制約束:
企業內部的網絡結構和系統之間的部署和隔離的情況可能會比較復雜。例如一個系統配置了防火墻,假設只能從內部訪問到外部,外部不能訪問內部,但又需要把系統內部的服務開放出去給別人用,CSB該怎么解決?又例如企業有多個子系統,相互之間是網絡隔絕的,只能和一個中心系統交互,那么CSB如何讓一個子系統的服務能為另一個子系統所用?
安全性管理授權鑒權:系統間的服務的訪問通常都需要認證和鑒權。在CSB的服務處理中,認證就是確定訪問方是系統認可的合法服務消費者,鑒權是指用戶對指定服務的訪問是得到過授權的。
訪問量與優先級控制:
從服務消費者的角度來看,一定會對服務調用頻度有要求,但作為服務提供方,需要考慮其服務器集群能支撐的業務訪問量,我們CSB需要一些保護措施保證不會被爆發的服務請求壓垮,首先會做限流,將一部分服務請求擋掉,而擋掉哪些放行哪些,又要考慮是否引入服務以及消費者的優先級處理。
服務消費量需求變化:
在互聯網場景里,我們經常會看到應用用戶量和業務量有非線性增長的情況,這個增長通常也很難預期,從服務提供方的角度講,我們CSB要有快速便捷進行線性擴容的能力。
多節點接力級聯服務:
有些企業本身內部的系統環境就比較多,再結合互聯網云計算,系統間服務互通的情況就更復雜了。不同的數據中心、地域、云上、云下,多個企業之間等等,每一個節點可能屬于不同的業務域,屬于不同的企業、不同的環境,之前也提到過,又由于防火墻以及網絡規劃,節點之間又會有這樣那樣的訪問約束。那么CSB要支持跨節點之間的服務互通,必須要解決路徑打通,以及路徑上不同歸屬的節點之間的授信問題。
企業業務能力API化
現在的企業正在面對迅速變化的經濟、市場以及技術環境,需要更靈活敏捷地進行產品設計開發,以應對快速的業務變化和緊張的經費壓力。企業可以采用例如阿里巴巴Aliware這樣的企業互聯網架構技術,實現自身的服務化沉淀和組織,形成以厚實的中臺共享業務,高效靈活支撐前臺多變業務需求的結構。同時可以根據自身技術能力、資金以及時間各方面情況的考慮,選擇專業、高效、更有成本優勢的第三方服務,來快速、靈活、組合式地構建企業應用。
另一方面,越來越多的企業組織也需要以API方式把自己的核心業務資產整理開放給合作伙伴,或者讓第三方的應用整合。結合之前提到的系統間服務互通的典型問題,可以注意到,CSB更強調從服務提供方的角度來看,面對更多變和廣泛的消費群,怎樣更高效、更靈活、更彈性地開放服務。從服務消費者的角度來講,會希望有這樣一個平臺,能夠方便地搜尋和消費需要的服務,不需要冗長、繁瑣的商務過程,簡單訂閱調用就實現了服務能力的集成,這就是API的概念。
對服務提供方來說,如果想把API開放出來,需要持續對自身能力做分析和梳理,而且開放成API后,來自服務消費方的反饋也是非常直接的,有利于幫助企業思考自身的業務能力,到底什么東西最有價值,有助于發掘新的業務模式,提高服務水平。當把一個能力以API的形式開放出來后,由于消費的便捷和高效,更利于潛在客戶的發掘和合作空間的拓展。我們需要這樣一個產品,無論是跟已有系統的集成,還是把企業的能力開放出來給別人用,還是把企業內部各個系統之間以能力互通的方式去促進各個業務的創新和融合,都需要有一個能力的開放平臺。
云服務總線CSB
服務處理過程
服務請求經過負載均衡,需要經過一個網絡的防護,例如設置一些IP上的黑白名單,也可以集成一些網絡安全的產品,來預防DDOS等網絡攻擊。當CSB確定是一個來自合法來源的請求后 ,需要進行協議適配,看服務調用者到底是誰,訪問的是哪個服務。然后,CSB進行鑒權,識別是否是合法身份的調用者,是否被授權訪問目標服務,以及是否達到約定的服務訪問限制等等。接下來,如果不是本地節點提供的服務。需要進行CSB級聯處理,可能會轉接到另外的CSB實例。如果服務確實是本地節點能夠提供,我們就要做進一步的服務請求的解析和校驗。然后進入結果緩存模式,因為拿到的請求不一定需要放到后端去,如果服務發布者指定對該服務開啟CSB緩存功能,一定時間內對該服務相同的請求,可以直接返回緩存的結果。緊接著要進行服務編排,常見的是服務路由處理。接下來進行消息映射和報文轉換,最后通過協議適配到達服務提供方,獲得結果經過轉換返回給調用方。這就是CSB處理一個請求的大體過程。
如果鏈路很復雜,我們從鏈路的調用端到服務的提供端,任何一個環節都有可能出問題,這時候我們CSB需要有一個監控的機制,并且要有一個鏈路級的分析方式,幫助快速地排查、分析、解決問題。
綜合場景
圖中連接不同環境的是一個典型的雙箭頭的雙魚型的標志,它其實就是所謂的CSB實例。用CSB實例間的連接為橋梁,實現它們各自“負責”的不同環境內部以及相互之間的服務互通。整個場景里可以看到,CSB可以放在企業自己的數據中心和阿里云等環境里,打通各個系統,實現企業內部互通,企業內外互通,云上云下互通,復雜級聯互通。在任何一個節點上,我們開放出去的服務,也可以是我們自己的一些終端應用、設備在消費。合作伙伴、內外系統、移動端和云端應用, 用CSB可以連接一切。
來自:http://jm.taobao.org/2016/08/18/csb-intro/