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