資訊專欄INFORMATION COLUMN
摘要：這么思考問題的原因也很簡單，我們篤信工程師文化，靠技術而不是管理解決問題，正如陳皓同學所言如果你是一個技術公司，你就會更多的相信技術而不是管理。
鄭昀 創建于2017/3/8 最后更新于2017/3/10
關鍵詞：研發協作，Docker，環境變量，開發聯調，環境維護，虛擬機，中間件，配置與代碼分離，git，jenkins
開發聯調，測試，預發，生產，稍微上規模的互聯網技術團隊，每一次發布都需要經歷這四個階段。每一個階段都對應于一個環境。所以我們會面對：
開發聯調環境，測試環境，預發環境，生產環境。
產品線若干條。并發多個版本。工程無數，有Java，有PHP，有中間件。
說句狠話：沒有趁手的利器，生產效率打完對折再打對折，勿謂言之不預也。
云縱有 CloudEngine，如我的《私有云的難處—為什么需要CloudEngine？》和《#研發解決方案#研發協作平臺CloudEngine》文章所述，我以為能非常流暢地打通這四個環境，即使生產環境是混合云，即使應用可能發布在Docker容器里也可能發布在虛擬機里。
陳皓同學在《從Gitlab誤刪除數據庫想到的》中說道：
一個公司的運維能力的強弱和你上線上環境敲命令是有關的，你越是喜歡上線敲命令，你的運維能力就越弱，越是通過自動化來處理問題，你的運維能力就越強。
而我希望的是：
環境維護，應用部署，只是勾勾點點，沒有心理負擔，dont make me think。 一個代碼分支，對應的一個包（或鏡像，對應于
Docker 的
Image），可以流經開發聯調環境、測試環境，直接上預發環境，上生產環境，上云端，一路穿行沒有障礙，全程無需手工干預，無需手工改配置文件重新打包。
這么思考問題的原因也很簡單，我們篤信工程師文化，靠技術而不是管理解決問題，正如陳皓同學所言：
如果你是一個技術公司，你就會更多的相信技術而不是管理。相信技術會用技術來解決問題。相信管理，那就只會由制度、流程和價值觀來解決問題。
那么怎么辦到呢？
先來一個管中窺豹：
圖0 管中窺豹，CE里是怎么申請服務器資源的
再來品嘗一下關鍵點。
我之前說過：
要做到真正的大環境一致，必須將配置完全與代碼分離，這里的配置不僅僅是服務之間的 IP
地址/內部域名/自動發現，還包括不同環境下不同應用的配置參數等。 首先我們把與環境相關的參數都存儲在持久化配置中心里，比如 redis/zk
的訪問域名，比如第三方合作伙伴的接口IP地址等。 其次，每個應用也都有自己的配置模板，不同環境部署的應用默認繼承配置模板，我們可以通過
CloudEngine 對配置做一些微調，也就是下面要講到的“臨時屬性信息”了。
CloudEngine 和 SimpleWay 會把環境標識（如 dev/dev-stable/test/test-stable/product 等）和需求工單號，以環境變量的方式打入“服務器”（即容器或虛擬機）里。
工程通過環境變量確認自己在哪一個環境里，對應哪一個需求工單，從而從持久化配置中心讀取到當前環境和當前需求對應的屬性信息。
所謂屬性信息有三類：
1）環境屬性信息：
環境的配置信息在環境層級設置，對應于“環境管理”菜單。比如開發穩定環境下的環境變量，我可以通過如下界面統一配置：
（圖1 環境屬性信息）
2）應用屬性信息：
應用的配置信息在應用層級設置，對應于“應用管理”菜單。比如janus工程（Java）的應用配置，我可以通過如下界面來配置：
（圖2 應用屬性信息）
3）臨時屬性信息：
應用實例的配置信息在服務器層級設置，對應于“服務器管理”菜單。也就是這次我申請機器資源時，可以通過如下界面設置好臨時屬性信息，只有這個應用實例能訪問到：
（圖3 臨時屬性信息）
以前沒有 CloudEngine 的時候，我們會維護三套測試環境：常規分支測試環境，緊急分支測試環境，特殊分支測試環境。分別對應于上線的班車模式（每周固定發車），警車模式（bugfix），專車模式（版本很大，開發和測試周期較長）。
維護三套測試環境，真心累。
現在只需要維護一套測試環境。
那么問題來了，多個需求工單，怎么在一套環境里并行測試？
秘訣就是，在環境里再建一個穩定環境（Stable）。
穩定環境里的應用，只會部署 Release 版本。
根據需求工單申請的新服務器資源，可以訪問穩定環境里的業務中心，至少能保證相關業務能正常運行，不會說突然功能不能用了，突然服務宕機了。
如果開發聯調環境和測試環境里的應用需要接受外網的請求，那么在 CloudEngine 里也不需要反復申請外網域名。統一使用 router.yourcompany.com 域名接受外網請求，然后通過 nginx 轉發請求到相應的內網應用。
圖4 是否需要接受外網請求
在相應的環境里，申請服務器資源時，你不需要鍵入 git 的代碼分支，你輸入應用名稱，選好應用之后，系統會自動列出相應的分支，智能吧：
（圖5 分支自動展現）
這充分體現了我們的哲學：dont make me think。
五，小結我們技術團隊可以標準化輸出的成體系的通用技術能力有：
1）
基于虛擬機集群和容器集群的研發協作平臺：
申請服務器資源（虛擬機或容器），自動化構建，自動化部署，可自動發布到我們自己的公司機房、阿里云、螞蟻金融云和IDC機房，支持版本回滾；
2）
電商全套中間件解決方案：
定時任務管理與調度平臺，
異步消息可靠推送系統，
分布式并行計算調度和管理系統，
一站式智能監控報警平臺，
分布式跟蹤系統，
分布式緩存管理系統，
數據庫自動化運維平臺，
3）
大數據全套解決方案：
自助式報表平臺，
即席查詢系統，
數據庫變更訂閱中心，
實時數據大屏發布平臺，
大數據計算任務發布管理平臺，
4）
運維基礎設施：
運維自動化平臺，
云平臺基礎（虛擬機集群和容器集群），
大數據分析棧架構。
此體系絕非一朝一夕所能搭建，這是秉承著平凡人做非凡事的理念，一群信仰技術的工程師邊開飛機邊換引擎，花了幾年歲月建造的森嚴有序的技術體系。
-EOF-
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/66912.html
摘要：這么思考問題的原因也很簡單，我們篤信工程師文化，靠技術而不是管理解決問題，正如陳皓同學所言如果你是一個技術公司，你就會更多的相信技術而不是管理。 鄭昀 創建于2017/3/8 最后更新于2017/3/10 關鍵詞：研發協作，Docker，環境變量，開發聯調，環境維護，虛擬機，中間件，配置與代碼分離，git，jenkins 開發聯調，測試，預發，生產，稍微上規模的互聯網技術團隊，每一次...
摘要：小編一哥們和我吐槽自家的煩惱原本一個有錢有閑的證券行業經理一年前被老板派去支持創新業務探索因為新型業務在不斷加速鋪開當前的單體式應用復雜度越來越高業務上線過程繁瑣流程冗長資源分配耗時較多更新頻率越來越低人員也越來越顯得捉襟見肘這哥們于是開始 小編一哥們和我吐槽自家的煩惱原本一個有錢有閑的證券行業IT經理一年前被老板派去支持創新業務探索因為新型業務在不斷加速鋪開當前的單體式應用復雜度越來...
摘要：以推出輕舟微服務平臺的網易云為代表，云計算公司正在微服務領域發力，促進企業數字化創新。以網易云輕舟微服務平臺為例，該平臺已經在物流工業和金融等領域得到了深度應用。 所謂數字化轉型升級，就是以數字技術優化傳統資源，企業需要謹慎地選擇合適的技術逐步完成自己的數字化戰略。以推出輕舟微服務平臺的網易云為代表，云計算公司正在微服務領域發力，促進企業數字化創新。那么，微服務對數字化轉型意味著什么？...
摘要：近日，網易云輕舟微服務團隊接受了的采訪，分享了網易云在云原生領域尤其是方面的實踐經驗。影響根據網易云團隊的數據，使研發效率提高了以上，部署效率提高了。無論是否使用網易云產品，網易云都鼓勵其他公司嘗試。 近日，網易云輕舟微服務團隊接受了CNCF的采訪，分享了網易云在云原生領域尤其是Kubernetes方面的實踐經驗。以下為案例全文：showImg(https://segmentfault...
摘要：然而，敏銳的已經意識到，德邦快遞率先引入的微服務架構，正在成為企業數字化轉型升級戰略成功的基石，成為企業引領行業創新的秘密武器。 2018年雙11，中國網民釋放出來超過2000億元的購買力，給快遞公司帶來了新的一輪考驗。剛剛從大件快遞切入快遞市場的德邦快遞，卻無驚無險地完成了客戶的托付。信任德邦快遞的店主和買家并不知道，在這戰績背后，德邦快遞投入了每年5億元的數字化建設成本，并采用了先...
閱讀 3712·2021-10-12 10:11
閱讀 1978·2019-08-30 15:53
閱讀 1587·2019-08-30 13:15
閱讀 2301·2019-08-30 11:25
閱讀 1796·2019-08-29 11:24
閱讀 1646·2019-08-26 13:53
閱讀 3520·2019-08-26 13:22
閱讀 1746·2019-08-26 10:24
