簡介：?高效開發(fā)、穩(wěn)健發(fā)布。

在云原生環(huán)境中，基于Kubernetes的工具鏈一方面簡化了開發(fā)者的許多日常瑣碎，另一方面也帶來了許多新的概念和工作方式的改變。本篇文章將聚焦于云原生基礎(chǔ)設(shè)施，談?wù)勅绾卧诿嫦蛟圃拈_發(fā)流程中，高效地進行開發(fā)調(diào)測以及發(fā)布。

首先，從通用意義上講，作為一個開發(fā)者，你期望怎樣的研發(fā)流程？

我理解的理想研發(fā)過程

基于這個理想的研發(fā)流程，當(dāng)研發(fā)基礎(chǔ)設(shè)施遷移到云原生和微服務(wù)架構(gòu)之后，在開發(fā)、調(diào)試和發(fā)布方面會遇到什么問題，又要如何解決？

一個典型的研發(fā)過程包含三個環(huán)節(jié)：開發(fā)、測試和部署。

開發(fā)主要指的是代碼的編寫和自測。當(dāng)你寫好代碼和單元測試之后，需要在一個運行環(huán)境中進行功能性驗證。本地IDE提供了大量用于調(diào)測的功能，并且本地服務(wù)的重新啟動速度也比較快。相比將代碼部署到遠端的測試環(huán)境，能夠完全在本地進行編寫、啟動、debug，是最理想的工作方式。

實際的工作中，為了驗證一個特定功能場景，往往需要配合其它的外部依賴，比如當(dāng)前我編寫的這個服務(wù)依賴什么別的服務(wù)；還有什么其他服務(wù)需要調(diào)用我的服務(wù)，我才能做一個完整的驗證？

這些問題都需要很好的解決，才能真正享受到本地開發(fā)的便利。

測試一般指的是在CI環(huán)境中的各種自動化測試和驗收環(huán)境中的測試驗證，本文的重點不在這里，因此假設(shè)我們已經(jīng)完成了這些操作。來到了部署的環(huán)節(jié)。

雖然已經(jīng)經(jīng)過了很多的驗證，我們對要發(fā)布的版本的質(zhì)量已經(jīng)有了相當(dāng)程度的信心。但發(fā)布發(fā)上線之后，也不可避免的時不時會引入一些缺陷，因此如何讓出現(xiàn)的這些問題的影響面最小，就是所謂的穩(wěn)健發(fā)布。

首先來關(guān)注在云原生下的開發(fā)和調(diào)試。

隨著微服務(wù)技術(shù)和各類開源服務(wù)組件普及，如今的軟件系統(tǒng)或多或少的都會包含數(shù)個相互獨立的服務(wù)實體，之間通過接口調(diào)用相互連接。因此在本地進行服務(wù)測試的時候，難免涉及到與上下游的其他服務(wù)的互動，特別是在進行完整功能驗證時，常常需要在本地將上下游鏈路的所有服務(wù)全部啟動起來。然而隨著系統(tǒng)的演進和服務(wù)的增多，本地資源很快就無法支撐整體系統(tǒng)啟動了。那么，是否能夠?qū)y試環(huán)境中的公共服務(wù)節(jié)點和本地服務(wù)串聯(lián)在一起，行成完整的測試鏈路呢？

在云原生的環(huán)境下，測試環(huán)境被Kubernetes的集群網(wǎng)絡(luò)邊界所隔離。從集群外部訪問測試集群中的服務(wù)需要經(jīng)過統(tǒng)一的Ingress網(wǎng)關(guān)，且只能訪問配置了網(wǎng)關(guān)路由的一小部分部分服務(wù)。同時由于開發(fā)者的本地主機通常沒有公網(wǎng)IP地址，從測試環(huán)境中完全無法連接到本地的服務(wù)實例。

為此云效創(chuàng)造了kt-connect工具來解決本地測試時的網(wǎng)絡(luò)聯(lián)通問題，它能夠在開發(fā)者的本地環(huán)境和Kubernetes測試集群之間，建立起一條虛擬的雙向網(wǎng)絡(luò)通路。

kt-connect是一款簡單易用的命令行工具。對于從本地連接測試環(huán)境的情況，它提供了一個connect命令，利用在集群中部署一個作為網(wǎng)絡(luò)代理的Pod節(jié)點，使得從本地網(wǎng)絡(luò)能夠直接訪問集群中的任意Service域名、IP地址和任意Pod的IP地址。而對于其從集群訪問本地的情況，kt-connect提供了exchange命令，通過另一個反向的代理節(jié)點實現(xiàn)將集群中流入指定服務(wù)的所有請求導(dǎo)向到本地的指定端口。

對于個人開發(fā)者的使用場景來說，以上兩個命令就能夠完全滿足日常工作了。然而對于團隊開發(fā)的場景下，則會帶來新的問題。當(dāng)一個開發(fā)者使用了exchange命令，將特定服務(wù)實例的流量全部導(dǎo)向本地，在同一個集群中工作的所有其他開發(fā)者都會隨之受到影響。為了避免這樣的相互干擾，kt-connect又創(chuàng)造了第三種命令mesh，它的功能與exchange命令相似，但并不會將網(wǎng)絡(luò)中的所有流量全部導(dǎo)入到開發(fā)者本地，而是基于特定的網(wǎng)格規(guī)則，只將符合要求的測試流量導(dǎo)向開發(fā)者的本地環(huán)境，從而實現(xiàn)測試環(huán)境資源的最大化利用率和多項目的和平共處。

從本質(zhì)上來說，kt-connect主要利用了Kubernetes原生命令行的端口轉(zhuǎn)發(fā)和開源SSH工具的四層網(wǎng)絡(luò)代理能力實現(xiàn)，對應(yīng)用本身不產(chǎn)生任何侵入，目前我們已經(jīng)將它的所有源代碼在Github開源。

接下來來到發(fā)布的環(huán)節(jié)。

云原生基礎(chǔ)設(shè)施內(nèi)置了滾動發(fā)布的能力，可以很好的滿足發(fā)布本身的可靠性的需求，保證整個發(fā)布過程是優(yōu)雅的。但這個模式有一些問題，比如發(fā)布和回滾的時間都比較長，且無法暫定下來進行業(yè)務(wù)運行狀態(tài)的觀察。一個進階的模式是藍綠發(fā)布，新啟動一個副本，然后把所有流量全切到新的版本，這樣發(fā)布和回滾都很快了，但所有流量還是一次性切換的，沒法進行增量驗證。金絲雀發(fā)布可以解決這個問題，可以通過路由控制，逐步將流量導(dǎo)入到新版本上。但一般是采用流量百分比的方式，所有沒法指定特定人群使用新版本。

一個更加可控的金絲雀方式，需要給每個用戶設(shè)置一個流量標(biāo)志，比如使用cookie。也就是說通過一個類似interpcetor的機制，判斷當(dāng)前用戶是否應(yīng)該是一個灰度用戶，如果是的話，就給他設(shè)置一個cookie，后續(xù)來自該用戶的所有流量都會帶上這個cookie。有了這個流量標(biāo)志，就可以在流量入口處根據(jù)cookie的值判斷該請求應(yīng)該到新版本還是老版本。

有了這個路由機制，還是不夠。因為我們實際的應(yīng)用程序并不是只有一個服務(wù)，而是像圖中的由多個服務(wù)互相調(diào)用而組成。比如當(dāng)我要發(fā)布服務(wù)B的時候，因為服務(wù)B并不是直接面向瀏覽器的，所有無法接收到用戶的cookie。這時就需要有一個流量表自動傳遞機制。一般的做法是在請求的入口處把灰度標(biāo)記存在一個ThreadLocal中，然后在應(yīng)用的出口處，比如一個OkHttpClient的調(diào)用處再把這個ThreadLocal中的值放到cookie中繼續(xù)往下傳遞。

我們已經(jīng)理解了“全鏈路可控金絲雀發(fā)布”的做法，接下來要探討在技術(shù)上如何實現(xiàn)。在阿里巴巴，我們使用了一個叫做統(tǒng)一接入的技術(shù)，所有的請求（包括入口流量和內(nèi)部服務(wù)之間互相調(diào)用的流量）都會經(jīng)過通過接入，然后有統(tǒng)一接入決定該將這個請求分發(fā)到哪里。

到了云原生時代，Service Mesh的概念興起，其實本質(zhì)上就是一個“分布式統(tǒng)一接入”。這個統(tǒng)一接入不再是一個中心化的服務(wù)，而是隨著每個服務(wù)的每個實例一起部署在一起的進程，這個進程負責(zé)接收改實例的入口流量，并轉(zhuǎn)發(fā)給實際的服務(wù)；同時也攔截實例的出口流量，并決定下一跳應(yīng)該是誰。

Istio是Service Mesh的一個被廣泛采用的實現(xiàn)。

了解了這個原理之后，從上圖中，可以看到一次發(fā)布過程是什么樣子。

這個發(fā)布過程中涉及到多次Kubernetes資源的更新操作，如果完全采用原生命令+手工配置來操作，不僅復(fù)雜還容易出錯。為此云效對云原生的各種常見發(fā)布模式都進行了產(chǎn)品化封裝，開發(fā)者只需要配置一些簡單的發(fā)布和路由規(guī)則，就可以輕松地實現(xiàn)安全可控發(fā)布過程。

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

總結(jié)

以上是生活随笔為你收集整理的阿里云云效技术专家分享：云原生开发、调测及可靠发布解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。