獨家系列:讓咱們碰見將來——爲何選擇SEDA做爲雲平臺的基礎消息處理架構(PPT)

本文爲普元軟件產品部大數據產品線副總臧一超在普元雲計算架構設計羣的微課堂分享,轉載需與本號聯繫,歡迎關注EAII(微信公衆號:eaworld)。web


普元新一代數字化企業雲平臺研發設計羣,將公開普元研發和設計過程並直播架構設計與討論及相關PPT素材。如需加入此羣請直接回復此公衆號:「加羣 姓名 公司 職位 微信號」。算法



咱們身處在一個數字化商業的時代,做爲一名IT工做者,如何保證咱們所設計的系統、開發的服務在面對複雜不肯定的網絡環境中,還要去交付準確可靠穩定的服務?編程


咱們在數以千計微服務支撐的雲計算平臺下,怎麼考慮不肯定性的併發請求、超量請求、請求的不斷積壓?微信


同時,咱們還要兼顧外部所鏈接的商業功能網絡中斷、服務不可用、服務超時、事務完整性等等一系列的問題。那麼,如何來解決現實世界中的這些問題呢?網絡



傳統的併發編程模型主要有兩種:一種是Thread-based concurrency, 另外一種是Event-driven concurrency。多線程



總結下兩種模式的特色,
架構


基於線程的併發:每一個任務一線程直線式的編程使用資源高昂,context切換代價高,競爭鎖昂貴,太多線程可能致使吞吐量降低,響應時間暴漲;併發


基於事件的併發:單線程處理事件的每一個併發流實現爲一個有限狀態機應用直接控制併發負載增長的時候,吞吐量飽和響應時間線性增加。框架


SEDA架構是目前雲計算、微服務時代下一種優秀的消息處理架構,並且歷經考驗,穩定可靠。異步



SEDA架構的核心思想:把一個請求處理過程分紅幾個Stage,每一個Stage可由不一樣的微服務進行處理,不一樣資源消耗的Stage使用不一樣數量的線程來處理,微服務之間採用異步通信的模式。


時代在變,咱們的技術架構也在變,順時針看架構的以下演進過程:



應用邏輯封裝到Event Handler,接收到許多事件。處理這些事件,而後派發事件加入其餘Stage的queue。對queue和threads沒有直接控制Event queue吸納過量的負載,有限的線程池維持併發。


Stage控制器:負責資源的分配和調度;控制派發給Event Handler的事件的數量和順序;Event Handler可能在內部丟棄、過濾、重排序事件。



接下來,說一下這種架構裏的動態資源控制器,一個是線程池管理,另外一個是批量管理。


線程池管理器決定了每一個微服務處理下的Stage合理的併發程度,經過觀察隊列長度,超過閾值就添加線程並移除空閒線程。



SEDA架構中SEDA併發模型依賴於Event-driven concurrency模型來支持高併發。利用一組線程來處理每一個請求,而不是每個請求一個線程,利用Nonblocking I/O來避免資源的阻塞。



它的核心是,全部的邏輯處理以及接入、接出所有進行隔離,根據不一樣的業務操做類型分別對待合理進行分組。實際上,基於微服務架構的雲平臺在實現這一理念的時候有先天性的優點。



SEDA框架根據業務系統可靠性要求、消息框架能夠採用內存隊列或者持久化隊列,知足不一樣SLA要求下的可靠性保障。



SEDA架構下提供服務宿主處理的容器,容器是服務運行的基礎環境,容器負責資源分配管理、服務超時管理、服務流量控制、服務路由控制。



每一個容器有2組channel(每組有請求、響正常應、錯誤響應)組成,根據是否具備輸入、輸出,容器分爲三種類型。


接下來,咱們來看看容器的路由。



做爲獨立的stage,channel根據不一樣業務負載提供路由,根據路由規則和服務元數據對服務進行路由。路由提供本地路由及遠程路由能力,支持服務的橫向擴展。


爲了支撐遠程路由,須要平臺提供分佈式的調度框架能力支撐,一個簡化的分佈式調度框架以下:



容器提供資源管理能力,對服務性資源、對象資源提供池化調度能力,精確匹配服務請求量。



在這種架構下,咱們能夠很方便的對雲環境下的微服務(商業功能)實現多種控制、保障機制。
舉個例子:分佈式雲環境下的流量控制機制在SEDA架構下的實現。




最後給你們奉上雲平臺下基礎消息處理架構的SEDA架構整體設計:







附: 各 羣 答 疑


Q一、羣友1:普元的技術架構強調容器和統一資源調度嗎?怎麼解決跨雲的微服務高可用,彈性伸縮,服務框架跨DC的RPC問題?如今不少密集計算的平臺都會考慮基於容器,這樣能夠和mesos配合解決彈性和容量的問題。


答:沒有強調容器,調度是必不可少的。容器只是給彈性伸縮提供了基本的可能性,關鍵是包括無狀態、分佈式的設計,才能真正解決彈性和容量。mesos側重資源調度,是個好東西。不過咱們如今作的簡單,只用了k8s。(普元產品部主任架構師顧偉)


羣友2:高性能路由器裏QOS的算法能夠參考。

羣友1:簡化是最重要的,初期能夠跳過mesos直接k8s,後期仍是建議通用mesos.


答:恩,一種是QOS的算法以解決通訊,還有業務雙活的一些作法,儘量減小跨數據中心調用。(普元產品部主任架構師顧偉)


Q二、羣友:這個架構的產品形態和用戶界面是什麼?

答:架構的自己就是分佈式可伸縮的,任何須要高可靠、高可用、海量消息、事件處理的商業功能均可以使用它。它做爲雲計算下的一種基礎服務,也能夠做爲雲計算微服務架構下的消息處理服務。(普元大數據產品線副總臧一超)


如需加入EAII研究院成爲會員請點擊此公衆號菜單:EAII-在線註冊或添加微信號:elaineyuan928。


關於做者:

臧一超

EAII-企業架構創新研究院 專家委員

現任普元大數據產品線副總,基於微服務的企業架構實踐者。十餘年IT行業經驗,專一於SOA、分佈式計算、大數據處理、企業架構設計等領域。曾指導帶領技術團隊完成航天科工四院協同數據交換平臺、上海移動ESB集成平臺、華夏人壽服務治理平臺等項目的系統實施以及方案撰寫。


關於EAII

EAII(Enterprise Architecture Innovation Institute)企業架構創新研究院,是專一於企業架構與業務創新領域的研究機構,致力於金融、電信、能源與政務等行業領域的企業軟件架構優化設計與 創新研究,以及分佈式計算、服務構件技術、可視化技術、業務流程管理、內存計算、企業移動計算、數據治理等領域的技術研究。


eaworld項目(微信號:eaworld,長按二維碼關注)


eaworld是EAII的官方微信帳號。


↓↓↓閱讀原文,下載課件!

本文分享自微信公衆號 - EAWorld(eaworld)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。

相關文章
相關標籤/搜索