新網銀行微服務轉型實踐

本文整理自謝延澤先生在 Dubbo 開發者日成都站活動中的演講，主要分享關於微服務轉型的內容，也總結一下這些年做者在微服務領域的一些經驗。

2012 年 James Lewis 在波蘭第 33 次 Degree in Kraków 會議上分享了一個案例，名稱是 「Micro Services - Java, the Unix Way」。在這個分享裏，James Lewis 分享了在 2011 年中參與的一個項目中所採用的一系列實踐，以 UNIX 的哲學從新看待企業級 Java 應用程序，而且把其中的一部分稱之爲「 Micro-Services 」。總結了五大特徵:
Small with a single responsibility —— 「小到只有單一原則」

• Containerless and installed as wellbehaved Unix services —— 「去容器化而且做爲 Unix Service 安裝」
• Located in different VCS roots ——「分佈在不一樣的版本控制代碼庫裏」
• Provisioned automatically ——「自動初始化」
• Status aware and auto-scaling ——「關注狀態和自動擴展」

2014 Martin Fowler 試圖將 James Lewis 的微服務定義進行通常化推廣，使其不光能夠在不一樣的語言架構和技術棧上使用。又能夠兼顧敏捷、DevOps 等其它技術，成爲一個架構的「最佳實踐」集合。提出 9 大特徵：經過服務組件化、圍繞業務能力組織、是產品不是項目、智能端點和啞管道、去中心化治理、去中心化數據管理、基礎設施自動化、爲失效設計、演進式設計

2016年 Sam Newman 《Building Microservice》4個特徵 7大原則。

4 大特徵：能夠獨立部署。經過網絡通訊。對消費方的透明。儘量下降耦合，使其自治。

7 大原則：圍繞業務概念建模、接受自動化文化、隱藏內部實現細節、讓一切都去中心化、可獨立部署、隔離失敗、高度可觀察。

這裏澄清一個觀點，在工做過程當中偶爾會聽到某些同窗說，我使用了 Dubbo ，使用了 spring-boot ，或者使用了 Spring-Cloud ，我開發出來的系統就是微服務。我的觀點，微服務是一個架構風格或者架構原則，與實現系統的框架無關。好比：一個系統知足了上面的特徵和原則，使用 WebService 通信，難道就不是微服務嗎？固然實際實施過程當中應該選擇一個輕量級的通信框架。

微服務從 2014 年在國內開始傳播，到如今已經有 5 年時間裏，關於微服務的優勢論述的文章有不少，好比邏輯清晰、簡化部署、可擴展、靈活組合、技術易購、故障隔離等等這就不作詳細展開。

全面微服務化帶來的挑戰

1. 可用率下降

全面微服務化以後，原先的單個應用可能會拆分爲多個獨立進程。爲避免進程之間爭用資源，通常公司都會獨立部署，即單個虛擬機內只部署一個 jvm 進程。由此帶來了更多服務器、網絡設備、安全設備，這些硬件設備的可靠性都會影響到業務連續性。

服務跨進程間通信，必然要選擇一種通信協議、序列化框架，額外引入的代碼可靠性也會對總體的可用性形成影響。
所以，微服務的設計是須要面向故障進行設計，在設計要考慮重試、冪等、故障隔離、熔斷、降級等等。

2. 事務複雜度

微服務拆分後，雖然按照領域模型作了解耦，但不可避免會帶來分佈式事務問題。目前分佈式事務在社區也有一些解決方案和開源框架，方案有基於消息隊列最終一致、TCC 分佈式事務框架以及自動化的分佈式事務框架，例如 Seata 等，但分佈式事務的處理，對開發人員設計要求比較高，使用成本較高。

在拆分的時候，建議仍是儘量避免分佈式事務，引入分佈式事務框架要評估成本和收益。

3. 運維複雜度

當一個單體應用拆分爲多個微服務以後，應用數量會大幅增長。若是沒有一個可靠穩定的運維平臺或資源編排平臺（如 k8s ),全面微服務化，對運維就是一個災難，工做量的大幅增長，直接會影響系統穩定性進而影響到業務連續性。

4. 調試優化複雜度

應用拆分後，業務調用關係變複雜，調用鏈總體變長。若是沒有一套合適的調用鏈追蹤平臺，很難定位到整個系統的性能瓶頸，調優成本很高。另外一個問題是，生產環境業務數據異常時，因爲調用鏈過長，若是沒有規範的 Request、Response 日誌，很容易形成各服務之間相互甩鍋，難以定位問題。全面微服務化以後，因爲衆多的服務節點，調優排查錯誤更加依賴於日誌平臺，高性能的日誌平臺也會提升效率。

5. 測試難度

在單體應用的時候，調用鏈路短，通常都是作黑盒測試，測試人員無需瞭解複雜的業務實現。而進行微服務改造後，單個業務可能會由多個服務組合編排完成，若是繼續作黑盒測試，意味着必須等待全部服務開發完成以後才能進行，致使測試周期邊長、定位困難，作邊界測試須要更多的測試用例才能覆蓋，測試總體成本會變高。這種狀況下，單元測試、單系統測試的重要性就凸顯出來了。若是須要作單系統測試，可能須要 mock 被調用的服務，通信協議使用 http 還好，社區有不少開源的框架可使用。若是是 RPC 框架，意味着須要準備一套好用的 mock 測試系統才能支撐單系統測試。

6. 聚合查詢

在領域建模的時候，通常是按照用戶角度去劃分，而運營需求與用戶需求天生不是一個維度的。舉個例子：按用戶維度領域建模，會劃分用戶服務、訂單服務，用戶和訂單數據存儲在不一樣的數據庫，假設運營有一個需求是查詢某個年齡段用戶的訂單，在用戶達到千萬級的時候，這種需求對微服務體系是個災難。須要一個強大的大數據平臺對數據按業務維度進行聚合，才能知足運營的查詢需求和報表功能。

微服務拆分原則

微服務拆分原則中，特別須要提到的是康威定律。

康維定律簡單來講就是系統設計(產品結構)等同組織形式，每一個設計系統的組織，其產生的設計等同於組織之間的溝通結構。若是單個服務由不一樣組織管理，需求沒法達成統一，面臨着令出多頭、需求干擾的風險。

伸縮需求，同一個進程以內的不一樣業務功能，有時在業務量方面會出現較大的差別，具體要求的進程數量會有較大差異，這樣的模塊鎖定在同一進程以內，勢必會形成資源的浪費。

部署頻率，同一個交付物內不一樣的組件有着不一樣的上線頻率，會大大的提升上線流程的發生頻率，會形成較大的人員浪費。

修改的相關性，若是同一交付物內的不一樣組件，常常會被同步修改，這可能說明，若是發生拆分，這兩個模塊應該是」在一塊兒「的。

領域建模，針對業務領域，引入限界上下文（Bounded Context）和上下文映射 （Context Map）對業務領域進行合理的分解，識別出核心領域（Core Domain） 與子領域（SubDomain），並肯定領域的邊界以及它們之間的關係。依據核心領域和子領域劃分微服務邊界。

對於一個單體應用，拆分過程應該是按部就班、逐步拆分、由簡到繁、由粗到細，是一個漸進的過程。例如先將有明顯邊界的業務拆分爲獨立服務，沒法明細邊界的先混在一塊兒，等業務需求逐步清晰後再拆。拆分時先拆分爲幾個相對較粗粒度的服務，根據業務需求狀況，逐步將粗粒度的服務中相對穩定，能夠沉澱的業務拆分爲獨立服務。在這個過程當中，原有的單體應用也能夠承擔部分兼容能力，在改造完成前，不對外部系統形成過大的影響。

微服務的拆分是跟業務需求強相關的，若是業務需求變動很少、相對穩定，處理的請求併發量不高，單體應用的穩定性和可維護性更好，更加適用。

總結

微服務不是銀彈，是用來處理海量用戶、業務複雜和需求頻繁變動場景下的一種架構風格。引用一句話「好的架構是演化出來的，而不是設計出來的」。任何一種架構的引入，都會帶來利弊兩個方面的影響，如何平衡才最重要。

四川新網銀行是全國三家互聯網銀行之一，於 2016 年 12 月 28 日正式開業。新網銀行註冊資本 30 億元，由新但願集團、小米、紅旗連鎖等股東發起設立，是銀監會批准成立的全國第七家民營銀行，也是四川省首家民營銀行，同時也是全國第二家得到國家高新技術企業認定的銀行。新網銀行堅持「移動互聯、普惠補位」的差別化定位，以及「數字普惠、開放鏈接」的特點化經營，着力打形成爲一家數字科技普惠銀行，依託領先的金融科技能力、穩健的大數據風控技術和高效的互聯網開放平臺運營模式，服務小微羣體、支持實體經濟、踐行普惠金融。截止目前服務用戶數 2900 多萬，累計放款 9000 多萬筆。

做者信息：謝延澤，目前就任於新網銀行，負責技術中臺建設，核心系統技術架構設計。關注雲原生領域，探索在金融行業實踐思路。

---

本文做者：謝延澤

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。