微服務(wù)一個(gè)相對較小且獨(dú)立的功能單元，是用戶可以感知的最小功能集，如一個(gè)網(wǎng)站有訂單管理、用戶管理、商品管理等模塊，我們就可以把其中的訂單管理、用戶管理做成微服務(wù)。

微服務(wù)架構(gòu)風(fēng)格是一種使用一套小服務(wù)來開發(fā)單個(gè)應(yīng)用的方式突進(jìn)，每個(gè)服務(wù)運(yùn)行在自己的進(jìn)程中，并且使用輕量級通信如HTTPAPI，這些服務(wù)基于業(yè)務(wù)能力構(gòu)建，并能夠通過自動化部署機(jī)制來獨(dú)立部署，這些服務(wù)可以使用不同的編程語言，以及不同的數(shù)據(jù)儲存技術(shù)等。

項(xiàng)目開始階段，運(yùn)維場景功能并不是很齊全、體量小，單體架構(gòu)可以滿足業(yè)務(wù)需要。但伴隨著業(yè)務(wù)能力拓展、自動化服務(wù)越來越集中，尤其是筆者公司希望給地場景能像貨幣一樣流通，單體架構(gòu)會帶來一些問題：

單體架構(gòu)系統(tǒng)本身過于龐大和復(fù)雜，以至于任何一個(gè)開發(fā)者都很難以理解它的全部。這種極度的復(fù)雜度會形成惡性循環(huán)，由于代碼難以理解，因此開發(fā)人員更改更容易出錯，每一次更改系統(tǒng)更復(fù)雜、更難懂。

隨著時(shí)間推移、需求變更和人員更迭，會逐漸形成應(yīng)用程序的技術(shù)債務(wù)，并且越積越多?！安粔牟恍蕖保@在軟件開發(fā)中非常常見，在單體應(yīng)用中，這種思想更嚴(yán)重。已使用的系統(tǒng)設(shè)計(jì)或代碼難以被修改，因?yàn)閼?yīng)用程序中的其他模塊可能會以意料之外的方式使用它。

隨著代碼的增多，構(gòu)建和部署的時(shí)間也會增加。而在單體應(yīng)用中，每次功能的變更或缺陷的修復(fù)都會導(dǎo)致重新部署整個(gè)應(yīng)用，而且全量部署的方式耗時(shí)長、影響范圍大、風(fēng)險(xiǎn)高。

單體應(yīng)用往往使用統(tǒng)一的技術(shù)平臺或方案解決所有的問題，團(tuán)隊(duì)中的每個(gè)成員必須使用相同的開發(fā)語言和框架，要想引入新框架或新技術(shù)平臺會非常困難。例如，一個(gè)使用Struts2構(gòu)建的、有百萬行代碼的單體應(yīng)用，如果想要換用SpringMVC，毫無疑問切換的成本是非常高的。

單體應(yīng)用只能作為一個(gè)整體進(jìn)行擴(kuò)展，無法根據(jù)業(yè)務(wù)模塊的需要進(jìn)行伸縮。例如，應(yīng)用中有的模塊是計(jì)算密集型的，它需要強(qiáng)勁的CPU；有的模塊則是IO密集型的，需要更大的內(nèi)存。由于這些模塊部署在一起，不得不在硬件的選擇上做出妥協(xié)。

綜上，隨著業(yè)務(wù)需求的發(fā)展，功能的不斷增加，單體架構(gòu)很難滿足互聯(lián)網(wǎng)時(shí)代快速變化的需要。

微服務(wù)易于被一個(gè)開發(fā)人員理解，修改和維護(hù)，實(shí)現(xiàn)了模塊化的解決方案。

微服務(wù)架構(gòu)模式是每個(gè)微服務(wù)獨(dú)立的部署，開發(fā)者不再需要協(xié)調(diào)其它服務(wù)部署對本服務(wù)的影響，這種改變可以加快部署速度。

這種架構(gòu)使得每個(gè)微服務(wù)都可以有專門開發(fā)團(tuán)隊(duì)來開發(fā)，開發(fā)者可以自由選擇開發(fā)技術(shù)，提供API服務(wù)。這種自由意味著開發(fā)者不需要被迫使用某項(xiàng)目開始時(shí)采用的過時(shí)技術(shù)，他們可以選擇現(xiàn)在的技術(shù)。甚至于，因?yàn)槲⒎?wù)都是相對簡單，即使用現(xiàn)在技術(shù)重寫以前代碼也不是很困難的事情。

微服務(wù)架構(gòu)模式使得每個(gè)微服務(wù)獨(dú)立擴(kuò)展，你可以根據(jù)每個(gè)微服務(wù)的規(guī)模來部署滿足需求的規(guī)模。甚至于，你可以使用更適合于微服務(wù)資源需求的硬件。比如，你可以把依賴CPU計(jì)算能力的指標(biāo)管理微服務(wù)部署在高配置的多核CPU實(shí)例上，把視頻管理模塊部署在高內(nèi)存、I/O讀寫能力強(qiáng)的實(shí)例上。

對于單體架構(gòu)來講，我們只需要維護(hù)好這一個(gè)項(xiàng)目就可以了，但是對于微服務(wù)架構(gòu)來講，由于項(xiàng)目是由多個(gè)微服務(wù)構(gòu)成的，每個(gè)模塊出現(xiàn)問題都會造成整個(gè)項(xiàng)目運(yùn)行出現(xiàn)異常，想要知道是哪個(gè)模塊造成的問題往往是不容易的，因?yàn)槲覀儫o法一步一步通過debug的方式來跟蹤，這就對運(yùn)維人員提出了很高的要求。

對于單體架構(gòu)來講，我們可以不使用分布式，但是對于微服務(wù)架構(gòu)來說，分布式幾乎是必會用的技術(shù)，由于分布式本身的復(fù)雜性，導(dǎo)致微服務(wù)架構(gòu)也變得復(fù)雜起來。

比如，用戶微服務(wù)是要被訂單微服務(wù)和電影微服務(wù)所調(diào)用的，一旦用戶微服務(wù)的接口發(fā)生大的變動，那么所有依賴它的微服務(wù)都要做相應(yīng)的調(diào)整，由于微服務(wù)可能非常多，那么調(diào)整接口所造成的成本將會明顯提高。

對于單體架構(gòu)來講，如果某段業(yè)務(wù)被多個(gè)模塊所共同使用，我們便可以抽象成一個(gè)工具類，被所有模塊直接調(diào)用，但是微服務(wù)卻無法這樣做，因?yàn)檫@個(gè)微服務(wù)的工具類是不能被其它微服務(wù)所直接調(diào)用的，從而我們便不得不在每個(gè)微服務(wù)上都建這么一個(gè)工具類，從而導(dǎo)致代碼的重復(fù)。

SpringCloud為開發(fā)者提供了快速構(gòu)建分布式系統(tǒng)的通用模型的工具（包括配置管理springcloudconfig，服務(wù)發(fā)現(xiàn)Eureka，熔斷器Hystrix，服務(wù)網(wǎng)關(guān)Zuul，微代理，控制總線，一次性令牌，全局鎖，領(lǐng)導(dǎo)選舉，分布式會話，集群狀態(tài)等）。SpringCloud并沒有重復(fù)制造輪子，它只是將各家公司開發(fā)的比較成熟、經(jīng)得起實(shí)際考驗(yàn)的服務(wù)框架組合起來，通過SpringBoot風(fēng)格進(jìn)行再封裝屏蔽掉了復(fù)雜的配置和實(shí)現(xiàn)原理，最終給開發(fā)者留出了一套簡單易懂、易部署和易維護(hù)的分布式系統(tǒng)開發(fā)工具包。一般項(xiàng)目中用到SpringCloud的工具包微服務(wù)架構(gòu)如下：

Eureka是Netflix開發(fā)的服務(wù)發(fā)現(xiàn)框架，本身是一個(gè)基于REST的服務(wù)，用于定位服務(wù)，以實(shí)現(xiàn)云端中間層服務(wù)發(fā)現(xiàn)和故障轉(zhuǎn)移。SpringCloud將它集成在其子項(xiàng)目spring-cloud-netflix中，以實(shí)現(xiàn)SpringCloud的服務(wù)發(fā)現(xiàn)功能，類似于Dubbo的注冊中心Zookeeper。實(shí)現(xiàn)原理如下：

EureKa采用C-S的設(shè)計(jì)架構(gòu)，即包括了EurekaServer（服務(wù)端），EureKaclient（客戶端）。

在項(xiàng)目中業(yè)務(wù)量不大情況下，例如微服務(wù)消費(fèi)者A可以通過url地址調(diào)用微服務(wù)生產(chǎn)者B的接口服務(wù)，這種直接指定url調(diào)用有如下隱患：1、微服務(wù)B的IP和端口變了，那微服務(wù)A通過之前的url調(diào)用微服務(wù)B就會報(bào)錯；2、因業(yè)務(wù)量大增，微服務(wù)B需要擴(kuò)容做成集群，如果微服務(wù)A還是通過指定url調(diào)用微服務(wù)B就無法做到集群的負(fù)載均衡以及高可用。

綜上所述，我們用Eureka來解決這一難題，各微服務(wù)啟動時(shí)都注冊服務(wù)名在Eureka中，例如微服務(wù)消費(fèi)者A在Eureka中注冊服務(wù)名為’consumer,微服務(wù)生產(chǎn)者B在Eureka中注冊服務(wù)名為’producer’,那微服務(wù)消費(fèi)者A就可以通過指定要調(diào)用的服務(wù)名’producer’通過Eureka的負(fù)載均衡返回實(shí)際微服務(wù)生產(chǎn)者B的url地址，這樣就解決了以上問題。

微服務(wù)之間調(diào)用接口通過Feign，它是聲明式的Rest客戶端，基于接口的注解方式，它跟Eureka配套使用，Eureka中自帶了Ribbon實(shí)現(xiàn)了負(fù)載均衡。例如代碼中微服務(wù)消費(fèi)者A通過Feign要調(diào)用微服務(wù)生產(chǎn)者B的接口服務(wù)，只需在微服務(wù)A的Feign注解中指定微服務(wù)者生產(chǎn)B在Eureka中的注冊服務(wù)名即可，如下：

在微服務(wù)架構(gòu)中，根據(jù)業(yè)務(wù)來拆分成一個(gè)個(gè)的微服務(wù)，微服務(wù)與微服務(wù)之間可以相互調(diào)用，為了保證其高可用，單個(gè)微服務(wù)通常會集群部署。由于網(wǎng)絡(luò)原因或者自身的原因，微服務(wù)并不能保證100%可用，如果單個(gè)微服務(wù)出現(xiàn)問題，調(diào)用這個(gè)微服務(wù)就會出現(xiàn)線程阻塞，此時(shí)若有大量的請求涌入該微服務(wù)實(shí)例，會導(dǎo)致該實(shí)例的線程資源會被消耗完畢，導(dǎo)致服務(wù)癱瘓。因微服務(wù)與微服務(wù)之間的依賴性，所以故障會傳播，會對整個(gè)微服務(wù)系統(tǒng)造成災(zāi)難性的嚴(yán)重后果，這就是微服務(wù)故障的“雪崩”效應(yīng)。

綜上情況，我們使用到了斷路器Hystrix，當(dāng)對特定的微服務(wù)的調(diào)用的不可用達(dá)到一個(gè)閥值（Hystric默認(rèn)是5秒20次）斷路器將會被打開,下次請求過來微服務(wù)會直接通過fallback返回一個(gè)固定值快速失敗響應(yīng)，不會走內(nèi)部邏輯占用資源。

斷路器還能自動回復(fù)，在熔斷機(jī)制的異常情況邏輯中，當(dāng)熔斷器打開的時(shí)候，會自動的啟動自動恢復(fù)休眠窗（一個(gè)計(jì)時(shí)器，默認(rèn)10秒），在這個(gè)休眠期內(nèi)，所有請求都會快速失敗。

但是當(dāng)休眠期到期的時(shí)候，此時(shí)熔斷器會進(jìn)入半開狀態(tài)，讓下一次請求繼續(xù)調(diào)用內(nèi)部資源，而不是快速失敗。如果這時(shí)候調(diào)用成功，熔斷開關(guān)置為關(guān)閉狀態(tài)。

反之，熔斷開關(guān)繼續(xù)打開狀態(tài)，再次進(jìn)入快速失敗的狀態(tài)，并繼續(xù)進(jìn)行休眠，等待下一次嘗試恢復(fù)。斷路器提供了看板監(jiān)控如下：

所有從設(shè)備或網(wǎng)站來的請求都會經(jīng)過Zuul到達(dá)后端微服務(wù)應(yīng)用程序。作為一個(gè)邊界性質(zhì)的應(yīng)用程序，Zuul提供了動態(tài)路由、監(jiān)控、彈性負(fù)載和安全功能。Zuul底層利用各種filter實(shí)現(xiàn)如下功能：

配置了服務(wù)網(wǎng)關(guān)zuul后，不管微服務(wù)url接口地址是否改變，不影響外部調(diào)用：

我們知道，每個(gè)獨(dú)立的微服務(wù)都有配置文件，一個(gè)項(xiàng)目至少有幾個(gè)、甚至十幾個(gè)微服務(wù)以上，如果要修改微服務(wù)的配置文件參數(shù)，需要登陸到每個(gè)微服務(wù)項(xiàng)目的resources目錄下進(jìn)行修改，不方便維護(hù)。尤其是更新微服務(wù)項(xiàng)目配置后需要重啟，而重啟項(xiàng)目的代價(jià)還是很高的。而配置中心SpringCloudConfig提供了公有云遠(yuǎn)程Git倉庫、本地Git倉庫，可以把每個(gè)微服務(wù)的配置文件統(tǒng)一集中管理，當(dāng)配置文件內(nèi)容修改時(shí)，可以同步到每個(gè)微服務(wù)的內(nèi)存中，不需要重啟，實(shí)現(xiàn)了高可用，非常方便。

我們可以指定一個(gè)微服務(wù)為Configserver，實(shí)時(shí)同步遠(yuǎn)程Git倉庫、本地Git倉庫的所有微服務(wù)配置文件，當(dāng)配置文件參數(shù)有改動時(shí)程序會自動同步到上圖中的微服務(wù)A、B中，微服務(wù)A、B啟動時(shí)也會主動從微服務(wù)Configserver同步一次配置文件參數(shù)。