基於SOA的高併發和高可用分散式系統架構和元件詳解
基於SOA的分散式高可用架構和微服務架構,是時下如日中天的網際網路企業級系統開發架構選擇方案。在核心思想上,兩者都主張對系統的橫向細分和擴充套件,按不同的業務功能模組來對系統進行分割並且使用一定的手段實現服務之間的通訊,並且基於彈性雲服務搭建高可用的分散式解決方案。
但它們之間的區別可能比相似的地方要多,特別是體現在對服務的使用和與雲服務的深度結合上。在具體實踐中,微服務的架構也可以與其它網際網路中介軟體組合在一起,組成規模更為龐大的SOA分散式系統。本文主要對一個典型的SOA分散式應用的架構和元件做詳細的說明。
企業級系統架構的演變
單體式
單體架構即所有系統功能和模組基於MVC的設計模式耦合在一個單體伺服器單元中。基於傳統的MVC思想,單體應用基於前後端分離的原則,通過Model、Control和View共同來完成一個特點的服務請求。這種傳統的架構模式帶了了多人團隊合作、程式碼更新和維護、持續部署方面的困難,更重要的是,這種架構無法支援網際網路行業對高併發的需求。下圖為一個典型商城應用的單體架構及其SSM實現架構:
關於單體式應用的更多資料,可參看:
叢集
至少在高併發的需求上,單體應用的缺陷是行業所無法忍受的, 那如何提升併發效能呢?一個直接的思路是,把單體應用變成多體,變成叢集,通過負載均衡分發服務請求到不同的應用伺服器中。這也是早期淘寶的解決思路。下面是叢集的架構草圖:
雖然叢集的架構有效解決了高併發的問題,但是卻帶來了難度極大的維護和可用性問題。另外在功能上,哪怕是解決使用者單點登入,都需要通過Session廣播的方式進行,消耗了資源和寬頻。雖然叢集面向高併發而生,但是如果要達到上萬的併發級別,即便是強力增加節點數量,效能也不會提升很大,有其瓶頸。
分散式
上面的叢集,相當於把一份工程程式碼部署到多臺伺服器中,每臺伺服器獨立部署執行;而分散式的思想是,把系統按照模組劃分為多個子系統,多個子系統之間需要進行通訊,來共同完成業務流程。分散式的架構如下圖所示:
分散式的架構具有很多優勢:
- 把模組拆分,使用介面通訊,降低模組之間的耦合度。
- 把專案拆分成若干個子專案,不同的團隊負責不同的子專案。
- 增加功能時只需要再增加一個子專案,呼叫其他系統的介面就可以。
- 可以靈活的進行分散式部署。
但是,分散式介面通訊的開發,帶來了相應的開發壓力,提高了團隊的學習成本。
基於SOA的架構
SOA:Service Oriented Architecture面向服務的架構。也就是把工程都拆分成服務層工程、表現層工程。服務層中包含業務邏輯,只需要對外提供服務即可。表現層只需要處理和頁面的互動,業務邏輯都是呼叫服務層的服務來實現。工程都可以獨立部署。
核心模組和中介軟體詳解
SOA架構為高併發而生,需要解決高併發下不同服務之間的通訊問題。在實踐中,SOA架構需要配合多種中介軟體技術,包括快取服務、資料庫中介軟體、服務釋出和訂閱、訊息佇列等等。以下為一個典型的SOA商城架構簡圖:
一、系統間通訊
一般來說,基於SOA的架構,它的表現層和服務層是不同的工程。所以要實現一個服務流程需要兩個系統之間進行通訊。那麼如何實現遠端通訊?常用的方式包括: 1、使用WebService:效率不高,它是基於SOAP協議(http+xml)。專案中不推薦使用。 2、使用Restful形式的服務:http+json。很多專案中應用。如果服務越來越多,服務與服務之間的呼叫關係複雜,呼叫服務的URL管理複雜,什麼時候新增機器難以確定。 3、使用Dubbo。使用rpc協議進行遠端呼叫,直接使用socket通訊。傳輸效率高,並且可以統計出系統之間的呼叫關係、呼叫次數,管理服務。 Dubbo DUBBO是一個分散式服務框架,致力於提供高效能和透明化的RPC遠端服務呼叫方案,是阿里巴巴SOA服務化治理方案的核心框架,每天為2,000+個服務提供3,000,000,000+次訪問量支援,並被廣泛應用於阿里巴巴集團的各成員站點。Dubbo元件的架構和工作機制如下圖所示:Zookeeper
註冊中心負責服務地址的註冊與查詢,相當於目錄服務,服務提供者和消費者只在啟動時與註冊中心互動,註冊中心不轉發請求,壓力較小。使用dubbo-2.3.3以上版本,建議使用zookeeper作為註冊中心。 Zookeeper是Apacahe Hadoop的子專案,是一個樹型的目錄服務,支援變更推送,適合作為Dubbo服務的註冊中心,工業強度較高(穩定性好),可用於生產環境,並推薦使用。二、分散式檔案伺服器
在分散式應用中,無法通過傳統手段解決檔案上傳和下載問題。因此,對於檔案上傳,業務系統節點可以把檔案集中到分散式檔案伺服器做統一管理,而使用者訪問,也可以通過分散式檔案伺服器提供快速的檔案下載支援。
FastDFS
FastDFS是用c語言編寫的一款開源的分散式檔案系統。FastDFS為網際網路量身定製,充分考慮了冗餘備份(高可用)、負載均衡(高併發量)、線性擴容(新增伺服器或者磁碟)等機制,並注重高可用、高效能等指標,使用FastDFS很容易搭建一套高效能的檔案伺服器叢集提供檔案上傳、下載等服務。 FastDFS架構包括 Tracker server和Storage server。客戶端請求Tracker server進行檔案上傳、下載,通過Tracker server排程最終由Storage server完成檔案上傳和下載。- Tracker server作用是負載均衡和排程,通過Tracker server在檔案上傳時可以根據一些策略找到Storage server提供檔案上傳服務。可以將tracker稱為追蹤伺服器或排程伺服器。
- Storage server作用是檔案儲存,客戶端上傳的檔案最終儲存在Storage伺服器上,Storage server沒有實現自己的檔案系統而是利用作業系統 的檔案系統來管理檔案。可以將storage稱為儲存伺服器。
FastDFS架構和工作機制如下圖所示:
三、負載均衡
以一個SOA商城系統為例,它的首頁是系統的門戶,也就是系統的入口。所以首頁的訪問量是這個系統最大的。如果每次展示首頁都從資料庫中查詢首頁的內容資訊,那麼勢必會對資料庫造成很大的壓力,所以需要使用快取來減輕資料庫壓力。實現快取的工具有很多,現在比較流行的是Redis。 Redis是用C語言開發的一個開源的高效能鍵值對(key-value)資料庫(nosql),應用在快取、任務佇列等場景較多。四、搜尋功能
Solr
SolrCloud(solr 雲)是Solr提供的分散式搜尋方案,當你需要大規模,容錯,分散式索引和檢索能力時使用 SolrCloud。當索引量很大,搜尋請求併發很高,這時需要使用SolrCloud來滿足這些需求。 SolrCloud是基於Solr和Zookeeper的分散式搜尋方案,它的主要思想是使用Zookeeper作為叢集的配置資訊中心。Solr叢集架構圖如下: Zookeeper它有幾個特色功能:- 集中式的配置資訊(資料庫連線池的配置檔案,修改檔案不用重啟就可以生效)
- 自動容錯
- 近實時搜尋
- 查詢時自動負載均衡
五、訊息佇列
MQ
MQ是一個訊息中介軟體,比如:ActiveMQ、RabbitMQ、kafka都屬於MQ,是MQ的產品。一般可以考慮使用Apache開源的訊息佇列ActiveMQ。ActiveMQ的訊息形式
對於訊息的傳遞有兩種型別:- 一種是點對點的,即一個生產者和一個消費者一一對應;
- 另一種是釋出/訂閱模式,即一個生產者產生訊息並進行傳送後,可以由多個消費者進行接收。
- http伺服器。Nginx是一個http服務可以獨立提供http服務。可以做網頁靜態伺服器。
- 虛擬主機。可以實現在一臺伺服器虛擬出多個網站。例如個人網站使用的虛擬主機。
- 反向代理,負載均衡。當網站的訪問量達到一定程度後,單臺伺服器不能滿足使用者的請求時,需要用多臺伺服器叢集可以使用nginx做反向代理。並且多臺伺服器可以平均分擔負載,不會因為某臺伺服器負載高宕機而某臺伺服器閒置的情況。