springcloud相關知識

一、單體架構

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

此時服務架構圖

單體架構不足之處：

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

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

這種架構圖

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

二、微服務

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

微服務優勢和劣勢：

-優勢：

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

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

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

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

-劣勢

--随着服務數量增加，管理複雜，部署複雜，伺服器需要增多，服務通信和調用壓力增大，
	運維工程師壓力增大，人力資源增多，系統依賴增強，資料一緻性，性能監控
           

微服務和SOA的關系：

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

微服務之間如何獨立通訊？

-同步通信：dobbo通過 RPC 遠端過程調用、springcloud通過 REST 接口json調用 等。

-異步：消息隊列，如：RabbitMq、ActiveM、Kafka 等

SpringCloud 和 Dubbo 有哪些差別?

-共同：都是分布式管理架構

-不同：

–dubbo 是二進制傳輸，占用帶寬會少一點。

SpringCloud是http 傳輸，帶寬會多一點，同時使用http協定一般會使用JSON封包，消耗會更大

–dubbo 開發難度較大，所依賴的 jar 包有很多問題大型工程無法解決。

SpringCloud 對第三方的繼承可以一鍵式生成，天然內建

–SpringCloud 接口協定約定比較松散，需要強有力的行政措施來限制接口無序更新

–Spring Cloud抛棄了Dubbo 的RPC通信，采用的是基于HTTP的REST方式

—REST犧牲了服務調用的性能，但也避免了上面提到的原生RPC帶來的問題。

而且REST相比RPC更為靈活，服務提供方和調用方的依賴隻依靠一紙契約，不存在代碼級别的強依賴，這在強調快速演化的微服務環境下，顯得更為合适

三、微服務架構

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

微服務架構系統

-是一個分布式的系統，按業務進行劃分為獨立的服務單元，解決單體系統的不足，同時也滿足越來越複雜的業務需求

四、SpringBoot 和 SpringCloud 之間關系

-SpringBoot：專注于快速友善的開發單個個體微服務（關注微觀）；

-SpringCloud：關注全局的微服務協調治理架構，将SpringBoot開發的一個個單體微服務組合并管理起來（關注宏觀）；

-SpringBoot可以離開SpringCloud獨立使用，但是SpringCloud不可以離開SpringBoot，屬于依賴關系。

五、什麼是熔斷？什麼是服務降級？

-服務熔斷的作用類似于我們家用的保險絲，當某服務出現不可用或響應逾時的情況時，為了防止整個系統出現雪崩，暫時停止對該服務的調用

-服務降級是從整個系統的負荷情況出發和考慮的，對某些負荷會比較高的情況，為了預防某些功能（業務場景）出現負荷過載或者響應慢的情況，在其内部暫時舍棄對一些非核心的接口和資料的請求，而直接傳回一個提前準備好的fallback（退路）錯誤處理資訊。這樣，雖然提供的是一個有損的服務，但卻保證了整個系統的穩定性和可用性

六、eureka和zookeeper都可以提供服務注冊與發現的功能，但有差別

-zookeeper 是CP原則，強一緻性和分區容錯性。

-eureka 是AP 原則 可用性和分區容錯性。

C-Consistency,強一緻性
A-Available,可用性
P-Partition tolerance,分區容錯性
           

-在分布式中P是必須要有的，是以分布式有CP和AP兩種模式：

AP的就是可用性強，一緻性弱；CP就是一緻性強,可用性弱
           

-zookeeper當主節點故障時，zk會在剩餘節點重新選擇主節點，耗時過長，雖然最終能夠恢複，但是選取主節點期間會導緻服務不可用，這是不能容忍的。

-eureka各個節點是平等的，一個節點挂掉，其他節點仍會正常保證服務。

七、微服務技術棧總結