內(nèi)容來源：2017年5月6日，鏈家網(wǎng)基礎(chǔ)架構(gòu)部高級研發(fā)工程師劉思賢在“Spring Cloud中國社區(qū)技術(shù)沙龍-北京站”進(jìn)行《基于Spring Cloud的微服務(wù)實(shí)踐》演講分享。IT 大咖說（ID：itdakashuo）作為獨(dú)家視頻合作方，經(jīng)主辦方和講者審閱授權(quán)發(fā)布。

閱讀字?jǐn)?shù)：2632?| 5分鐘閱讀

獲取嘉賓演講視頻回放及PPT，請點(diǎn)擊：http://t.cn/RFR0Suq

摘要

本次演講是由鏈家網(wǎng)基礎(chǔ)架構(gòu)部高級研發(fā)工程師劉思賢帶來基于Spring Cloud的微服務(wù)實(shí)踐經(jīng)驗(yàn)分享。

回到2015年

在2015年，我受朋友的邀請加入了愛油科技，擔(dān)任愛油科技的架構(gòu)師。愛油科技做了十年傳統(tǒng)行業(yè)的成品油交易，開始進(jìn)行互聯(lián)網(wǎng)化的轉(zhuǎn)型。它有非常重的線下業(yè)務(wù)，這些線下業(yè)務(wù)會通過信息化互聯(lián)網(wǎng)的手段搬到線上進(jìn)行一系列的改造。

我接手公司業(yè)務(wù)的時候只有一個單體應(yīng)用，通過團(tuán)隊大約兩年的維護(hù)，建設(shè)了很多不同的業(yè)務(wù)系統(tǒng)等。在我了解到這家公司的情況之后，和CTO討論決定通過微服務(wù)的方式來改造整個系統(tǒng)。

業(yè)務(wù)的變遷

為什么要做微服務(wù)呢？首先就要聚焦到我們當(dāng)前業(yè)務(wù)的變化。

以前的業(yè)務(wù)通常是一個網(wǎng)站打天下，而現(xiàn)在各種各樣的新媒體渠道成為了我們業(yè)務(wù)的重要入口，傳統(tǒng)單一網(wǎng)站的形式已經(jīng)不能滿足我們的要求了。

對愛油科技而言，以前的業(yè)務(wù)通常是線上收單線下處理，現(xiàn)在這家公司的重要使命就是要把所有的業(yè)務(wù)流程搬到線上，讓它流轉(zhuǎn)得更有效率。

在以往的系統(tǒng)中，使用它的主要用戶是系統(tǒng)管理員，他們通過后臺來維護(hù)一些商品的信息等等。而在我們想要把所有業(yè)務(wù)流程搬到線上之后，它面臨的變化就是業(yè)務(wù)人員需要用后臺，使用后臺的方式也從單一的網(wǎng)站轉(zhuǎn)變到了APP隨時辦公的場景。

研發(fā)犯難

需求變化侵蝕架構(gòu)，像熔化的反應(yīng)堆芯；

被技術(shù)平臺綁架，大炮打蚊子；

協(xié)作困難，牽一發(fā)而動全身。

架構(gòu)分層和基本原則

期望目標(biāo)

不綁定到特定的語言和框架，可以將多種多樣的語言快速實(shí)現(xiàn)業(yè)務(wù)最有效率地去交付業(yè)務(wù)價值為目標(biāo)；

當(dāng)一套微服務(wù)體系中引入多種語言的時候，必然涉及到多種語言、多種框架之間的集成。松散耦合的體系結(jié)構(gòu)便于多種語言框架的集成；

簡單、容易落地、方便擴(kuò)展。

原則

業(yè)務(wù)服務(wù)層服務(wù)完全對等；

業(yè)務(wù)服務(wù)層服務(wù)必須是無狀態(tài)的，這能保證業(yè)務(wù)服務(wù)層的所有服務(wù)能提供對外擴(kuò)展的能力；

接入層服務(wù)之間禁止相互調(diào)用；

接入層服務(wù)不能包含業(yè)務(wù)邏輯，這一層是輕和薄，面向渲染、面向輸出，不面向業(yè)務(wù)邏輯的處理；

業(yè)務(wù)接口必須是RESTful風(fēng)格，因?yàn)槲覀兤谕谖覀兊恼w架構(gòu)中不僅僅涵蓋Java的東西，也可以涵蓋其它語言的一系列服務(wù)；

所有服務(wù)必須運(yùn)行在容器里。我們整體團(tuán)隊有限，不可能提供大量的人力物力去進(jìn)行運(yùn)維等操作，利用容器可以幫助我們進(jìn)行服務(wù)的治理，以節(jié)約大量的資源。

SPRING CLOUD快速搭建微服務(wù)框架

服務(wù)注冊和發(fā)現(xiàn)

在Docker整個容器技術(shù)中，我們發(fā)現(xiàn)Consul作為一個服務(wù)注冊和發(fā)現(xiàn)中心，正好可以納入到我們的體系當(dāng)中，直接進(jìn)行使用。

Consul的服務(wù)注冊其實(shí)要比后來Spring Cloud Consul提供的Config的服務(wù)更加容易落地、更有實(shí)用性。

仍待解決

在這套方案中當(dāng)時有些問題還沒有得到很好的解決。

Consul服務(wù)注冊發(fā)現(xiàn)與七層Nginx聯(lián)動。我們期望的是當(dāng)一個服務(wù)啟動之后，它能夠直接被Nginx的七層發(fā)現(xiàn)，我們不用再手工地去更改Nginx的配置。

另一個就是灰度發(fā)布的問題。因?yàn)樵谡麄€現(xiàn)有的Spring Cloud的里，去做一個服務(wù)發(fā)布20%的流量到一個新的版本這件事情，現(xiàn)在處理起來還比較困難，很難把這20%的服務(wù)標(biāo)記出來。

Consul作為配置中心

統(tǒng)一管理Spring Cloud項(xiàng)目的配置文件；

為接入層服務(wù)下發(fā)配置。

仍待解決

Consul作為配置中心依然有些問題沒有解決。

配置的版本化管理。一個配置修改前后的版本差異是要能夠訪問得到的，不然線上修改配置一旦出現(xiàn)問題，就無法很快地還原配置。

灰度發(fā)布。在目前Spring Cloud的基礎(chǔ)設(shè)施中還很難允許在一個集群中20%用這個配置，80%用另一個配置。我們需要做一些定制化開發(fā)來解決這個問題。

服務(wù)集成

服務(wù)層Node：Consul、Brake

接入層Node：request to zuul

PHP接入層：guzzle to zuul

領(lǐng)域驅(qū)動設(shè)計指導(dǎo)業(yè)務(wù)服務(wù)開發(fā)

業(yè)務(wù)到微服務(wù)

我們把這種天然的業(yè)務(wù)彼此獨(dú)立或隔離叫做界限上下文。在界限上下文里面，它們使用相應(yīng)的統(tǒng)一語言描述業(yè)務(wù)。在每個領(lǐng)域內(nèi)它們有自己的模型，圍繞這個模型進(jìn)行建模，它們各種有統(tǒng)一的語言。這樣就天然地把它們拆成了成員微服務(wù)和交易微服務(wù)。

從業(yè)務(wù)到微服務(wù)的過程中，其實(shí)包含了兩種消息的傳遞。一個最基本的觀點(diǎn)就是，對象和對象之間消息的傳遞是通過方法調(diào)用來進(jìn)行的。我們有同樣的方法，就是一個服務(wù)去調(diào)用另外的服務(wù)，它產(chǎn)生的結(jié)果會作為這個服務(wù)的使用。

基于剛才領(lǐng)域驅(qū)動設(shè)計的觀點(diǎn)，領(lǐng)域模型被放在了六邊形架構(gòu)的中間，所有和領(lǐng)域進(jìn)行交互的東西都是通過六邊形架構(gòu)的邊來進(jìn)行。

還有一類是異步的消息。比如一個客戶下單之后要給他創(chuàng)建相應(yīng)的物流訂單，就是一個領(lǐng)域內(nèi)產(chǎn)生的消息通過領(lǐng)域事件的方式向另一個領(lǐng)域進(jìn)行傳播。

領(lǐng)域事件的傳遞

領(lǐng)域事件的傳遞很出現(xiàn)一個問題，每個不同的微服務(wù)使用不同的MQ服務(wù)，它們之間的消息怎樣進(jìn)行交互？

我們選用了一個消息服務(wù)的中間件，每一個需要發(fā)送事件的微服務(wù)都會維護(hù)一個Event Topic，然后再維護(hù)一個從其它領(lǐng)域內(nèi)傳來消息的Page。當(dāng)一個事務(wù)提交之后，每個事件會被投到Topic里面，Topic收到消息服務(wù)中，消息服務(wù)再按照訂閱關(guān)系投遞到相應(yīng)的Event Queue里面。它們各自消費(fèi)這個Event Queue就能處理這個事件。

消息服務(wù)

整個消息服務(wù)我們使用了某云計算廠商提供現(xiàn)成的消息服務(wù)作為我們的消息中間件。

分包/模塊原則：高內(nèi)聚、低耦合；

通過領(lǐng)域模型表達(dá)領(lǐng)域知識提高內(nèi)聚性；

應(yīng)用層使用領(lǐng)域模型；

防腐層提供領(lǐng)域?qū)铀璧膶?shí)現(xiàn)，防止實(shí)現(xiàn)耦合到領(lǐng)域。

這時大家所說的實(shí)體變成了失血的領(lǐng)域模型。而對于面向?qū)ο蟆⒄Z言來講，它表現(xiàn)業(yè)務(wù)規(guī)則、表現(xiàn)知識最大的表現(xiàn)力就是對象之間的交互。

這種更具領(lǐng)域知識表現(xiàn)力的設(shè)計方式會比事務(wù)腳本的方式更容易維護(hù)。

原則

以界限上下文劃分微服務(wù)；

領(lǐng)域模型表達(dá)領(lǐng)域知識，高內(nèi)聚；

服務(wù)與服務(wù)之間通過Rest和MQ集成，低耦合。

基礎(chǔ)設(shè)施與DEVOPS

基礎(chǔ)設(shè)施

對象存儲：S3/OpenSwift，存儲與計算分離；

消息服務(wù)：動態(tài)定義消息訂閱及路由；

容器資源管理：Rancher、SwarmKit；

日志服務(wù)：Docker、Rsyslog、Logstash。

DevOps

DevOps每個分支都會提供相應(yīng)的構(gòu)建，構(gòu)建出的結(jié)果就是標(biāo)準(zhǔn)化的鏡像，標(biāo)準(zhǔn)化鏡像帶來了Dev、QA、Production環(huán)境統(tǒng)一。

價值

整體實(shí)施完微服務(wù)之后，給公司帶來的價值是新業(yè)務(wù)最短1周上線，10人團(tuán)隊可以維護(hù)20余種微服務(wù)，每日數(shù)次線上發(fā)布，每周里程碑發(fā)布，全年核心業(yè)務(wù)可用性高達(dá)99.95%。

在整個微服務(wù)架構(gòu)落地中，技術(shù)體系的建設(shè)至關(guān)重要。

我今天的分享就到這里，謝謝大家！