企業(yè)傳統(tǒng)應(yīng)用架構(gòu)向微服務(wù)架構(gòu)轉(zhuǎn)型的一種流程設(shè)計

劉帥華， 王天青

(1. 上海道客網(wǎng)絡(luò)科技有限公司， 上海 200233； 2. 星環(huán)信息科技(上海)股份有限公司， 上海 200233)

0 引言

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

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

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

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

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

(3) 基礎(chǔ)架構(gòu)往往只是使用了虛擬化技術(shù)，對應(yīng)用的編排、調(diào)度、監(jiān)控和日志等支持相對較弱，同時很多操作都是手工完成。因此，需要一套敏捷的基礎(chǔ)架構(gòu)系統(tǒng)，用來支撐微服務(wù)系統(tǒng)由于它的復(fù)雜性帶來的編排、監(jiān)控和日志等新的挑戰(zhàn)。

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

1 架構(gòu)設(shè)計的流程與方法

企業(yè)傳統(tǒng)應(yīng)用架構(gòu)向微服務(wù)架構(gòu)轉(zhuǎn)型是一個系統(tǒng)工程，因此需要使用一套清晰完善的、具有普適性的流程指導(dǎo)幫助轉(zhuǎn)型。針對企業(yè)傳統(tǒng)應(yīng)用架構(gòu)向微服務(wù)架構(gòu)轉(zhuǎn)型遇到的挑戰(zhàn)，經(jīng)過多個項目的實踐和總結(jié)，總結(jié)出了一套轉(zhuǎn)型流程，能夠很好地解決轉(zhuǎn)型過程中遇到的問題，如圖1所示。

圖1 轉(zhuǎn)型流程

由圖1可知，前5部分為應(yīng)用架構(gòu)的轉(zhuǎn)型，后5部分是使用容器技術(shù)和DevOps自動化流程來標(biāo)準(zhǔn)化交付物和交付流程，以及滿足微服務(wù)架構(gòu)帶來的自動化運維需求。每一步的具體研究如下。

(1) 傳統(tǒng)應(yīng)用架構(gòu)的調(diào)研，了解企業(yè)目前的業(yè)務(wù)結(jié)構(gòu)，系統(tǒng)架構(gòu)及各類運營指標(biāo)。

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

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

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

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

(6) 微服務(wù)基礎(chǔ)設(shè)施構(gòu)建：除了微服務(wù)業(yè)務(wù)和通用服務(wù)之外，配置中心、服務(wù)注冊與發(fā)現(xiàn)和熔斷器等微服務(wù)基礎(chǔ)組件需要按需要進行構(gòu)建，核心是根據(jù)應(yīng)用需求設(shè)置部署模式和配置參數(shù)。

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

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

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

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

2 轉(zhuǎn)型實踐

傳統(tǒng)三層架構(gòu)圖如圖2所示。

圖2 傳統(tǒng)三層架構(gòu)圖

應(yīng)用該流程設(shè)計，以上述車企為例，轉(zhuǎn)型前它的架構(gòu)是一個典型的三層架構(gòu)，遇到了如下問題。

(a) 系統(tǒng)耦合性高

① 做任何改動花費太高；

② 功能，一掛全掛；

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

(b) 故障定位難

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

② 用戶請求在系統(tǒng)內(nèi)部的執(zhí)行流程無法有效跟蹤。

(c) 故障恢復(fù)復(fù)雜

當(dāng)發(fā)生異常時，會終止鏈接，要靠人工恢復(fù)，非常慢，而2017年，該App需要支撐的業(yè)務(wù)目標(biāo)卻有如下幾點。

① 用戶數(shù)：2017年底目標(biāo)120萬，挑戰(zhàn)150萬；

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

③ 可用性：滿足99.9%核心業(yè)務(wù)可用性；

④ 性能：單一請求響應(yīng)不超過3秒。

因此按照上述轉(zhuǎn)型流程對它進行轉(zhuǎn)型，如下。

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

② 重新構(gòu)建用戶故事地圖。

③ 根據(jù)業(yè)務(wù)梳理的結(jié)果進行領(lǐng)域設(shè)計，劃分領(lǐng)域并定義微服務(wù)。

④ 根據(jù)可用性和性能需求，對系統(tǒng)進行設(shè)計，包括緩存機制，負載均衡機制等。

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

⑥ 引入配置中心，服務(wù)注冊與發(fā)現(xiàn)，熔斷器等微服務(wù)基礎(chǔ)服務(wù)。

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

⑧ 引入Docker，構(gòu)建基礎(chǔ)鏡像并構(gòu)建應(yīng)用的鏡像。

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

⑩ K8S能夠和Spring Cloud Discovery集成，正確完成應(yīng)用的服務(wù)注冊與發(fā)現(xiàn)功能。

按照這個基本思路，拆分后包含10個業(yè)務(wù)服務(wù)，3個基礎(chǔ)服務(wù)，7個微服務(wù)基礎(chǔ)服務(wù)。目前注冊人數(shù)達到60萬，兩周一個迭代，已經(jīng)完成上線30個功能。

3 總結(jié)

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