OpenStack架構企業IT應用的敏捷實踐

發表于14小時前| 203次閱讀| 來源《程序員》電子刊| 0 條評論| 作者張小斌 肖何 謝勝

OpenStack云平臺敏捷架構應用 width="22" height="16" src="http://hits.sinajs.cn/A1/weiboshare.html?url=http%3A%2F%2Fwww.csdn.net%2Farticle%2F2015-11-08%2F2826148&type=3&count=&appkey=&title=%E6%9C%AC%E6%96%87%E6%9D%A5%E8%87%AA%E3%80%8A%E7%A8%8B%E5%BA%8F%E5%91%98%E3%80%8B%E7%94%B5%E5%AD%90%E5%88%8A1511A%E6%9C%9F%E5%B0%81%E9%9D%A2%E6%8A%A5%E9%81%93%EF%BC%8C%E4%BB%8B%E7%BB%8D%E4%BC%A0%E7%BB%9F%E4%BC%81%E4%B8%9AIT%E5%BA%94%E7%94%A8%E6%9E%B6%E6%9E%84%E5%9F%BA%E4%BA%8EOpenStack%E4%BA%91%E5%8C%96%E7%9A%84%E5%AE%9E%E8%B7%B5%EF%BC%8C%E6%96%87%E7%AB%A0%E4%BB%8E%E4%BA%91%E5%B9%B3%E5%8F%B0%E9%80%89%E5%9E%8B%E3%80%81%E6%A0%B8%E5%BF%83%E5%BA%94%E7%94%A8%E6%A8%A1%E5%BC%8F%E3%80%81%E6%95%B0%E6%8D%AE%E5%AD%98%E5%82%A8%E5%8F%8A%E7%AE%A1%E7%90%86%E3%80%81%E8%B5%84%E6%BA%90%E8%B0%83%E5%BA%A6%E4%BB%A5%E5%8F%8A%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91%E5%AE%9E%E8%B7%B5%E7%AD%89%E5%A4%9A%E8%A7%92%E5%BA%A6%E5%85%A8%E6%96%B9%E4%BD%8D%E8%AF%A0%E9%87%8A%E3%80%82&pic=&ralateUid=&language=zh_cn&rnd=1447374921976" frameborder="0" scrolling="no" allowtransparency="true">摘要：本文來自《程序員》電子刊1511A期封面報道，介紹傳統企業IT應用架構基于OpenStack云化的實踐，文章從云平臺選型、核心應用模式、數據存儲及管理、資源調度以及敏捷開發實踐等多角度全方位詮釋。

【編者按】本文來自《程序員》電子刊1511A期封面報道，介紹傳統企業IT應用架構基于OpenStack云化的實踐，文章從云平臺選型、核心應用模式、數據存儲及管理、資源調度以及敏捷開發實踐等多角度全方位詮釋。

傳統企業IT應用架構升級走入“深水區”

圖1 ?企業IT架構的驅動力

如圖1所示，隨著云計算、大數據等新興IT技術對傳統IT應用架構的沖擊越來越明顯，傳統企業對IT信息化的態度由被動轉變為主動，IT應用架構的升級與建設正逐漸“常態化”。這種沖擊主要體現在2個方面：

IT規劃建設碰到問題逐漸復雜與深入，現有的煙囪式多套應用系統并立局面與現代IT治理、業務流程優化出現不匹配的矛盾。比如眾多IT系統如何整合？現有系統問題較多，是替換還是升級？企業的戰略到管理、到IT信息化都存在斷層，如何重構業務匹配鏈條？

數據的價值正日益明顯，企業需要數據如何為企業的經營決策所服務，數據如何打破各個系統的分散組織，做到數據集中與管理。比如每個業務系統中不同的信息如何集中抽取？數據分散、數據質量、數據安全等眾多問題導致難以為企業決策所服務，甚至帶來錯誤的決策？

在傳統的零售行業的大企業，正面臨著如此的業務O2O轉型及全面的業務運營的難題。以筆者經歷過的國內某大型零售集團企業的實踐為例，集團旗下有龐大的線下電器零售商。隨著公司業務的戰略轉型，它依托線上線下平臺優勢，推行O2O模式。目前其電商門戶已是國內流量排名前5的電商平臺。

配合集團的業務戰略轉型過程中，O2O目標要求從IT戰略、IT治理及應用系統架構都依賴云計算模式的整體支撐。特別是線上業務的快速發展，電商平臺底層基礎需要大量穩定可靠的云主機、虛擬網絡、云硬盤、對象存儲，以及支撐云商城的數據庫、數據分析、應用中心、金融服務，還為CRM、ERP、SRM、PDM等生產系統提供IT能力。經過大量的評估后，公司選定OpenStack作為底層的基礎架構云平臺支撐集團業務。

2014年開始，該公司開始組建研發團隊并實踐OpenStack云平臺。在近1年半的時間，公司已經形成了核心業務的積累，打通了研發測試、金融、電商核心交易等業務的所有環節技術通道，擁有多個區域的OpenStack生產集群，最大的集群規模在300+物理節點，運行了數千KVM和容器。

企業IT應用架構之基礎云平臺選型

圖2 ?企業云計算產品周期

從應用的垂直技術棧來看，云計算的產品周期也需要經歷需求分析、技術選型、產品開發、項目實施上線、業務運營、運維及優化等步驟，如圖2所示。其 中，對云平臺的技術選型是面臨的一個大難題。

CloudStack的產品及市場影響力正逐漸消退，其創始公司Ctrix也加入OpenStack基金會之后，容器技術又撲面而來。技術總是在推陳出新，在開源和社區兩驅動力推動下，“亂花漸欲迷人眼”，然而面對企業問題的我們，還是要冷靜地分析企業到底面對什么問題，需要解決什么問題，需要用什么工具來解決這些問題。“羅馬不是一天建成的”，云平臺也不能從零開始，好的技術選型，可以事半而功倍。

對于任何一個云平臺來說，下面功能都是應當具有的：

• 云主機
• 云存儲

企業存儲、數據分析也是需要考慮的重大問題。在設計規劃云平臺時，對此予以考慮，則云平臺將可滿足 未來相當一段時間的需要，這種考慮既包括技術選型、時間節點，也包括與上述云平臺基本功能的聯通性、物理規劃、硬件采購等。

不容忽視的還有容器。這并不是為了追趕潮流，而是因為容器技術確實帶來巨大的便利性。事實上，幾乎大部分的輕型應用都可以移植到容器里來， 這樣既節省物理資源，又易于實現DevOps等。

圖3 ?企業云平臺邏輯功能

綜上，如圖3所示，相對完整的足以支撐我們絕大多數 企業應用的企業云平臺未來架構，既要包括已經成熟的IaaS功能（未必對外提供服務，但若沒有IaaS，其他 何以談起？）和PaaS功能，我們更應該提前考慮好分布式存儲（也許可以跨數據中心，用于非關鍵數據的同步），和基于Hadoop、Spark、Storm以及數據分析的分析即服務。

圖4 ?技術選型的考量

如圖4所示，技術選型的考量，Kubernetes、Mesos都能滿足我們的許多需求，業界也有許多實踐。但是我們還需要注意到兩點：

具有管理物理（裸機）需求，適用于某些工作負載 （如已經部署于物理機，且因服務原因不可遷移等）；

對外提供服務，由于容器與宿主機共享內核，而存在安全隱患。

于是，OpenStack成為首要選擇。另外OpenStack由于已經得到廣泛應用，互聯網上資料眾多，其部署和維護也不存在太大技術難題。

OpenStack包括如下組件和項目，足以滿足我們的需要：

• 以Nova、Neutron、Glance、Cinder等為主體的組件足以提供IaaS所需的功能；
• Trove提供各種數據庫即服務；
• Sahara提供分析即服務；
• Swift提供分布式對象存儲；
• Heat、Murano、Magnum提供應用編排。

企業IT應用架構之核心應用模式

圖5 ?企業應用的基本模式

絕大多數企業應用，基本呈現出一些固定的模式來，如圖5所示，包括：

• 負載均衡器（可選，包括軟件或硬件的方案）；
• Web服務器（可選，通常包括Tomcat、Apache或傳統企業級產品）；
• 應用服務器（通常包括Tomcat、Jboss或其他企業及應用服務器，或者輕量級的開源容器等）；
• 數據緩存（可選，通常包括Redis、MemCache等）；
• 數據庫（可選，通常包括MySQL、DB2、Oracle等， 也可以包括存儲于HBase的數據服務等）。

應用的功能可以容易更換、新增，然而應用的架構通 常保持長期的穩定性，企業應用需要選擇成熟的、而且適合公司/開發團隊的技術和工具；再考慮到線上大 量的應用和快速迭代，應用構件的演進是一個長期的過程。

圖6 ?企業應用的縱橫向關聯

這里我們的目的，是將這類模式“復制”到云平臺，然而，在基本模式之外，應用模型其實很復雜，下面從四個維度來分析，如圖6所示。

■ 第一個維度，從縱向角度，不同層之間需要關聯，包括：

• 動態發現
• 實時注冊
• 事務分發

■ 第二個維度，從橫向角度，同一層內部實例之間也包含如下關聯：

• 服務集群之間的管理關系；
• 同一宿主機上服務的管理關系；
• 服務自身的配置管理關系等。

■ 第三個維度，則與云平臺本身特性密切相關：

• 服務的自擴展（或縮容）；
• 調度規則；
• 自動化部署、配置與升級。

■ 第四個維度，企業IT管理需求：

• 企業ITIL流程系統；
• 監控、審計、安全；
• 研發團隊、版本、環境的管理對應關系等。

企業IT應用架構之數據存儲及管理

除了Web層之外，應用層和數據存儲層都呈現復雜的特點，這里以數據存儲層為例。

眾所周知，數據庫在企業應用中一般以單實例或集群為主。以MySQL集群為例，主要為一主多從形態。少數企業已經在嘗試多活的方案，例如，OpenStack三節點的控制集群本身，最主要的數據庫模式就是基于MySQL、Galera和HAProxy的多活方案。

考慮一個復雜的MySQL互聯網應用，由于預計會有千萬級到億級數量的用戶，在數據庫設計時候，使 用了分庫分表，那么不同用戶進來，根據手機號或其他ID，用戶信息根據Hash算法會訪問到后端不同數據庫。

圖7 ?基于MySQL的數據持久化層

如圖7所示，這里用到另外兩個開源組件：

• MyCAT：封裝了Partition，對應用透明，根據用戶ID 信息，將數據訪問請求Route到不同后端數據庫去，也 提供一定的對查詢結果的聚合功能；
• ZK，也就是Zookeeper，提供分布式協調服務，需要訪問到MySQL和MyCAT。

在這里，本身又包括幾個集群，一起協同工作：

MySQL主從集群；

多個MySQL主從集群組成的集群，提供數據存儲 后端；

MyCat集群；

ZK集群。

圖8 ?基于Redis的數據緩存層

另外一個重要組件是數據緩存，如圖8所示，數據緩存通常以Redis來實現。Redis也呈現上述MySQL服務類似的特點。

對于上述無論是數據持久層服務，還是非持久層，從云化角度，都需要完善如下功能：

• 服務的自擴展/自縮容；
• 集群服務的自動注冊，無論是擴容還是縮容；
• 調度規則；
• 自動部署、配置、升級；
• 監控、安全、審計；
• 以應用無感知的形式，在主/從節點失效（服務實例失效、虛擬機/容器失效、宿主機失效、交換機/電源失效）的服務自動切換。

最后的服務自動切換又至少包括：

• 服務實例的故障自動感知與實時自動切換；
• 服務IP的自動漂移，在復雜情況下，至少還包括讀、寫IP等；
• 整個集群管理關系的穩定；
• 應用的無感知（實際上應該略有感知，但數據無影響，服務略有遲滯）；
• 硬件更換、維護對于應用無感知；
• 服務遷移對應用的無感知。

其中，應用無感知的處理是難中之難。當單個服務失效，一般好處理，萬一是多個服務失效呢？

企業IT應用架構之應用資源的調度

圖9 ?企業應用服務的調度

如圖9所示，調度通常應包括以下層次：

• Region;
• 可用域；
• 集群（OpenStack主機集合）；
• 其他約束條件，如CPU、內存、磁盤、硬件類型等。

然而，事情往往比想象的復雜，如：

• 有限的物理資源，并不足以保證我們能將應用盡可能分布開；
• 實際環境還包括物理機上運行的應用、容器和虛擬機；
• 用戶在創建完初始環境之后，還要擴容（調度多次）等；
• ……

因此，調度并不能按理想行事，許多時候需要折中和遷就，調度邏輯需要將各種復雜的現實情況考慮在內，對每種情況進行演繹，才能得到較為理想的結果 （現實世界中，完美并不存在）。

企業IT應用架構之敏捷的產品開發

“老生常談”的產品開發的痛

如何破，讓老板和工程師都認可？老板希望實現產品開發價值的最大化，縮短開發時間，提高開發效率，但擔心形而上學；工程師需要的是簡單有效，而不是忽悠，繞圈的折磨人，做無用功。

如何立，讓老板和工程師都歡迎？解決現有的開發難點，不是推倒現有模式重頭開始。老板歡迎引入好的方法論，并帶來商業利益；工程師歡迎自動化辦法， 合理使用工具，而不是通過工具來玩人。

OpenStack項目帶來的CI/CD的啟示

對零售電商來說，產品的持續創新及發布流程是平臺的競爭力。特別在移動端的應用，從移動應用的設計、快速上線、產品運營到可視化管理，需要有自動化測試、敏捷開發、持續集成（CI）和持續交付 （CD）等手段進行高效率支撐。其中，產品開發設計和集成上線等重要環節，對開發團隊的開發效率及軟件的功能迭代都有較高要求。基于這些考慮，底層的OpenStack平臺做了大量的實踐優化。

■ 移動應用開發設計：

• ? VM/容器，按需提供
• ? 集成開發環境（定制鏡像包/軟件包）
• ? 內嵌應用開發市場

■ 移動應用集成測試：

• ? 持續集成（CI），快速迭代
• ? 協同測試環境
• ? 類生產環境，灰度發布
• ? APP客戶端測試環境

從實踐來看，敏捷開發的優勢是顯而易見的。以某互聯網消費金融產品為例，通過敏捷開發實踐彌補項目開發周期過長、需求變更復雜的弊端，產品需求的反饋周期能從6個月左右縮短至半個月；產品變更的需求，能從1個月縮短至1周。這些都是真實的開發能力提升。

僅僅有一些方法和工具是不夠的，真正對產品開發帶來價值，是如何完成產品的敏捷創新、降低風險、并根據市場反饋及時適配產品。但實際情況往往并不如想象中的美好。因為傳統的產品開發模式中，企業需 要協調大量的內部資源，牽涉到跨部門的業務邏輯、數據共享服務，往往會有多個部門要配合產品開發進行協作和業務審計。這些對小步迭代、自組織的敏捷開發來講，是真實的風險所在。

所以我們從OpenStack的CI/CD框架方法入手，借鑒了CI和CD等方法，來應用到自身的業務系統中。通過CI在開發階段，對項目進行持續性自動化編譯、測試，達到控制代碼質量的手段，持續提升開發效率；同時利用CD可以保證在短周期內生產有價值的產品，并且保證能夠可靠地在任何時間發布。

當然OpenStack CI/CD框架并不是萬靈丹，因為企業應用、Web應用、大數據分析等各類項目，從需求分析到項目管理、代碼質量、測試部署、開發環境和生產環境等，差異很大。唯一不變的就是軟件工程持續敏捷的思路，真正解決問題的思路！只有踏踏實實去實踐敏捷開發的思路，才可能開啟產品開發的破冰之旅。

項目團隊引入敏捷開發的步驟

■?組織架構的變革

首先要說服老板來做這個敏捷決定，最合適的辦法就是讓老板認清風險，提前做好應對風險的預案，并證明敏捷帶來的業務價值。

接下來，發揮領導者所起的導向作用，讓團隊參與其中，以敏捷和Scrum為基礎，探索具體的工作模式。

■?團隊人員分工優化

傳統的人員需盡快從組織職能上轉入敏捷，要明確各種成員的角色，比如一些中層IT主管適合平臺經理、交付經理；傳統的供應鏈、采購、人力、法務、財務等職能成員，需要以獨立的輔助部門引入；對于一線員工中資深的骨干，可以考慮以架構師、領域專家角色參與。

■?流程重定義與風險評估

從企業的敏捷實踐來看，必然會有一部分成員有利益犧牲，也會存在一部分成員的阻力，所謂的陣痛是必須的。所以配合敏捷開發，需要對業務流程需要進行重新梳理。

• 立項階段：與現有的研發需求流程進行連接，將關鍵的執行者進行確定；
• 架構階段：在團隊組建完畢后，將項目架構進行合理優化，與業務規劃保持一致；
• 發布計劃：團隊配置成型后，形成項目與產品的整體規劃；
• 產品開發：在業務和IT構建階段開始就實現緊密交互，每個迭代可產生交付件；
• 配置與交付：獲取產品配置的反饋；并形成最小化單次部署的環境。

■?管理優化及團隊的協作

在傳統的管理方式中，計劃與決定由項目經理制定，需求與分析由架構師制定，團隊所做的只能做實現。改為敏捷模式后，重心由流程向人轉移。計劃由團隊制定，決定由團隊制定。這樣發揮團隊主動與協同性。

OpenStack CI/CD任務分解及經驗

■?OpenStack CI/CD流程設計

OpenStack社區開發和CI/CD進行了緊密的集成，其中核心組件包括：Jenkins配置管理、Github代碼管理及Launchpad項目管理等。

圖10 ?OpenStack社區Zuul流程

以OpenStack Zuul項目為例，如圖10所示，簡要的CI/ CD步驟如下：

• 開發者提交code，通過Git提交后，首先到Gerrit上進行review，目的是通過協作，發現一些明顯問題，避免把bug帶到測試中；
• code發送到Jenkins后觸發build任務。同時Zuul作為調度器，基于接收的事件觸發測試和報告，作為項目的源代碼存儲庫，這樣保證code只有通過測試才能合并；
• Zuul開始推送自動化的測試任務。方式是Jenkins自動觸發集成測試（Tempest），并反方向地反饋到Gerrit；
• 等Zuul響應測試成功消息后，Gerrit會自動Merge合并代碼，再同步到Gitlab庫；
• 最后Zuul推送Jenkins的部署任務，進行自動化部署。

■?OpenStack CI/CD核心工具

在OpenStack CI/CD框架中，使用到的核心工具包括：

CI核心工具，以Jenkins為中心的自動化測試、集成和發布的平臺，實現持續集成。團隊開發成員可以經常集成他們的工作，而每次的集成都是通過自動化的構建來驗證，包括自動編譯、發布和測試，從而盡快地發現集成錯誤。

CD核心工具，以Gitlab作為項目管理和權限管理的持續交付平臺，實現一個自托管的Git項目倉庫。同時配合Gerrit，它是一款開源的代碼審查軟件，適用提交前review。一個團隊內的參與者，可以相互審閱各自修改后的代碼，決定是否能夠提交，退回或者繼續修改。

■?企業IT應用以OpenStack CI/CD開發模式的導入

借鑒OpenStack開發經驗，自有業務系統的敏捷開發流程設計：

• 項目開發準備All in One開發環境，業務系統保證源碼安裝，開發者鏈接Git版本庫的開發目錄；
• 開發者利用Gitlab本地提交，并上傳到Gerrit觸發 code review，然后發送給Jenkins構建任務；
• 正常的產品發布，在合并主干代碼，自動生成RPM，生成軟件鏡像分發；然后自動化安裝部署，交由測試人員進行相關測試；
• 在產品bug fix流程中，首先實現bug在all in one環境重現，開發人員完成bugfix，打包RPM，并提交bug驗證環境進行確認；待在bugfix確認后，進入正常Git流程。

導入敏捷開發的移動應用的實踐

我們在OpenStack平臺上構建了一個PaaS模塊產品一站式發布的Web Portal，包含有：企業應用模板、數據庫服務、大數據分析服務、業務編排服務等OpenStack各類功能；這樣，開發人員無需關注找服務器、部署環境（各種軟件包、MySQL、Nginx等）等步驟，只需要寫好工具本身的邏輯代碼，加載到PaaS容器就可以。

在代碼提交后，基于敏捷CI的系列流程管控。首先，OpenStack平臺上Master資源節點通過細粒度資源分配，將可用資源報告給上層Jenkins中心，Jenkins選擇某個Slave資源節點執行，完成一次資源分配。這樣可實現分組的代碼打包、編譯、分發的任務。其中，以Jenkins為核心的產品的周期管理，以及觸發軟件包自動構建；Gitlab和Gerrit協作完成代碼及軟件倉庫管理；由于移動應用本身對資源的任務調度依賴較弱，接下來可充分發揮任務編排的能力，從應用打包（build）、部署邏輯、部署數據、部署實施到部署驗證，完成一系列的產品集成部署。

目前我們從產品的配置管理、軟件包管理到任務編排都做了諸多到嘗試，效果比較滿意。后續將在流程管理部分上繼續實踐，比如線上服務變更、軟件發布周期等，爭取達到高效的持續部署。

作者簡介

張小斌，思源科技集團云服務中心副總經理，擁有近20年的計算機軟件設計、開發和管理經驗，在硅谷和國內多家企業擔任過工程師、技術經理、研發經理和研發總監職位，負責電信網管系統、企業解決方案、郵件安全、移動安全、移動互聯網搜索引擎、云計算等的研發管理工作。著有《OpenStack企業云平臺架構與實踐》。

肖何，云計算/大數據思科資深架構師，擅長虛擬化技術/分布式系統/容器技術/SDN/云數據中心/OpenStack云平臺/Hadoop大數據平臺/企業數據分析及商業智能等方案咨詢和設計，以及結合IT/OT創新的等行業解決方案。

謝超，云途騰科技有限責任公司T2Cloud云平臺高級研發工程師，從事過多年Linux內核的開發，DPDK用戶態防火墻及安全審計產品的研發工作，目前從事T2Cloud云平臺產品的研發，領導公司參與社區的貢獻和技術跟蹤，主要技術方向是網絡虛擬化項目Neutron。

總結

以上是生活随笔為你收集整理的OpenStack架构企业IT应用的敏捷实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。