線上環境建設，要扛得住真刀真槍的考驗

前面幾期我們分享了一些線下環境建設方面的內容，我們可以感受到，整個線下環境的建設是比較複雜的，那經過線下環境的驗證，是不是就可以直接釋出到線上生產環境了呢？答案同樣是否定的，由線下正式交付到線上之前，我們仍然會做很多的驗證和穩定性保障工作。

今天我們就一起來看一下線上環境是如何建設的。

下面，我們就生產環境、Beta環境、預發環境、辦公網生產環境這四種線上環境分別展開討論。

生產環境

我們還是進入到現實場景中。最初我們的軟體程式碼開發完成後，就可以釋出到生產環境，也就是可以正式接入使用者流量，承載真實的業務場景。

在最早期，我們業務複雜度不高，使用者量不大，叢集規模小，軟體架構也相對簡單。在這種情況下，其實這一個環境就足夠了，真有問題，也可以快速回退掉。退一步講，即使有問題也回退不了的話，影響範圍也有限。

所以，這個時候，線上環境=生產環境。

我們知道，隨著業務量增大和業務複雜度升高，我們的軟體架構、部署模式、叢集規模等等也相應變得複雜和龐大起來。同時，業務產品在使用者和業界的影響力也在變得越來越大。

這個時候，任何一個小的變更或一個不起眼的小問題，都有可能導致非常嚴重的故障，從而造成公司資損甚至是惡劣的產品口碑影響。

比如，我們假想一下，如果國內某個大型電商平臺不可用，或者某即時通訊軟體不可用，會造成何等嚴重的後果，就不難想象了。

所以，這時就需要我們非常嚴肅而謹慎地應對生產環境的變更。

我想你可能跟我一樣，會想到一個問題：就是我們不是已經線上下環境經過了很多輪不同形式的驗證測試環節，為什麼到了生產環境還會有驗證不到的嚴重問題？

這裡涉及一個使用者和業務場景的概念，就是線下和線上的使用者場景是完全不同的：線下是我們模擬出來的，線上卻是真實的使用者場景，這兩者之間會存在巨大的差異，有差異，系統的表現狀況就會不一樣。

所以線下我們只能儘可能地確保業務功能和業務流程是正常的，但是沒法百分之百模擬線上場景，特別是一些異常特殊場景方面。這一點後面的文章我們還會再分享，這篇文章我們只要知道存在差異即可。

這個時候，我們的第一個思路就是：即使有影響，也要把它控制在小範圍內，或者是在萌芽狀態時就發現。這樣就可以提前處理，而不是全量釋出到生產環境後才發現問題，影響全域性。

所以，線上的第二個環境，Beta環境就產生了。這個環境也可以叫做灰度環境，包括我們常提到的金絲雀釋出，也是基於這個環境的釋出模式。

Beta環境

這個環境的建設，我們簡單理解，就是從生產環境的叢集中，再建立一個獨立叢集。看過我們之前介紹CMDB應用和服務分組的文章的讀者應該不難理解，針對應用，就是再建立一個分組，獨立出一個叢集出來，但是這個叢集中伺服器數量1-2臺即可，主要還是針對小規模真實業務流量。如何做到小規模呢？這就要在負載均衡策略上做工作了，主要兩種方式：

• 呼叫RPC，在服務化框架的複雜均衡策略中，將其權重或者流量配比降低；
• 呼叫HTTP，在四層VIP或者七層權重上，將權重降低。

這個環境同樣不會全量建設，通常只針對核心應用，比如交易鏈路上的各個應用。同時，除了承擔的流量比重不同外，其它與生產環境的應用沒有任何差別。

後面的部署釋出環節，我們會看到，針對核心應用，必須要經過Beta釋出環節，才允許正式釋出到生產環境。

有了Beta環境之後，上面說到的影響範圍的問題從一定程度上就可控了。但是在Beta環境上我們仍然會有兩個問題無法很好的解決：

• 影響範圍再可控，其實也已經影響到了部分真實使用者，特別是當訪問量特別大的時候，即使是千分之一、萬分之一，也是不小的數量。

• 之前經歷的線下環境畢竟是一個模擬環境，一方面，在資料規模、分佈特點、多樣性以及真實性方面，跟生產環境的資料場景還是會有很大的區別，所以有很多跟業務邏輯相關性不大，但是跟資料相關性特別強的場景功能，線上下環境就很難驗證出來；另一方面，對於一些第三方的系統，特別是商家、支付和物流這樣的體系，線上下環境極有可能是Mock出來的，所以驗證的時候並不能代表真實場景，但是等到了線上再去發現問題，就可能就會造成真實的業務影響。業務訪問失敗可以重試，但是造成商家真實的銷售資料錯誤，或者使用者真實的支付資金錯誤，這樣就會非常麻煩了。所以，從線下直接進入Beta環境，還是會給生產環境，特別是資料層面造成影響。

當業務複雜度和系統規模發展到一定程度後，上面兩個問題就會非常突出，所以單純的Beta環境是無法滿足要求的。

這時，線上第三套環境，預發環境，就產生了。

預發環境

預發環境在建設上，有以下幾個規則要求：

狀態基礎服務共用，如DB、KV、檔案儲存以及搜尋類的資料服務。這裡基本就是真實的生產環境的基礎了，我們上述的問題在這個基礎上就可以很好地解決了。除有狀態服務外，其他都需要在預發環境上進行全套建設，但是資源使用上，一般是一個應用部署一個例項即可，所以規模比生產環境要小很多。

網路隔離上，預發環境做獨立網段的劃分，不承擔線上真實流量，獨佔一個B段，同時在網路上進行邏輯隔離。業務呼叫必須本環境內閉環，預發不允許跨環境進行應用服務呼叫，如預發應用呼叫生產環境應用，反之亦然。

要保證一定的穩定性。預發環節就是基於線上真實環境進行功能和業務流程的最終驗證，所以對於版本質量要求是要高於線下環境，所以不允許反覆頻繁地變更部署，出現異常或警告也必須要以較高優先順序處理。

上述環境的搭建，使用的技術方案，跟我們上篇文章講到的方案是通用的，如服務單元化呼叫、繫結hosts以及網路策略隔離等等。預發環境與生產環境的關係如下圖：

預發環境正式使用後的另一用途，就是在生產環境出現問題，但是線下復現不了時，就可以在預發環境上覆現，這樣對於問題定位會帶來很大幫助。如果是在生產環境上做除錯和問題定位，有時候會影響到正常使用者訪問，但是預發環境的影響就可控一些。

不過，定位問題可以，但是絕對不可以通過預發環境去做下面兩件事：

• 與資料訂正和變更相關的事情。因為這是由業務流程觸發，而不應該由調測觸發。而且要時刻牢記，在這個環境做的任何事情都是會對生產環境產生直接影響的，所以這裡必要要靠強調意識、事先培訓等方式進行避免。
• 阻塞他人工作。在定位問題的過程中，如果發現有其他應用依賴，這時要停下來，優先保證環境穩定性，而不是阻塞依賴方釋出前的準備工作。

形象一點描述，預發環境就像是球類運動員，他們平時可以在訓練場進行訓練，但是正式比賽前，一定是要到正式比賽場地提前適應場地或者熱身。一方面是為了瞭解現場的實際情況，做針對性的準備和調整；另一方面也是為了調動賽前興奮度和氛圍。

預發環境搭投入使用之後，有很多問題在這個階段被發現，而且是開發和測試同學目前強依賴的一個環境，所以確實進一步保障了業務的穩定性。

然而，在這個環境中仍然存在一個問題。下面我還是以電商為例。

電商每年大促，一般都是提前幾個月準備，有可能開發團隊在大促活動正式開始前3-4周左右，業務功能都已經開發完成，但是這個時候是不能上線的，或者上線了也要有入口開關控制，絕對不能讓使用者流量提前進來。

與此同時，運營側的招商、報名以及商品上架這些工作也會提前完成，所以這時線上實際已經具備了真實的大促環境，只是因為時間點不到，暫時只能等著。

但是，如果有一個只讓員工訪問，讓員工們體驗和反饋問題的環境，那麼，在這個階段我們是可以提前暴露很多問題，並進行很多優化改進的。這樣做就更進一步保障了大促的系統問題和使用者體驗。

不過，上述Beta環境和生產環境是無法滿足要求的。預發環境能滿足一部分要求，但是因為這個環境主要還是供開發和測試驗證功能使用，在訪問的便捷性和功能體驗方面，不能完全保證達到真實使用者訪問的要求和體驗。

為了滿足上述需求，我們會再單獨建設一個環境出來，於是，線上環境的第四套環境，辦公網生產環境，就應運而生了。

辦公網生產環境

辦公網生產環境建設的技術方案與預發環境一致，但是在要求上又有所不同：

訪問使用者是辦公網內的員工使用者，所以必須連線指定的辦公網wif接入點。於是，員工會通過wif被劫持到這個環境上，這時使用者就可以在這個環境中提前體驗新版本軟體的功能，比如我們之前說的大促活動等。

穩定性要求上，辦公網生產環境相當於生產環境，雖然不是外部使用者訪問，但是一個公司內的員工也算是真實使用者了，他們發現的問題等同於線上問題，但是級別上會降低一級處理。

建設規模上，公司有上千、上萬名員工，他們的頻繁訪問行為，也產生一定的業務量，所以綜合上述穩定性要求，辦公網生產環境在規模上會根據應用容量進行相應的資源分配，這裡至少每個應用應該以兩個例項做冗餘。

所以這個環境，從建設規模和穩定性要求上，就相當於一個小號的生產環境，所以我們內部又把它簡稱為“小蘑菇”環境。

總結

我們簡單構建一張模型圖來對線上環境作個展示：

我在這兩期文章中介紹了這麼多環境，我們可以看到，環境建設是一項異常繁瑣複雜的工作，這些工作不是一蹴而就，而是根據實際的場景和問題催生出來的，所以是個逐步漸進的過程。

而且，因為不同的業務型別和場景，以及業務發展的不同階段，場景和問題可能都是不一樣的，而且其建設需求也不一樣，所以在實際操作中，一定要切合具體情況進行建設。

再就是，環境管理是複雜的，多一個環境就多一份管理成本。所以環境並不是越多越好，反而是越精簡越好。這個時候也需要各位讀者能夠有一定的ROI評估，畢竟能帶來最大價值的投入才是有意義的，而不是盲目地建設和投入。

最後，給你留幾個問題思考：

• 我們分別介紹了線下環境和線上環境的建設，這兩個環境在持續交付體系中，分別對應哪些理念和指導思想？

• 我們建設了這麼多的環境，都是為了解決不同場景下的問題，那麼還有哪些問題是上述這些環境仍然解決不了的？

歡迎你留言與我討論。

精選提問

1. 預發和辦公室線上環境使用的都是生產資料，會不會存在干擾？預發的使用者限定為內部測試嗎，與預發資料層和生產分開有什麼利弊？

   測試目的不一樣，預發環境主要給開發和測試做最終的聯調，介面和核心功能驗證，辦公網線上環境就正式開放給使用者通過app或電腦使用，只不過使用者是公司員工而已。
   用線上資料就是為了保證真實資料環境下確保沒有問題，對於會造成資料汙染的操作是禁止的，這一點在研發內部是要專門培訓和強調的，出現問題也是要承擔責任的。
   

2. 預發辦公室 第三方回撥的問題 有無遇到 怎麼解決

   通常mock模擬，依賴外部的環節又是無法完全具體條件
   

3. 這三套生產環境公用一套資料庫，意味著所有對資料庫的升級要考慮平滑了

   相容性是介面設計時必須考慮的環節，這個是前提