背景

我們這邊有一個系統，和大多數系統一樣吧，涉及后臺管理部分、后臺管理相關服務、數據庫，另外，由于該系統對app提供接口，還涉及app接口服務。這個系統，業務上歸屬于我們部門，但是目前在線上，是在另一個部門的服務器上運行（這個部門是由于前兩年組織架構調整，從我們部門拆分出去成立的），運行也算平穩，但是，這個系統最近突然有個需求要做，新部門這邊明確表示需求他們不做，他們不做，就我們做唄。但是，我們開發完，上線又去他們的服務器上上線，流程也比較麻煩，我們這邊最后決定是把系統遷回到我們部門的服務器上運行。

這個系統整體遷移完成，大概兩個月左右，還是比較麻煩的，大概包括：現狀梳理、遷移方案評審、開發驗證、測試方案評審、測試驗證、運維上線方案評審、運維上線、業務上線。下面簡單講講。

這個系統，在經過對線上鏈路的梳理后，也畫了架構圖，大體來說呢，類似下面這樣：

大家可以看到，上圖有的是紅色，有的是綠色，這個圖實際是最終我們這邊部署完成后的架構圖，對方部門那邊得原始架構也差不多（我就偷懶不弄了），畢竟這次任務就是做遷移，相當于把系統涉及的各類組件，都在我們這邊部署一遍。當然了，有些組件其實我們已經有了，如后臺管理系統、內部路由服務，這兩個服務只需要做一些變更就行了，不用新部署；另外的綠色部分組件，就是我們這邊沒有的，本次需要在我們這邊新部署。另外，還有個APP測路由的組件（可以簡單理解為業務網關，如spring gateway），這個組件，原本是把app側的接口轉發到對方業務部門的服務，現在是要改一下，轉到我們這邊的業務服務A來，這樣呢，app側是無感的。

后臺管理部分

前端頁面的遷移

這個后臺管理系統，其實挺有意思，是傳統的以前servlet war包部署的架構，不過servlet容器不是tomcat，是resin（以前我也沒聽過）。不過這個不重要，這個管理系統，是廠商做的，一般來說，廠商把系統賣給我們了，但我們后續想在這個管理系統里加一些菜單、頁面、功能，怎么辦呢？難道廠商來給我們開發嗎，那是不可能的，因為廠商賣給我們的這套系統是沒賣源碼的，沒法改。

那這個系統怎么支持加菜單、頁面這些呢？

這個系統做了些功能，支持你新建菜單，點擊菜單后一般會渲染一個前端頁面對吧，那頁面怎么來呢，它就還支持你創建一個前端頁面：

頁面內容由你自己定義，可以看到，下面就是一些前端標簽，但這個標簽怎么都帶了個前綴啥的，這我也沒仔細研究，自然是弄了個前端渲染的引擎，不然瀏覽器肯定不認識這個html：

然后呢，頁面數據從哪里來呢，點擊按鈕后，又觸發什么動作呢。這些都是可以自己定義的，比如上圖我框出來的，這個form對應的加載數據的事件就是e_q_important_notice。

那這個事件其實就相當于我們現在的接口了，但是為了保證擴展性，這里支持好幾種事件。

這里的bus接口就是類似于現在的rest接口，只是你要指定一個服務名和接口名。

如果是想直接查庫，也是支持的，需要指定一個datasource的名字（后臺配置了對應datasource的數據庫連接信息，ip端口用戶名密碼啥的）：

所以，靠這么一套框架，廠商，既賣了管理系統給我們，代碼沒泄露，且后續的業務開發還不需要他們投人力。該說不說，10幾年搞的這套東西，還是不錯的，雖然它不符合現在的時代了（開發頁面很不舒服，效率低），但上面有太多的業務功能了，該維護還得維護著。

說回遷移，所以這次，前端的遷移還是比較簡單，因為這些頁面對應的html代碼、事件啥的，都是存儲在管理系統的數據庫里的，而且頁面上支持導出這些html代碼、事件，我們只需要把他們在原系統導出，然后在我們這邊的系統導入即可。

為什么我們這邊可以直接導入呢，導入到哪里呢，因為那時候基于廠商這套框架，搞了2個后臺管理系統，1個是給員工相關系統用的（employee），1個是給app那種面向客戶的系統用的（customer），兩個系統獨立演化了好些年，已經大不相同（畢竟廠商不能預判到所有需求，所以之前的開發同事們，在各自負責系統上弄了各種騷操作，后面會提到）。

部門拆分后，當時兩個系統都歸他們，后來呢，為了部門切割干凈，我們把給員工用的那個系統（employee）復刻了一套（假設為employee-own），這次要遷移的功能的前端頁面，其實是在customer那一套上面的，也就是從customer導出，然后在employee-own中導入。

數據庫遷移

這塊其實還是有點麻煩，我們做完遷移方案評審后，接下來就是驗證方案的可行性。我先在開發環境做驗證，盡量確保各種坑都能踩到。但我們這邊的開發環境、測試環境，都沒有這個庫，然后對方部門呢，由于這個業務也是好幾年沒需求了，他們的開發、測試環境的庫，和目前的線上環境也是差異很大。

為了保證在開發、測試環境的遷移步驟和生產一樣，我們就直接是申請從線上數據庫整庫dump，數據量大概30-40個g左右吧，但問題是里面有不少敏感數據，然后就又發郵件給各路領導，申請導出脫敏的線上庫，然后在開發、測試環境進行恢復。

至于線上的話，其實更麻煩一點，因為我們這個庫的部分表，是從上游通過數據倉庫同步來的，也就是我們依賴人家；另外呢，我們這邊產生的一些數據，又需要通過數倉同步給下游，另一些人依賴我們，生產上的遷移，就會涉及到這些同步鏈路的切換，主要是協調溝通、確保萬無一失為主。另外，我們這邊，數據庫是dba們負責，數據倉庫是另外的小組負責，而數倉同步時，需要確保源庫、目標庫的網絡暢通、且需要分配對應的數據庫賬號（要有對應的權限）。

內部路由服務遷移

這個就比較簡單，原部門的路由服務和我們用的路由服務，都是廠商的同一套技術，路由，我們一般就是改下目標服務的ip端口就行了。

業務服務遷移

業務服務，我們這邊也是廠商搞的一套，大家簡單理解為spring后臺接口服務即可。主要就是把原來的服務從對方部門的服務器上dump一份出來，在我們這邊服務器上拷貝，然后改改配置，比如數據庫配置改一下。

當然，廠商喜歡搞license這一套，dump出來后，在我們機器上發現就運行不了了，說license不對，然后這個玩意都過保了，廠商都不維護了。后來才從一個哥們那邊拿到不需要license的版本。

遇到的各種問題

其實整體來看，把這些各種服務弄起來倒是不難，難在各種細節。

確保遷移后文件上傳路徑不變

在后臺管理系統中上傳圖片等，具體上傳到什么地方，都是靠各種配置。然后前端上傳時，去查詢這些配置。如下,接口就是會返回上傳的接口路徑、上傳的相對路徑等。

這里有一個點就是，上傳完成后，我們會拿到一個文件的相對路徑，存儲到數據庫中。app側要展示這些文件時，是查到后端返回的相對路徑再去拼接成絕對路徑。

在app端不改動的情況下，我們必須確保，遷移后的文件上傳路徑，在app端是可以訪問的，那就需要去梳理這些亂七八糟的配置是怎么玩的，具體就不說了。

富文本編輯器xml轉義問題

遷移過來的頁面，涉及使用富文本編輯器，ueditor，支持寫word這種。

最終呢，數據庫里會把這個富文本存儲起來：

結果測試同事發現，在app端展示的格式不對，后來一查，是數據庫里對那些< 、>這種xml元素做了轉義，存儲在數據庫的就是下面這種：

后來才定位到是后臺管理系統的那個廠商框架搞的鬼。如果要想不進行xml轉義，要把這些接口對應的字段配成白名單。

ueditor表格不展示邊框問題

這個問題折騰了我夠嗆，就是說，在ueditor里表格有邊框，但是app側看就沒有，如下：

剛開始以為是app有問題，后來把數據庫里存的html拿出來渲染，一看也沒有邊框，那就是后端寫進去就有問題了。

一開始也以為是后臺管理系統的問題，后來通過查看接口參數、抓包等，也排除了，發現就是前端這個ueditor的問題。

但，有個很疑惑的點，目前，app里的展示的那些老的文章，都是有邊框的；我們就不知道，老系統（線上正在運行的，對方部門的那個系統：customer）難道沒問題，只有我們的復刻的employee-own有問題？

技術架構都是廠商那套，但獨立運行了這么多年，有什么差異也很正常，我也找了好久的問題，對前端js進行了一陣子調試（就在頁面上F12 debug，還是比較痛苦，前端異步又多，經常就不知道跳哪里去了），對比了兩個系統的不少配置，我就感覺，老系統（customer那套）應該也有類似問題。

后來找對方部門的同事配合驗證，檢查了數據庫里寫進去的html，發現也是沒邊框的，所以認定在他們那邊確實應該有類似問題。唯一的問題就是，不知道目前在使用這個功能的業務運營人員，到底是怎么繞過這個bug的，然后我們開始去想辦法聯系業務運營人員，但我們也不知道誰在使用這個功能，就發郵件讓人梳理，收到郵件的人又怕漏了擔責，就推事，過了好久才聯系到使用這塊的業務人員。

當時開會時，一聽她說的辦法，我就明白了，是uedirot提供了一個按鈕，對著表格點右鍵，有一個隱蔽的按鈕：設置表格邊線可見。 參考：https://www.ymama.net/news/txtlist_i2124v.html

為啥我沒發現這個功能呢，首先就是，我剛開始甚至不知道還能右鍵，一般web系統很少做這種右鍵操作；其次，這個右鍵呢，按鈕很多，如果屏幕分辨率不高，就看不到（算是一個bug）

我之前的定位思路歪了，因為當時想著，表格要么是在ueditor里插入，要么word里弄好了貼過來。

ueditor里插入表格，我找到了解決方案，就是要改下js源碼：

https://blog.csdn.net/qq_33769914/article/details/97612061
修改ueditor.all.js里面的 UE.commands['inserttable']函數

加上下面標紅的樣式：

style="border:1px solid #ddd;" 

style="border-collapse:collapse;"

但從word里粘貼的話，邊框就被ueditor的代碼自動去掉了，這塊的邏輯死活沒弄清楚（個人前端能力不足）。

后來知道業務人員可以繞過后，也就沒管了。

ueditor附件上傳問題

這個問題是完成上線后才發現的，測試也沒測到，剛上線的前幾天也沒遇到，因為當時業務不需要在ueditor里傳附件。

用戶說，這塊會失敗:

然后，其實直到業務反饋的時候，我們才知道，這個富文本編輯器，還能傳附件呢。當時時間很緊急，對這塊也不理解，運維同事也請假了，然后就協調業務同事先想辦法繞過這個問題，比如不傳附件。。

后來開始排查，讓運維看下管理系統的日志，發現是報主機名無法解析：

這個域名竟然是文件服務器的地址，之前都不知道，管理系統所在的服務器，還會直接訪問文件服務器的接口。

通過這個域名，我找到了配置這個地址的地方。然后運維側，配置了hosts文件后，再試，發現又報：

是https請求時，證書有問題。由于當時急于恢復，讓業務能不受影響，我提議改成http訪問，我們試了下，http協議對應的端口是通的，那就太好了，不用申請開網絡。改成http后，重啟服務，這塊就解決了。

后來我空余又看了下，這個https問題其實就是：因為后臺管理系統是jdk1.7的，而jdk1.7信任的根證書庫里，沒有digicert global root g2，而文件服務器返回的根證書正好就是g2.

這塊只需要把g2導入到根證書信任庫中即可。

ueditor附件上傳如何實現了自定義

當時我雖然猜測到了附件上傳配置：上傳url的地方，

但是代碼沒搞明白怎么走的，如下圖這個報錯的調用棧，這個FileService的包名就能看出來，是廠商這邊的代碼，而ueditor是百度出的，這個ueditor是如何被修改成調我們自己的文件服務器接口的呢？

我剛用阿里那個arthas工具，看了下百度那個類的情況（就是調用我們廠商代碼的上一層）：

發現這個類，竟然不是從jar包里加載的，而是從WEB-INFO/classes目錄下加載的，而classes下，一般主要是些配置文件啊。

去看了下，發現下面真有class，甚至還有源碼文件。我查看了源碼文件后，發現就是這里面修改了百度原來的實現，改成了調我們自己的文件服務器。

為啥要放到WEB-INFO/classes下呢，因為要確保classloader加載這個類時，優先加載。

再一個就是，我之前還以為程序用到是另一處地方（存放ueditor前端js的地方）的ueditor-1.1.2.jar呢，沒想到還是WEB-INF下的，看來還是不能亂猜：

而且，上圖中的那幾個ueditor框架中帶的那幾個jar包，都全拷貝到了WEB-INF/lib下，但有個包有點怪：

官方ueditor帶的是json.jar，而我們這邊，不知道為什么是：json-20160212.jar

不知道又是這幫哥們為啥這么弄，我就先不深究了。

兩個包內容比了下，不一樣，我也找到了這個20160212的包，這里記錄下。

https://mvnrepository.com/artifact/org.json/json/20160212

<!-- https://mvnrepository.com/artifact/org.json/json -->
<dependency>
    <groupId>org.json</groupId>
    <artifactId>json</artifactId>
    <version>20160212</version>
</dependency>

總結

這個事，主要是技術工作和各種溝通協調工作，前前后后兩個月，弄完上線，也算是了了一個事，壓力小了不少。技術上看著并不困難，就是把服務各種重新部署、已有的服務改一改就完了，但是，中間的任何一個細節漏了，就會導致出現各種問題，不過，細心點，基本還是都能解決，要相信：辦法總比困難多，實在不行，還可以繞著走。