隨著我廠業(yè)務(wù)需求的壓力逐漸增長，同時基礎(chǔ)設(shè)施的不斷完善，系統(tǒng)架構(gòu)的微服務(wù)改造被正式提上日程。從微服務(wù)改造的目標(biāo)架構(gòu)藍圖設(shè)計開始討論，架構(gòu)組進行了整整兩天的激烈討論，明確了很多的業(yè)務(wù)邊界。在此過程中我學(xué)習(xí)到很多知識，結(jié)合之前的一些經(jīng)驗在此總結(jié)分享一下。

1.png

00 前言

至于為什么構(gòu)建微服務(wù)架構(gòu)的系統(tǒng)設(shè)計，如何構(gòu)建微服務(wù)架構(gòu)，這些問題有很多文章介紹，我自己也有一篇文章介紹相關(guān)話題，感興趣的同學(xué)可以翻看。

本文的主題思想是，介紹一下如何在進行微服務(wù)改造的初始階段構(gòu)建一個完美的目標(biāo)架構(gòu)，未來的一切改造動作都向著這個目標(biāo)靠近，目標(biāo)架構(gòu)對我們進行的微服務(wù)改造實施起到一個指引的作用。

本文的素材來源是我廠的微服務(wù)改造目標(biāo)架構(gòu)產(chǎn)生的過程，記錄下這個難忘又燒腦的過程，寫完之后有可能就是一個流水賬。希望微服務(wù)改造完成之后再看這篇文章時，發(fā)現(xiàn)開始的這些架構(gòu)設(shè)計都落地了，簡直就完美啦！！！

本次討論會的成員來自技術(shù)部門的架構(gòu)組和各個業(yè)務(wù)能力開發(fā)組的主要開發(fā)人員，同時也邀請了華為的軟件專家現(xiàn)場指導(dǎo)。從參與人員上來看，既有能夠總覽公司當(dāng)前現(xiàn)狀的架構(gòu)師，也有開發(fā)經(jīng)驗開發(fā)的一線開發(fā)人員（覆蓋多數(shù)的業(yè)務(wù)場景），在每個人的心中都有一個美好的愿景，大家的思想互相碰撞融合，吸收各自的優(yōu)秀方案，最后形成了一個相對完善的目標(biāo)架構(gòu)。

01 微服務(wù)改造實施計劃

微服務(wù)改造是一個漫長的過程，看過一些公司的改造歷程，類似規(guī)模的系統(tǒng)改造下來需耗時2年左右。因此，為了保證整個微服務(wù)改造過程能夠有條不紊的進行，必需一個可落地實施的規(guī)劃。我們的計劃如下：

1. 給出公司目標(biāo)架構(gòu)藍圖。
2. 框架選型和基礎(chǔ)設(shè)施的完善。
3. 制定出微服務(wù)改造的開發(fā)規(guī)范。
4. 典型項目實踐，總結(jié)經(jīng)驗。
5. 修訂架構(gòu)規(guī)范。
6. 大規(guī)模微服務(wù)改造推行。

看起來這是一個相對穩(wěn)妥的計劃，經(jīng)過這樣一個微服務(wù)的改造過程之后，我們的所有業(yè)務(wù)系統(tǒng)結(jié)構(gòu)更加合理，互相之間的耦合度降低，明確的業(yè)務(wù)邊界，依賴關(guān)系接近一個從上到下的樹形結(jié)構(gòu)。

02 架構(gòu)現(xiàn)狀

我們是一家第三方支付公司，同學(xué)們應(yīng)該很容易能夠想象到一個大致的業(yè)務(wù)系統(tǒng)范圍，以及內(nèi)部的系統(tǒng)組成架構(gòu)。我們在網(wǎng)上也能夠看到各大第三方支付公司的系統(tǒng)架構(gòu)圖，我們雖然是一家小的支付公司，但是麻雀雖小五臟俱全，應(yīng)有盡有。只是由于在發(fā)展初期都是業(yè)務(wù)驅(qū)動，涌現(xiàn)出了很多系統(tǒng)，很多都是獨立建設(shè)的，難免系統(tǒng)建設(shè)的有些臃腫，很多系統(tǒng)之間存在大量不合理的調(diào)用，畫出調(diào)用關(guān)系圖來看，顯得非常凌亂。并且很多功能重復(fù)建設(shè)，浪費資源。

2.png

目前的這個架構(gòu)中，有一部分系統(tǒng)是已經(jīng)經(jīng)過了重構(gòu)的，但是這些重構(gòu)也是相對的獨立的進行的，而且沒有統(tǒng)一的規(guī)范。重構(gòu)系統(tǒng)的設(shè)計完全取決于主要設(shè)計人員的知識視野，以及他對業(yè)務(wù)的理解。在技術(shù)選型上也是各有不同，一般選擇相對熟悉并且把握比較大框架。每個系統(tǒng)在架構(gòu)設(shè)計上也各有不同，最近建設(shè)的幾個系統(tǒng)基本都是采用了微服務(wù)設(shè)計模式，也有采用SOA架構(gòu)的，也有僅僅是做了前后分離設(shè)計的系統(tǒng)，完全是單體結(jié)構(gòu)的項目也有存在。

雖然我們開始對系統(tǒng)建設(shè)有一定的規(guī)劃，但是隨著業(yè)務(wù)的快速野蠻發(fā)展，一味地追求快，遷就于業(yè)務(wù)設(shè)計。這樣結(jié)果就是，不論是重構(gòu)和改造的系統(tǒng)，還是新建的系統(tǒng)所包含的業(yè)務(wù)邊界不明顯，互相之間都存在重復(fù)的功能被開發(fā)，相對比較零散，建造系統(tǒng)的時候沒有一種渾然天成的感覺。

這樣的現(xiàn)狀引發(fā)的問題主要有：

1. 新產(chǎn)品構(gòu)建緩慢，完全不能滿足快速的業(yè)務(wù)發(fā)展。
2. 難以實現(xiàn)運維自動化。
3. 很難通過擴容來提高性能。

借著微服務(wù)架構(gòu)的設(shè)計思想，指導(dǎo)我們進行系統(tǒng)改造。將基礎(chǔ)服務(wù)從各個業(yè)務(wù)系統(tǒng)中剝離，形成統(tǒng)一服務(wù)能力；各種支撐系統(tǒng)實現(xiàn)高性能、高可用的基礎(chǔ)設(shè)施逐漸完善；讓業(yè)務(wù)系統(tǒng)能夠更加專注于業(yè)務(wù)邏輯實現(xiàn)。利用領(lǐng)域驅(qū)動設(shè)計的指導(dǎo)思想，劃清各系統(tǒng)的業(yè)務(wù)邊界。經(jīng)過這樣的一番規(guī)劃和設(shè)計之后，應(yīng)該能夠?qū)崿F(xiàn)系統(tǒng)架構(gòu)的完美升級。

03 爭論的主要問題

微服務(wù)架構(gòu)只是在概念上給我們指明了方向，制定了幾個重要的設(shè)計原則：服務(wù)盡可能小、可獨立部署、自動化部署和運維。這些概念需要在落地實施，由于理解上的差異以及公司的現(xiàn)狀各式各樣，每個公司實施下來肯定各有不同，都是每個公司自己特色的微服務(wù)架構(gòu)，畢竟架構(gòu)設(shè)計是服務(wù)于業(yè)務(wù)模塊的。所以我廠也在討論符合我們自己公司特色的微服務(wù)架構(gòu)如何實施。

在討論的過程中有幾個爭論的話題，在這里總結(jié)一下：

1. 底層能力和上層產(chǎn)品之間的邊界在哪里？底層能力抽象到什么程度，要不要關(guān)心上層產(chǎn)品業(yè)務(wù)邏輯？
2. 拆分與合并的博弈。
3. 業(yè)務(wù)模塊上的設(shè)計是否允許存在單點。
4. 組織結(jié)構(gòu)與分工能夠做出多大的改變。

其實前面兩點說的都是業(yè)務(wù)邊界劃分的問題，第一點是分層之后的縱向邊界，第二點是橫向邊界。針對第一點，我們拿充值功能舉例：

標(biāo)準(zhǔn)的充值流程是1. 用戶銀行卡上扣錢（支付接口）；2. 用戶內(nèi)部賬戶記賬。詳細(xì)的步驟這里沒有說明，熟悉支付業(yè)務(wù)的同學(xué)應(yīng)該了解，支付有多種支付方式，內(nèi)部賬戶也有多種（標(biāo)準(zhǔn)充值上賬是用戶的現(xiàn)金賬戶）。若是標(biāo)準(zhǔn)的充值，這兩步分別走的也是標(biāo)準(zhǔn)流程；若是有特殊的業(yè)務(wù)，充值是充到傭金賬戶，這樣的特定業(yè)務(wù)的充值是否要放到充值中心實現(xiàn)？在第三方支付公司待久了會發(fā)現(xiàn)，有各種標(biāo)準(zhǔn)產(chǎn)品，也有很多定制化的產(chǎn)品。

我們的結(jié)論是：標(biāo)準(zhǔn)化的功能，由底層服務(wù)為產(chǎn)品層提供標(biāo)準(zhǔn)能力支撐，具有強烈的個別業(yè)務(wù)特性化的功能，由產(chǎn)品層直接調(diào)用更底層的能力自己封裝實現(xiàn)。

就第二點而言，可能有些同學(xué)會疑惑，微服務(wù)架構(gòu)的原則不是將服務(wù)拆分的盡可能小，實現(xiàn)高內(nèi)聚、低耦合嗎？為什么還有合并呢？我的理解是，這個原則只是適用于完全的業(yè)務(wù)邏輯設(shè)計，在系統(tǒng)建設(shè)中也有一些基本業(yè)務(wù)無關(guān)的組件要實現(xiàn)，這些公共服務(wù)（如，統(tǒng)一流水號、統(tǒng)一session管理等）應(yīng)該抽象出來統(tǒng)一實現(xiàn)，被業(yè)務(wù)系統(tǒng)調(diào)用。還有一些在管理方式和用途上都很類似的數(shù)據(jù)，這些數(shù)據(jù)可放在一起管理，統(tǒng)一提供服務(wù)。

在做業(yè)務(wù)設(shè)計時，微服務(wù)的設(shè)計原則是避免單點模塊，完全分布式、高內(nèi)聚的服務(wù)好處很多，壓力分散，互相之間影響較小，但是它們需要各自管理。其實這些好處都是相對的，在一個技術(shù)平均水平較高的公司里，內(nèi)聚的系統(tǒng)相對較好，各種技術(shù)都能駕馭的很好。比如，支付訂單系統(tǒng)是否要分散到各個產(chǎn)品系統(tǒng)中，還是統(tǒng)一做一個訂單中心，這樣在需要提高性能的時候，需要做一些異步化處理的時候，都能統(tǒng)一在一處實現(xiàn)性能提高。

在Martin Fowler對微服務(wù)的論證中能夠看到，微服務(wù)架構(gòu)不僅僅是系統(tǒng)架構(gòu)，也是人員組織架構(gòu)的指導(dǎo)。團隊要盡可能的全棧，實現(xiàn)高內(nèi)聚、低耦合。為了減少部門組織交叉協(xié)作帶來的低效，我們負(fù)責(zé)的是一個個產(chǎn)品，不是一個交付了就完事的項目，產(chǎn)品的整個生命周期都應(yīng)該由這個團隊維護。這樣的話，原來的組織結(jié)構(gòu)在微服務(wù)改造的實施下也需要做出調(diào)整，這是需要領(lǐng)導(dǎo)的支持力度的。

在支撐系統(tǒng)和基礎(chǔ)設(shè)施上，沒有太多的討論，這套底層運維服務(wù)相對比較標(biāo)準(zhǔn)，而且大部分已經(jīng)建設(shè)完成，目前處于完善和優(yōu)化的階段。

總結(jié)一下，架構(gòu)設(shè)計本身就是一門博弈權(quán)衡的學(xué)問，無論是現(xiàn)在流行的微服務(wù)架構(gòu)還是之前的SOA等其它架構(gòu)，都無例外。最好的架構(gòu)設(shè)計是要適合公司本身的業(yè)務(wù)發(fā)展和規(guī)劃，以及組織結(jié)構(gòu)，目前的這些可能會阻礙微服務(wù)化的進程，但是從實際出發(fā)，這些業(yè)務(wù)和組織能夠為微服務(wù)化做出多大的改變，也是需要考慮的問題。我們不是在做大刀闊斧的改革，微服務(wù)化改造應(yīng)該是一個水到渠成的、循序漸進的優(yōu)化過程。

第一次參與這么大范圍的架構(gòu)設(shè)計，發(fā)現(xiàn)需要權(quán)衡的東西太多了，有些設(shè)計原則是否需要堅持。

04 目標(biāo)架構(gòu)（藍圖）

最終我根據(jù)大家討論達成的共識，以及自己對業(yè)務(wù)的理解，做出了下面的架構(gòu)設(shè)計圖：

3.png

本文是我對微服務(wù)改造和業(yè)務(wù)重構(gòu)的理解，并不能代表公司的正式架構(gòu)，有些設(shè)計并沒有好與壞，權(quán)衡利弊、審時度勢才是重點。

來源：rabbitGYK的博客

鏈接：http://rabbitgyk.com/2018/01/14/microservice-improve-architecture/