溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
今天就跟大家聊聊有關(guān)如何用K8S搞定1000個應用的測試環(huán)境，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。
差不多是半年以前，基礎(chǔ)框架團隊接到了一個任務：環(huán)境治理。究其原因是開發(fā)團隊被測試環(huán)境的問題困擾，影響了研發(fā)效率和進度，急需一套解決方案。
讓我們看看當時的情景，信也科技是一家有著10多年歷史的金融互聯(lián)網(wǎng)公司，業(yè)務產(chǎn)品非常多，應用數(shù)目累計1000+ 的樣子，整個系統(tǒng)可以說是非常龐大。有同事形象地形容這套系統(tǒng)，這是一條從新疆到上海的鐵路，用戶在新疆上車，途徑了10來個省（團隊）的地盤，最后在上海下車。
可想而知，這條路上無論那個環(huán)節(jié)出了問題，整條路可能就不通了。當時公司內(nèi)部有3套比較完整的大環(huán)境，分別是 FAT、UAT、PRE。不過 UAT 與 PRE 都不是開發(fā)直接使用，所有的開發(fā)測試都在使用 FAT 環(huán)境，后果就是沖突非常嚴重，新功能測試上線，舊 Bug 修復，日常組件故障都時時困擾著大家?？梢哉f那個時候 通訊基本靠吼，如果出了問題，有時候必須不同組件、不同團隊排查問題，非常影響效率。
現(xiàn)狀知道了，核心問題是什么呢？通過分析，我們認為核心問題有2個。
最終系統(tǒng)穩(wěn)定不下來，想穩(wěn)定就要組件穩(wěn)定，但是業(yè)務高速發(fā)展，就要不斷引入組件和新版本。這2者矛盾了。
資源沖突，只有一套完整環(huán)境，資源成為了瓶頸，如果我們多復制幾套環(huán)境 問題不就解決了嗎？
但是問題來了，復制幾套環(huán)境，如何復制這個環(huán)境呢？復制的資源成本和維護成本怎么控制？我們希望復制維護的成本足夠的小，其次，多套環(huán)境意味著需要不停地將各個環(huán)境的應用版本進行同步，否則會出現(xiàn)一個個環(huán)境版本老化，劣化，逐漸失去它存在的意義，最終大家又回到一個測試環(huán)境的情況。
所以我們最終是這樣設計的。
根據(jù)核心問題的定義，我們的也隨之定了2個小目標。
提供一個穩(wěn)定的測試環(huán)境 保證整個測試環(huán)境的穩(wěn)定。它會隨著生產(chǎn)環(huán)境同步 保證它一直是線上最新的。
為每個團隊提供多套私有的測試環(huán)境，每個團隊在私有環(huán)境測試不會影響其他團隊。
在實施目標之前，我們也已經(jīng)有足夠的技術(shù)儲備和開發(fā)規(guī)范，首先是容器及 K8S 已經(jīng)落地，應用已經(jīng)基本完全容器化，容器的發(fā)布流程已經(jīng)平臺化，團隊的應用配置也使用了 Apollo 這樣的中心配置服務，MQ 等組件支持 Restful 接口，容器具有靜態(tài)IP分配技術(shù)。這些技術(shù)條件是項目最終成功的技術(shù)基石。
通過努力，星云系統(tǒng)誕生了。利用它，我們操作 K8S 完成了環(huán)境的創(chuàng)建、管理、銷毀，很好地達成預計的目標。（根據(jù)本公司的實際情況，大部分應用都是利用 Restful RPC 進行交互，利用域名進行尋址，一般情況下用 Nginx 進行消息轉(zhuǎn)發(fā)，所有設計以此為前提。）
快速地創(chuàng)建測試環(huán)境，
應用可在不同環(huán)境里復用。
零配置使用系統(tǒng)。
應用無需改造
這一切是如何做到的呢？
我們?nèi)绾卫?K8S 完成這一切的呢？整體組件及流程這樣
我們創(chuàng)建了星云多環(huán)境管理平臺，用戶可以自助在上面創(chuàng)建測試環(huán)境，在創(chuàng)建指令發(fā)出后，星云平臺會把指令轉(zhuǎn)換成一批創(chuàng)建容器的指令，利用現(xiàn)有的容器發(fā)布平臺進行容器創(chuàng)建（主要利用已有穩(wěn)定服務）?，F(xiàn)有容器發(fā)布平臺會讓 K8S 將指定的鏡像，應用按照指定順序啟動，并進行相應的配置。
在一個環(huán)境里所有的應用都啟動以后，一個測試環(huán)境就準備好了，這時候測試人員或者開發(fā)人員就可以利用這個獨立的測試環(huán)境進行開發(fā)、測試了。每個環(huán)境都是個獨立的環(huán)境，相互不影響。
在這里我們只是利用 K8S 管理容器，讓 K8S 進行 Pod 的管理，并不涉及任何其他服務，對它的依賴降低到了最低。
星云的設計和實現(xiàn) 從用戶的角度看大概是這樣的。環(huán)境之間是完全隔絕的。
首先我們需要讓每個環(huán)境正常的運行起來，相互之間不影響，如何實現(xiàn)這一切呢？
在這點上，我們其實參考的是 K8S 本身的架構(gòu)，K8S 是如何讓整個系統(tǒng)運行起來的？
在 K8S 內(nèi)部有2個很重要的組件 一個是 CoreDNS，一個是 Ingress, 它們分別完成了內(nèi)部尋址和對外交流這2個重要的功能。在星云里，我們也是借鑒了這一設計思想。
我們在每個新拉起的環(huán)境里都預先加入了2個重要的組件，一個是 Dns，另一個是流量網(wǎng)關(guān)（Nginx）。
它們?yōu)橹粸閱为毉h(huán)境服務，是單個環(huán)境的核心。DNS 組件首先啟動，它和星云多環(huán)境管理平臺通訊，獲取本測試環(huán)境內(nèi)實例的數(shù)據(jù)，而網(wǎng)關(guān)就是普通的 nginx，它也會和星云管理平臺通訊，獲得相應的轉(zhuǎn)發(fā)策略，按照轉(zhuǎn)發(fā)策略工作。
當環(huán)境里的普通業(yè)務應用啟動后，他們會首先從環(huán)境內(nèi)的 DNS 組件里獲取信息，這樣他們就能進行相互定位，它們之間通過網(wǎng)關(guān)轉(zhuǎn)發(fā)消息。當用戶在外部需要利用這個環(huán)境進行測試的時候，測試將測試流量打到網(wǎng)關(guān)這個容器上。網(wǎng)關(guān)預設的轉(zhuǎn)發(fā)策略將流量分發(fā)到環(huán)境內(nèi)合適的容器上，讓整個測試正常工作。
Dns 本身的實現(xiàn)其實也不復雜，下圖簡單的描述了 DNS 的原理，星云多環(huán)境管理平臺會根據(jù)環(huán)境里的實例狀況，把信息同步到每個環(huán)境的 Dns 組件里，同一個站點的記錄有優(yōu)先級的區(qū)分。這樣就可以定制出我們想要的效果。
環(huán)境1里的應用訪問 A.com 的時候，會得到 192.168.2.200 這個結(jié)果。訪問 B.com 的時候會得到 192.168.2.101 這個結(jié)果，而訪問 C.com 的時候 會得到 172.168.2.4 這個結(jié)果。
因為有優(yōu)先級，有自動同步的數(shù)據(jù)，也可以用戶自由設置，這樣我們在星云中心是可以隨意設計環(huán)境內(nèi)部的 DNS。
總結(jié)成一句話，每個環(huán)境里的 DNS 里的記錄是星云控制的，大部分是自動的，但是你也可以控制它。
網(wǎng)關(guān)的實現(xiàn)的原理也類似，星云控制中心會根據(jù)不同的環(huán)境，計算出它的網(wǎng)關(guān)的規(guī)則是什么樣子。星云把規(guī)則推送到網(wǎng)關(guān)服務器上。這樣通過網(wǎng)關(guān)和 Dns 的配合，星云系統(tǒng)完成控制層面的操作，網(wǎng)關(guān)和 DNS 執(zhí)行數(shù)據(jù)流層面的操作。
在 DNS 和 網(wǎng)關(guān)完成以后，我們只是完成初步的環(huán)境搭建，還有很多細節(jié)需要優(yōu)化，其中最關(guān)鍵的是 RPC 部分。
因為我們有1000+的實例，如果靠簡單的拉起實例，那么一個環(huán)境就需要拉起1000個實例，10套環(huán)境就有1萬+實例，首先資源上這是一個巨大的負載，其次維護這么多環(huán)境的維護成本會很高。所以我們需要讓應用能在不同的環(huán)境復用。
正所謂一圖勝千言，整個系統(tǒng)差不多就是下面這張圖所描述的場景。
公共基礎(chǔ)環(huán)境就是 Default 基礎(chǔ)環(huán)境，它和生產(chǎn)保持一致，我們讓它保持穩(wěn)定。項目環(huán)境-1，項目環(huán)境-2，項目環(huán)境-3 則是星云利用 K8S 的容器管理技術(shù)生成的。用戶在這里測試新的需求，修復 Bug，相互之間是不會影響的。也不會影響到 FAT 環(huán)境的穩(wěn)定。
我們最終實現(xiàn)的效果大概這樣。
帶顏色的箭頭代表了不同環(huán)境RPC消息流轉(zhuǎn)。
首先我們參考了 Google 的論文：Dapper，大規(guī)模分布式系統(tǒng)的跟蹤系統(tǒng)。大部分 APM (Application Performance Management)都以此為基礎(chǔ)開發(fā)。我們基于這個設計做了一些擴展來達成我們的需求。
在 APM 中有一個概念叫 TraceID, 它可以唯一標識一次調(diào)用。它本身只是唯一，沒有其他含義。它可以在一個請求和它的子請求中保持。在我們的系統(tǒng)里，我們也需要類似的能力，除了需要 TraceID 以外，還需要一個 EnvID，當請求和它的子請求在不同的系統(tǒng)里傳輸?shù)臅r候，除了會帶上唯一的 TraceID, 還會帶上 EnvID。我們依靠 EnvID 來實現(xiàn)多個環(huán)境的流轉(zhuǎn)。
在上圖箭頭代表了 RPC 消息，不同的顏色代表這個消息里含有的 Env-ID 是不同的。比如紅色箭頭代表這個消息含有的 env-ID 是 FAT1，綠色的箭頭代表含有的 env-ID 是 FAT2，藍色箭頭代表含有 Env-ID 是 Default。
在此時我們需要解決3個問題：
為此我們用染色、透傳、智能路由3個解決方案來解決這3個問題。下面就是具體的過程。
目前所有的系統(tǒng)，都是靠客戶端來發(fā)起的，比如 H5、手機、App 都是客戶端，它們用標準的 Http 的請求和后端系統(tǒng)進行交互，發(fā)起業(yè)務?？蛻舳耸褂妙愃七@樣的請求和服務器進行交互。
我們唯一需要做的，就是在流量進入各個環(huán)境的時候，需要加一個標識，表明自己的來源。類似這樣
我們用這個標識表明了消息來源于那個環(huán)境，這個過程我們稱之認為是染色。它會在整個生命周期里一直存在，在它和它的子請求里不會變化。
染色方案的比較：關(guān)于如何染色有2個方案，一個我們稱之為客戶端染色，另一種為網(wǎng)關(guān)染色。
這種方案，需要改造客戶端，讓客戶端發(fā)出的請求直接帶上環(huán)境標識。這種方案的優(yōu)點是標識可定制，操作性強。但缺點同樣明顯， 它會入侵前端業(yè)務，不靈活，H5、 Web等客戶端可能不支持，如果環(huán)境標識的內(nèi)容需要擴展，則所有客戶端都需要重新改造。
網(wǎng)關(guān)染色的方案靈活很多，它不需要改造客戶端，對業(yè)務沒有入侵，對 H5、Web 也都能支持，升級也很方便。所以我們選擇了網(wǎng)關(guān)染色的方案。
這個其實是一個技術(shù)債了，其本質(zhì)就是獲得 APM 技術(shù)里類似 PinPoint、 zipkin、 jaeger、 skywalking 透傳信息的能力。
結(jié)合我們項目的本身特點，如果選用有代碼入侵的方案，大量現(xiàn)有系統(tǒng)改造成本太高。只能采用無代碼入侵的方案。最后我們實現(xiàn)了一個J ava Agent 實現(xiàn)了類似 Skywalking/pip 的能力。將 Env-ID 能夠通過應用，在子請求中繼續(xù)傳播下去。
在下面的例子可以看到 應用1 在收到一個請求后，它的子請求上都帶上了一樣的Env-id
EnvID 在什么時候工作，它具體工作的原理是怎么樣的？
雖然我們已經(jīng)知道了 EnvID，如何產(chǎn)生，如何透傳，如何傳播，但是我們?nèi)匀桓悴磺宄?，它怎么幫助我們完成多個環(huán)境應用復用呢？那么下面我們將詳細解釋EnvID 是如何工作的，我們稱這個過程為智能路由。
這個過程可以分為2種情況。在這里我們演示了 A 應用調(diào)用 B 應用，B 應用調(diào)用 C 應用，這樣一次調(diào)用過程。
這種情況很簡單，這里的情況說明每個環(huán)境里都有不同的版本，應用之間調(diào)用不會跨環(huán)境，每個應用都只調(diào)用本環(huán)境內(nèi)的其他應用。
真實的運行情況，其實是這樣的。每次請求都是通過網(wǎng)關(guān)轉(zhuǎn)發(fā)一下的，并沒有直接連接的。
星云多環(huán)境平臺控制了 Dns，也控制網(wǎng)關(guān)轉(zhuǎn)發(fā)規(guī)則，星云多環(huán)境平臺系統(tǒng)讓所有應用將請求都發(fā)給網(wǎng)關(guān)，網(wǎng)關(guān)拿到請求，根據(jù)規(guī)則再轉(zhuǎn)發(fā)出去。在這種情況下，似乎沒有太大意義，直連也可以。好我們看下一種場景。
在這種場景下 我們將實現(xiàn)下面的效果
這里基本涵蓋了所有的應用復用的所有情況。
在測試環(huán)境 FAT1 里，A 應用的版本1實例希望將請求發(fā)往 B 應用，但是 FAT1 環(huán)境里沒有 B 應用的實例，所以請求被發(fā)往了 Default 環(huán)境的 B 應用的穩(wěn)定版本實例，在 Default 環(huán)境的 B 應用的穩(wěn)定版本實例處理后，B 應用的穩(wěn)定版本實例希望將請求發(fā)往 C 應用，因為 FAT1 環(huán)境里也沒有 C 應用，所以請求繼續(xù)發(fā)往了 Default 環(huán)境的 C 應用的穩(wěn)定版本。
在測試環(huán)境 FAT2 里，A 應用的版本2實例希望將請求發(fā)往 B 應用，但是 FAT2環(huán)境也沒有 B 應用的實例，所以請求被發(fā)往了 Default 環(huán)境的 B 應用的穩(wěn)定版本實例，在 Default 環(huán)境的 B 應用的穩(wěn)定版本實例處理后，B 應用的穩(wěn)定版本實例希望將請求發(fā)往 C 應用，因為 FAT-2 環(huán)境有 C 應用的實例. 所以 Default 環(huán)境的 B 應用的穩(wěn)定版本實例將請求發(fā)往了測試環(huán)境 Fat2 里的 C 版本2。最終實現(xiàn)了消息在不同環(huán)境內(nèi)的穿梭，也實現(xiàn)了我們先要的應用復用。
在 Default 環(huán)境里的消息 則和上面一樣。究竟這是如何實現(xiàn)的呢？真實的流程大概如下。
每個環(huán)境的網(wǎng)關(guān)的規(guī)則是星云系統(tǒng)自動生成的，星云系統(tǒng)知道所有環(huán)境實例的狀態(tài)，所以星云是這樣寫網(wǎng)關(guān)規(guī)則的，如果一個環(huán)境里有某個應用的實例，那么網(wǎng)關(guān)就把請求指向本環(huán)境實例，如果沒有此實例，則把這個應用的目標指向 Default的網(wǎng)關(guān)。
這樣在本例中，當測試環(huán)境的 FAT1，F(xiàn)AT2 網(wǎng)關(guān)收到一個發(fā)往B應用的請求時，因為本環(huán)境里沒有B 應用，那么請求就直接被發(fā)往了 Default 網(wǎng)關(guān)。
Default 網(wǎng)關(guān)又是如何工作的呢？Default 網(wǎng)關(guān)是一臺 Openresty 服務器，我們略微擴展了一下它的能力，它的工作流程如下：
它收到請求消息后，先解析請求，先找出Env-ID和目標域名，確定它是來自哪個環(huán)境的，它想去那個目標應用。
它會利用目標應用域名和Env-ID 去星云里查找這個實例信息.
如果星云告訴它 域名+Env-ID有實例存在，則把消息轉(zhuǎn)發(fā)給 Env-ID環(huán)境的網(wǎng)關(guān)，如果域名+Env-ID實例不存在，就把消息轉(zhuǎn)發(fā)給Default環(huán)境里對應的實例。
按照上面的規(guī)則，我們把上面的實現(xiàn)再看一遍。以測試環(huán)境 FAT2 為例：
Env-ID：FAT2 和目標域名 B。Env-ID: Fat2 和目標域名C按照這個設計方案，我們在不改動應用的前提下實現(xiàn)了我們的目標。按照這套設計無論環(huán)境里有還是沒有對應實例，消息都能按照我們設計的流程進行流轉(zhuǎn)。這樣可以幫助我們節(jié)省大量的實例。
在項目啟動之前，我也參考過很多公司經(jīng)驗，我認為其中有一項比較挑戰(zhàn)的地方就是改造成本。不少大公司在 RPC 設計之初就已經(jīng)考慮了染色和按標簽路由的功能，他們在所有的應用在開發(fā)是已經(jīng)注意了這個問題。而對于我們這個項目而言，存在大量歷史系統(tǒng)，不具備這個條件，如果改造 RPC，我們需要把所有的項目都重新改造，打包，測試，時間成本和人力成本都太高。我們采用了目前這種成本較低的方案，把應用改造作為另一項長期方案來完成。最終做到快速、低成本上線。
如果在 RPC 這些方面基礎(chǔ)措施做得好，那么實現(xiàn)這個目標會簡單。此外還有入侵性較小的方案是采用 Service Mesh 的方式來實現(xiàn)，將網(wǎng)關(guān)的功能在 Sidecar 里實現(xiàn), 但是消息透傳仍然是需要解決的。
除了 RPC 以外， Redis 也是我們需要攻克的技術(shù)點。因為拉起了新環(huán)境，為避免數(shù)據(jù)沖突，是需要新的 Redis 實例。按照常規(guī)的做法，需要為各個環(huán)境里重新生成 Redis 實例。但是我們遇到了一些問題，因為 Redis 的使用方法很多，有的項目使用 IP+端口，有的采用域名，有的使用 Cachecloud，并不統(tǒng)一。長期地看規(guī)范使用 redis 是一個解決辦法，但是如何解決現(xiàn)有問題呢？常見的辦法是需要進行替換配置，這不可避免的會入侵到業(yè)務的配置。為減少這種入侵，我們采用了 Java Agent 的模式，攔截了應用調(diào)用 Redis 的接口，在 Redis 的 key 前面加了一個前綴，這種既做到了數(shù)據(jù)隔離，又做到節(jié)省資源。大概的原理這樣
不同環(huán)境所有數(shù)據(jù)都被加上了一個前綴，做到了相互不干擾，這樣一個 redis 實例就可以同時被多個環(huán)境共享了。（如果開發(fā)初期，規(guī)范里就預制了 redis 數(shù)據(jù)前綴配置的話，解決這個問題就會簡單。）
除了后端以外，我們的前端也都上到容器里，但是前端使用容器存在一個資源問題，大部分的前端站點都是編譯后的靜態(tài)文件，文件不大，資源消耗也很低，但是域名數(shù)量非常多，一套環(huán)境里經(jīng)常有40+前端站點。按普通方案，我們需要啟動40多個容器來完成。這樣資源利用率較低，為了節(jié)省資源，我們將一個項目的全部靜態(tài)資源最終打到一個鏡像里。然后利用 dns 和網(wǎng)關(guān)配合，實現(xiàn)前端站點的代理，做到了一個應用同時服務幾十個靜態(tài)站點，不但資源節(jié)省了，站點管理起來也非常簡單，靈活。
目前所有的環(huán)境都復用了一套數(shù)據(jù)庫系統(tǒng)，究其原因還是因為數(shù)據(jù)庫的規(guī)模太大，數(shù)據(jù)初始化，復用，數(shù)據(jù)合并上還有比較大的挑戰(zhàn)。所以用戶測試一般使用不同的區(qū)域、賬號進行邏輯隔離，目前來看也是滿足需要的。但是數(shù)據(jù)整理仍有很大的進步空間。
看完上述內(nèi)容，你們對如何用K8S搞定1000個應用的測試環(huán)境有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。
免責聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號
手機網(wǎng)站二維碼