為什么我選擇了 SPRING CLOUD 分布式 微服務(wù)

常見的架構(gòu)單體架構(gòu)
單體架構(gòu)在小微企業(yè)比較常見，一個(gè)應(yīng)用、一個(gè)數(shù)據(jù)庫、一個(gè)web容器就可以跑起來。在兩種情況下可能會(huì)選擇單體架構(gòu)：一、在企業(yè)發(fā)展的初期，為了保證快速上線，采用此種方案較為簡(jiǎn)單靈活；二、傳統(tǒng)企業(yè)中垂直度較高，訪問壓力較小的業(yè)務(wù)。在這種模式下對(duì)技術(shù)要求較低，方便各層次開發(fā)人員接手，也能滿足客戶需求。?單體架構(gòu)的架構(gòu)圖：

在單體架構(gòu)中，技術(shù)選型非常靈活，優(yōu)先滿足快速上線的要求，也便于快速跟進(jìn)市場(chǎng)。?垂直架構(gòu)
在單體架構(gòu)發(fā)展一段時(shí)間后，公司的業(yè)務(wù)模式得到了認(rèn)可，交易量也慢慢的大起來。這時(shí)候?yàn)榱藨?yīng)對(duì)更大的訪問流量，就會(huì)對(duì)原有的業(yè)務(wù)進(jìn)行拆分，比如說：后臺(tái)系統(tǒng)、前端系統(tǒng)、鑒權(quán)系統(tǒng)和業(yè)務(wù)系統(tǒng)等。在這一階段往往會(huì)將系統(tǒng)分為不同的層級(jí)，每個(gè)層級(jí)有對(duì)應(yīng)的職責(zé)。UI層負(fù)責(zé)和用戶進(jìn)行交互、業(yè)務(wù)邏輯層負(fù)責(zé)具體的業(yè)務(wù)功能、數(shù)據(jù)庫層負(fù)責(zé)和上層進(jìn)行數(shù)據(jù)交換和存儲(chǔ)。比如我們開發(fā)的資產(chǎn)盤活和資產(chǎn)驗(yàn)收就是垂直架構(gòu)的系統(tǒng)。
垂直架構(gòu)的架構(gòu)圖：

在這個(gè)階段SSM（SpringMVC、Spring、MyBatis）是項(xiàng)目的關(guān)鍵技術(shù)，SpringMVC負(fù)責(zé)邏輯控制、Spring負(fù)責(zé)業(yè)務(wù)層管理Bean、MyBatis負(fù)責(zé)數(shù)據(jù)庫操作進(jìn)行封裝，持久化數(shù)據(jù)。?
服務(wù)化架構(gòu)SOA
如果公司進(jìn)一步的做大，垂直子系統(tǒng)會(huì)變的越來越多，系統(tǒng)和系統(tǒng)之間的調(diào)用關(guān)系呈指數(shù)上升。在這樣的背景下很多公司都會(huì)考慮服務(wù)SOA化。SOA代表面向服務(wù)的架構(gòu)，將應(yīng)用程序根據(jù)不同的職責(zé)劃分為不同的模塊，不同的模塊直接通過特定的協(xié)議和接口進(jìn)行交互。整個(gè)系統(tǒng)切分成很多單個(gè)組件服務(wù)來完成請(qǐng)求，當(dāng)流量過大時(shí)通過水平擴(kuò)展相應(yīng)的組件來支撐，所有的組件通過交互來滿足整體的業(yè)務(wù)需求。優(yōu)點(diǎn)是可以根據(jù)需求通過網(wǎng)絡(luò)對(duì)應(yīng)用組件進(jìn)行分布式部署、組合和使用。服務(wù)化架構(gòu)是一套松耦合的架構(gòu)，服務(wù)的拆分原則是服務(wù)內(nèi)部高內(nèi)聚，服務(wù)之間低耦合。?
服務(wù)化架構(gòu)圖：

SOA的隱性缺陷 當(dāng)集中式應(yīng)用轉(zhuǎn)變成分布式系統(tǒng)后，系統(tǒng)之間的相互可靠調(diào)用一直以來都是分布式架構(gòu)的難題。網(wǎng)絡(luò)通信，序列化協(xié)議設(shè)計(jì)等很多技術(shù)細(xì)節(jié)需要確定。一個(gè)高性能的框架，能夠構(gòu)建高可用的分布式系統(tǒng)，系統(tǒng)地考慮各個(gè)應(yīng)用之間的分布式服務(wù)發(fā)現(xiàn)、服務(wù)路由、服務(wù)調(diào)用以及服務(wù)安全等細(xì)節(jié)。

對(duì)比SOA和微服務(wù)架構(gòu)服務(wù)化架構(gòu)已經(jīng)可以解決大部分企業(yè)的需求了，為什么要研究微服務(wù)？微服務(wù)架構(gòu)強(qiáng)調(diào)：業(yè)務(wù)系統(tǒng)需要徹底的組件化和服務(wù)化，一個(gè)組件就是一個(gè)產(chǎn)品，可以獨(dú)立對(duì)外提供服務(wù)。不再?gòu)?qiáng)調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB企業(yè)服務(wù)總線。強(qiáng)調(diào)每個(gè)微服務(wù)都有自己獨(dú)立的運(yùn)行空間，包括數(shù)據(jù)庫資源。源于互聯(lián)網(wǎng)的思路，服務(wù)強(qiáng)調(diào)了采用HTTP Rest API的方式來進(jìn)行切分粒度會(huì)更小微服務(wù)架構(gòu)是 SOA 架構(gòu)思想的一種擴(kuò)展，更加強(qiáng)調(diào)服務(wù)個(gè)體的獨(dú)立性、拆分粒度更小。微服務(wù)架構(gòu)關(guān)鍵詞

有新的應(yīng)用上線應(yīng)該怎么辦？
應(yīng)用是運(yùn)維管理的基本單位

完整的應(yīng)用生命周期管理機(jī)制應(yīng)該包括：

1、應(yīng)用創(chuàng)建 2、部署 3、啟動(dòng) 4、回滾 5、擴(kuò)容縮容 6、停止下線等。

我們需要服務(wù)注冊(cè)和發(fā)現(xiàn)服務(wù)中心將所有的可以提供的服務(wù)都注冊(cè)到它這里來管理，其它各調(diào)用者需要的時(shí)候去注冊(cè)中心獲取，然后再進(jìn)行調(diào)用，避免了服務(wù)之間的直接調(diào)用，方便后續(xù)的水平擴(kuò)展、故障轉(zhuǎn)移等。隨著系統(tǒng)的流量不斷增加，需要根據(jù)情況來擴(kuò)展某個(gè)服務(wù)，只需要增加相應(yīng)的服務(wù)端實(shí)例既可。在系統(tǒng)的運(yùn)行期間服務(wù)中心有一個(gè)心跳檢測(cè)機(jī)制，如果某實(shí)例在規(guī)定的時(shí)間內(nèi)沒有進(jìn)行通訊則會(huì)自動(dòng)被剔除掉，避免了某個(gè)實(shí)例掛掉影響服務(wù)。從而實(shí)現(xiàn)了注冊(cè)、負(fù)載均衡、故障轉(zhuǎn)移的功能。

多應(yīng)用如何相互訪問才能保證安全？
一個(gè)好的服務(wù)框架要保證用戶每一次分布式調(diào)用的穩(wěn)定與安全。在服務(wù)注冊(cè)、服務(wù)訂閱以及服務(wù)調(diào)用等每一個(gè)環(huán)節(jié)，都需要進(jìn)行嚴(yán)格的服務(wù)鑒權(quán)。

我們需要服務(wù)網(wǎng)關(guān)?網(wǎng)關(guān)提供了動(dòng)態(tài)路由，監(jiān)控，彈性，安全等的邊緣服務(wù)。它的具體作用就是服務(wù)轉(zhuǎn)發(fā)，接收并轉(zhuǎn)發(fā)所有內(nèi)外部的客戶端調(diào)用。作為資源的統(tǒng)一訪問入口，同時(shí)也可以做權(quán)限校驗(yàn)等類似的功能。 不同的服務(wù)一般有不同的網(wǎng)絡(luò)地址，而外部的客戶端可能需要調(diào)用多個(gè)服務(wù)的接口才能完成一個(gè)業(yè)務(wù)需求。以資產(chǎn)盤活數(shù)據(jù)統(tǒng)計(jì)為例,可能會(huì)調(diào)用以下幾個(gè)服務(wù)：用戶微服務(wù)? 資產(chǎn)分類微服務(wù)? 訂單微服務(wù)等如果客戶端直接和微服務(wù)進(jìn)行通信，會(huì)存在以下問題：客戶端會(huì)多次請(qǐng)求不同服務(wù)，增加復(fù)雜性。存在跨域請(qǐng)求，處理復(fù)雜。每一個(gè)服務(wù)都需要獨(dú)立認(rèn)證認(rèn)。代碼難以重構(gòu)。上述問題，都可以借助網(wǎng)關(guān)解決。微服務(wù)網(wǎng)管是介于客戶端和服務(wù)器端之間的中間層，所有的外部請(qǐng)求都會(huì)先經(jīng)過微服務(wù)網(wǎng)關(guān)。

應(yīng)用如何高效管控，服務(wù)又如何治理？
服務(wù)降級(jí)

流量管控

我們需要熔斷器服務(wù)雪崩效應(yīng)：一種因“服務(wù)提供者”的不可用導(dǎo)致“服務(wù)消費(fèi)者”的不可用,并將不可用逐漸放大的過程。熔斷器在某個(gè)服務(wù)連續(xù)調(diào)用N次不響應(yīng)的情況下，立即通知調(diào)用端調(diào)用失敗，避免調(diào)用端持續(xù)等待而影響了整體服務(wù)。間隔一段時(shí)間后再次檢查此服務(wù)，如果服務(wù)恢復(fù)將繼續(xù)提供服務(wù)。 不適用場(chǎng)景
核心無降級(jí)業(yè)務(wù):拍照驗(yàn)收時(shí)驗(yàn)收照片是業(yè)務(wù)核心，這時(shí)如果拍照服務(wù)無法使用整個(gè)資產(chǎn)驗(yàn)收服務(wù)就應(yīng)該終止。適用場(chǎng)景邊緣業(yè)務(wù)或者可降級(jí)的業(yè)務(wù):同樣是拍照，在資產(chǎn)盤活中上架物品對(duì)照片的需求沒有非常強(qiáng)烈，這時(shí)如果拍照服務(wù)出現(xiàn)問題，不應(yīng)該影響資產(chǎn)上架，就可以利用熔斷器來保證上架流程正常進(jìn)行。

運(yùn)維如何高效定位問題？ 隨著服越來越多，對(duì)調(diào)用鏈的分析會(huì)越來越復(fù)雜。服務(wù)之間的調(diào)用關(guān)系、某個(gè)請(qǐng)求對(duì)應(yīng)的調(diào)用鏈、調(diào)用之間消費(fèi)的時(shí)間等，對(duì)這些信息進(jìn)行監(jiān)控就成為一個(gè)問題。在實(shí)際的使用中我們需要監(jiān)控服務(wù)和服務(wù)之間通訊的各項(xiàng)指標(biāo)，這些數(shù)據(jù)將是我們改進(jìn)系統(tǒng)架構(gòu)的主要依據(jù)。因此分布式的業(yè)務(wù)流程跟蹤就變的非常重要。我們需要鏈路跟蹤
通過鏈路追蹤可以很清楚的了解到一個(gè)服務(wù)請(qǐng)求經(jīng)過了哪些服務(wù)，每個(gè)服務(wù)處理花費(fèi)了多長(zhǎng)時(shí)間。從而讓我們可以很方便的理清各微服務(wù)間的調(diào)用關(guān)系。

微服務(wù)的技術(shù)棧

Eureka進(jìn)行服務(wù)注冊(cè)發(fā)現(xiàn)，連接微服務(wù)Hystrix監(jiān)控服務(wù)調(diào)用進(jìn)行熔斷保護(hù)Config提供了統(tǒng)一的配置中心服務(wù)所有對(duì)外的請(qǐng)求和服務(wù)都通過Zuul來進(jìn)行轉(zhuǎn)發(fā)，起到API網(wǎng)關(guān)的作用使用Sleuth、Zipkin將所有的請(qǐng)求數(shù)據(jù)記錄下來，進(jìn)行后續(xù)分析這些功能都是以插拔的形式提供出來，方便我們系統(tǒng)架構(gòu)演進(jìn)的過程中，可以合理的選擇需要的組件進(jìn)行集成，從而在架構(gòu)衍進(jìn)的過程中會(huì)更加平滑順利。

我們可以獲得什么？

硬件部署架構(gòu)