企業傳統應用架構向微服務架構轉型的一種流程設計

劉帥華， 王天青

(1. 上海道客網絡科技有限公司， 上海 200233； 2. 星環信息科技(上海)股份有限公司， 上海 200233)

0 引言

在互聯網化轉型過程中，傳統企業的銷售模式轉為直接服務最終消費者。這對企業創新的速度，服務的連續性、擴展性和移動為中心的用戶體驗提出了很高的要求。相應地，也對企業IT架構，以及軟件交付的速度及質量提出了新的要求。云原生[1]技術棧正好符合企業架構轉型的需求，但是經研究數十個項目的經驗表明，企業轉型過程中，具體的架構技術，DevOps研發流程和工具鏈往往并不是首當其沖的問題，最大挑戰往往是這些傳統企業缺乏對整個轉型流程的正確認識[2]。

傳統的應用架構，不管是單體架構還是SOA架構，在滿足這樣的需求方面往往已經力不從心了。微服務架構[3]的提出恰當其時。簡單來說，微服務架構風格是一種將一個單一應用程序開發為一組小型服務的方法，每個服務運行在自己的進程中，服務間通信采用輕量級通信機制。這些服務圍繞業務能力構建并且可通過全自動部署機制獨立部署。這些服務共用一個最小型的集中式管理，服務可用不同的語言開發，使用不同的數據存儲技術。

然后，這種轉型并不容易，在轉型的過程中，很多企業往往只了解了微服務架構本身或者微服務開發框架本身，但是對于如何落地微服務架構，包括從需求分析、系統設計、代碼框架、研發流程與平臺和應用運行平臺等多個方面如何循序漸進并相互配合的推進缺少系統化的認識，導致了轉型失敗或者低效。

(1) 業務人員對IT和研發不甚了解，表達需求的時候使用了很多口語化的表達，而不是系統性和結構化的表述需求。但是，任何一個微服務架構都是對業務架構的映射，因此開發者需要一套方法梳理需求，將其中的業務邏輯、流程和約束以形式化的方式進行描述，從而便于開發人員理解和實現需求。

(2) 服務的劃分往往憑著架構師或者開發人員的經驗，沒有一套成熟的方法論。因此，需要一套方法論將單體應用進行拆分為一組合理的微服務，以便滿足業務部門對應用架構的需求。

(3) 基礎架構往往只是使用了虛擬化技術，對應用的編排、調度、監控和日志等支持相對較弱，同時很多操作都是手工完成。因此，需要一套敏捷的基礎架構系統，用來支撐微服務系統由于它的復雜性帶來的編排、監控和日志等新的挑戰。

(4) 交付流程自動化程度低，往往只實現了持續集成。因此，需要一套從需求分析、編碼、測試、部署到運維的一套方法論和工具鏈來加快從代碼到生產的交付速度和信心指數。

1 架構設計的流程與方法

企業傳統應用架構向微服務架構轉型是一個系統工程，因此需要使用一套清晰完善的、具有普適性的流程指導幫助轉型。針對企業傳統應用架構向微服務架構轉型遇到的挑戰，經過多個項目的實踐和總結，總結出了一套轉型流程，能夠很好地解決轉型過程中遇到的問題，如圖1所示。

圖1 轉型流程

由圖1可知，前5部分為應用架構的轉型，后5部分是使用容器技術和DevOps自動化流程來標準化交付物和交付流程，以及滿足微服務架構帶來的自動化運維需求。每一步的具體研究如下。

(1) 傳統應用架構的調研，了解企業目前的業務結構，系統架構及各類運營指標。

(2) 業務架構梳理：可以使用用戶故事地圖[4]，將需要完成的功能按照時間維度進行排序和管理，同時編寫產品需求文檔，將重要的業務流程，邏輯和約束進行描述。

(3) 領域設計：使用領域驅動設計[5]的方法論和原則，識別上下文和領域，定義領域模型、實體對象和值對象等。

(4) 系統設計：主要針對系統性的需求[6]，即非功能性需求來進行設計。例如，為了達到系統高可用，對于服務經過研究需要采用Master-Slave或者Cluster的方式；為了達到高伸縮性，需要使用負載均衡和服務注冊與發現。

(5) 微服務開發框架引入：業界已經整理出了微服務架構的一些核心模式[7]，同時例如Spring Cloud[8]這樣的微服務開發框架已經將微服務的一些核心模式以組件的方式提供支持，包括配置中心、服務注冊與發現、熔斷器和分布式追蹤等，因此可以將這樣的開發框架引入，加快微服務應用的開發。

(6) 微服務基礎設施構建：除了微服務業務和通用服務之外，配置中心、服務注冊與發現和熔斷器等微服務基礎組件需要按需要進行構建，核心是根據應用需求設置部署模式和配置參數。

(7) DevOps自動化流程構建：微服務架構帶來的復雜性，導致用人工部署/管理的成本極高，因此經過研究需要將需求分析的工具、任務分配的工具、代碼管理的工具、持續集成的工具、測試的工具、部署的工具和運維的工具，按照既定的流程整合在一起，并實現自動化，從而加快交付的速度及質量。

(8) 應用容器化：容器[9]技術最大的好處是標準化，它將程序及其依賴的環境以鏡像的方式標準化，從而確保它在任何支持容器的操作系統上運行的行為是一樣的。同時它標準化了運維的工作，簡化了運維的復雜程度。

(9) 容器管理平臺集成：當運行的容器數量大大增加并且跨多臺主機的時候，容器管理平臺[10]就顯得非常重要。它提供了容器編排、調度、監控和日志管理等管理平臺必備的功能。

(10) 微服務運維設施構建：微服務架構中服務是第一公民，而容器世界中容器是第一公民，因此一些有交集的功能，如應用的服務注冊與發現和容器的服務注冊與發現需要很好地集成在一起，以免出現不匹配的情況。

2 轉型實踐

傳統三層架構圖如圖2所示。

圖2 傳統三層架構圖

應用該流程設計，以上述車企為例，轉型前它的架構是一個典型的三層架構，遇到了如下問題。

(a) 系統耦合性高

① 做任何改動花費太高；

② 功能，一掛全掛；

③ 模塊與模塊之間功能有重疊，設計不合理，存在數據不一致的問題。

(b) 故障定位難

① 發生異常時，對于影響范圍無法做出清晰的判斷；

② 用戶請求在系統內部的執行流程無法有效跟蹤。

(c) 故障恢復復雜

當發生異常時，會終止鏈接，要靠人工恢復，非常慢，而2017年，該App需要支撐的業務目標卻有如下幾點。

① 用戶數：2017年底目標120萬，挑戰150萬；

② 迭代速度：一月一迭代，全年完成49個大功能；

③ 可用性：滿足99.9%核心業務可用性；

④ 性能：單一請求響應不超過3秒。

因此按照上述轉型流程對它進行轉型，如下。

① 對已有需求和2019年的新需求進行梳理。

② 重新構建用戶故事地圖。

③ 根據業務梳理的結果進行領域設計，劃分領域并定義微服務。

④ 根據可用性和性能需求，對系統進行設計，包括緩存機制，負載均衡機制等。

⑤ 將原有Spring MVC項目改造為Spring Cloud項目。

⑥ 引入配置中心，服務注冊與發現，熔斷器等微服務基礎服務。

⑦ 使用以Jenkins為核心持續交付平臺，將相關的工具整合進來，并增加自動化測試的比例。

⑧ 引入Docker，構建基礎鏡像并構建應用的鏡像。

⑨ 引入K8S，一種容器管理平臺，提供了應用編排，性能監控，日志管理，負載均衡，自動伸縮功能等能力。

⑩ K8S能夠和Spring Cloud Discovery集成，正確完成應用的服務注冊與發現功能。

按照這個基本思路，拆分后包含10個業務服務，3個基礎服務，7個微服務基礎服務。目前注冊人數達到60萬，兩周一個迭代，已經完成上線30個功能。

3 總結

傳統企業的應用架構向微服務架構轉型的過程中，面臨著各種困難，各種先進的技術，流行DevOps研發流程和強大工具鏈，并不是轉型成功的特效藥。作為經驗匯集，經過研究提出了一個轉型的流程包括：分解需求，使用領域驅動的設計方法，按照特定的非功能性需求進行設計，并引入微服務開發框架，DevOps平臺，容器平臺等技術，加快業務開發，提升自動化交付的水平，從而加快軟件交付的質量與速度等步驟。這一套流程具有一定的普適性，它是對現有技術，方法，流程和工具的一個有機組合，對轉型實踐具有很好的指導作用。