云架構(gòu)下RS10系統(tǒng)遷移的策略和挑戰(zhàn)

戴云鵬，喬運(yùn)華，班玉榮，周文坤，張宵銘

（1.北京機(jī)械工業(yè)自動(dòng)化研究所，北京 100120；2.北京機(jī)械工業(yè)自動(dòng)化研究所有限公司，北京 100120）

0 引言

隨著時(shí)間的發(fā)展，RS10系統(tǒng)的功能越來越多，代碼也越來越復(fù)雜。在這種情況下，系統(tǒng)的迭代和重構(gòu)逐漸變得困難，即使出現(xiàn)了更適合系統(tǒng)的框架，也需要在昂貴的時(shí)間成本和人力成本面前讓步，不得不繼續(xù)使用原來的框架。系統(tǒng)啟動(dòng)需要的時(shí)間也越來越長，這對于需要多次重啟系統(tǒng)的底層開發(fā)者來說是一種折磨，嚴(yán)重的降低了系統(tǒng)的開發(fā)效率。由于所有模塊都運(yùn)行在一個(gè)進(jìn)程中，任何一個(gè)模塊中出現(xiàn)錯(cuò)誤，都有可能弄垮整個(gè)進(jìn)程，而隨著系統(tǒng)變得復(fù)雜，系統(tǒng)出現(xiàn)錯(cuò)誤的可能性逐漸增大，系統(tǒng)的穩(wěn)定性隨之降低。這些問題是單體式架構(gòu)無法解決的，因此將單體式架構(gòu)的系統(tǒng)遷移到更加支持復(fù)雜功能，更加容易擴(kuò)展的基于微服務(wù)架構(gòu)的云平臺上已經(jīng)變得刻不容緩。

1 RS10云平臺

RS10云平臺采用了docker容器引擎和Kubernetes編排調(diào)度引擎。平臺上負(fù)載的功能模塊主要包含持續(xù)集成模塊、鏡像倉庫模塊、負(fù)載均衡模塊、存儲模塊、安全認(rèn)證模塊、網(wǎng)絡(luò)模塊、日志模塊、監(jiān)控模塊這八個(gè)模塊。其中持續(xù)集成模塊主要作用是幫助開發(fā)人員自動(dòng)化完成代碼編譯、構(gòu)建及鏡像發(fā)布，并將生成的鏡像自動(dòng)部署運(yùn)行到平臺上。鏡像倉庫模塊主要作用是存儲和管理鏡像，無論是常用的鏡像，還是用戶打包的鏡像，都可以傳輸?shù)界R像倉庫中。負(fù)載均衡模塊負(fù)責(zé)將外部用戶訪問平臺服務(wù)的請求轉(zhuǎn)發(fā)給平臺內(nèi)運(yùn)行的相應(yīng)服務(wù)，并將訪問流量分?jǐn)偨o運(yùn)行中的容器應(yīng)用。存儲模塊負(fù)責(zé)提供多種類型的存儲資源，在容器應(yīng)用需要時(shí)動(dòng)態(tài)綁定。安全認(rèn)證模塊用于防止平臺中各個(gè)主機(jī)節(jié)點(diǎn)之間的通信內(nèi)容被第三方竊取和篡改。平臺各個(gè)主機(jī)節(jié)點(diǎn)之間采用客戶端證書認(rèn)證方式，客戶端和服務(wù)端需要相互驗(yàn)證證書，雙方都確認(rèn)證書的正確性后才會(huì)協(xié)調(diào)通信加密方案。網(wǎng)絡(luò)模塊是整個(gè)平臺運(yùn)行的基礎(chǔ)組件，在平臺搭建之初運(yùn)行，負(fù)責(zé)為平臺中運(yùn)行的每個(gè)容器應(yīng)用分配獨(dú)立的IP地址，使所有容器應(yīng)用之間都可以跨主機(jī)相互通信。日志模塊負(fù)責(zé)收集、存儲、展示整個(gè)平臺及平臺內(nèi)各個(gè)容器應(yīng)用的日志。監(jiān)控模塊用于監(jiān)控平臺中所有資源的使用情況，并提供圖表展示，同時(shí)負(fù)責(zé)將監(jiān)控到的異常情況發(fā)送給指定人員。

圖1 RS10云平臺層次結(jié)構(gòu)

2 系統(tǒng)遷移策略

系統(tǒng)從單體式架構(gòu)遷移到云平臺的過程應(yīng)該是平緩的，不應(yīng)該是一開始就將所有代碼重寫，這樣既充滿了風(fēng)險(xiǎn)，又不符合企業(yè)發(fā)展的需要，系統(tǒng)的遷移應(yīng)該是逐步的，有策略的。

2.1 從新服務(wù)到舊服務(wù)

系統(tǒng)在遷移的過程中，客戶需要的新功能如果繼續(xù)在原有的單體式架構(gòu)的系統(tǒng)上擴(kuò)展，不但會(huì)因?yàn)樵到y(tǒng)太復(fù)雜而需要很多時(shí)間，而且再次遷移到新平臺上會(huì)造成二次開發(fā)，浪費(fèi)時(shí)間的同時(shí)還會(huì)造成人力資源的浪費(fèi)。因此客戶需要的新功能可以直接在新平臺上進(jìn)行開發(fā)，這樣可以讓開發(fā)一步到位，減少資源和時(shí)間的浪費(fèi)。在開發(fā)完成新服務(wù)之后再遷移原來的舊服務(wù)。

2.2 從重要到次要

所有的服務(wù)都是系統(tǒng)的組成部分，系統(tǒng)遷移的目標(biāo)也是將所有的服務(wù)都遷移到云平臺上，但是有的服務(wù)是系統(tǒng)所必須的，是系統(tǒng)的基礎(chǔ)服務(wù)，如日志服務(wù)，安全認(rèn)證、監(jiān)控服務(wù)等，這些服務(wù)為系統(tǒng)的運(yùn)行提供了最基本的安全和功能保障，每個(gè)服務(wù)的運(yùn)行都要和這些服務(wù)進(jìn)行協(xié)同，因此這些使用最頻繁的，也是最重要的服務(wù)應(yīng)該首先遷移。其次還有一些其他的業(yè)務(wù)功能方面的服務(wù)，如郵箱、工作流等大部分用戶都要使用的服務(wù)，需要在基礎(chǔ)服務(wù)遷移之后進(jìn)行遷移，保證新平臺上的系統(tǒng)能夠滿足大多數(shù)用戶的需求，最后再將一些用戶使用較少的功能遷移到新平臺上。

2.3 新舊系統(tǒng)可以相互訪問

因?yàn)橄到y(tǒng)的遷移是逐步的，但是有些用戶在用到新系統(tǒng)上的服務(wù)的同時(shí)，還會(huì)用到舊系統(tǒng)上的服務(wù)，在系統(tǒng)遷移完成之前，很多用戶都會(huì)有這樣的需求，因此需要保證新平臺上的服務(wù)和舊有的系統(tǒng)之間可以相互訪問，這樣既保證了系統(tǒng)更新的穩(wěn)步前行，又不會(huì)影響客戶的使用體驗(yàn)，保證了系統(tǒng)可以穩(wěn)步遷移。

3 系統(tǒng)遷移面臨的挑戰(zhàn)

3.1 配置文件的分散

在單體式架構(gòu)下，配置文件是集中的，配置文件的修改方便且快捷，但是在微服務(wù)架構(gòu)下，每個(gè)微服務(wù)都是獨(dú)立部署和運(yùn)行的，如果將每個(gè)服務(wù)的配置信息都和鏡像打包在一起，就會(huì)出現(xiàn)配置文件分散的問題。每當(dāng)系統(tǒng)部署的環(huán)境發(fā)生改變，如從開發(fā)環(huán)境變成測試環(huán)境，都要重新修改配置信息并打包鏡像，隨著系統(tǒng)中的服務(wù)不斷增多，這個(gè)問題會(huì)變得越來越突出。因此不同于單體式架構(gòu)下將配置文件和程序同時(shí)集中在一個(gè)war包或ear包里面的方式，微服務(wù)架構(gòu)下的配置文件需要和程序分開，將所有配置文件集中在一起，集中進(jìn)行修改。采用nacos組件管理系統(tǒng)的配置文件可以解決這個(gè)問題。nacos可以將配置文件集中到一個(gè)UI界面上進(jìn)行修改，同時(shí)相同的配置可以合并，例如連接數(shù)據(jù)庫相同的服務(wù)可以共用一個(gè)數(shù)據(jù)庫配置文件，這樣方便修改的同時(shí)減少了文件的數(shù)量。

圖2 nacos配置文件管理

3.2 文件的存儲

在單體式架構(gòu)下，文件的存儲是一個(gè)很容易解決的問題，只要存儲到本地服務(wù)器即可，但是在微服務(wù)架構(gòu)下，服務(wù)運(yùn)行在不同的節(jié)點(diǎn)上，文件的存儲和共享就變成了一個(gè)需要考慮的問題。如果在每個(gè)節(jié)點(diǎn)上都指定一個(gè)目錄，負(fù)責(zé)存儲運(yùn)行在本節(jié)點(diǎn)上的服務(wù)上傳或修改的文件，會(huì)遇到很多問題。例如郵箱服務(wù)運(yùn)行在A節(jié)點(diǎn)，會(huì)把郵件以文件的方式存儲在A節(jié)點(diǎn)上。但是由于A節(jié)點(diǎn)資源緊張，郵箱服務(wù)調(diào)度到了B節(jié)點(diǎn)上運(yùn)行，由于不同節(jié)點(diǎn)上的目錄無法共享存儲文件，郵箱服務(wù)會(huì)發(fā)現(xiàn)在服務(wù)調(diào)度之前收到和發(fā)出的郵件無法讀取。因此為了解決這個(gè)問題，需要一個(gè)可以在不同節(jié)點(diǎn)上共享存儲目錄的文件系統(tǒng)。RS10系統(tǒng)使用了nfs，即網(wǎng)絡(luò)文件系統(tǒng)。nfs分為服務(wù)端和客戶端兩部分，文件存儲在服務(wù)端，客戶端只要將服務(wù)端的目錄掛載在本地，就可以像使用本地文件一樣使用資源[1]。這樣可以完美解決不同節(jié)點(diǎn)上的服務(wù)無法共享文件的問題。同時(shí)nfs可以設(shè)置客戶端的權(quán)限，既可以將客戶端的節(jié)點(diǎn)設(shè)置為只讀，也可以設(shè)置為具有讀寫權(quán)限，可以根據(jù)客戶的需求靈活設(shè)置權(quán)限。nfs依賴于RPC協(xié)議傳輸數(shù)據(jù)，服務(wù)端通過網(wǎng)絡(luò)訪問位于服務(wù)端的文件，本身并不占用磁盤空間，這無疑極大地節(jié)省了系統(tǒng)的磁盤資源，避免磁盤被重復(fù)的文件占用資源。

3.3 系統(tǒng)的響應(yīng)速度

微服務(wù)架構(gòu)服務(wù)間通過TCP/IP進(jìn)行通信，不同節(jié)點(diǎn)上的服務(wù)通信勢必要受到網(wǎng)絡(luò)延遲的影響，使系統(tǒng)的響應(yīng)速度變慢。但是網(wǎng)絡(luò)延遲無法在系統(tǒng)方面解決，因此為了系統(tǒng)的整體響應(yīng)速度不受影響，需要提高數(shù)據(jù)庫的響應(yīng)速度。為了提高數(shù)據(jù)庫的響應(yīng)速度，RS10系統(tǒng)使用redis作為公共緩存。不同于一般使用的數(shù)據(jù)庫在磁盤上進(jìn)行IO操作，redis運(yùn)行在內(nèi)存上，因此擁有極快的讀寫速度。將數(shù)據(jù)庫中使用頻繁的數(shù)據(jù)存入redis中，這樣客戶端發(fā)送請求之后，首先到redis中查詢數(shù)據(jù)，如果有數(shù)據(jù)則直接返回，否則到一般數(shù)據(jù)庫中查詢，并將數(shù)據(jù)存放到緩存中[2]。這樣看似增加了一個(gè)步驟，使訪問變得復(fù)雜，但是相同數(shù)據(jù)只需要在數(shù)據(jù)庫中查找一次，剩余查詢在緩存中進(jìn)行，這無疑大大提高了系統(tǒng)整體的響應(yīng)速度，提高了系統(tǒng)的用戶體驗(yàn)[3]。同時(shí)redis還有限流的功能，可以保證高并發(fā)下系統(tǒng)的穩(wěn)定。

圖3 數(shù)據(jù)庫訪問示意圖

4 結(jié)語

系統(tǒng)的遷移是復(fù)雜的，從單體式架構(gòu)到微服務(wù)架構(gòu)的遷移，必須要講究策略。一開始就將代碼完全重寫，既有很大的風(fēng)險(xiǎn)，又不符合企業(yè)發(fā)展的需要。采用從新服務(wù)到舊服務(wù)、從重要到次要、新舊系統(tǒng)可以相互訪問的策略，將新功能的開發(fā)放在新平臺上，在滿足系統(tǒng)升級擴(kuò)展的同時(shí)，將舊有系統(tǒng)的功能逐漸拆分，平滑且穩(wěn)定的遷移到新平臺上，將系統(tǒng)遷移的風(fēng)險(xiǎn)降到最低，這樣可以最大程度的保證系統(tǒng)在新平臺上的穩(wěn)定性。在遷移過程中，一定會(huì)遇到很多挑戰(zhàn)，如配置文件的分散，文件存儲困難等。但結(jié)果是可以預(yù)期的，在穩(wěn)定的遷移策略下，困難終將被一一克服。