今天給大家?guī)淼姆窒硎腔谥Ц秷?chǎng)景的一個(gè)微服務(wù)實(shí)戰(zhàn)，會(huì)更偏向于應(yīng)用層的內(nèi)容。

[[220030]]

主要圍繞以下四點(diǎn)進(jìn)行分享：

• SOA 與微服務(wù)
• 老支付架構(gòu)遇到的挑戰(zhàn)
• 基于微服務(wù)怎么做的改造
• 未來計(jì)劃要做的事

SOA 與微服務(wù)

在我看來，微服務(wù)雖是國(guó)外傳進(jìn)來的技術(shù)，卻和咱們中國(guó)的一些理論是掛鉤的。所以在正式進(jìn)入主題之前，先給大家簡(jiǎn)單介紹一下麥田理論。

關(guān)于麥田理論

古代周朝時(shí)期，老百姓種地實(shí)際是沒有任何規(guī)劃的，也沒有任何區(qū)域的限制。

一般來說在地里一會(huì)種水稻，一會(huì)種小麥，一會(huì)種蔬菜地交叉來種，可收成之后發(fā)現(xiàn)莊稼受陽光程度非常低，營(yíng)養(yǎng)非常不均衡，后期維護(hù)成本非常高。

直到戰(zhàn)國(guó)時(shí)期，有一位農(nóng)業(yè)專家把地劃分為多個(gè)區(qū)域，每一個(gè)區(qū)域種一種莊稼，地跟地隔開，形成最初的微服務(wù)理念。

過去我們看到的很多文章都只是講到 SOA 和微服務(wù)之間的比較，我今天在這個(gè)基礎(chǔ)上加了一個(gè) DDD。下面就 DDD、SOA 以及微服務(wù)的演進(jìn)過程先做個(gè)引子。

DDD、SOA 與微服務(wù)

SOA 架構(gòu)

SOA 是上一個(gè)時(shí)代的產(chǎn)物，大概是在 2010 年之前出現(xiàn)的，最早提出時(shí)是提供給傳統(tǒng)行業(yè)計(jì)算領(lǐng)域的解決方案，當(dāng)時(shí) Oracle、IBM 也提了很多方案，包括出現(xiàn)的很多流程引擎。

它的思想是將緊耦合的系統(tǒng)，劃分為面向業(yè)務(wù)的粗粒度、松耦合、無狀態(tài)的服務(wù)。

在這之后，微服務(wù)的提出者基于 SOA 做了一個(gè)改進(jìn)，就把它變成單一職責(zé)、獨(dú)立部署、細(xì)小的微服務(wù)，是一個(gè)相反的概念。

微服務(wù)與 DDD

今天我們一說到微服務(wù)就會(huì)想到 DDD，有不少朋友認(rèn)為 DDD 就是為微服務(wù)而生的。其實(shí)不是這樣的，我在接觸 DDD 時(shí)，它最早是用來做 UML 設(shè)計(jì)、領(lǐng)域建模的。

DDD 講究充血模型，而 J2EE 模型以傳統(tǒng)的分層架構(gòu)和 Spring 架構(gòu)捆綁在一起形成了以貧血模型為主的架構(gòu)模式。

貧血模型的優(yōu)點(diǎn)是容易入門、分層清晰，而充血模型要求設(shè)計(jì)者前期對(duì)業(yè)務(wù)理解較深，不然后期項(xiàng)目會(huì)產(chǎn)生混亂。

另外就是 DDD 思想比較寬泛，導(dǎo)致形成百家爭(zhēng)鳴的姿態(tài)，沒有形成一套固定的方法論。

開發(fā)者不容易理解，所以后面關(guān)注 DDD 的人變少了，而微服務(wù)的提出巧妙地借鑒了 DDD 里面的限界上下文、子域、領(lǐng)域事件等關(guān)鍵詞，在微服務(wù)得到越來越多業(yè)界認(rèn)可的情況下，也給 DDD 帶來了重新的煥發(fā)機(jī)會(huì)。

老支付架構(gòu)遇到的挑戰(zhàn)

判斷項(xiàng)目好壞的兩個(gè)角度

我們判斷一個(gè)優(yōu)秀項(xiàng)目的好壞，可以從優(yōu)秀的代碼和高可用架構(gòu)兩個(gè)方向來講。

我們?cè)谠O(shè)計(jì)高可用架構(gòu)的同時(shí)，也不能忽視代碼的重要性，優(yōu)秀的代碼指的是冗錯(cuò)能力、冥等操作、并發(fā)情況、死鎖情況等，并不一定是指代碼寫得多漂亮。

這就好比蓋樓一樣，樓房的基礎(chǔ)架子搭得很好，但蓋房的工人不夠?qū)I(yè)，有很多需要注意的地方忽略了，那么在往里面填磚加瓦的時(shí)候出了問題。

后果就是房子經(jīng)常漏雨，墻上有裂縫等各種問題出現(xiàn)，雖然不至于樓房塌陷，但樓房也已經(jīng)變成了危樓。

從代碼和設(shè)計(jì)的角度來看有：

• 由不合理的代碼所引起的項(xiàng)目無擴(kuò)展性
• 數(shù)據(jù)庫(kù)經(jīng)常發(fā)生死鎖
• 數(shù)據(jù)庫(kù)事務(wù)亂用，導(dǎo)致事務(wù)占用時(shí)間過長(zhǎng)
• 代碼容錯(cuò)能力很差，經(jīng)常因?yàn)榭紤]不足引起事故
• 程序中打印的大量的無用日志，并且引起性能問題
• 常用配置信息依然從數(shù)據(jù)庫(kù)中讀取
• 濫用線程池，造成棧和堆溢出
• 從庫(kù)中查詢數(shù)據(jù)，每次全部查出
• 業(yè)務(wù)代碼研發(fā)不考慮冪等操作
• 使用緩存不合理，存在驚群效應(yīng)、緩存穿透等情況
• 代碼上下流流程定義混亂
• 異常處理機(jī)制混亂

再?gòu)恼w架構(gòu)角度來看：

• 整體依然使用單體集群架構(gòu)
• 采用單機(jī)房服務(wù)器布署方式
• 采用 Nginx+hessian 的方式實(shí)現(xiàn)服務(wù)化
• 業(yè)務(wù)架構(gòu)劃分不徹底，邊界模糊
• 項(xiàng)目拆分不徹底，一個(gè) Tomcat 共用多個(gè)應(yīng)用
• 無故障降級(jí)策略
• 監(jiān)控系統(tǒng)不合理（網(wǎng)絡(luò)、系統(tǒng)）
• 支付運(yùn)營(yíng)報(bào)表，大數(shù)據(jù)量查詢
• 運(yùn)維手動(dòng)打包，手動(dòng)上線
• 系統(tǒng)擴(kuò)容手動(dòng)布署

基于以上兩點(diǎn)，我們可以清晰地看到以前老項(xiàng)目的存在問題，并開始思考新的微服務(wù)架構(gòu)應(yīng)該怎么去做。

基于微服務(wù)怎么做的改造

如上圖，想做高可用的微服務(wù)架構(gòu)，必須先確立以下五個(gè)點(diǎn)：

• 產(chǎn)品迭代速度，當(dāng)架構(gòu)設(shè)計(jì)完以后一定是對(duì)產(chǎn)品有利的，不能設(shè)計(jì)完了之后反而比以前開發(fā)得更慢了。這也是微服務(wù)的核心，通過把業(yè)務(wù)拆遷，將不同的產(chǎn)品一個(gè)個(gè)進(jìn)行產(chǎn)品化，而不是項(xiàng)目化。
• 系統(tǒng)穩(wěn)定性，單體架構(gòu)時(shí)一個(gè)系統(tǒng)報(bào)錯(cuò)就全部報(bào)錯(cuò)，現(xiàn)在更是粒度細(xì)一些，同時(shí)架構(gòu)各種監(jiān)控。
• 研發(fā)效率。
• 問題快速定位，也就是每年給我們幾十分鐘的故障時(shí)間。
• 系統(tǒng)耦合度，不要把系統(tǒng)都放在一起，要多拆開。

利用 DDD 來劃分限界上下文

這是根據(jù)一些業(yè)務(wù)場(chǎng)景做的業(yè)務(wù)架構(gòu)圖，中間綠色部分是產(chǎn)品服務(wù)層。用 DDD 的思想來分析，產(chǎn)品服務(wù)層也就是產(chǎn)品服務(wù)域，這個(gè)域里包含三個(gè)子域，一個(gè)是收銀臺(tái)子域，一個(gè)是商戶子域，一個(gè)是個(gè)人子域。

每一個(gè)域里都包含有限界上下文，收銀臺(tái)包含兩個(gè)，商戶包含四個(gè)，個(gè)人包含兩個(gè)。

有些同學(xué)可能不太了解限界上下文概念，可以把它理解為一個(gè)系統(tǒng)、一個(gè)邊界或者一個(gè)實(shí)體。

比如說我們每天上班要倒三次地鐵，這里面的關(guān)鍵事件是什么？就是上班，那限界上下文就是坐地鐵，中間切換三次。

限界上下文就可以把它理解為一個(gè)微服務(wù)，也可以把它理解為一個(gè)系統(tǒng)、一個(gè)模塊。

限界上下文的劃分可以根據(jù)我們的團(tuán)隊(duì)規(guī)模來定，如果團(tuán)隊(duì)規(guī)模沒有達(dá)到一定的程度，可以將邊界定的粗一些，如果項(xiàng)目規(guī)模和團(tuán)隊(duì)規(guī)模不斷擴(kuò)大，還可以再把大的領(lǐng)域和限界上下文繼續(xù)拆分成多個(gè)小的。

微服務(wù)治理架構(gòu)圖

這是我們大致的一個(gè)微服務(wù)整體流程圖，采用的是 Spring Boot+Dubbo 的架構(gòu)。

為什么主張用 Dubbo 而不是 Spring Cloud？有兩點(diǎn)原因：

• 要看目前這個(gè)架構(gòu)是什么，如果是 Dubbo，很多組件的一些設(shè)施都要圍繞它來做，如果這時(shí)把它完全推倒換成別的架構(gòu)，成本部分我們需要慎重考慮。
•  Spring Cloud 技術(shù)雖新但不見得一定比 Dubbo 好用。目前公司就維護(hù)了一個(gè)叫 Dubbo Cloud，自己研發(fā)一套基于 Dubbo 的微服務(wù)體系。

上圖中間這塊的探針也是我們自主研發(fā)的，能夠?qū)崿F(xiàn)把整個(gè)服務(wù)鏈路的各種信息采集到。

比如掉網(wǎng)時(shí)間、報(bào)錯(cuò)、返回值以及參數(shù)全部采集到，采集完之后就把這些信息用一個(gè)開源組件進(jìn)行改造，把信息全部推給它，透過那個(gè)界面展示出我們要的東西。

后面這一套比如 Hystrix 熔斷、Dubbo Admin 和 Mock Server，我們是參考 Dubbo 的思路做的智能化攔截和服務(wù)降級(jí)。

后面的服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、服務(wù)路由、失敗重試和服務(wù)監(jiān)控等是 Dubbo 本身提供的，也就是圖片綠色的部分是我們自研的新功能，未來我們會(huì)把這個(gè) Dubbo Cloud 體系進(jìn)行開源。

通道報(bào)警切換系統(tǒng)的演進(jìn)

這是我們通道報(bào)警系統(tǒng)的框架演進(jìn)。為什么叫“通道”呢？因?yàn)槲覀兊闹Ц兑鱼y行，但銀行本身是相對(duì)偏傳統(tǒng)的，它們的通道不是很穩(wěn)定。

經(jīng)常有各種各樣的問題，而每個(gè)銀行都有 N 個(gè)通道，我們無法得知哪個(gè)通道近期是穩(wěn)定的或不穩(wěn)定，都是會(huì)來回變的。

這里我們自研了一個(gè) Agent，通過采集它通道里的一些使用數(shù)據(jù)，比如說這次我們連成功了，獲取到了數(shù)據(jù)，然后放到 Kafka 里。

之后還有一個(gè)統(tǒng)計(jì)分析的東西，如果這個(gè)通道連接成功一次會(huì)對(duì)它的統(tǒng)計(jì)加一次，***把每隔一段時(shí)間的結(jié)果存到 Redis 集群里。

圖中的路由系統(tǒng)就是做通道選擇的。這是一個(gè)業(yè)務(wù)系統(tǒng)，路由系統(tǒng)每次在做通道選擇時(shí)要先從 Redis 集群里把這個(gè)銀行的通道拿出來，選出評(píng)分***的一個(gè)。

拿出后再經(jīng)過自己的一套路由選舉的配套做一個(gè)清洗或者選擇，***得到一個(gè)***的通道，直接連到銀行通道上，這樣我們就能知道哪些通道是高可用的。

底下的過程還是通過 Kafka，并進(jìn)行各種各樣的統(tǒng)計(jì)分析，也非常好用。然后這里會(huì)有一個(gè)圖表，如果當(dāng)前有問題，在界面上都能可以看到，同時(shí)可以給你發(fā)短信、發(fā)郵件。

為什么我們這里做了兩套？***期的時(shí)候我們要做一個(gè)數(shù)據(jù)的比對(duì)，因?yàn)槿绻杉臄?shù)據(jù)不準(zhǔn)確，這個(gè)通道就會(huì)存在問題。

所以我們一方面是通過上面這種方式來做評(píng)分策略，另一方面是把數(shù)據(jù)采集過來以后放到一個(gè)庫(kù)里，通過這個(gè)庫(kù)再做一次，***每次做一個(gè)比較，以統(tǒng)計(jì)正確率。

當(dāng)這個(gè)通道也發(fā)生了問題，比如某一個(gè)銀行通道發(fā)生了問題，我們的監(jiān)控系統(tǒng)就會(huì)直接把銀行通道設(shè)置為不可用，然后通知研發(fā)部門讓他們?nèi)ソ鉀Q，完了以后再把這個(gè)通道變?yōu)榭捎谩?/p>

如果這個(gè)過程數(shù)據(jù)不準(zhǔn)確，會(huì)造成頻繁的通道切換，會(huì)產(chǎn)生很多不必要的問題，所以在***期時(shí)我們先做成半自動(dòng)化的。

雙活體系架構(gòu)的演進(jìn)

雙活機(jī)房的演進(jìn)，也是需要兩個(gè)階段：

***個(gè)階段是偽雙活

• 兩個(gè)機(jī)房同時(shí)提供服務(wù)，但需要設(shè)置主備機(jī)房；備機(jī)房的應(yīng)用只能通過專線訪問主機(jī)房的數(shù)據(jù)庫(kù)；備機(jī)房的 Redis 也需要通過專線訪問主機(jī)房的 Redis。
• 當(dāng)主機(jī)房掛了后，需要先將備機(jī)房應(yīng)用的數(shù)據(jù)庫(kù)配置改成備庫(kù)，同時(shí)備庫(kù)停機(jī)，修改備庫(kù)為主庫(kù)。

第二個(gè)階段是泳道雙活

雙活體系架構(gòu)的演進(jìn)，在ZK做數(shù)據(jù)同步的時(shí)候，采用兩種方式 Curator 的 TreeCacheListener 監(jiān)控相應(yīng)節(jié)點(diǎn)的變化從而同步數(shù)據(jù)，另一個(gè)是修改 ZK 源碼偽裝成 Observer 接收事務(wù)日志數(shù)據(jù)從而實(shí)現(xiàn)數(shù)據(jù)同步。

ZK 的同步***還是不進(jìn)行同步、泳道隔離，比如像使用 Dubbo 這種的時(shí)候，完全可以同步二套環(huán)境，如果使用當(dāng)當(dāng)?shù)?Elastic-Job，在做雙活的時(shí)候就會(huì)相對(duì)麻煩。

微服務(wù)架構(gòu)全景圖

這個(gè)就是我們整個(gè)微服務(wù)的整體架構(gòu)。圖中左半部分體現(xiàn)了怎么把服務(wù)進(jìn)行劃分，劃分了哪些領(lǐng)域，然后有哪些服務(wù)，數(shù)據(jù)庫(kù)內(nèi)容怎么劃分，網(wǎng)關(guān)層怎么做的，是從業(yè)務(wù)角度來做的一個(gè)劃分。

右邊這塊是體現(xiàn)我們?nèi)绾伪Ｕ衔⒎?wù)的可靠性。***層主要是給項(xiàng)目運(yùn)營(yíng)人員使用，第二層是我們?yōu)榱吮Ｕ衔⒎?wù)都做了什么東西，有統(tǒng)一調(diào)度中心、雙活管控架構(gòu)，還有大數(shù)據(jù)平臺(tái)、分布式緩存，做了各種各樣的組件來保障微服務(wù)順利的開展。

再下面是一些監(jiān)控，這里我們用了 APM 分布式調(diào)鏈的監(jiān)控，包括我們自己也做了一些監(jiān)控平臺(tái)。

持續(xù)集成測(cè)試

接下來講講我們的持續(xù)測(cè)試經(jīng)驗(yàn)。怎么來保證代碼的質(zhì)量？這里就涉及到了集成測(cè)試的概念。

我們分了四個(gè)象限：一是單元測(cè)試，這是由開發(fā)自己來做的，一般覆蓋率在60-80%就不錯(cuò)了；二是驗(yàn)收測(cè)試和探索測(cè)試。

這兩個(gè)實(shí)際上是我們的測(cè)試人員在做，一個(gè)是驗(yàn)證業(yè)務(wù)的可行性，一個(gè)是采取一些非法條件或者是一些破壞性測(cè)試，***是壓力測(cè)試，通過壓測(cè)看系統(tǒng)能承受的負(fù)載情況。

這是我們的整個(gè)測(cè)試流程：

• 首先，我們參照了阿里和其他公司的一些編碼規(guī)范，制定一套自己的編碼規(guī)范，并跟所有開發(fā)人員達(dá)成共識(shí)。
• 然后我們有自己的靜態(tài)代碼檢查，這里也可以用阿里的組件，這是前兩步。
• 第三步就是單元測(cè)試，基本上前三部分都是由開發(fā)來保障代碼的健壯性和正確性。
• 第四是持續(xù)集成，我們根據(jù)自己的規(guī)則和模板對(duì)它再進(jìn)行一次代碼的掃描，掃描完之后就組織一些架構(gòu)師或是技術(shù)專家，對(duì)一些關(guān)鍵核心代碼再做一個(gè)代碼重構(gòu)，大致是分了五步。

未來計(jì)劃要做的事

上圖幾點(diǎn)就是未來我們計(jì)劃要做的一些事情，因?yàn)楝F(xiàn)在業(yè)務(wù)量越來越大了，而不久后央行會(huì)再出一個(gè)文件，要考慮異地多活這個(gè)情況，這塊我覺得是一種趨勢(shì)，目前也有很多公司在做這件事情。

然后我們也會(huì)有一個(gè) Dubbo Cloud，未來也是會(huì)開源的。后面就是大數(shù)據(jù)平臺(tái)的持續(xù)建設(shè)，目前我們的大數(shù)據(jù)平臺(tái)還不是特別完善。

像數(shù)據(jù)的挖掘這塊還沒有做，而現(xiàn)在一般的金融公司還有支付公司的風(fēng)控都要做得特別好，而我們才剛起步。

[[220035]]

程超，智慧支付***支付專家，12 年 Java 開發(fā)經(jīng)驗(yàn)，對(duì)互聯(lián)網(wǎng)支付、電商業(yè)務(wù)方向較為了解，擅長(zhǎng)分布式、性能調(diào)優(yōu)等技術(shù)領(lǐng)域，對(duì)高并發(fā)、大數(shù)據(jù)有濃厚興趣?！渡钊敕植际骄彺妗芬粫?lián)合作者。