雲的難處——咱們爲何須要 CloudEngine？

時間 2019-12-07

標籤雲的難處咱們爲何須要 cloudengine 简体版

原文原文鏈接

——咱們爲何須要 CloudEngine？
鄭昀建立於2016/7/31
關鍵詞：容器、Docker、OpenStack、虛擬機、私有云、Mesos、配置管理、部署、發佈web

2014年年末，咱們開始試着將原有的持續集成和持續發佈流程，從 OpenStack 遷移到 Docker 上。後來，我整理過兩篇文章講容器私有云和持續發佈都要解決哪些基礎問題（I，II）。
如今，OpenStack 又回來了，與 Docker 並肩做戰。不論是容器化 OpenStack，仍是 Docker 集羣，作到這一步就解決問題了嗎？數據庫

Docker+OpenStack，就夠了嗎？

咱們要的不只僅是容器或虛擬機
咱們都知道，Docker 實現的只是鏡像內部的小環境的一致性，它保證了一個應用程序在不一樣機器上運行時的一致性。tomcat

就咱們以前持續經營了五年之久的 O2O 電商平臺而言，首先它存在多條業務線：安全

團購服務器
POP 平臺網絡
電影訂座運維
網店通ssh
……分佈式

其次，它打通了供應鏈管理的全鏈條，從商機管理，銷售行動管理，簽約，終端設備鋪設，……，到與商戶的資金結算，與銷售體系的佣金計算，與第三方支付的自動對帳，與流量渠道的佣金對帳，各類平臺收費的核賬和攤銷等等，加上外圍技術支撐體系（如天機和鷹眼），裏裏外外大約近百個 Java 和 PHP 工程，每一個工程都是集羣。
這還不算上那些開源組件所需的集羣，如 ZooKeeper，Redis， MyCat，Elastic Search，還不算上商業智能的那套體系。工具

因此才雲科技的張鑫說得對：

然而大中型企業用戶很快意識到，真正的難點在於如何保證「大環境」一致，即整個業務系統中衆多容器、組件、服務之間如何配置、互聯、依賴，如何保證開發、測試、生產環境能相互轉化、克隆等。這些環境和配置在容器概念之上，是容器自身沒法解決的，只能依賴集羣層面的管理工具。

是的，給你一堆虛擬機，給你鏡像庫和一堆容器，你仍然很難構建出能 Run 起來的業務系統。

累覺不愛的部署

環境維護傷不起
一線互聯網公司的技術團隊紛紛誇耀本身在生產環境發佈的頻次。無疑，一天以內發佈頻次越高，同時發佈質量還很穩定，意味着技術管理水平越高超。

好吧，假定咱們僅僅是每週發佈一個常規版本（少則幾個工程，多則幾十個工程），每日可能有幾回 hotfix。那麼在生產環境中，部署時間 30 分鐘仍是 2 小時，區別不大，畢竟部署是一次性的工做。
但對於開發聯調和測試來講，就徹底不同。若是 1 分鐘就能完成一次部署，信手拈來，毫無意理負擔，能夠測試驗證的東西，和幾個小時才能完成一次的部署，差別是巨大的。

說白了，分佈式系統的線下環境維護，作過的人都知道，傷不起。

你家的業務系統能DRP嗎？

如何快速重建
何謂 DRP？
Disaster Recovery Plan，災難恢復計劃是也。

2011年藝龍曾經由於 EMC 存儲設備故障而連續 27 個小時沒法對外提供服務，在此以後他們作了相應的規範和開發，我去年看到一份資料說，藝龍能夠在 30 分鐘內異地重建集羣。此後適逢著名的攜程 5·28 停服 11 個小時的大事件，驚嚇之餘咱們啓動了 DRP 計劃。
DRP 涵蓋的事務有：

代碼
配置
數據

DRP 面對的災難場景：

生產機房物理毀滅，或短期內網絡不通（如光纜被挖斷）
線下機房毀滅

想一想看，若是你有一整套研發測試運維流程規範，還有：

代碼庫備份，
鏡像庫（包括了基礎鏡像）備份，
分環境的配置管理（一個環境對應一套持久化配置中心），
運維層面的 CMDB 備份，
數據庫備份（跨機房數據同步），
在虛擬機和容器集羣之上的集羣管理工具

那 DRP 可能真的是水到渠成。

大前提：配置管理規範

配置與代碼分離
前面說過，給你 OpenStack 和 Docker，你也很難快速構建出可運行的業務系統，那該怎麼辦？

首先咱們要明白，要作到真正的大環境一致，必須將配置徹底與代碼分離，這裏的配置不只僅是服務之間的 IP 地址/內部域名/自動發現，還包括不一樣環境下不一樣應用的配置參數等。
咱們要求的是，線下測試環境測試經過的包（或鏡像），能夠直接上預發環境，上生產環境，一路穿行沒有障礙。
咱們不但願看到的是，不一樣環境須要打不一樣的包/鏡像。

所以，首先咱們要一套環境對應一個持久化配置中心，與環境有關的參數都存儲在配置中內心。
其次，每一個應用都有本身的配置模板，不一樣環境部署的應用默認繼承配置模板，人們能夠經過集羣管理工具（或配置中心的管理界面）對本環境配置作一些微調。

必定要能管到應用層面

自研的 Java/PHP 工程，中間件，開源組件，這些都叫「應用」。
咱們在集羣管理工具裏，操做的對象是「應用」而不是裸機（固然你也能申請裸虛擬機）。
重要的是，將鏡像的構建與代碼庫的分支構建整合。

想一想看，
你本身的應用，應用的元信息裏已經指定好了代碼倉庫地址，你本次只須要指定分支（一套環境對應一個分支，如測試環境對應於測試分支），選擇虛擬化技術（虛擬機仍是容器），指定節點數量；
開源組件，好比你選擇構建一個 Redis 集羣，你只須要選擇相應的鏡像，指定節點數量，微調下配置；
幾分鐘後一切成爲現實，網絡已經配置好了，內部域名就位，你能馬上開始聯調測試，是否是很美好？

背後對應哪些事情？咱們以阿里的 ACP 給應用分配虛擬機資源爲例吧：