分布式和集群 springcloud

什麼是單體架構系統？

所謂的單體架構就是所有功能，都放在乙個應用裡。

比如後面要講的乙個單體產品服務應用，提供資料和檢視都在乙個springboot裡。

單體架構系統有其好處，如便於開發，測試，部署也很方便，直接打成乙個 jar 或者 war, 就什麼都好了。

不過單體架構也有其弊端，最主要體現在高訪問，高併發的上限是固定的。比如乙個單體架構，能夠承受 1000次訪問/秒。但是訪問量達到 2000次/秒的時候，就會非常卡頓，嚴重影響業務，並且僅僅依靠單體架構本身，很難突破這個瓶頸了。

簡而言之，就是所有雞蛋放乙個籃子裡，要是多個人取雞蛋的話，就非常慢，還可能摔了籃子，打碎雞蛋。

什麼是分布式和集群？

既然單體架構會有效能上的瓶頸，那麼總要解決呀。解決辦法通常就是採用分布式和集群來做。

簡單來說，就是把雞蛋放到不同的籃子裡

要說springcloud 分布式之前，先引入微服務概念。

微服務簡單說，乙個 springboot 就是乙個微服務，並且這個 springboot 做的事情很單純。比如乙個專案中，有提供資料和查詢資料兩個功能，那麼就可以拆成兩個微服務，分別是資料微服務，和檢視微服務，其實就是倆 springboot, 只是各自做的事情都更單純~

那既然我們把專案拆分成了兩個微服務，也就是兩個spring boot 那我們如何管理這個微服務，以及這兩個微服務之間如何通訊的問題？

所以就要引入乙個微服務註冊中心概念，這個微服務註冊中心在 springcloud 裡就叫做 eureka server, 通過它就可以把微服務註冊起來，以供將來呼叫。

原來是在乙個 springboot裡就完成的事情，現在分布在多個 springboot裡做，這就是初步具備分布式雛形了。

在業務邏輯上，檢視微服務需要資料微服務的資料，所以就存在乙個微服務訪問另乙個微服務的需要。而這倆微服務已經被註冊中心管理起來了，所以檢視微服務就可以通過註冊中心定位並訪問資料微服務了。就相當於eureka是乙個排程中心，用來管理這兩個微服務之間的協調通訊。

那麼分布式有什麼好處呢？

1 . 如果我要更新資料微服務，檢視微服務是不受影響的

2 . 可以讓不同的團隊開發不同的微服務，他們之間只要約定好介面，彼此之間是低耦合的。

3 . 如果檢視微服務掛了，資料微服務依然可以繼續使用

什麼是集群？

原來資料微服務只有這乙個springboot, 現在做同樣資料微服務的，有兩個 springboot, 他們提供的功能一模一樣，只是埠不一樣，這樣就形成了集群。

集群的好處

1 . 比起乙個 springboot, 兩個springboot 可以分別部署在兩個不同的機器上，那麼理論上來說，能夠承受的負載就是 x 2. 這樣系統就具備通過橫向擴充套件而提高效能的機制。

2 . 如果 8001 掛了，還有 8002 繼續提供微服務，這就叫做高可用。

以上是很簡單的分布式結構，圍繞這個結構，我們有時候還需要做如下事情：

哪些微服務是如何彼此呼叫的？ sleuth 服務鏈路追蹤

如何在微服務間共享配置資訊？配置服務 config server

如何讓配置資訊在多個微服務之間自動重新整理？ rabbitmq 匯流排 bus

如果資料微服務集群都不能使用了，檢視微服務如何去處理? 斷路器 hystrix

檢視微服務的斷路器什麼時候開啟了？什麼時候關閉了？斷路器監控 hystrix dashboard

如果檢視微服務本身是個集群，那麼如何進行對他們進行聚合監控？斷路器聚合監控 turbine hystrix dashboard

如何不暴露微服務名稱，並提供服務？ zuul 閘道器

後續將會更新關於spring boot的其他內容

1.spring cloud-------註冊中心

2.springcloud----註冊資料微服務

3.springcloud-檢視微服務-ribbon

4.springcloud-檢視微服務-feign

*帥氣的遠遠啊*