微服務改造—架構設計
阿新 • • 發佈：2019-02-10
微服務架構只是在概念上給我們指明瞭方向，制定了幾個重要的設計原則：服務儘可能小、可獨立部署、自動化部署和運維。這些概念需要在落地實施，由於理解上的差異以及公司的現狀各式各樣，每個公司實施下來肯定各有不同，都是每個公司自己特色的微服務架構，畢竟架構設計是服務於業務模組的。所以我廠也在討論符合我們自己公司特色的微服務架構如何實施。
在討論的過程中有幾個爭論的話題，在這裡總結一下：
1. 底層能力和上層產品之間的邊界在哪裡？底層能力抽象到什麼程度，要不要關心上層產品業務邏輯？
2. 拆分與合併的博弈。
3. 業務模組上的設計是否允許存在單點。
4. 組織結構與分工能夠做出多大的改變。
其實前面兩點說的都是業務邊界劃分的問題，第一點是分層之後的縱向邊界，第二點是橫向邊界。針對第一點，我們拿充值功能舉例：
標準的充值流程是：1. 使用者銀行卡上扣錢（支付介面）；2. 使用者內部賬戶記賬。詳細的步驟這裡沒有說明，熟悉支付業務的同學應該瞭解，支付有多種支付方式，內部賬戶也有多種（標準充值上賬是使用者的現金賬戶）。若是標準的充值，這兩步分別走的也是標準流程；若是有特殊的業務，充值是充到佣金賬戶，這樣的特定業務的充值是否要放到充值中心實現？在第三方支付公司待久了會發現，有各種標準產品，也有很多定製化的產品。
我們的結論是：標準化的功能，由底層服務為產品層提供標準能力支撐，具有強烈的個別業務特性化的功能，由產品層直接呼叫更底層的能力自己封裝實現。
就第二點而言，可能有些同學會疑惑，微服務架構的原則不是將服務拆分的儘可能小，實現高內聚、低耦合嗎？為什麼還有合併呢？我的理解是，這個原則只是適用於完全的業務邏輯設計，在系統建設中也有一些基本業務無關的元件要實現，這些公共服務（如，統一流水號、統一session管理等）應該抽象出來統一實現，被業務系統呼叫。還有一些在管理方式和用途上都很類似的資料，這些資料可放在一起管理，統一提供服務。
在做業務設計時，微服務的設計原則是避免單點模組，完全分散式、高內聚的服務好處很多，壓力分散，互相之間影響較小，但是它們需要各自管理。其實這些好處都是相對的，在一個技術平均水平較高的公司裡，內聚的系統相對較好，各種技術都能駕馭的很好。比如，支付訂單系統是否要分散到各個產品系統中，還是統一做一個訂單中心，這樣在需要提高效能的時候，需要做一些非同步化處理的時候，都能統一在一處實現效能提高。
在Martin Fowler對微服務的論證中能夠看到，微服務架構不僅僅是系統架構，也是人員組織架構的指導。團隊要儘可能的全棧，實現高內聚、低耦合。為了減少部門組織交叉協作帶來的低效，我們負責的是一個個產品，不是一個交付了就完事的專案，產品的整個生命週期都應該由這個團隊維護。這樣的話，原來的組織結構在微服務改造的實施下也需要做出調整，這是需要領導的支援力度的。
在支撐系統和基礎設施上，沒有太多的討論，這套底層運維服務相對比較標準，而且大部分已經建設完成，目前處於完善和優化的階段。
總結一下，架構設計本身就是一門博弈權衡的學問，無論是現在流行的微服務架構還是之前的SOA等其它架構，都無例外。最好的架構設計是要適合公司本身的業務發展和規劃，以及組織結構，目前的這些可能會阻礙微服務化的程序，但是從實際出發，這些業務和組織能夠為微服務化做出多大的改變，也是需要考慮的問題。我們不是在做大刀闊斧的改革，微服務化改造應該是一個水到渠成的、循序漸進的優化過程。
第一次參與這麼大範圍的架構設計，發現需要權衡的東西太多了，有些設計原則是否需要堅持。