天天看點

基于SOA的高并發和高可用分布式系統架構群組件詳解

基于SOA的分布式高可用架構和微服務架構,是時下如日中天的網際網路企業級系統開發架構選擇方案。在核心思想上,兩者都主張對系統的橫向細分和擴充,按不同的業務功能子產品來對系統進行分割并且使用一定的手段實作服務之間的通信,并且基于彈性雲服務搭建高可用的分布式解決方案。

但它們之間的差別可能比相似的地方要多,特别是展現在對服務的使用和與雲服務的深度結合上。在具體實踐中,微服務的架構也可以與其它網際網路中間件組合在一起,組成規模更為龐大的SOA分布式系統。本文主要對一個典型的SOA分布式應用的架構群組件做詳細的說明。

企業級系統架構的演變

單體式

單體架構即所有系統功能和子產品基于MVC的設計模式耦合在一個單體伺服器單元中。基于傳統的MVC思想,單體應用基于前後端分離的原則,通過Model、Control和View共同來完成一個特點的服務請求。這種傳統的架構模式帶了了多人團隊合作、代碼更新和維護、持續部署方面的困難,更重要的是,這種架構無法支援網際網路行業對高并發的需求。下圖為一個典型商城應用的單體架構及其SSM實作架構:

基于SOA的高并發和高可用分布式系統架構群組件詳解
基于SOA的高并發和高可用分布式系統架構群組件詳解
關于單體式應用的更多資料,可參看: JavaWeb開發之詳解Servlet及Servlet容器 基于SSM的Java Web應用開發原理初探

叢集

至少在高并發的需求上,單體應用的缺陷是行業所無法忍受的, 那如何提升并發性能呢?一個直接的思路是,把單體應用變成多體,變成叢集,通過負載均衡分發服務請求到不同的應用伺服器中。這也是早期淘寶的解決思路。下面是叢集的架構草圖:

基于SOA的高并發和高可用分布式系統架構群組件詳解

雖然叢集的架構有效解決了高并發的問題,但是卻帶來了難度極大的維護和可用性問題。另外在功能上,哪怕是解決使用者單點登入,都需要通過Session廣播的方式進行,消耗了資源和寬帶。雖然叢集面向高并發而生,但是如果要達到上萬的并發級别,即便是強力增加節點數量,性能也不會提升很大,有其瓶頸。

分布式

上面的叢集,相當于把一份工程代碼部署到多台伺服器中,每台伺服器獨立部署運作;而分布式的思想是,把系統按照子產品劃分為多個子系統,多個子系統之間需要進行通信,來共同完成業務流程。分布式的架構如下圖所示: 

基于SOA的高并發和高可用分布式系統架構群組件詳解
分布式的架構具有很多優勢:

  1. 把子產品拆分,使用接口通信,降低子產品之間的耦合度。
  2. 把項目拆分成若幹個子項目,不同的團隊負責不同的子項目。
  3. 增加功能時隻需要再增加一個子項目,調用其他系統的接口就可以。
  4. 可以靈活的進行分布式部署。

但是,分布式接口通信的開發,帶來了相應的開發壓力,提高了團隊的學習成本。 

基于SOA的架構

SOA:Service Oriented Architecture面向服務的架構。也就是把工程都拆分成服務層工程、表現層工程。服務層中包含業務邏輯,隻需要對外提供服務即可。表現層隻需要處理和頁面的互動,業務邏輯都是調用服務層的服務來實作。工程都可以獨立部署。 

基于SOA的高并發和高可用分布式系統架構群組件詳解

在一個典型的SOA架構中,加入了大量的中間件和子系統,用于解決分布式架構中的服務通信及衍生問題,具體包括服務間通信、負載均衡、反向代理、資訊中心、檔案管理、主從備份等等。

核心子產品和中間件詳解

SOA架構為高并發而生,需要解決高并發下不同服務之間的通信問題。在實踐中,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元件的架構和工作機制如下圖所示:

基于SOA的高并發和高可用分布式系統架構群組件詳解
基于SOA的高并發和高可用分布式系統架構群組件詳解

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的高并發和高可用分布式系統架構群組件詳解
基于SOA的高并發和高可用分布式系統架構群組件詳解

三、負載均衡

以一個SOA商城系統為例,它的首頁是系統的門戶,也就是系統的入口。是以首頁的通路量是這個系統最大的。如果每次展示首頁都從資料庫中查詢首頁的内容資訊,那麼勢必會對資料庫造成很大的壓力,是以需要使用緩存來減輕資料庫壓力。實作緩存的工具有很多,現在比較流行的是Redis。

Redis是用C語言開發的一個開源的高性能鍵值對(key-value)資料庫(nosql),應用在緩存、任務隊列等場景較多。

四、搜尋功能

Solr

SolrCloud(solr 雲)是Solr提供的分布式搜尋方案,當你需要大規模,容錯,分布式索引和檢索能力時使用 SolrCloud。當索引量很大,搜尋請求并發很高,這時需要使用SolrCloud來滿足這些需求。

SolrCloud是基于Solr和Zookeeper的分布式搜尋方案,它的主要思想是使用Zookeeper作為叢集的配置資訊中心。Solr叢集架構圖如下:

基于SOA的高并發和高可用分布式系統架構群組件詳解

Zookeeper它有幾個特色功能:

  • 集中式的配置資訊(資料庫連接配接池的配置檔案,修改檔案不用重新開機就可以生效)
  • 自動容錯
  • 近實時搜尋
  • 查詢時自動負載均衡

五、消息隊列

MQ

MQ是一個消息中間件,比如:ActiveMQ、RabbitMQ、kafka都屬于MQ,是MQ的産品。一般可以考慮使用Apache開源的消息隊列ActiveMQ。

ActiveMQ的消息形式 

對于消息的傳遞有兩種類型:

  1. 一種是點對點的,即一個生産者和一個消費者一一對應;
  2. 另一種是釋出/訂閱模式,即一個生産者産生消息并進行發送後,可以由多個消費者進行接收。

JMS定義了五種不同的消息正文格式,以及調用的消息類型,允許你發送并接收以一些不同形式的資料,提供現有消息格式的一些級别的相容性。

六、反向代理

Nginx

Nginx是一款高性能的http 伺服器/反向代理伺服器及電子郵件(IMAP/POP3)代理伺服器。由俄羅斯的程式設計師Igor Sysoev用c語言所開發,官方測試nginx能夠支支撐5萬并發連結,并且cpu、記憶體等資源消耗卻非常低,運作非常穩定,而且開源。Nginx的應用場景包括:

  1. http伺服器。Nginx是一個http服務可以獨立提供http服務。可以做網頁靜态伺服器。
  2. 虛拟主機。可以實作在一台伺服器虛拟出多個網站。例如個人網站使用的虛拟主機。
  3. 反向代理,負載均衡。當網站的通路量達到一定程度後,單台伺服器不能滿足使用者的請求時,需要用多台伺服器叢集可以使用nginx做反向代理。并且多台伺服器可以平均分擔負載,不會因為某台伺服器負載高當機而某台伺服器閑置的情況。

七、主從備份

Keepalived

keepalived是以VRRP協定為實作基礎的,VRRP全稱Virtual Router Redundancy Protocol,即虛拟路由備援協定。

虛拟路由備援協定,可以認為是實作路由器高可用的協定,即将N台提供相同功能的路由器組成一個路由器組,這個組裡面有一個master和多個backup,master上面有一個對外提供服務的vip(VIP = Virtual IP Address,虛拟IP位址,該路由器所在區域網路内其他機器的預設路由為該vip),master會發多點傳播,當backup收不到VRRP包時就認為master宕掉了,這時就需要根據VRRP的優先級來選舉一個backup當master。這樣的話就可以保證路由器的高可用了。

keepalived主要有三個子產品,分别是core、check和VRRP。core子產品為keepalived的核心,負責主程序的啟動、維護以及全局配置檔案的加載和解析。check負責健康檢查,包括常見的各種檢查方式。VRRP子產品是來實作VRRP協定的。