基於SOA的高併發和高可用分佈式系統架構和組件詳解

基於SOA的分佈式高可用架構和微服務架構，是時下如日中天的互聯網企業級系統開發架構選擇方案。在覈心思想上，二者都主張對系統的橫向細分和擴展，按不一樣的業務功能模塊來對系統進行分割而且使用必定的手段實現服務之間的通訊，而且基於彈性雲服務搭建高可用的分佈式解決方案。

但它們之間的區別可能比類似的地方要多，特別是體如今對服務的使用和與雲服務的深度結合上。在具體實踐中，微服務的架構也能夠與其它互聯網中間件組合在一塊兒，組成規模更爲龐大的SOA分佈式系統。本文主要對一個典型的SOA分佈式應用的架構和組件作詳細的說明。

企業級系統架構的演變

單體式

單體架構即全部系統功能和模塊基於MVC的設計模式耦合在一個單體服務器單元中。基於傳統的MVC思想，單體應用基於先後端分離的原則，經過Model、Control和View共同來完成一個特色的服務請求。這種傳統的架構模式帶了了多人團隊合做、代碼更新和維護、持續部署方面的困難，更重要的是，這種架構沒法支持互聯網行業對高併發的需求。下圖爲一個典型商城應用的單體架構及其SSM實現架構：

 

關於單體式應用的更多資料，可參看：

JavaWeb開發之詳解Servlet及Servlet容器

基於SSM的Java Web應用開發原理初探

集羣

至少在高併發的需求上，單體應用的缺陷是行業所沒法忍受的， 那如何提高併發性能呢？一個直接的思路是，把單體應用變成多體，變成集羣，經過負載均衡分發服務請求到不一樣的應用服務器中。這也是早期淘寶的解決思路。下面是集羣的架構草圖：

雖然集羣的架構有效解決了高併發的問題，可是卻帶來了難度極大的維護和可用性問題。另外在功能上，哪怕是解決用戶單點登陸，都須要經過Session廣播的方式進行，消耗了資源和寬帶。雖然集羣面向高併發而生，可是若是要達到上萬的併發級別，即使是強力增長節點數量，性能也不會提高很大，有其瓶頸。

分佈式

上面的集羣，至關於把一份工程代碼部署到多臺服務器中，每臺服務器獨立部署運行；而分佈式的思想是，把系統按照模塊劃分爲多個子系統，多個子系統之間須要進行通訊，來共同完成業務流程。分佈式的架構以下圖所示： 

分佈式的架構具備不少優點：

1. 把模塊拆分，使用接口通訊，下降模塊之間的耦合度。
2. 把項目拆分紅若干個子項目，不一樣的團隊負責不一樣的子項目。
3. 增長功能時只須要再增長一個子項目，調用其餘系統的接口就能夠。
4. 能夠靈活的進行分佈式部署。

可是，分佈式接口通訊的開發，帶來了相應的開發壓力，提升了團隊的學習成本。 

基於SOA的架構

SOA：Service Oriented Architecture面向服務的架構。也就是把工程都拆分紅服務層工程、表現層工程。服務層中包含業務邏輯，只須要對外提供服務便可。表現層只須要處理和頁面的交互，業務邏輯都是調用服務層的服務來實現。工程均可以獨立部署。 

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

核心模塊和中間件詳解

SOA架構爲高併發而生，須要解決高併發下不一樣服務之間的通訊問題。在實踐中，SOA架構須要配合多種中間件技術，包括緩存服務、數據庫中間件、服務發佈和訂閱、消息隊列等等。如下爲一個典型的SOA商城架構簡圖：

1、系統間通訊

通常來講，基於SOA的架構，它的表現層和服務層是不一樣的工程。因此要實現一個服務流程須要兩個系統之間進行通訊。那麼如何實現遠程通訊？經常使用的方式包括：

一、使用WebService：效率不高，它是基於SOAP協議（http+xml）。項目中不推薦使用。

二、使用Restful形式的服務：http+json。不少項目中應用。若是服務愈來愈多，服務與服務之間的調用關係複雜，調用服務的URL管理複雜，何時添加機器難以肯定。

三、使用Dubbo。使用rpc協議進行遠程調用，直接使用socket通訊。傳輸效率高，而且能夠統計出系統之間的調用關係、調用次數，管理服務。

Dubbo

DUBBO是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，是阿里巴巴SOA服務化治理方案的核心框架，天天爲2,000+個服務提供3,000,000,000+次訪問量支持，並被普遍應用於阿里巴巴集團的各成員站點。Dubbo組件的架構和工做機制以下圖所示：

Zookeeper

註冊中心負責服務地址的註冊與查找，至關於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小。使用dubbo-2.3.3以上版本，建議使用zookeeper做爲註冊中心。

Zookeeper是Apacahe Hadoop的子項目，是一個樹型的目錄服務，支持變動推送，適合做爲Dubbo服務的註冊中心，工業強度較高(穩定性好)，可用於生產環境，並推薦使用。

2、分佈式文件服務器

在分佈式應用中，沒法經過傳統手段解決文件上傳和下載問題。所以，對於文件上傳，業務系統節點能夠把文件集中到分佈式文件服務器作統一管理，而用戶訪問，也能夠經過分佈式文件服務器提供快速的文件下載支持。

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架構和工做機制以下圖所示：

3、負載均衡

以一個SOA商城系統爲例，它的首頁是系統的門戶，也就是系統的入口。因此首頁的訪問量是這個系統最大的。若是每次展現首頁都從數據庫中查詢首頁的內容信息，那麼勢必會對數據庫形成很大的壓力，因此須要使用緩存來減輕數據庫壓力。實現緩存的工具備不少，如今比較流行的是Redis。

Redis是用C語言開發的一個開源的高性能鍵值對（key-value）數據庫（nosql），應用在緩存、任務隊列等場景較多。

4、搜索功能

Solr

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

SolrCloud是基於Solr和Zookeeper的分佈式搜索方案，它的主要思想是使用Zookeeper做爲集羣的配置信息中心。Solr集羣架構圖以下：

Zookeeper它有幾個特點功能：

• 集中式的配置信息(數據庫鏈接池的配置文件，修改文件不用重啓就能夠生效)
• 自動容錯
• 近實時搜索
• 查詢時自動負載均衡

5、消息隊列

MQ

MQ是一個消息中間件，好比：ActiveMQ、RabbitMQ、kafka都屬於MQ,是MQ的產品。通常能夠考慮使用Apache開源的消息隊列ActiveMQ。

ActiveMQ的消息形式 

對於消息的傳遞有兩種類型：

1. 一種是點對點的，即一個生產者和一個消費者一一對應；
2. 另外一種是發佈/訂閱模式，即一個生產者產生消息並進行發送後，能夠由多個消費者進行接收。

JMS定義了五種不一樣的消息正文格式，以及調用的消息類型，容許你發送並接收以一些不一樣形式的數據，提供現有消息格式的一些級別的兼容性。

6、反向代理

Nginx

Nginx是一款高性能的http 服務器/反向代理服務器及電子郵件（IMAP/POP3）代理服務器。由俄羅斯的程序設計師Igor Sysoev用c語言所開發，官方測試nginx可以支支撐5萬併發連接，而且cpu、內存等資源消耗卻很是低，運行很是穩定，並且開源。Nginx的應用場景包括：

1. http服務器。Nginx是一個http服務能夠獨立提供http服務。能夠作網頁靜態服務器。
2. 虛擬主機。能夠實如今一臺服務器虛擬出多個網站。例如我的網站使用的虛擬主機。
3. 反向代理，負載均衡。當網站的訪問量達到必定程度後，單臺服務器不能知足用戶的請求時，須要用多臺服務器集羣可使用nginx作反向代理。而且多臺服務器能夠平均分擔負載，不會由於某臺服務器負載高宕機而某臺服務器閒置的狀況。

7、主從備份

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協議的。