[[334093]]

 1. 項目遷移背景

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

目前公司的測試環(huán)境、UAT環(huán)境、生產(chǎn)環(huán)境均已經(jīng)使用k8s進行維護管理，大部分項目均已完成容器化，并且已經(jīng)在線上平穩(wěn)運行許久。在我們將大大小小的項目完成容器化以后，測試、UAT、生產(chǎn)環(huán)境的發(fā)版工具以及CICD流程慢慢的實現(xiàn)統(tǒng)一化管理，并且基于k8s開發(fā)了內(nèi)部的發(fā)版審核平臺，同時接入了Jira等項目管理工具。

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

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

1.2 為什么要棄用Git Runner?

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

1.2.1 多分支并行開發(fā)問題

當(dāng)多分支并行開發(fā)或者能夠發(fā)版到生產(chǎn)環(huán)境的分支較多時，很容易在手動部署的階段點錯，或者看串行，當(dāng)然這種概率很小。

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

1.2.2 多微服務(wù)配置維護問題

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

1.2.3 安全問題

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

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

1.3 為什么要容器化?

1.3.1 端口沖突問題

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

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

1.3.2 程序健康問題

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

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

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

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

1.3.3 故障恢復(fù)問題

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

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

1.3.4 其他小問題

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

2. 遷移計劃

2.1 藍綠遷移

首先來看一下遷移之前的架構(gòu)

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

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

2.2 灰度遷移

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

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

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

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

2.3 Eureka遷移

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

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

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

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

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

最終的架構(gòu)圖如圖：

3. 總結(jié)

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

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