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

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

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

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

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

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

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

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

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

Eureka不再?gòu)淖?cè)列表中移除因?yàn)殚L(zhǎng)時(shí)間沒(méi)收到心跳而應(yīng)該過(guò)期的服務(wù)

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

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

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

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

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

Ribbon的默認(rèn)策略是輪詢

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

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

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

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

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

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

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

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

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

通過(guò)近實(shí)時(shí)的統(tǒng)計(jì)/監(jiān)控/報(bào)警功能，來(lái)提高故障發(fā)現(xiàn)的速度。

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

不方便維護(hù)，多人同時(shí)對(duì)配置文件進(jìn)行修改，沖突不斷，很難維護(hù)

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

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

配置文件存儲(chǔ)在遠(yuǎn)端Git（比如GitHub，Gitee等倉(cāng)庫(kù)），config-server從遠(yuǎn)端Git拉取配置文件，并保存到本地Git。

本地Git和config-server的交互是雙向的，因?yàn)楫?dāng)遠(yuǎn)端Git無(wú)法訪問(wèn)時(shí)，會(huì)從本地Git獲取配置文件。

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

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

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