SpringCloud架構設計

2021-08-31 07:25:14 字數 2445 閱讀 8542

最近一直在針對springcloud框架做專案,從中踩了不少的坑,也漸漸梳理出了一些內容,由於springcloud作為乙個全家桶,其中東西太多,所以這時候就要有所取捨,這裡就想把自己比較常用元件及架構推薦上來。本文基於springboot 1.5.7和spirngcloud  dalston.sr5。

針對這個架構圖我分層介紹一下:

1、是web伺服器的選型,這個我選擇的是nginx+keepalived,haproxy也是乙個選擇,但是haproxy在反向**處理跨域訪問的時候問題很多。所以我們nginx有些地方做了keep-alive模式處理,減少了三次握手的次數,提高了連線效率。keepalived做nginx的負載,虛擬乙個vip對外,兩個nginx做高可用,nginx本身反向**zuul集群。

2、api gateway,這裡的zuul很多人詬病,說是速度慢推薦直接用nginx,這裡我還是推薦使用zuul的,畢竟zuul含有***和反向**,在許可權管理、單點登入、使用者認證時候還是很有用的,而且zuul自帶ribbon負載均衡,如果你直接用nginx,還需要單獨做乙個feign或者ribbon層,用來做業務集群的負載層,畢竟直接把介面暴露給web伺服器太危險了。這裡zuul帶有ribbon負載均衡和hystrix斷路器,直接反向**serviceid就可以**整個集群了。

3、業務集群,這一層我有些專案是分兩層的,就是上面加了乙個負載層,下面是從service開始的,底層只是單純的介面,controller是單獨一層由feign實現,然後內部不同業務服務介面互調,直接呼叫controller層,只能說效果一般,多了一次tcp連線。所以我推薦合併起來,因為做過spring cloud專案的都知道,feign是含有ribbon的,而zuul也含有ribbon,這樣的話zuul呼叫服務集群,和服務集群間介面的互調都是高可用的,保證了通訊的穩定性。hystrix還是要有的,沒有斷路器很難實現服務降級,會出現大量請求傳送到不可用的節點。當然service是可以改造的,如果改造成rpc方式,那服務之間互調又是另外一種情況了,那就要做成負載池和介面服務池的形式了,負載池呼叫介面池,介面池互相rpc呼叫,feign client只是通過實現介面達到了仿rpc的形式,不過速度表現還是不錯的。

4、redis快取池,這個用來做session共享,分布式系統session共享是乙個大問題。同時呢,redis做二級快取對降低整個服務的響應時間,並且減少資料庫的訪問次數是很有幫助的。當然redis cluster還是redis sentinel自己選擇。

5、eurake註冊中心這個高可用集群,這裡有很多細節,比如多久重新整理列表一次,多久監測心跳什麼的,都很重要。

6、spring admin,這個是很推薦的,這個功能很強大,可以整合turbine斷路器監控器,而且可以定義所有類的log等級,不用單獨去配置,還可以檢視本地log日誌檔案,監控不同服務的機器引數及效能,非常強大。它加上elk動態日誌收集系統,對於專案運維非常方便。

7、zipkin,這個有兩種方式,直接用它自己的功能介面檢視方式,或者用stream流的方式,由elk動態日誌系統收集。但是我必須要說,這個對系統的效能損害非常大,因為鏈路追蹤的時候會造成響應等待,而且等待時間非常長接近1秒,這在生產環境是不能忍受的,所以生產環境最好關掉,有問題除錯的時候再開啟。

8、訊息佇列,這個必須的,分布式系統不可能所有場景都滿足強一致性,這裡只能由訊息佇列來作為緩衝,這裡我用的是kafka。

9、分布式事物,我認為這是分布式最困難的,因為不同的業務集群都對應自己的資料庫,互相資料庫不是互通的,互相服務呼叫只能是相互介面,有些甚至是異地的,這樣造成的結果就是網路延遲造成的請求等待,網路抖動造成的資料丟失,這些都是很可怕的問題,所以必須要處理分布式事物。我推薦的是利用訊息佇列,採取二階段提交協議配合事物補償機制,具體的實現需要結合業務,這裡篇幅有限就不展開說了。

10、config配置中心,這是很有必要的,因為服務太多配置檔案太多,沒有這個很難運維。這個一般利用訊息佇列建立乙個spring cloud bus,由git儲存配置檔案,利用bus匯流排動態更新配置檔案資訊。

11、實時分布式日誌系統,logstash收集本地的log檔案流,傳輸給elasticsearch,logstash有兩種方式,1、是每一台機器啟動乙個logstash服務,讀取本地的日誌檔案,生成流傳給elasticsearch。2、logback引入logstash包,然後直接生產json流傳給乙個中心的logstash伺服器,它再傳給elasticsearch。elasticsearch再將流傳給kibana,動態檢視日誌,甚至zipkin的流也可以直接傳給elasticsearch。這個配合spring admin,乙個檢視動態日誌,乙個檢視本地日誌,同時還能遠端管理不同類的日誌級別,對整合和運維非常有利。

最後要說說,spring cloud的很多東西都比較精確,比如斷路器觸發時間、事物補償時間、http響應時間等,這些都需要好好的設計,而且可以優化的點非常多。比如:http通訊可以使用okhttp,jvm優化,nio模式,資料連線池等等,都可以很大的提高效能。

SpringCloud架構設計

最近一直在針對springcloud框架做專案,從中踩了不少的坑,也漸漸梳理出了一些內容,由於springcloud作為乙個全家桶,其中東西太多,所以這時候就要有所取捨,這裡就想把自己比較常用元件及架構推薦上來。本文基於springboot 1.5.7和spirngcloud dalston.sr5...

Spring Cloud 2 軟體架構設計

分層架構是運用最為廣泛的架構模式,幾乎每個軟體系統都需要經過層來隔離不同的關注點,以此應對不同需求的變化,使得這種變化可以獨立進行 各個層 甚至同一層中的各個元件都會以不同速率發生變化。這裡所謂的 以不同速率發生變化 其實就是引起變化的原因各有不同,這正好是單一職責原則 single respons...

salesforce 架構設計 從架構設計到架構師

因為碎片化的時間多了,所以開始刷起某乎了,關注了架構相關的板塊,也順手回答了一些問題。發現有很多同道中人正在經歷著我前兩年經歷的階段,對於做架構沒有相對具象的一些理解,更沒有系統化的認識。所以把最近回答的一些內容整理一下,權當記錄,留給3年後的自己 按慣例,容許我裝x開頭 一 架構的定義 在軟體開發...