行業資訊
要討論微服務、集群、分布式,需要先講講“單機架構”,單機架構很常見,比如有一個很小的系統,不用處理很多東西,只需要一臺服務器,在上面搭建出自己需要的服務,就可以開始工作。這種架構優點顯而易見,方便維護,出了問題解決起來很方便。缺點也很明顯,如果處理變多,資源也就不夠用了。
單機架構無法滿足要求,集群架構就可以提供更好更快的處理,簡單來說,集群架構就是把單機架構上面運行的服務,摘出來,然后復制,在多個服務器上面進行部署,這樣可以提高工作效率。在集群中,每個服務器都稱為節點,每個節點提供不同的服務,比如Database、Web、日志工具。
國外服務器免費測試:http://www.bxgb88.com/
一、什么是微服務架構?
它是Martin Fowler在2014年首次提出的一個概念,「微服務是一種架構風格,可以說是一種處理問題的思想,通過這種思想可以將原來一個復雜的系統拆分成多個子系統,多個子系統之間是相互獨立的」,有自己獨立的進程,可以單獨部署,每個子系統(微服務)都只關注實現自己的業務功能,這樣子就解決了原來所有業務都存放在一個系統上,讓系統顯得很臃腫,并且難以抽離的問題。
下面開始介紹所謂的微服務。 微服務就是將一個完整的系統,按照業務功能,拆分成一個個獨立的子系統,在微服務結構中,每個子系統就被稱為“服務”。這些子系統能夠獨立運行在web容器中,它們之間通過RPC方式通信。
1、RPC通信是什么?
這里制作一個簡單介紹,想具體了解RPC的,請自行Google。RPC(Remote Procedure Call Procotol)遠程過程調用協議,通俗的解釋就是:客戶端在不知道調用細節的情況下,調用存在于遠程計算機上的某個對象,就像調用本地應用程序中的對象一樣。阿里巴巴的Dubbo框架,就是運用RPC協議比較好的框架
舉個例子,假設需要開發一個在線商城。按照微服務的思想,我們需要按照功能模塊拆分成多個獨立的服務,如:用戶服務、產品服務、訂單服務、后臺管理服務、數據分析服務等等。這一個個服務都是一個個獨立的項目,可以獨立運行。如果服務之間有依賴關系,那么通過RPC方式調用。
這樣的好處有很多:系統之間的耦合度大大降低,可以獨立開發、獨立部署、獨立測試,系統與系統之間的邊界非常明確,排錯也變得容易,開發效率大大提升。
系統之間的耦合度降低,從而系統更易于擴展。我們可以針對性地擴展某些服務。假設這個商城要搞一次大促,下單量可能會大大提升,因此我們可以針對性地提升訂單系統、產品系統的節點數量,而對于后臺管理系統、數據分析系統而言,節點數量維持原有水平即可。
服務的復用性更高。比如,當我們將用戶系統作為單獨的服務后,該公司所有的產品都可以使用該系統作為用戶系統,無需重復開發。
那么問題來了,當采用微服務結構后,一個完整的系統可能有很多獨立的子系統組成,當業務量漸漸發展起來之后,而這些子系統之間的關系將錯綜復雜,而且為了能夠針對性地增加某些服務的處理能力,某些服務的背后可能是一個集群模式,由多個節點構成,這無疑大大增加了運維的難度。微服務的想法好是好,但開發、運維的復雜度實在是太高。為了解決這些問題,阿里巴巴的Dubbo就橫空出世了。
2、Dubbo,Dubbo是一套微服務系統的協調者,在它這套體系中,一共有三種角色,分別是:服務提供者(下面簡稱提供者)、服務消費者(下面簡稱消費者)、注冊中心。
你在使用的時候需要將Dubbo的jar包引入到你的項目中,也就是每個服務都要引入Dubbo的jar包。然后當這些服務初始化的時候,Dubbo就會將當前系統需要發布的服務、以及當前系統的IP和端口號發送給注冊中心,注冊中心便會將其記錄下來。這就是服務發布的過程。與此同時,也是在系統初始化的時候,Dubbo還會掃描一下當前系統所需要引用的服務,然后向注冊中心請求這些服務所在的IP和端口號。接下來系統就可以正常運行了。當系統A需要調用系統B的服務的時候,A就會與B建立起一條RPC信道,然后再調用B系統上相應的服務。這,就是Dubbo的作用。
3、具體部署
當我們使用了微服務架構后,我們將一個原本完整的系統,按照業務邏輯拆分成一個個可獨立運行的子系統。為了降低系統間的耦合度,我們希望這些子系統能夠運行在獨立的環境中,這些環境之間能夠相互隔離。
在Docker出現之前,若使用虛擬機來實現運行環境的相互隔離的話成本較高,虛擬機會消耗較多的計算機硬件/軟件資源。Docker不僅能夠實現運行環境的隔離,而且能極大程度的節約計算機資源,它成為一種輕量級的“虛擬機”。
docker具體是什么或者怎么用,這里就不講解了,自行搜索吧。
當我們使用微服務架構后,隨著業務的逐漸發展,系統之間的依賴關系會日益復雜,而且各個模塊的構建順序都有所講究。對于一個小型系統來說,也許只有幾個模塊,那么你每次采用人肉構建的方式也許并不感覺麻煩。但隨著系統業務的發展,你的系統之間的依賴關系日益復雜,子系統也逐漸增多,每次構建一下你都要非常小心謹慎,稍有不慎整個服務都無法正常啟動。而且這些構建的工作很low,但卻需要消耗大量的精力,這無疑降低了開發的效率。不過沒關系,Jenkins就是來幫助你解決這個問題的。
我們只需在Jenkins中配置好代碼倉庫、各個模塊的構建順序和構建命令,在以后的構建中,只需要點擊“立即構建”按鈕,Jenkins就會自動到你的代碼倉庫中拉取最新的代碼,然后根據你事先配置的構建命令進行構建,最后發布到指定的容器中運行。你也可以讓Jenkins定時檢查代碼倉庫版本的變化,一旦發現變動就自動地開始構建過程,并且讓Jenkins在構建成功后給你發一封郵件。這樣你連“立即構建”的按鈕也不需要按,就能全自動地完成這一切構建過程。
二、什么是集群架構?
集群搭建出來后,有這樣一個角色,負責調度客戶端來的請求究竟要到哪一臺服務器上去,然后在進行接下來的工作流,這個角色叫做——“負載均衡器”
集群也分為高可用集群,負載均衡集群(可能高并發架構就是負載均衡架構的升級版)。
高可用集群工具常見的有:heartbeat,pacemaker,keepalived
負載均衡器工具常見的有:nginx,lvs,HAproxy
集群架構優點:可擴展性,服務器資源不夠用,就可以加一臺繼續進行工作
缺點:維護起來困難,trouble shoot的時候需要花費時間較多
三、微服務、集群、分布式三者的關系和區別:
1.微服務是將一個復雜系統根據業務或者其他方式拆分成具有不同功能的子系統的思想或者說架構風格,可以說是實現集群或者分布式的前提,畢竟,沒有系統的話集群和分布式也就沒有作用的對象了。
2.集群則是將按照微服務架構風格拆分出來的同一個業務系統部署到不同的服務器上,這樣一個系統就存在多份,保障了系統的高可用性。
3.分布式則是按照微服務架構風格拆分出來的不同業務的系統系統部署到不同的服務器上,可以對分布式上的每一個節點進行集群設置,實現高可用,它是一種工作的方式。
4.簡單說,分布式是以縮短單個任務的執行時間來提升效率的,如一個任務由5個小任務組成,處理完一個任務需要1個小時,那么使用一臺服務器的話則需要五個小時,如果使用五臺服務器則只需要一個小時,這種也是Hadpood中的一種Map/Reduce 分布式計算模型的工作模式。