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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2）Service Chain 路由

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

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

首先應(yīng)用框架層面改造，實(shí)現(xiàn) RPC SC 路由，再通過 web 發(fā)布平臺(tái)將應(yīng)用帶有 sc 標(biāo)識(shí)服務(wù)信息寫入 etcd，這樣 RPC 調(diào)用的時(shí)候直接通過 RPC 路由將 sc 標(biāo)識(shí)進(jìn)行透傳，如果沒有匹配到 sc 標(biāo)識(shí)，默認(rèn)走到基礎(chǔ)鏈路服務(wù)，RPC 路由實(shí)現(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ā)布平臺(tái)將應(yīng)用帶有 sc 標(biāo)識(shí)的 rest 服務(wù)信息寫入到 etcd；接下來很重要的一步，實(shí)現(xiàn) rest sc 路由，做法是部署一臺(tái)專門干這個(gè)活的機(jī)器, 這里稱為 sc-nginx0 機(jī)器；rest 通過域名調(diào)用都會(huì)走到 sc-nginx0，sc-nignx0 再通過 nginx 配置做全應(yīng)用名稱模糊匹配，從而轉(zhuǎn)發(fā)到對(duì)應(yīng)的應(yīng)用 rest sc 服務(wù)節(jié)點(diǎn)，這樣就實(shí)現(xiàn)了 rest 調(diào)用標(biāo)識(shí)透傳。需要注意的是如果路由不上，會(huì)走到兜底的 sc-nginx1 機(jī)器，sc-nginx1 會(huì)路由基礎(chǔ)鏈路服務(wù)。鏈路圖如下：

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

3）Service Chain 入口

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

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

第一種，iron 入口。

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

第二種，node 入口。

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

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

4）Service Chain 出口

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

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

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

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

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

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

2）推動(dòng)應(yīng)用接入配置平臺(tái)

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

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

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

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

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

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

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

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

5）推動(dòng)項(xiàng)目試點(diǎn)

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

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

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

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

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

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

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

服務(wù)異常告警

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

五、個(gè)中得失感悟

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