云架構下RS10系統遷移的策略和挑戰

戴云鵬，喬運華，班玉榮，周文坤，張宵銘

（1.北京機械工業自動化研究所，北京 100120；2.北京機械工業自動化研究所有限公司，北京 100120）

0 引言

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

1 RS10云平臺

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

圖1 RS10云平臺層次結構

2 系統遷移策略

系統從單體式架構遷移到云平臺的過程應該是平緩的，不應該是一開始就將所有代碼重寫，這樣既充滿了風險，又不符合企業發展的需要，系統的遷移應該是逐步的，有策略的。

2.1 從新服務到舊服務

系統在遷移的過程中，客戶需要的新功能如果繼續在原有的單體式架構的系統上擴展，不但會因為原系統太復雜而需要很多時間，而且再次遷移到新平臺上會造成二次開發，浪費時間的同時還會造成人力資源的浪費。因此客戶需要的新功能可以直接在新平臺上進行開發，這樣可以讓開發一步到位，減少資源和時間的浪費。在開發完成新服務之后再遷移原來的舊服務。

2.2 從重要到次要

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

2.3 新舊系統可以相互訪問

因為系統的遷移是逐步的，但是有些用戶在用到新系統上的服務的同時，還會用到舊系統上的服務，在系統遷移完成之前，很多用戶都會有這樣的需求，因此需要保證新平臺上的服務和舊有的系統之間可以相互訪問，這樣既保證了系統更新的穩步前行，又不會影響客戶的使用體驗，保證了系統可以穩步遷移。

3 系統遷移面臨的挑戰

3.1 配置文件的分散

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

圖2 nacos配置文件管理

3.2 文件的存儲

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

3.3 系統的響應速度

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

圖3 數據庫訪問示意圖

4 結語

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