天天看點

微服務SpringCloudAlibaba——簡介(1)前言單體架構微服務微服務整體結構springcloud技術站

微服務SpringCloudAlibaba——簡介(1)

微服務SpringClout Alibaba——Nacos注冊中心、配置中心和Nacos叢集(2)

微服務SpringClout Alibaba——Sentinel流控、熔斷、降級(3)

微服務SpringClout Alibaba——Seata分布式事務(4)

微服務SpringCloud——GateWay網關(5)

目錄

前言

單體架構

什麼是單體架構

單體架構存在的問題

微服務

微服務最初是由Martin Fowler提出來的他的了解如下:

微服務的優勢:

微服務宇SOA的關系

微服務整體結構

springcloud技術站

前言

版本說明和選擇:https://github.com/alibaba/spring-cloud-alibaba/wiki/%E7%89%88%E6%9C%AC%E8%AF%B4%E6%98%8E

說到微服務,首先我們先談談架構的變遷

單體架構

什麼是單體架構

在軟體設計的時候經常提到和使用經典的3層模型,即表現層,業務邏輯層,資料通路層。雖然在軟體設計中劃分了3層模型,但是對業務場景沒有劃分,一個典型的單體架構就是将所有的業務場景的表現層,業務邏輯層,資料通路層放在一個工程中最終經過編譯,打包,部署在一台伺服器上。此時服務架構如圖:

微服務SpringCloudAlibaba——簡介(1)前言單體架構微服務微服務整體結構springcloud技術站

單體架構存在的問題

在小型應用的初期,通路量小的時候這種架構的成本效益還是比較高的,開發速度快,成本低,但是随着業務的發展,邏輯越來越複雜,代碼量越來越大,代碼得可讀性和可維護性越來越低。使用者的增加,通路量越來越多單體架構的應用并發能力十分有限。

可能會有人想到将單體應用進行叢集部署,并增加負載均衡伺服器,再來個緩存伺服器和檔案伺服器,資料庫再搞個讀寫分離。這種架構如圖:

微服務SpringCloudAlibaba——簡介(1)前言單體架構微服務微服務整體結構springcloud技術站

這種架構雖然有一定的并發能力,及應對一定複雜業務,但是依然沒有改變系統為單體架構的事實。大量的業務必然會有大量的代碼,代碼得可讀性和可維護性依然很差。如果面對海量的使用者,它的并發能力依然不夠。基于以上單體架構系統的不足,微服務架構就應運而生。

微服務

微服務最初是由Martin Fowler提出來的他的了解如下:

微服務架構就是将單一程式開發成一個微服務,每個微服務運作在自己的程序中,并使用輕量級的機制通信,通常是HTTP RESTFUL API。這些服務圍繞業務能力來劃分,并通過自動化部署機制來獨立部署。這些服務可以使用不同的程式設計語言,不同資料庫,以保證最低限度的集中式管理。

總的來說:

總結起來微服務就是将一個單體架構的應用按業務劃分為一個個的獨立運作的程式即服務,它們之間通過HTTP協定進行通信(也可以采用消息隊列來通信,如RoocketMQ,Kafaka等),可以采用不同的程式設計語言,使用不同的存儲技術,自動化部署(如Jenkins)減少人為控制,降低出錯機率。服務數量越多,管理起來越複雜,是以采用集中化管理。例如Eureka,Zookeeper等都是比較常見的服務集中化管理架構。

微服務的優勢:

将複雜的業務拆分成多個小的業務,每個業務拆分成一個服務,将複雜的問題簡單化。利于分工,降低新人的學習成本。

微服務系統是分布式系統,業務與業務之間完全解耦,随着業務的增加可以根據業務再拆分,具有極強的橫向擴充能力。面對搞并發的場景可以将服務叢集化部署,加強系統負載能力。

服務間采用HTTP協定通信,服務與服務之間完全獨立。每個服務可以根據業務場景選取合适的程式設計語言和資料庫。

微服務每個服務都是獨立部署的,每個服務的修改和部署對其他服務沒有影響。

微服務宇SOA的關系

SOA即面向服務的架構,SOA是根據企業服務總線(ESB)模式來整合內建大量單一龐大的系統,微服務可以說是SOA的一種實作,将複雜的業務元件化。但它比ESB實作的SOA更加的輕便靈活和簡單。

微服務整體結構

一個完整的微服務項目結構如下:

微服務SpringCloudAlibaba——簡介(1)前言單體架構微服務微服務整體結構springcloud技術站

springcloud技術站

微服務SpringCloudAlibaba——簡介(1)前言單體架構微服務微服務整體結構springcloud技術站

服務注冊中心:

Eureka:官方停止更新,并且已經有更好的替代産品了,可以使用,但是官方已經不建議使用了。

Zookeeper:某些老系統,以前是用的Zookeeper + Dubbo,後來做技術更新,結果發現SpringCloud的Eureka停更了,然後就用了最少的技術切換,那麼就用了Zookeeper做注冊中心。

Consul:go語言開發的,也是一個優秀的服務注冊架構,但是使用量較少,風頭都被Nacos搶了。

Nacos:來自于SpringCloudAlibaba,在企業中經過了百萬級注冊考驗的,不但可以完美替換Eureka,還能做其他元件的替換,是以強烈建議使用,是學習的重點。

服務調用:

Ribbon:也進入了維護狀态,停止更新了,但是Spring官方還在使用。

LoadBalancer:Spring官方推出的一個新的元件,打算逐漸取代掉Ribbon,但是現在還處于萌芽狀态。

服務調用2:

Feign:Netflix 公司産品,已經停止更新了。

OpenFeign:Spring社群等不了Netflix更新了,然後就自己做了一個元件,不用Feign了。

服務降級:

Hystrix:官網不推薦使用,但是中國企業中還在大規模使用。

Resilience4J:官網推薦使用,但是國内很少用這個。

Sentienl:來自于SpringCloudAlibaba,在中國企業替換Hystrix的元件,國内強烈建議使用。

服務網關:

Zuul:Netflix 公司産品,公司内部産生分歧,有的人想自己出一個Zuul2。

Zuul2:也是Netflix 公司準備出的産品,但是由于内部分歧,是以Zuul2已經胎死腹中了。

gateway:Spring社群自己出的網關元件,官方隆重介紹和極度推薦的網關服務元件。

服務配置:

Config:目前也在使用,風頭被Nacos搶了。

Nacos:來自于SpringCloudAlibaba,後來居上,把Config給替換了。

服務總線:

Bus:SpringCloud原生的服務總線元件,現在風頭也被Nacos搶了。

Nacos:來自于SpringCloudAlibaba,後來居上,把Bus給替換了。