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

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

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

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

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

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

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

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

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

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

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

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

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

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

對于單體架構(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ù)被多個模塊所共同使用，我們便可以抽象成一個工具類，被所有模塊直接調(diào)用，但是微服務(wù)卻無法這樣做，因為這個微服務(wù)的工具類是不能被其它微服務(wù)所直接調(diào)用的，從而我們便不得不在每個微服務(wù)上都建這么一個工具類，從而導(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)得起實際考驗的服務(wù)框架組合起來，通過SpringBoot風(fēng)格進行再封裝屏蔽掉了復(fù)雜的配置和實現(xiàn)原理，最終給開發(fā)者留出了一套簡單易懂、易部署和易維護的分布式系統(tǒng)開發(fā)工具包。一般項目中用到SpringCloud的工具包微服務(wù)架構(gòu)如下：

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

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

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

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

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

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

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

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

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

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

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

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

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

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