[[334093]]

 1. 項目遷移背景

1.1 為什么要在“太歲”上動土?

目前公司的測試環境、UAT環境、生產環境均已經使用k8s進行維護管理，大部分項目均已完成容器化，并且已經在線上平穩運行許久。在我們將大大小小的項目完成容器化以后，測試、UAT、生產環境的發版工具以及CICD流程慢慢的實現統一化管理，并且基于k8s開發了內部的發版審核平臺，同時接入了Jira等項目管理工具。

在自研平臺進行發版時，能夠自動關聯項目的開發進度以及Release版本，最重要的是其可以控制發版權限、統一發版工具及發版模式，并且支持一鍵式發版多個項目的多個模塊，同時也包括了發版失敗應用的統一回滾及單個應用的回滾。

因為該項目從始至今一直在使用GitRunner進行發版，并且基于虛機部署，所以一直沒有集成到發版審核平臺，但是由于項目比較重要，并且涉及的服務和機器較多，所以必須要把這個項目進行容器化并且統一發版工具才能更好的適應公司的環境，以及更好的應對下一代云計算的發展。

1.2 為什么要棄用Git Runner?

首先我們看一下Git Runner發版的頁面，雖然看起來很簡潔清爽，但是也難免不了會遇到一些問題。

 

 

1.2.1 多分支并行開發問題

當多分支并行開發或者能夠發版到生產環境的分支較多時，很容易在手動部署的階段點錯，或者看串行，當然這種概率很小。

但是我們可以看到另外一個問題，每次提交或者合并，都會觸發構建，當我們使用Git Flow分支流時，可能同時有很多分支都在并行開發、并行測試、并行構建，如果Git Runner是基于虛機創建的，很有可能會出現構建排隊的情況，當然這個排隊的問題，也是能解決的。

1.2.2 多微服務配置維護問題

其次，如果一個項目稍微大一些，維護起來也不是很方便。比如這個準備要遷移的項目，一個前端和二十多個業務應用，再加上Zuul、ConfigServer、Eureka將近三十個服務，每個服務對應一個Git倉庫，然后每個服務同時在開發的分支又有很多，如果想要升級GitLab CI腳本或者微服務的機器想要添加節點，這將是一個枯燥乏味的工作。

1.2.3 安全問題

最后，還有一個安全的問題，GitLab的CI腳本一般都是內置在代碼倉庫里面的，這就意味著任何有Push或者Merge權限的人都可以隨意的修改CI腳本，這會導致意想不到的結果，同時也會威脅到服務器和業務安全，針對發版而言，可能任何的開發者都可以點擊發版按鈕，這些可能一直都是一個安全隱患。

但是這些并不意味著Git Runner是一個不被推薦的工具，新版的GitLab內置的Auto DevOps和集成Kubernetes依舊很香。但是可能對于我們而言，使用Git Runner進行發版的項目并不多，所以我們想要統一發版工具、統一管理CI腳本，所以可能其它的CI工具更為合適。

1.3 為什么要容器化?

1.3.1 端口沖突問題

容器化之前這個項目采用虛機部署的，每個虛擬機交叉的啟動了兩個或者三個微服務，這會遇到一個問題，就是端口沖突的問題，在項目加入新應用時，需要考慮服務器之間端口沖突問題的，還要考慮每個微服務的端口不能一樣，因為使用虛擬機部署應用時，可能會有機器節點故障需要手動遷移應用的情況，如果部分微服務端口一樣，遷移的過程可能會受阻。

另外，當一個項目只有幾個應用時，端口維護起來可能沒有什么問題，像本項目，涉及三十多個微服務，這就會成為一件很痛苦的事情。而使用容器部署時，每個容器相互隔離，所有應用可以采用同樣的端口，就無需再去關心端口的問題。

1.3.2 程序健康問題

使用過Java程序的人大部分都遇到過程序假死的情況，比如端口明明是通的，但是請求就是不處理，這就是一種程序假死的現象。而我們在使用虛機部署時，往往不能把健康檢查做的很好，或許在虛機上面并沒有做接口級的健康檢查，這就會造成程序假死無法自動處理的問題，并且在虛機上面做一些接口級的健康檢查及處理操作并不是一件簡單的事情，同樣也是一件枯燥乏味的事情，尤其是當一個項目微服務過多，健康檢查接口不一致時更為痛苦。

但在k8s上面，自帶的Read和Live探針用以處理上面的問題就極其簡單，如圖所示，我們可以看到目前支持三種方式的健康檢查：

 

 

• tcpSocket: 端口健康檢查
• exec: 根據指定命令的返回值
• httpGet: 接口級健康檢查

同時這些健康檢查的靈活性也很高，可以自定義檢查間隔、錯誤次數、成功次數、檢查Host等參數，而且上面提到的接口級健康檢查httpGet也支持自定義主機名、請求頭、檢查路徑以及HTTP或者HTTPS等配置，可以看到用k8s自帶的健康檢查可以省去我們很大一部分工作，不用再去維護非常多令人討厭的腳本。

1.3.3 故障恢復問題

在使用虛機部署應用時，有時可能會碰到宿主機故障，單節點的應用無法使用，或者多節點部署的應用由于其他副本不可用，導致自身壓力大出現服務延遲的情況。而恰恰宿主機無法很快恢復，這時可能就需要手動添加節點或者需要新加服務器才能解決這類問題，這個過程可能會很漫長，或許也很痛苦。因為需要去準備依賴環境，然后才能去部署自己的應用，并且有時候你可能還需要更改CI腳本。。。

而使用k8s編排時，我們無需關心這類問題，一切的故障恢復、容災機制都由強大的k8s負責，你可以去喝杯咖啡，或者你剛打開電腦去處理這個問題時，一切都已經恢復如初。

1.3.4 其他小問題

當然k8s給我們帶來的便利性和解決的問題遠不止上面所說的，容器鏡像幫我們解決了依賴環境的問題，服務編排幫我們解決了故障容災的問題，我們可以使用k8s的包管理工具一鍵創建一套新的環境，我們可以使用k8s的服務發現讓開發人員無需再關注網絡部分的開發，我們可以使用k8s的權限控制讓運維人員無需再去管理每臺服務器的權限，我們可以使用k8s強大的應用程序發布策略讓我們無需過多的考慮如何實現零宕機發布應用及應用回滾，等等，這一切的便利性正在悄悄的改變著我們的行為。

2. 遷移計劃

2.1 藍綠遷移

首先來看一下遷移之前的架構

 

 

和大多數SpringCloud架構一樣，使用NodeJS作為前端，Eureka用作服務發現，Zuul進行路由分發，ConfigServer作為配置中心。這種架構也是SpringCloud在企業中最普遍的架構，沒有使用更多額外的組件，所以我們在第一次遷移時，也沒有考慮太多，還是按照遷移其他項目使用的方案，即在k8s上新建一套環境(本次遷移沒有涉及到中間件)，也就是容器化環境，配置一個同樣的域名，然后添加hosts解析進行測試，沒有問題的話直接進行域名切換即可完成遷移。這種方式是最簡單也是最常用的方式，類似于程序發版的藍綠部署，此時在k8s新建一套環境對應的架構圖如下：

 

 

在進行測試時，此項目同時并行了兩套環境，一套虛機環境，一套容器環境，容器環境只接收測試人員的流量，兩套環境連接的是同一套中間件服務，因為其他項目大部分也是按照這種方式遷移的，并且該項目在測試環境也進行過同樣的流程，沒有出現什么問題，所以也同樣認為這種方式在本項目也不會出現什么問題。但往往現實總會與預期有所差異，在測試過程中由于兩套環境并存，導致了部分生產數據出現問題，由于容器環境沒有經過完整性測試，也沒有強制切換域名，后來緊急關停了所有的容器問題才得以恢復。由于時間比較緊迫，我們并沒有仔細排查問題所在，只是修復了部分數據，后來我們認為可能是遷移過程中部分微服務master分支和生產代碼不一致造成的，當然也可能并不是這么簡單。為了規避這類問題再次發生只能去修改遷移方案。

2.2 灰度遷移

由于上面的遷移方案出了點問題，就重新定了一個方案，較上次略微麻煩，采用逐個微服務遷移至k8s，類似于應用程序發版的灰度發布。

單個應用遷移時，需要確保容器環境和虛機環境的代碼一致，在遷移時微服務采用域名注冊的方式。也就是每個微服務都配置一個內部域名，通過域名去注冊到Eureka，而不是采用容器的IP和端口去注冊(因為k8s內部的IP和虛擬機未打通)，此時的環境如下圖所示：

 

 

此時有一個域名service-c.interservice.k8s指向ServiceC，然后ServiceC注冊到Eureka時修改自己的地址為該域名(默認是宿主機IP+端口)，之后別的應用通過該地址調用ServiceC，當ServiceC測試無問題后，下線虛擬機里面的ServiceC，最后的架構如圖所示：

 

 

除了Zuul、前端UI和Eureka，其他服務都使用灰度的方式遷移到k8s，比藍綠的形式更為復雜，需要為每個微服務單獨創建Service、域名，在遷移完成之后還需要刪除。到這一步后，除了Eureka其他服務都已經部署在k8s上，而對于Eureka的遷移，涉及的細節更多。

2.3 Eureka遷移

到這一步后，服務訪問沒有出現其他問題，除了Eureka之外的服務，都已經部署在k8s，而Eureka的過渡性遷移設計的問題可能會更多。因為我們不能直接在k8s上部署一套高可用的Eureka集群，然后直接把ConfigServer里面的微服務注冊地址改成k8s中的Eureka地址，因為此時兩個Eureka集群都是獨立的Zone，注冊信息并不會共享，這種會在更改配置的過程中丟失注冊信息，此時架構圖可能會出現如下情況：

 

 

也就是在替換配置的過程中，可能會有ServiceA注冊到了之前的Eureka上，ServiceB注冊到了k8s中的Eureka，就會導致ServiceA找不到ServiceB，反過來也是同樣的問題。

所以在k8s搭建Eureka的集群后，需要給每個Eureka實例配置一個臨時域名，然后更改之前的Eureka集群和k8s里面的Eureka集群的zone配置，讓k8s里面的Eureka和虛機里面的Eureka組成一個新的集群，這樣注冊信息就會被同步，無論注冊到Eureka都不會造成服務找不到，此時的架構圖如下(此時所有的服務還是注冊到原來的Eureka集群中)：

 

 

接下來需要做的事情，就是更改微服務的配置，此時需要更改地方有三處：

1. 微服務注冊到Eureka的地址更為容器IP和端口，不再使用域名注冊，因為此時微服務都已經在k8s中，直接通過內部Pod IP即可連接;
2. 更改服務注冊的Eureka地址為k8s Eureka的service地址，Eureka使用StatefulSet部署，直接通過eureka-0/1/2.eureka-headless-svc就可以連接;
3. 待所有的微服務都已經遷移完畢后，更改k8s的Eureka集群的zone為：eureka-0/1/2.eureka-headless-svc，并刪除其他微服務的Service和域名。

最終的架構圖如圖：

 

 

3. 總結

為了保證服務的可用性，我們無奈的采用灰度的方式進行遷移，比藍綠的方式麻煩了很多，而且需要考慮的問題也有很多。在程序沒有任何問題的前提下，還是建議采用藍綠的方式進行遷移，不僅遇到的問題少，遷移也比較方便快捷。當然采用灰度的方式對于大型的項目或者不能中斷服務的項目可能更為穩妥，因為一次性全部切換可能會有遺漏的需要測試的地方。當然無論哪種方式，對應用的容器化、遷移至Kubernetes才是比較重要的事情，畢竟云計算才是未來，而Kubernetes是云計算的未來。

原文鏈接：https://www.cnblogs.com/dukuan/p/13285941.html