專欄策劃｜雅純
志愿編輯｜jimmy、呂瑞星
“對于生產環境，準確、穩定最重要，我們推薦以應用為中心的基于OAM和IaC的實踐方式，
對于測驗環境，隔離、低成本和穩定的依賴最重要，我們推薦基于穩定環境的隔離測驗環境的實踐，復用穩定環境，通過流量隔離和資料隔離來生成測驗環境，“
以下是詳細內容，
環境這個概念，大多數開發者都很熟悉，一個穩定、可預期、低成本的環境也是大家一致的訴求，
如下圖所示,我們將環境分為生產環境、測驗環境、開發環境3類，很多時候我們會把生產環境、測驗環境、開發環境隔離開，就像圖上的那個防火墻一樣，分為線下環境和線上環境，
但在實際情況下，考慮公司體量和開發成本等諸多因素，環境的使用和劃分會發生一些變化，
例如，基于成本考量，首先要保證的是生產環境，一切以提供服務為核心要務；其次是測驗環境，在遷移至線上環境之前我們需要在類似于生產環境的測驗環境中進行相應的驗證，只有在測驗環境中驗證無誤才可以遷移至生產環境，從而保證系統穩定的過渡，
生產環境
對于生產環境，準確、穩定的運行是相當重要的，也產生了大量的運維和治理的訴求，
如果測驗環境給配置一個節點就夠了，生產環境就要考慮備份、主備、分流、容災等諸多問題，其目的都是為了保障環境的穩定運行，
準確、穩定是生產環境和別的環境的最大區別，這一特點帶來了大量的運維的和服務治理的配置訴求，如何有效維護這些配置也是我們基于OAM模型、以IaC的方式來管理配置的初衷，上篇文章中有做分享，
（小編注：云效AppStack正是基于OAM的云原生應用交付平臺，企業可以通過應用編排、占位符、變數等宣告式定義，實作一套編排多環境差異化部署，同時基于版本和基線實作環境一鍵拉起、一鍵回滾，感興趣的同學點擊文末閱讀原文可以免費使用），
生產環境包含了很多種配置，如應用配置、應用鏡像、應用運維配置、基礎設施運維配置等，這些不同的配置和鏡像的內容是由不同的同學關注和管理的，
開發修改代碼，代碼發布會改變鏡像和配置；應用運維會主動修改應用運維配置；基礎設施運維會修改基礎設施配置，所有的配置改動都會對生產環境產生影響，帶來生產環境的變化，進而可能帶來風險，
因此生產環境的運維和和管理顯然應該是由開發和運維來共同負責的，
測驗環境
測驗環境是另一類重要環境，測驗環境包含兩種型別：一種是集成環境，一種是預發環境，預發環境也就是類生產環境，集成環境主要用于集成測驗，或者功能性的驗證；預發環境主要在驗收的程序中使用，
測驗環境的目標是用盡可能少的資源進行獨立的測驗，做到隔離、復用、模擬，
例如，應用要跟外部的服務互動，如果外部服務有問題，可以在測驗環境中模擬一個，
以某大資料產品為例，大資料產品大家可能會覺得環境要求太高了，沒有辦法做測驗環境，很多的技術服務如Hive、Kafka、MySQL，對機器的要求會很高：Hive、Kafka需要有很多的機器，另外，還需要Redis做快取、Zookeeper做服務發現，最早的時候就一套測驗環境，這個顯然是很低效的，如果有50個開發，共享一套測驗環境，頻繁沖突的情況下，幾乎沒有辦法做測驗，
為了解決這個問題，服務和應用可以做一些分層，這里分成三層，首先是公共的基礎服務，比如Hive、Kafka；然后是獨立的小服務，比如Redis、Zookeeper，在測驗環境下，Redis和Zookeeper全部用單點是沒有問題的，可以在一臺虛擬機上跑起來；最上層是應用，只部署必須的應用以完成所要的測驗作業，
因此，測驗環境將會這么管理：首先所有的公共服務是共享的基礎服務，所有的測驗環境都依賴這些基礎服務，各個環境的資料通過邏輯機制（如命名空間）進行隔離，在每一個測驗環境會部署一套獨立服務的Redis、Zookeeper，
應用層只部署所需要的應用，這樣基本可以做到只消耗很小的資源就可以部署一套測驗環境，很多的測驗資源利用率很低，如果完整的搭一套環境的話你會發現99.99%的情況下，資源利用率都很低，
另外測驗環境都應當是臨時環境，這一點很重要，如果把測驗環境用作長期環境，使用者會習慣某個環境就是他的，例如給環境起名字，這個環境其他人不能用，而這樣會造成很大的浪費，畢竟每天使用的時間都是有限的，我們希望測驗環境的資源是一個池子，可以被復用，用完即銷毀，這也同時要求提高測驗效率，在最短的時間內做更多的測驗，
開發環境
開發環境是除了上文我們說到的生產環境和測驗環境之外涉及最多的環境，比如開發、構建要用到的一些工具鏈，都屬于開發環境的范疇，在開發環境下，我們的關注點是在本地上怎么把服務順暢跑起來，
理想的開發環境可以跟其他的服務打通，且雙向連通，因此有3個需要解決的問題：首先這個開發環境怎么訪問基礎環境中的服務，比如另外一個Service，第二個是怎么讓其他服務訪問到我們開發中的服務，第三個是怎么與其他的開發環境的請求和資料隔離，這也是我們在前面測驗環境遇到的類似的問題，因此在開發環境之間也需要類似的手段，云效團隊開源的kt-connect就是為了解決這個問題而設計的一個工具，
在開發環境里也會有相應的一些工具，如上圖所示，大家也可以看一下，你常用的有哪些，
測驗環境之痛
很多公司、很多人一提到測驗環境就會說測驗環境不夠用、測驗環境不穩定，我們在測驗環境中會面臨哪些挑戰？尤其是分布式應用，在微服務化之后，分布式所面對的挑戰也越發明顯，這些挑戰很多和環境有關，
例如某個應用變化沒有做很好的驗證，無意間進入到集成環境，這樣它進入集成環境的時候本身質量是無法保證的，而在集成測驗階段，應用之間的關系非常復雜，一個服務不穩定，其他的鏈路都很有可能不穩定，
這也導致我們經常沒有辦法很好地進行日常集成測驗，因為前面的程序沒有辦法保證，這個時候變化的應用會占用預發環境，而預發環境又是一個相對高成本的環境，不可能經常被某個人占用，于是，為了能讓所有人都可以使用預發，對預發的使用將會變成很多人批量進行，這樣預發變成長期環境，帶來的后果就是預發的時間增長，整個開發周期和交付周期都會增長，在持續交付的流程當中，我們在測驗環境當中會面臨非常多的挑戰：不穩定的問題、資源的問題、集成的問題等，
就目前來說，大家會遇到的比較多的測驗環境的問題，大都源自服務沒有進行有效的治理，服務方法多，耦合高，一旦某個服務出現問題，其他的都會受到影響，當一個環境的服務都是處在變化中時，由于隨時都有不穩定的服務在部署，整個環境也將是不穩定的，
集成環境無法穩定的后果是大量的測驗遷往預發，預發成為瓶頸之后又往線上遷移，任何應用最終都會用線上環境來兜底，
總結來看，測驗環境主要面臨如下2個挑戰：
第一個是如何解決服務之間的依賴，比如A對C的強依賴，A的功能成功與否取決于C，而且C變化之后也要在A上面做相應的驗證，保證C的變化是對的，
另外一個是環境本身的，主要有2點，一個是機器的穩定性，另一個是服務本身的穩定性，
機器的穩定主要是：有效應對硬碟故障，網路故障等情況，做好系統的備份和容災，
服務本身的穩定主要是：有效確保每個服務自身的可用性，因為假如一個應用的可用性是90%的話，那10個應用就是90%的10次方，導致整個的系統都會很低，
如何保證測驗環境的穩定性
上文我們說到了測驗環境存在的兩種挑戰，任何測驗環境都需要保證其穩定性，降低使用線上環境的風險，那么如何保證測驗環境的穩定性呢？
在測驗環境中常用的實踐主要有：雙機部署、N+1部署、隔離環境等，
例如我們一個應用至少部署兩個Pod，保證至少一個在提供服務，不能讓兩個同時重啟，確實會發生這樣的情況：在某個測驗環境，如果某個服務只有一個副本，該服務發生部署導致重啟，會導致整個測驗的不可用，在這種情況下雙機部署是很好的快速解決手段，但也占用了較多的資源，
為了解決雙機部署資源占用高的缺點，N+1的部署方式應運而生，采用滾動的方式逐個替換服務應用，這樣你的機器就只有一個是處于變化當中，其他都是work的，這也是K8S默認的方式，一般會生成新的實體，然后再把舊的實體下掉，
為了保證測驗系統的穩定性，我們需要做隔離，盡量做到除自己修改的應用，其它應用都是穩定的，
在阿里，團隊引入了專案預集成環境，在阿里內部叫專案環境，這是一個隔離出來的環境，針對某一個特性在開發的階段單獨的拉取一個環境出來，
綜上所述，預集成環境是隔離的，跟誰都沒有關系，所依賴的其它服務都來源于穩定的環境，以保證依賴的服務都是穩定的，以便進行獨立的開發和測驗，
在專案早期的時候，專案預集成環境里依賴的環境還是日常集成環境，無論如何肯定比什么都不做直接放入日常集成環境里面好很多，這個時候我們發現日常集成環境還是有問題，因為在專案初期并不能保證所有的提交都會在專案預集成環境去做驗證，因此會導致日常集成環境里面的依賴也可能存在很大的問題，其實本質上又回到了我們要治理日常的集成環境的事情，怎么樣維持相對穩定，
針對上述問題，我們引入穩定環境的概念，既然我們將環境隔離出來了，但隔離依賴的基礎環境不穩定，這個時候假如我們有一個穩定的環境是否就能解決問題了呢？
什么樣的環境是穩定環境呢？就是能夠發布到線上版本的環境，線上環境肯定是穩定環境，所以我們的穩定環境其實是由與線上版本一致的應用服務組成的，跟線上的服務是一致的，線上穩定，這個環境就是穩定的，所以我們就可以在這種穩定環境下再去創造隔離環境，從而保證整體穩定性，
當有了穩定的基礎環境，在應用部署到生產環境之后，也同樣要把它部署到基礎環境中去，提供一個給測驗環境作為依賴的基礎環境，有了這樣一個基礎環境依賴，在我們應用開發時，拉出來的環境就是完全隔離的，只包含和我緊密相關的幾個變化當中的應用，其余所有的依賴的服務都是從基礎環境里面來的，
這里提到了基礎環境的概念，那么什么是基礎環境呢？基礎環境是一個穩定的環境，當有了一個穩定的集成環境就可以做隔離的環境，特性測驗將可以基于該隔離環境，依賴的流量也可以在隔離環境里面找，但基礎環境有一定的維護成本，雖然部署成本相對來說很低，其占用的機器資源相對于一般大公司來說不是太大的問題，但對小公司可能是一個問題，但主要的成本是基礎環境的維護，對基礎環境進行監控并修復出現的問題，這在人力上需要一定的投入，
基礎環境的維護者一般不是這個環境的使用者，所以這個時候需要有一個比較成熟的機制保證基礎環境長期穩定的運行，我們開一下腦洞，如果說沒有新的基礎環境，哪一個環境是最穩定的呢？我們在前面把線上線下用防火墻隔開了，為什么隔開大家都知道，我們是怕安全風險，怕資料污染，但是如果我們的隔離能力做的足夠好，服務路由做的足夠好，監控做的足夠好，安全保護做的足夠好，我們是可以用生產環境來做基礎環境的，
生產環境做基礎環境，要解決兩個重要的問題，第一個是流量隔離，流量隔離相對來說問題不太大，從以前面向資源到現在面向流量的隔離有很多現成的手段可以做，第二個是資料隔離，這個是挺大的挑戰，資料形式有很多種，比如說訊息佇列和普通的資料庫不一樣，數倉又不一樣，很多麻煩的問題在這里，但是具體到某一個點上都有辦法解決，
小結
總結一下，對于生產環境，準確、穩定最重要，我們推薦以應用為中心的基于OAM和IaC的實踐方式；對于測驗環境，隔離、低成本和穩定的依賴是最重要的，我們推薦基于穩定環境的隔離測驗環境的實踐，復用穩定環境，通過流量隔離和資料隔離來生成測驗環境，通過環境建設，我們解決了研發程序中的資源沖突，下一章我們將關注研發程序中的協作問題，
點擊下方鏈接體驗云效云原生應用交付平臺AppStack！
https://www.aliyun.com/product/yunxiao/appstack?channel=yy_rccb_36
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/432028.html
標籤：其他