從單一模式系統架構往微服務架構遷移轉化技術研究

王健+李冬睿

摘 要 文章針對目前單一模式系統開發周期周期長、開發成本高等困難，將原有系統往微服務架構上遷移提出了幾種解決方案，結合具體場景，講述了各個環節的實現機制。

關鍵詞 微服務 單一模式 遷移轉化技術

中圖分類號：TP271.4 文獻標識碼：A DOI：10.16400/j.cnki.kjdkx.2016.09.021

Abstract Aiming at the current development cycle of single mode system of long period， high cost of development difficulties， the original system to the micro service architecture on migration of several solutions are proposed， combined with the specific scene， describes the realization mechanism of each link.

Key words micro service； single mode； migration and transformation technology

1 Web系統架構情況概述和分析

目前web系統架構具有如下幾個特征：（1）以快速上線，快速迭代方式發布單一系統為主要模式。單一系統開發易于調試，只需要簡單運行此應用；易于部署，只需要把打包應用拷貝到服務器端，通過在負載均衡器后端運行多個拷貝無狀態服務就可以輕松實現應用的橫行擴展。對于中小型web系統開發周期快，運維門檻低。（2）隨著需求變更，系統逐漸演變的越來越復制。最主要問題就是這個應用太復雜，以至于任何單個開發者都不可能搞懂它。因此，修正bug和正確的添加新功能變的非常困難，并且很耗時。另外，如果代碼難于理解，就不可能被正確的修改。最終會走向巨大的、不可理解的泥潭。（3）傳統開發模式無成本和效率優勢，制約企業發展。目前單一架構應用也使得采用新架構和語言非常困難。應用無法擴展，可靠性很低，最終，敏捷開發和快速部署變得無法完成。

2 微服務架構處理復雜事務

2.1 微服務架構優勢

微服務架構將服務拆分，分別采用相對獨立的服務對各方面進行管理，彼此之間使用統一的接口來進行交流，架構變得復雜，優勢也很明顯（如圖1）。

（1）解決了復雜性問題。它把龐大的單一模塊應用分解為一系列的服務，同時保持總體功能不變。這個應用被分解為多個可管理的分支或服務，每一個服務都有良好定義的邊界，以遠程過程調用（RPC）驅動或信息驅動的API的形式；微服務架構模式單一模塊代碼庫，實際很難實現。因此，獨立的服務開發速度明顯更快，而且更易理解和維護。

（2）讓每個服務能夠獨立開發，開發者能夠自由選擇可行的技術，讓服務來決定API約定。當然，大多數組織會通過限制技術選擇來避免完全的失控。然而，這種自由意味著開發者們不用被迫使用從項目開始就存在的陳舊技術，他們可以選擇使用當下的技術編寫一個新的服務。另外，由于這些服務本身相對比較小，用新的技術來重寫舊的服務也更可行一些。

（3）每個微服務都能獨立配置，開發者不必協調對于本地服務配置上的變化，這種變化一旦測試完成就被配置了。舉個例子，UI團隊可以執行A|B測試后立刻對UI的變化執行迭代。微服務架構模式使不斷地配置成為可能。

（4）讓每個服務都可以獨立調整，你可以給每個服務配置正好滿足容量和可用性限制的實例數。另外，你也可以使用最適合服務的資源需求的硬件。舉例說明，你可以在EC2計算優化的實例上配置CPU加強的圖片處理服務，另外給EC2存儲優化的實例配置內存中的數據庫服務。

2.2 實踐從單一模式系統重構到微服務架構系統

為了未來系統的擴展性，對原有龐大的單一模式系統進行微服務重構，既讓人興奮，又充滿挑戰，下文將提到幾種重構方案。這里需要強調下按照微服務架構，重寫全部系統代碼，對任何已經在線上運行的中大型web系統來說，都是不可行的，變更風險太大，系統測試不完善會直接導致，系統擋掉，無法對外提供服務。

2.2.1 停止在單一模式的系統上開發新業務

首先停止讓問題更糟。不要繼續通過向單一應用程序添加代碼的方式來實現新功能。采用某種方式來將新功能實現為獨立的服務。這可能并不容易。你可能會編寫凌亂的，復雜的膠水代碼來向單塊應用程序集成服務。但這是打散單塊程序的第一步。

這種方案有2個新增模塊“request router”和“glue code”（如圖2）：

Request Router

前端的請求路由層，用于處理（HTTP）請求，將符合新規則的請求發送給新增的服務，老的請求發給原有系統。

GlueCode

在程序設計中，為了讓新服務可以使用老系統的功能和數據設計編寫的，將不同部分的不兼容的代碼“粘合在一起”。在編寫代碼過程中，粘合代碼為了讓存在的庫或程序間進行交互。這里有3種訪問老系統方案：

（1）給單一系統添加遠程調用API

可以使用REST HTTP API

或者跨語言調用框架 Thrift RPC；

（2）直接訪問單一系統數據庫；

（3）訪問復制的同步的單一系統數據庫，并保持同步。

利用以往的開發經驗，可以新建一個可伸縮的微服務，控制住單一系統的復雜度。

2.2.2抽離web層與業務邏輯層

表現層與業務邏輯層分離。單一模式系統內的架構中，調整本地調用方法，更改為遠程調用方法。

典型Web應用通常由至少三個不同類型的部分組成（如圖3）：

表示層——處理HTTP請求并實現（REST）API或基于HTML的網頁UI的組件。在一個有復雜的用戶界面的應用中，表達層常常有大量的代碼段。

業務邏輯層——是應用的核心組件，實現業務規則。

數據訪問層——訪問基礎設施組件的組件，比如數據庫和消息代理。

抽離展現層的優點：

（1）接口預先定義，開發視野提升，需求驅動。

（2）開發和設計工作分離。

（3）利于更快定位性能瓶頸。

3 總結

單一模式是構建企業級應用程序常用的模式。對于小的應用程序它很適用：開發，測試和部署小型的單塊程序相對簡單。但是，對于大型的復雜的應用程序，單一模式會阻礙開發和部署。如果你經常長期的鎖定你的初始技術選擇，則會使得持續交付變得困難。對于大型的應用程序，更適合適用微服務架構，其將應用程序分解為一組服務。

微服務架構有很多優點。例如，單個服務更容易理解，可以獨立于其它服務來開發和部署。也更容易使用新的語言和技術，因為你可以一次只對一個服務嘗試新技術。微服務架構也有一些顯著的缺點。特別是對那些更復雜，擁有更多變化部分的應用程序。你需要高級別的自動化，來高效地使用微服務。你也需要在開發微服務時處理一些復雜的分布式數據管理問題。盡管有這些缺點，微服務架構還是更適用于大型的復雜的應用程序，因為可以快速演化。

參考文獻

[1] 韋伯.帕拉斯泰迪斯.魯濱遜.REST實戰：中文版超媒體和系統架構.中國：東南大學出版社，2011.

[2] MICROSERVICES From Design to Deployment by Chris Richardson with Floyd Smith.

[3] Building Micorservices by Sam Newman Copyright 2015 Published by OReilly Media.