環(huán)境對于一個迭代迅速的電商公司來說，它的重要性無須贅述了；如何讓環(huán)境高效，滿足多項目并發(fā)對環(huán)境的需求，節(jié)約環(huán)境機器成本，建立環(huán)境標準體系，這不是幾個人的事情，而是框架組、運維組、開發(fā)、測試、pm 大家共同努力的結(jié)果，其中的過程也不是一帆風順的，有贊在這條路上走過了很多坑，今天就給大家分享下我們的經(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 應用隔離解決方案是由框架組提出的解決方案，產(chǎn)生的背景是為了解決項目并行，大家搶占資源，開發(fā) 5 分鐘，聯(lián)調(diào)測試 1 小時的問題。

1）全鏈路標識透傳弱隔離方案

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

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

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

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

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

框架設計這個方案最初設定了 4 個目標：

a. 按需隔離應用，只需要隔離需求中有變更的應用

b. 全鏈路標識透傳，為以后的全鏈路壓測打下基礎

c. 應用侵入低，更多的由應用框架和中間件來感知和擔保，應用自身做到低侵入

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

最初的全鏈路設計方案

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

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

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

2）Service Chain 路由

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

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

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

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

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

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

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

3）Service Chain 入口

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

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

第一種，iron 入口。

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

第二種，node 入口。

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

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

4）Service Chain 出口

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

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

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

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

1）推動應用框架升級接入sc

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

2）推動應用接入配置平臺

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

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

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

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

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

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

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

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

5）推動項目試點

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

6）共性問題解決方案跟進

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

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

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

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

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

服務異常告警

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

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

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

9）環(huán)境培訓

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

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

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

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

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

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

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

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

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

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

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

五、個中得失感悟

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