Spring Cloud架構(gòu)的各個組件的原理分析

降低耦合：每一個微服務(wù)專注于單一功能，并通過定義良好的接口清晰表述服務(wù)邊界。由于體積小、復(fù)雜度低，每個微服務(wù)可由一個小規(guī)模開發(fā)團隊完全掌控，易于保持高可維護性和開發(fā)效率。

獨立部署：由于微服務(wù)具備獨立的運行進程，所以每個微服務(wù)也可以獨立部署。當(dāng)某個微服務(wù)發(fā)生變更時無需編譯、部署整個應(yīng)用。由微服務(wù)組成的應(yīng)用相當(dāng)于具備一系列可并行的發(fā)布流程，使得發(fā)布更加高效，同時降低對生產(chǎn)環(huán)境所造成的風(fēng)險，最終縮短應(yīng)用交付周期。

選型靈活：微服務(wù)架構(gòu)下，技術(shù)選型是去中心化的。每個團隊可以根據(jù)自身服務(wù)的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術(shù)棧。由于每個微服務(wù)相對簡單，故需要對技術(shù)棧進行升級時所面臨的風(fēng)險就較低，甚至完全重構(gòu)一個微服務(wù)也是可行的。

容錯機制：當(dāng)某一組建發(fā)生故障時，在單一進程的傳統(tǒng)架構(gòu)下，故障很有可能在進程內(nèi)擴散，形成應(yīng)用全局性的不可用。在微服務(wù)架構(gòu)下，故障會被隔離在單個服務(wù)中。若設(shè)計良好，其他服務(wù)可通過重試、平穩(wěn)退化等機制實現(xiàn)應(yīng)用層面的容錯。

靈活擴展：單塊架構(gòu)應(yīng)用也可以實現(xiàn)橫向擴展，就是將整個應(yīng)用完整的復(fù)制到不同的節(jié)點。當(dāng)應(yīng)用的不同組件在擴展需求上存在差異時，微服務(wù)架構(gòu)便體現(xiàn)出其靈活性，因為每個服務(wù)可以根據(jù)實際需求獨立進行擴展。

背景分析：Dubbo，是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于中國各互聯(lián)網(wǎng)公司；Spring Cloud是知名的Spring家族的產(chǎn)品。阿里巴巴是一個商業(yè)公司，雖然也開源了很多的頂級的項目，但從整體戰(zhàn)略上來講，仍然是服務(wù)于自身的業(yè)務(wù)為主。Spring專注于企業(yè)級開源框架的研發(fā)，不論是在中國還是在世界上使用都非常廣泛，開發(fā)出通用、開源、穩(wěn)健的開源框架就是他們的主業(yè)。

活躍度對比：Dubbo是一個非常優(yōu)秀的服務(wù)治理框架，并且在服務(wù)治理、灰度發(fā)布、流量分發(fā)這方面做的比Spring Cloud還好，除過當(dāng)當(dāng)網(wǎng)在基礎(chǔ)上增加了rest支持外，已有兩年多的時間幾乎都沒有任何更新了。在使用過程中出現(xiàn)問題，提交到GitHub的Issue也少有回復(fù)。相反Spring Cloud自從發(fā)展到現(xiàn)在，仍然在不斷的高速發(fā)展，從GitHub上提交代碼的頻度和發(fā)布版本的時間間隔就可以看出，現(xiàn)在Spring Cloud即將發(fā)布2.0版本，到了后期會更加完善和穩(wěn)定。

平臺架構(gòu)：Dubbo框架只是專注于服務(wù)之間的治理，如果我們需要使用配置中心、分布式跟蹤這些內(nèi)容都需要自己去集成，這樣無形中使用Dubbo的難度就會增加。Spring Cloud幾乎考慮了服務(wù)治理的方方面面，更有Spring Boot這個大將的支持，開發(fā)起來非常的便利和簡單。

技術(shù)前景：Dubbo在各中小公司也從中受益不少。經(jīng)過了這么多年的發(fā)展，互聯(lián)網(wǎng)行業(yè)也是涌現(xiàn)了更多先進的技術(shù)和理念，Dubbo有點可惜。Spring 推出Spring Boot/Cloud也是因為自身的很多原因。Spring最初推崇的輕量級框架，隨著不斷的發(fā)展也越來越龐大，隨著集成項目越來越多，配置文件也越來越混亂，慢慢的背離最初的理念。隨著這么多年的發(fā)展，微服務(wù)、分布式鏈路跟蹤等更多新的技術(shù)理念的出現(xiàn)，Spring急需一款框架來改善以前的開發(fā)模式，因此才會出現(xiàn)Spring Boot/Cloud項目，我們現(xiàn)在訪問Spring官網(wǎng)，會發(fā)現(xiàn)Spring Boot和Spring Cloud已經(jīng)放到首頁最重點突出的三個項目中的前兩個，可見Spring對這兩個框架的重視程度。Dubbo實現(xiàn)如下：

Eureka不再從注冊列表中移除因為長時間沒收到心跳而應(yīng)該過期的服務(wù)

Eureka仍然能夠接受新服務(wù)的注冊和查詢請求，但是不會被同步到其它節(jié)點上（即保證當(dāng)前節(jié)點依然可用）

當(dāng)網(wǎng)絡(luò)穩(wěn)定時，當(dāng)前實例新的注冊信息會被同步到其它節(jié)點中

負載均衡：用于將工作負載分布到多個服務(wù)器來提高網(wǎng)站、應(yīng)用、數(shù)據(jù)庫或其他服務(wù)的性能和可靠性。

使用負載均衡帶來的好處很明顯：當(dāng)集群里的1臺或者多臺服務(wù)器down的時候，剩余的沒有down的服務(wù)器可以保證服務(wù)的繼續(xù)使用；將訪問壓力分配到各個服務(wù)器，不會由于某一高峰時刻導(dǎo)致系統(tǒng)cpu急劇上升。

負載均衡有好幾種實現(xiàn)策略，常見的有：隨機（Random），輪詢（RoundRobin），一致性哈希（ConsistentHash），哈希（Hash），加權(quán)（Weighted）

Ribbon的默認策略是輪詢

PRE（前置）：這種過濾器在請求被路由之前調(diào)用。我們可利用這種過濾器實現(xiàn)鑒權(quán)、限流、參數(shù)校驗調(diào)整等。

ROUTING（路由）：這種過濾器將請求路由到微服務(wù)。這種過濾器用于構(gòu)建發(fā)送給微服務(wù)的請求，并使用Apache HttpClient或Netfilx Ribbon請求微服務(wù)。

POST（后置）：這種過濾器在路由到微服務(wù)以后執(zhí)行。這種過濾器可用來為響應(yīng)添加標準的HTTP Header、收集統(tǒng)計信息和指標、將響應(yīng)從微服務(wù)發(fā)送給客戶端、日志等。

ERROR（錯誤）：在其他階段發(fā)生錯誤時執(zhí)行該過濾器。

資源隔離（線程池隔離和信號量隔離）機制：限制調(diào)用分布式服務(wù)的資源使用，某一個調(diào)用的服務(wù)出現(xiàn)問題不會影響其它服務(wù)調(diào)用。

限流機制：限流機制主要是提前對各個類型的請求設(shè)置最高的QPS閾值，若高于設(shè)置的閾值則對該請求直接返回，不再調(diào)用后續(xù)資源。

熔斷機制：當(dāng)失敗率達到閥值自動觸發(fā)降級（如因網(wǎng)絡(luò)故障、超時造成的失敗率真高），熔斷器觸發(fā)的快速失敗會進行快速恢復(fù)。

降級機制：超時降級、資源不足時（線程或信號量）降級、運行異常降級等，降級后可以配合降級接口返回托底數(shù)據(jù)。

緩存支持：提供了請求緩存、請求合并實現(xiàn)。

通過近實時的統(tǒng)計/監(jiān)控/報警功能，來提高故障發(fā)現(xiàn)的速度。

通過近實時的屬性和配置熱修改功能，來提高故障處理和恢復(fù)的速度。

不方便維護，多人同時對配置文件進行修改，沖突不斷，很難維護

配置內(nèi)容安全和權(quán)限，主要是針對線上的配置來說，一般不對開發(fā)公開，只有運維有權(quán)限所以需要將配置文件隔離，不放到項目代碼里

更新配置項目需要重啟，每次更新配置文件都需要重啟項目，很耗時。使用了配置中心后，即可實現(xiàn)配置實時更新congfig Server和Config Client結(jié)合Spring Cloud Bus實現(xiàn)配置自動刷新。

配置文件存儲在遠端Git（比如GitHub，Gitee等倉庫），config-server從遠端Git拉取配置文件，并保存到本地Git。

本地Git和config-server的交互是雙向的，因為當(dāng)遠端Git無法訪問時，會從本地Git獲取配置文件。

config-client（即各個微服務(wù)），從config-server拉取配置文件。

Config Server：提供配置文件的存儲、以接口的形式將配置文件的內(nèi)容提供出去。

Config Client：通過接口獲取數(shù)據(jù)、并依據(jù)此數(shù)據(jù)初始化自己的應(yīng)用。