隨著我廠業務需求的壓力逐漸增長，同時基礎設施的不斷完善，系統架構的微服務改造被正式提上日程。從微服務改造的目標架構藍圖設計開始討論，架構組進行了整整兩天的激烈討論，明確了很多的業務邊界。在此過程中我學習到很多知識，結合之前的一些經驗在此總結分享一下。
微服務改造做的就是這件事
00 前言 至于為什么構建微服務架構的系統設計，如何構建微服務架構（http://www.lxweimin.com/p/77ce2dbd1d6e），這些問題有很多文章介紹，我自己也有一篇文章介紹相關話題，感興趣的同學可以翻看。
本文的主題思想是，介紹一下如何在進行微服務改造的初始階段構建一個完美的目標架構，未來的一切改造動作都向著這個目標靠近，目標架構對我們進行的微服務改造實施起到一個指引的作用。
本文的素材來源是我廠的微服務改造目標架構產生的過程，記錄下這個難忘又燒腦的過程，寫完之后有可能就是一個流水賬。希望微服務改造完成之后再看這篇文章時，發現開始的這些架構設計都落地了，簡直就完美啦！！！
本次討論會的成員來自技術部門的架構組和各個業務能力開發組的主要開發人員，同時也邀請了華為的軟件專家現場指導。從參與人員上來看，既有能夠總覽公司當前現狀的架構師，也有開發經驗開發的一線開發人員（覆蓋多數的業務場景），在每個人的心中都有一個美好的愿景，大家的思想互相碰撞融合，吸收各自的優秀方案，最后形成了一個相對完善的目標架構。
01 微服務改造實施計劃 微服務改造是一個漫長的過程，看過一些公司的改造歷程，類似規模的系統改造下來需耗時2年左右。因此，為了保證整個微服務改造過程能夠有條不紊的進行，必需一個可落地實施的規劃。我們的計劃如下：
1. 給出公司目標架構藍圖。
2. 框架選型和基礎設施的完善。
3. 制定出微服務改造的開發規范。
4. 典型項目實踐，總結經驗。
5. 修訂架構規范。
6. 大規模微服務改造推行。
看起來這是一個相對穩妥的計劃，經過這樣一個微服務的改造過程之后，我們的所有業務系統結構更加合理，互相之間的耦合度降低，明確的業務邊界，依賴關系接近一個從上到下的樹形結構。
02 架構現狀 我們是一家第三方支付公司，同學們應該很容易能夠想象到一個大致的業務系統范圍，以及內部的系統組成架構。我們在網上也能夠看到各大第三方支付公司的系統架構圖（https://mp.weixin.qq.com/s/z8sHTaJXXfeOXKjDcio29Q），我們雖然是一家小的支付公司，但是麻雀雖小五臟俱全，應有盡有。只是由于在發展初期都是業務驅動，涌現出了很多系統，很多都是獨立建設的，難免系統建設的有些臃腫，很多系統之間存在大量不合理的調用，畫出調用關系圖來看，顯得非常凌亂。并且很多功能重復建設，浪費資源。
全靠它
目前的這個架構中，有一部分系統是已經經過了重構的，但是這些重構也是相對的獨立的進行的，而且沒有統一的規范。重構系統的設計完全取決于主要設計人員的知識視野，以及他對業務的理解。在技術選型上也是各有不同，一般選擇相對熟悉并且把握比較大框架。每個系統在架構設計上也各有不同，最近建設的幾個系統基本都是采用了微服務設計模式，也有采用SOA架構的，也有僅僅是做了前后分離設計的系統，完全是單體結構的項目也有存在。
雖然我們開始對系統建設有一定的規劃，但是隨著業務的快速野蠻發展，一味地追求快，遷就于業務設計。這樣結果就是，不論是重構和改造的系統，還是新建的系統所包含的業務邊界不明顯，互相之間都存在重復的功能被開發，相對比較零散，建造系統的時候沒有一種渾然天成的感覺。
這樣的現狀引發的問題主要有：
1. 新產品構建緩慢，完全不能滿足快速的業務發展。
2. 難以實現運維自動化。
3. 很難通過擴容來提高性能。
借著微服務架構的設計思想，指導我們進行系統改造。將基礎服務從各個業務系統中剝離，形成統一服務能力；各種支撐系統實現高性能、高可用的基礎設施逐漸完善；讓業務系統能夠更加專注于業務邏輯實現。利用領域驅動設計的指導思想，劃清各系統的業務邊界。經過這樣的一番規劃和設計之后，應該能夠實現系統架構的完美升級。
03 爭論的主要問題 微服務架構只是在概念上給我們指明了方向，制定了幾個重要的設計原則：服務盡可能小、可獨立部署、自動化部署和運維。這些概念需要在落地實施，由于理解上的差異以及公司的現狀各式各樣，每個公司實施下來肯定各有不同，都是每個公司自己特色的微服務架構，畢竟架構設計是服務于業務模塊的。所以我廠也在討論符合我們自己公司特色的微服務架構如何實施。
在討論的過程中有幾個爭論的話題，在這里總結一下：
1. 底層能力和上層產品之間的邊界在哪里？底層能力抽象到什么程度，要不要關心上層產品業務邏輯？
2. 拆分與合并的博弈。
3. 業務模塊上的設計是否允許存在單點。
4. 組織結構與分工能夠做出多大的改變。
其實前面兩點說的都是業務邊界劃分的問題，第一點是分層之后的縱向邊界，第二點是橫向邊界。針對第一點，我們拿充值功能舉例：
標準的充值流程是：1. 用戶銀行卡上扣錢（支付接口）；2. 用戶內部賬戶記賬。詳細的步驟這里沒有說明，熟悉支付業務的同學應該了解，支付有多種支付方式，內部賬戶也有多種（標準充值上賬是用戶的現金賬戶）。若是標準的充值，這兩步分別走的也是標準流程；若是有特殊的業務，充值是充到傭金賬戶，這樣的特定業務的充值是否要放到充值中心實現？在第三方支付公司待久了會發現，有各種標準產品，也有很多定制化的產品。
我們的結論是：標準化的功能，由底層服務為產品層提供標準能力支撐，具有強烈的個別業務特性化的功能，由產品層直接調用更底層的能力自己封裝實現。
就第二點而言，可能有些同學會疑惑，微服務架構的原則不是將服務拆分的盡可能小，實現高內聚、低耦合嗎？為什么還有合并呢？我的理解是，這個原則只是適用于完全的業務邏輯設計，在系統建設中也有一些基本業務無關的組件要實現，這些公共服務（如，統一流水號、統一session管理等）應該抽象出來統一實現，被業務系統調用。還有一些在管理方式和用途上都很類似的數據，這些數據可放在一起管理，統一提供服務。
在做業務設計時，微服務的設計原則是避免單點模塊，完全分布式、高內聚的服務好處很多，壓力分散，互相之間影響較小，但是它們需要各自管理。其實這些好處都是相對的，在一個技術平均水平較高的公司里，內聚的系統相對較好，各種技術都能駕馭的很好。比如，支付訂單系統是否要分散到各個產品系統中，還是統一做一個訂單中心，這樣在需要提高性能的時候，需要做一些異步化處理的時候，都能統一在一處實現性能提高。
在Martin Fowler對微服務的論證中能夠看到，微服務架構不僅僅是系統架構，也是人員組織架構的指導。團隊要盡可能的全棧，實現高內聚、低耦合。為了減少部門組織交叉協作帶來的低效，我們負責的是一個個產品，不是一個交付了就完事的項目，產品的整個生命周期都應該由這個團隊維護。這樣的話，原來的組織結構在微服務改造的實施下也需要做出調整，這是需要領導的支持力度的。
在支撐系統和基礎設施上，沒有太多的討論，這套底層運維服務相對比較標準，而且大部分已經建設完成，目前處于完善和優化的階段。
總結一下，架構設計本身就是一門博弈權衡的學問，無論是現在流行的微服務架構還是之前的SOA等其它架構，都無例外。最好的架構設計是要適合公司本身的業務發展和規劃，以及組織結構，目前的這些可能會阻礙微服務化的進程，但是從實際出發，這些業務和組織能夠為微服務化做出多大的改變，也是需要考慮的問題。我們不是在做大刀闊斧的改革，微服務化改造應該是一個水到渠成的、循序漸進的優化過程。
第一次參與這么大范圍的架構設計，發現需要權衡的東西太多了，有些設計原則是否需要堅持。
04 目標架構（藍圖） 最終我根據大家討論達成的共識，以及自己對業務的理解，做出了下面的架構設計圖：
目標架構
本文是我對微服務改造和業務重構的理解，并不能代表公司的正式架構，有些設計并沒有好與壞，權衡利弊、審時度勢才是重點。
版權申明：內容來源網絡，版權歸原創者所有。除非無法確認，我們都會標明作者及出處，如有侵權煩請告知，我們會立即刪除并表示歉意。謝謝。
