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

劉帥華， 王天青

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

0 引言

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

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

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

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

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

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

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

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

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

圖1 轉(zhuǎn)型流程

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

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

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

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

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

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

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

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

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

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

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

2 轉(zhuǎn)型實(shí)踐

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

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

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

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

① 做任何改動(dòng)花費(fèi)太高；

② 功能，一掛全掛；

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

(b) 故障定位難

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

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

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

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

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

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

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

④ 性能：?jiǎn)我徽?qǐng)求響應(yīng)不超過(guò)3秒。

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

① 對(duì)已有需求和2019年的新需求進(jìn)行梳理。

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

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

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

⑤ 將原有Spring MVC項(xiàng)目改造為Spring Cloud項(xiàng)目。

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

⑦ 使用以Jenkins為核心持續(xù)交付平臺(tái)，將相關(guān)的工具整合進(jìn)來(lái)，并增加自動(dòng)化測(cè)試的比例。

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

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

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

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

3 總結(jié)

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