環(huán)境對于一個迭代迅速的電商公司來說，它的重要性無須贅述了；如何讓環(huán)境高效，滿足多項目并發(fā)對環(huán)境的需求，節(jié)約環(huán)境機(jī)器成本，建立環(huán)境標(biāo)準(zhǔn)體系，這不是幾個人的事情，而是框架組、運維組、開發(fā)、測試、pm 大家共同努力的結(jié)果，其中的過程也不是一帆風(fēng)順的，有贊在這條路上走過了很多坑，今天就給大家分享下我們的經(jīng)驗。

一、有贊測試環(huán)境背景歷程

有贊從最早到現(xiàn)在一共有過 dev（已廢棄），daily，qa，perf，pre5 套環(huán)境，其中 perf 環(huán)境，是專門用來做性能測試的：

二、有贊測試環(huán)境多環(huán)境實現(xiàn)原理

剛才我們講了有贊環(huán)境的歷程，提到了 sc 多環(huán)境方案，想必大家關(guān)注到了，現(xiàn)在就開始講下 sc 多環(huán)境的解決方案。

有贊 sc 應(yīng)用隔離解決方案是由框架組提出的解決方案，產(chǎn)生的背景是為了解決項目并行，大家搶占資源，開發(fā) 5 分鐘，聯(lián)調(diào)測試 1 小時的問題。

1）全鏈路標(biāo)識透傳弱隔離方案

全鏈路標(biāo)識透傳 service chain，簡稱 sc 方案，是一種弱隔離的環(huán)境方案，簡單分析下兩種主要的隔離方案：

兩種隔離方案優(yōu)缺點分明：

強(qiáng)隔離：優(yōu)點，隔離性強(qiáng)，不用修改應(yīng)用，對應(yīng)用侵入性低；缺點，運維成本高

弱隔離：優(yōu)點，全鏈路標(biāo)識透傳，降低不必要的運維機(jī)器成本；缺點，隔離性弱，對應(yīng)用侵入性高

最終我們選擇了弱隔離，原因是有贊業(yè)務(wù)發(fā)展形態(tài)決定的。有贊零售等垂直業(yè)務(wù)的崛起，而垂直業(yè)務(wù)依賴了絕大多數(shù)的底層應(yīng)用服務(wù)，為了降低運維服務(wù)器成本，所以我們選擇了弱隔離。

框架設(shè)計這個方案最初設(shè)定了 4 個目標(biāo)：

a. 按需隔離應(yīng)用，只需要隔離需求中有變更的應(yīng)用

b. 全鏈路標(biāo)識透傳，為以后的全鏈路壓測打下基礎(chǔ)

c. 應(yīng)用侵入低，更多的由應(yīng)用框架和中間件來感知和擔(dān)保，應(yīng)用自身做到低侵入

d. 使用方便快捷，通過平臺（基礎(chǔ)保障平臺）創(chuàng)建隔離的 sc（service chain）環(huán)境

最初的全鏈路設(shè)計方案

面那條線我們稱為“基礎(chǔ)環(huán)境”鏈路，下面那條線我們稱為“sc 環(huán)境”鏈路，當(dāng)標(biāo)識透傳到下一個服務(wù)的時候，如果沒有找到對應(yīng) sc 應(yīng)用節(jié)點，會默認(rèn)走標(biāo)準(zhǔn)環(huán)境，如果有對應(yīng)的節(jié)點，走 sc 環(huán)境的應(yīng)用節(jié)點，整個過程 sc 標(biāo)識從一開始的 web 端 http 請求傳入，就一直透傳下去。

此外還會遇到一些重要的細(xì)節(jié)點，比如消息 NSQ 中間件，我們也做了隔離標(biāo)識透傳設(shè)計方案：

比如業(yè)務(wù)代碼異步調(diào)用標(biāo)識透傳問題，可以自行定制 Runnable 或者定制線程池再或者業(yè)務(wù)方自行定制實現(xiàn)。

2）Service Chain 路由

全鏈路標(biāo)識透傳，那就要求入口發(fā)起的請求，無論是哪種業(yè)務(wù)應(yīng)用或者何種協(xié)議，何種框架，都必須將源端的 sc 標(biāo)識透傳下去，如果其中任何一個環(huán)節(jié)標(biāo)識透傳失敗，就沒有意義了；這里主要講下兩種主要協(xié)議的標(biāo)識透傳：

第一種，RPC 調(diào)用。

首先應(yīng)用框架層面改造，實現(xiàn) RPC SC 路由，再通過 web 發(fā)布平臺將應(yīng)用帶有 sc 標(biāo)識服務(wù)信息寫入 etcd，這樣 RPC 調(diào)用的時候直接通過 RPC 路由將 sc 標(biāo)識進(jìn)行透傳，如果沒有匹配到 sc 標(biāo)識，默認(rèn)走到基礎(chǔ)鏈路服務(wù)，RPC 路由實現(xiàn)原理如下：

第二種，REST調(diào)用。

規(guī)定 rest 調(diào)用必須通過域名調(diào)用，規(guī)范統(tǒng)一的域名命名方式，比如應(yīng)用 A 提供 rest 調(diào)用，這樣命名：http://A.qa.xxx.com:port/

盡量做到命名簡單統(tǒng)一規(guī)范，再通過 web 發(fā)布平臺將應(yīng)用帶有 sc 標(biāo)識的 rest 服務(wù)信息寫入到 etcd；接下來很重要的一步，實現(xiàn) rest sc 路由，做法是部署一臺專門干這個活的機(jī)器, 這里稱為 sc-nginx0 機(jī)器；rest 通過域名調(diào)用都會走到 sc-nginx0，sc-nignx0 再通過 nginx 配置做全應(yīng)用名稱模糊匹配，從而轉(zhuǎn)發(fā)到對應(yīng)的應(yīng)用 rest sc 服務(wù)節(jié)點，這樣就實現(xiàn)了 rest 調(diào)用標(biāo)識透傳。需要注意的是如果路由不上，會走到兜底的 sc-nginx1 機(jī)器，sc-nginx1 會路由基礎(chǔ)鏈路服務(wù)。鏈路圖如下：

這里再給大家展示下，有贊的標(biāo)識透傳表現(xiàn)形式，僅供參考：

3）Service Chain 入口

前面講了 sc 的整體和路由，sc 標(biāo)識究竟是怎么傳遞進(jìn)來的呢，那就自然要講 sc 入口了。

有贊業(yè)務(wù)業(yè)務(wù)入口，絕大多數(shù)是在 iron 工程，因為歷史包袱這是一個相當(dāng)復(fù)雜冗余的 php 工程。后來隨著業(yè)務(wù)發(fā)展，我們將部分業(yè)務(wù)入口從 iron 代碼剝離出來，形成一個個獨立的前端是 node 的微服務(wù)，簡單分別講下兩種不同的入口實現(xiàn) sc 方式。

第一種，iron 入口。

首先針對不同的環(huán)境，本地需要綁定 host，域名需要接入統(tǒng)一網(wǎng)關(guān)，接著通過 web 代理頁面，給瀏覽器 http 訪問 header 頭帶上 iron 訪問多人路徑名 who 信息、sc 標(biāo)識信息必要信息，最后在代理頁面選擇入口機(jī)器（ps：多人 iron 機(jī)器），就可以開始 sc 調(diào)用之旅了；iron 服務(wù)我們不同環(huán)境只有一臺服務(wù)，在機(jī)器上建立多人路徑名，通過 who 信息由 tengine 走到各自的路徑 iron 代碼，這樣我們就解決了 iron 入口的問題；接下來 iron 調(diào)其他服務(wù)，會通過 rest 請求，前面我們有講過 rest 調(diào)用的路由，我們在代理頁面已經(jīng)將 sc 標(biāo)識帶入了，所以 sc 標(biāo)識會接著往后面透傳了。絕大多數(shù) iron 調(diào)用服務(wù)化服務(wù)都是通過 rest 調(diào)用的，但是 iron 復(fù)雜在歷史有些業(yè)務(wù)還通過了 rpc（nova） 調(diào)用，我們通過改造 tether 中間件給與了 sc 標(biāo)識透傳支持，這里有贊特色特別鮮明就不過多介紹了；這里還有一些 php 比較復(fù)雜的 nginx，tengine 代理也不講了，有同樣背景且感興趣的伙伴可以私下交流。

第二種，node 入口。

node 入口，類似于前面介紹過的 rest 調(diào)用路由，需要申請瀏覽器訪問的外部域名，同時外部域名要確保接入統(tǒng)一網(wǎng)關(guān)；再通過 web 發(fā)布平臺將帶有 sc 的外部域名 rest 信息寫入到 etcd，我們通過瀏覽器域名訪問的時候，入口通過 web 代理頁面選擇 sc-nginx 路由機(jī)器，sc 路由機(jī)器會轉(zhuǎn)到對應(yīng)的 sc node 服務(wù)，這樣就解決了 node 入口的問題。

最后為了降低環(huán)境使用成本，我們?nèi)肟谧隽私y(tǒng)一，將測試環(huán)境老的多人 iron 入口使用姿勢也改成了 sc-nginx 入口，同時兼容了多人 iron 的訪問實現(xiàn)；因為有贊鮮明特色不多說了，僅供參考，鏈路方案如下：

4）Service Chain 出口

對于內(nèi)部業(yè)務(wù)來說，沒有 sc 出口一說，這里說的出口是指外部三方的調(diào)用。三方調(diào)用支持 sc 分為兩種，一種是同步查詢只要對接的第三方應(yīng)用支持 sc 標(biāo)識就可以了；還有一種是異步回調(diào)，可以通過給三方傳回調(diào)地址加入 sc 標(biāo)識實現(xiàn)，內(nèi)部應(yīng)用獲取回到 url 的 sc 信息，這樣可以實現(xiàn) sc 標(biāo)識涉及第三方透傳，這種方法大多數(shù)情況下三方都是可以支持的。

至此 service chain 環(huán)境隔離技術(shù)層面的方案差不多這樣了。

三、有贊環(huán)境推動

上一個環(huán)節(jié)已經(jīng)大致的介紹了有贊 service chain 全鏈路標(biāo)識透傳隔離方案的技術(shù)實現(xiàn)，這個環(huán)節(jié)開始介紹我們在確定技術(shù)實現(xiàn)方案之后，做的一些列推動的措施。

1）推動應(yīng)用框架升級接入sc

前面我們說了 RPC 調(diào)用是通過框架實現(xiàn) sc 路由的，所以推動應(yīng)用框架、nsq 客戶端升級，這一步非常重要；因為很多業(yè)務(wù)鏈路很長，如果某些業(yè)務(wù)線沒有升級，整個 sc 鏈路就會卡在某個應(yīng)用沒法透傳標(biāo)識；這點在一開始的時候，我們沒有做好，因為前期的宣傳力度不夠，推動不足，導(dǎo)致有些業(yè)務(wù)線接入 sc 升級比較快，有些業(yè)務(wù)線相當(dāng)滯后，項目試點之后才發(fā)現(xiàn)還不支持 sc，給后面的試點帶來了很大的阻力和困難；所以建議，如果一旦確定好適合自己的隔離方案之后，開始推動的時候，做好充分的準(zhǔn)備，定好時間，并指定各業(yè)務(wù)線的跟進(jìn) owner。

2）推動應(yīng)用接入配置平臺

因為經(jīng)常會發(fā)現(xiàn)某個應(yīng)用因為環(huán)境依賴的基礎(chǔ)服務(wù)配置不對，導(dǎo)致應(yīng)用的測試環(huán)境服務(wù)各種問題，排查的時候要去 code 里看配置，非常的耗時與不便；所以為了方便管理應(yīng)用環(huán)境配置，我們做了應(yīng)用配置平臺，推動應(yīng)用平臺配置化，把一些基礎(chǔ)的配置模板固化，這樣我們環(huán)境配置的問題基本就能解決了。

3）推動基礎(chǔ)環(huán)境整治

這一步非常核心，因為只有基礎(chǔ)環(huán)境穩(wěn)定，大的測試環(huán)境才會穩(wěn)定。核心是維護(hù)基礎(chǔ)環(huán)境服務(wù)，下掉多余的基礎(chǔ)環(huán)境機(jī)器（ps：服務(wù)不帶標(biāo)識信息的機(jī)器）及服務(wù)，基礎(chǔ)環(huán)境的應(yīng)用服務(wù)只保留一個，這樣保證了我們基礎(chǔ)環(huán)境服務(wù)鏈路簡單清晰，方便了問題定位，也方便控制基礎(chǔ)環(huán)境發(fā)布權(quán)限。還可以從以下幾點考慮來治理基礎(chǔ)環(huán)境：1，測試環(huán)境基礎(chǔ)鏈路服務(wù)發(fā)布權(quán)限管控，只允許發(fā)布 master 代碼，不允許輕易發(fā)布，保證基礎(chǔ)鏈路服務(wù)穩(wěn)定；2，基礎(chǔ)鏈路服務(wù)當(dāng)天生產(chǎn)環(huán)境有代碼變更，凌晨自動更新 master 代碼等。

4）web 應(yīng)用發(fā)布管理平臺

前面有說過，sc 應(yīng)用服務(wù)信息寫入 etcd，是通過 web 發(fā)布平臺，所以我們需要一個方便便捷的 sc 環(huán)境應(yīng)用發(fā)布管理平臺。

創(chuàng)建 sc 環(huán)境

sc環(huán)境應(yīng)用管理

這里值得一提的是，sc 服務(wù)的機(jī)器可以申請?zhí)摂M機(jī)，也可以用 docker，從成本而言，我們默認(rèn)是使用更加節(jié)約成本的 docker。

5）推動項目試點

在準(zhǔn)備工作做好之后，可以選試點項目試行了，因為環(huán)境方案問題的復(fù)雜性，建議不要一開始就推行全公司，可以找一些項目先做試點；在試點的過程中，我們會發(fā)現(xiàn)各種明顯坑，等把這些明顯的坑解決一圈之后，再推全公司實行。

6）共性問題解決方案跟進(jìn)

共性問題有哪些，比如有提到過的測試環(huán)境調(diào)用第三方支持 sc、卡門支持 sc 等等，在環(huán)境使用的過程中，會遇到大家都會遇到的問題，這類問題影響是大范圍的，那就必須拉群及時跟進(jìn)響應(yīng)解決，如果不能及時解決就會降低大家使用推動環(huán)境優(yōu)化的積極性；處理完問題，需要及時總結(jié)記錄，大的問題還要及時通知，以及在培訓(xùn)過程中給大家舉例講解；有贊在環(huán)境推動的過程中，我們大大小小的建了 40 多個問題跟進(jìn)的群，制定了 10 多個共性問題解決方法，這些方案有著很鮮明的我廠特色，這里就不給大家分享了。

7）環(huán)境基礎(chǔ)保障

測試環(huán)境使用的便捷穩(wěn)定，必然會要求我們做一些環(huán)境基礎(chǔ)保障的工作，比如開發(fā)測試環(huán)境數(shù)據(jù) mock 平臺、服務(wù)監(jiān)控平臺。

環(huán)境數(shù)據(jù) mock 平臺---測試團(tuán)隊目前開發(fā)覆蓋了包括大數(shù)據(jù)，交易，支付等 14 塊業(yè)務(wù) mock 場景，大大提升了測試環(huán)境的高效便捷；比如測試環(huán)境有些特殊的場景是需要數(shù)據(jù)構(gòu)造的，店鋪沒錢了，e卡支付賬號沒錢了，添加店鋪管理員等，都可以通過測試平臺自己實現(xiàn)。

基礎(chǔ)環(huán)境服務(wù)監(jiān)控平臺---測試環(huán)境基礎(chǔ)環(huán)境鏈路的服務(wù)穩(wěn)定直接影響了環(huán)境的穩(wěn)定性，如果基礎(chǔ)環(huán)境服務(wù)異常，會影響到所有人測試環(huán)境使用，為此開發(fā)了環(huán)境服務(wù)監(jiān)控平臺，覆蓋了 daily、qa、pre90% 以上的核心應(yīng)用的服務(wù)；每隔 10 分鐘監(jiān)測一次 etcd 應(yīng)用的 dubbo 服務(wù)，一但發(fā)現(xiàn)某環(huán)境服務(wù)異常，就會給應(yīng)用的測試角色發(fā)送郵件告警、以及內(nèi)部工具告警，測試童鞋收到服務(wù)異常告警，及時處理，避免測試環(huán)境服務(wù)長時間影響大家使用。

服務(wù)異常告警

環(huán)境監(jiān)控平臺非常重要，我做過統(tǒng)計，環(huán)境問題至少降低 70% 以上，提升環(huán)境排查解決效率至少 80%，很多時候服務(wù)異常了我們第一時間就解決了，避免了大家感知，還有其他的一些環(huán)境保障的工具這里就不多說了。

8）環(huán)境方案規(guī)范制定

對于環(huán)境使用者來說，很多時候他可能不需要詳細(xì)了解環(huán)境隔離方案的實現(xiàn)，更多時候比較關(guān)心環(huán)境究竟怎么使用。所以在方案之后，我們需要制定環(huán)境使用規(guī)范，有贊針對入口變化，前后制定過兩個版本的使用規(guī)范 ppt，大致的內(nèi)容如下：有贊環(huán)境介紹，應(yīng)用接入 sc 規(guī)范，環(huán)境使用規(guī)范，測試環(huán)境交付規(guī)范，移動端使用規(guī)范，環(huán)境保障，環(huán)境發(fā)布權(quán)限規(guī)則，很多內(nèi)容在前面也都講過了。

9）環(huán)境培訓(xùn)

有了環(huán)境方案規(guī)范之后，對于一個已超過 600 技術(shù)人員的公司來說，還需要通過一系列的環(huán)境培訓(xùn)，這樣才能確保每個人都知道如何做如何使用。在有贊是通過各業(yè)務(wù)線組一個個宣講進(jìn)行的，還有新人入職技術(shù)大學(xué)培訓(xùn)，前后組織了接近 20 場培訓(xùn)，除此之外還反復(fù)強(qiáng)調(diào)老人要幫扶指導(dǎo)新來的童鞋環(huán)境的使用，通過這些努力才能保證絕大多數(shù)人知道怎么使用環(huán)境。

10）環(huán)境故障定級

在我們做了大量的培訓(xùn)、宣導(dǎo)之后，還是會有童鞋將測試環(huán)境基礎(chǔ)環(huán)境服務(wù)弄出問題，這是很難避免的，畢竟使用的人多，大家對環(huán)境的學(xué)習(xí)理解程度又不一樣。對于這種情況就需要制定懲罰措施了，給環(huán)境故障定級，分為 p1（影響阻塞基礎(chǔ)環(huán)境主鏈路的故障），p2（影響非主鏈路或者非基礎(chǔ)環(huán)境的故障），對于故障多的業(yè)務(wù)組，予以通報tl。

11）環(huán)境問題記錄

環(huán)境的問題各式各樣，多而繁雜，需要組織專門的老司機(jī)，負(fù)責(zé)排查環(huán)境問題，尤其在當(dāng)下微服務(wù)越來越細(xì)化的背景下，一個環(huán)境問題出現(xiàn)了，需要查好幾個業(yè)務(wù)線N個應(yīng)用，這是很大的工作量。所以環(huán)境問題顯得非常必要了，有了環(huán)境問題記錄，當(dāng)我們再遇到類似的問題的時候，我們可以有經(jīng)驗知道怎么快速定位問題以及解決。

環(huán)境推動方面大致這些，每個公司都會有自己的制度，主要是希望可以給大家借鑒。

四、有贊環(huán)境與持續(xù)交付

有贊 2018 年提升研發(fā)效率，很重要的一個動作就是 devops，為此我們做了 CICD 平臺幫助我們更高效的進(jìn)行日常項目管理。環(huán)境的穩(wěn)定，與持續(xù)交付的推動是緊密聯(lián)系的，標(biāo)準(zhǔn)規(guī)范方便使用的穩(wěn)定環(huán)境是持續(xù)交付的基礎(chǔ)。

項目的發(fā)起從 daily（開發(fā)）環(huán)境發(fā)起，開發(fā)完成 daily 環(huán)境的冒煙自測之后交付到 qa 環(huán)境，測試童鞋 qa 環(huán)境完成測試之后交付到 pre 預(yù)發(fā)環(huán)境，預(yù)發(fā)驗收之后就可以發(fā)布上線，這是一個完整的項目生命周期，開發(fā)和測試環(huán)境的隔離，可以使得項目進(jìn)行的更加順利。

舉例說明，xx 項目是一個非常大的項目，涉及到的業(yè)務(wù)方 7，8 個，涉及的應(yīng)用 60 多個，如果測試和開發(fā)童鞋都在 qa 的 sc 環(huán)境測試，那么會出現(xiàn)測試在測試的同時開發(fā)修復(fù) bug 重發(fā)服務(wù)，從而打斷測試的情況，這樣的大項目就沒有辦法進(jìn)行下去了。如果按照交付的思路，開發(fā)在 daily 環(huán)境完成自測，交付 qa 測試，大家互不影響，可以很好的提升項目效率。

通過 web 平臺，目前準(zhǔn)備一個隔離的復(fù)雜的項目環(huán)境基本上可以控制在半個小時內(nèi)。我們還有很大的提升空間，比如在 docker 容器服務(wù)化上還可以做很多改進(jìn)，和 CICD 結(jié)合之后，整個項目的生命周期過程實現(xiàn)自動化。

五、個中得失感悟

到了這里有贊環(huán)境方便的分享差不多就結(jié)束了，因為有贊的歷史包袱復(fù)雜性，導(dǎo)致我們的環(huán)境相對復(fù)雜，從接手環(huán)境治理到取得階段性結(jié)果，差不多半年時間。期間處理遇到很多的環(huán)境問題，也走了不少彎路，一點一滴的經(jīng)驗都是寶貴的。環(huán)境問題在大多數(shù)公司都是一個頭痛的問題，所以很多時候心態(tài)上需要心平氣和，遇到問題大家一起解決也是獲得成長和友誼的過程。特別感謝運維和框架的兄弟們特別多的幫助和付出，有你有贊！