本文主要談及了服務互通開放典型問題，也介紹了企業業務能力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幫助企業構建自己的能力開放平台，實現內部、與合作夥伴以及第三方的系統之間跨協議的服務能力互通，對服務
api的發布、訂閱、消費提供一致的組織管理。
服務處理過程
服務請求經過負載均衡，需要經過乙個網路的防護，例如設定一些
ip上的黑白名單，也可以整合一些網路安全的產品，來預防
ddos
等網路攻擊。當
csb確定是乙個來自合法**的請求後
，需要進行協議適配，看服務呼叫者到底是誰，訪問的是哪個服務。然後，
csb進行鑑權，識別是否是合法身份的呼叫者，是否被授權訪問目標服務，以及是否達到約定的服務訪問限制等等。接下來，如果不是本地節點提供的服務。需要進行
csb級聯處理，可能會轉接到另外的
csb例項。如果服務確實是本地節點能夠提供，我們就要做進一步的服務請求的解析和校驗。然後進入結果快取模式，因為拿到的請求不一定需要放到後端去，如果服務發布者指定對該服務開啟
csb快取功能，一定時間內對該服務相同的請求，可以直接返回快取的結果。緊接著要進行服務編排，常見的是服務路由處理。接下來進行訊息對映和報文轉換，最後通過協議適配到達服務提供方，獲得結果經過轉換返回給呼叫方。這就是
csb處理乙個請求的大體過程。
如果鏈路很複雜，我們從鏈路的呼叫端到服務的提供端，任何乙個環節都有可能出問題，這時候我們
csb需要有乙個監控的機制，並且要有乙個鏈路級的分析方式，幫助快速地排查、分析、解決問題。
綜合場景
圖中連線不同環境的是乙個典型的雙箭頭的雙魚型的標誌，它其實就是所謂的
csb例項。用
csb例項間的連線為橋梁，實現它們各自「負責」的不同環境內部以及相互之間的服務互通。整個場景裡可以看到，
csb可以放在企業自己的資料中心和阿里雲等環境裡，打通各個系統，實現企業內部互通，企業內外互通，雲上雲下互通，複雜級聯互通。在任何乙個節點上，我們開放出去的服務，也可以是我們自己的一些終端應用、裝置在消費。合作夥伴、內外系統、移動端和雲端應用, 用
csb可以連線一切。
雲服務匯流排（cloud service bus，簡稱csb）公測中，可訪問官網檢視具體產品資訊：
雲服務匯流排
服務匯流排提供了安全訊息傳遞和中繼功能，使您能夠在雲中構建鬆散耦合的分布式應用程式以及跨私有雲和公有雲的混合應用程式。它不僅支援多種訊息傳遞協議和模式，而且將處理針對應用程式的交付保證 可靠訊息傳遞和縮放。服務匯流排有多種實際用途。一些常見用途包括 利用服務匯流排，您可以安全連線私有雲中執行的企業系...
雲服務匯流排CSB
雲平台和社交網路時代的企業，移動服務模式正在改變企業的企業傳統的運營和工作方式 然而，大多企業在主動，或者跟風建設移動應用的時候，卻遇到種種挑戰 如何有效的管理移動應用的上架和更新，如何自動化發布到員工移動裝置中，如何確保應用僅被授權的人員來安裝和使用？it部門如何規範化移動應用技術架構，企業it的...
阿里雲產品公測 訊息佇列服務MQS使用分享
訊息佇列mqs，顧名思義，是用於傳送接收訊息用的。廢話不說，直接進入主題。由此決定使用3臺伺服器同時處理，將任務分布到3臺伺服器中。另外有一台伺服器用於提交任務。mqs支援多個生產者 多個消費者併發訪問乙個佇列 本例是乙個生產者，3個消費者 簡單的伺服器部署情況如下圖 具體的 實現這裡就不再說明了，...