OpenStack架構(gòu)企業(yè)IT應(yīng)用的敏捷實(shí)踐

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

OpenStack云平臺敏捷架構(gòu)應(yīng)用 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期封面報(bào)道，介紹傳統(tǒng)企業(yè)IT應(yīng)用架構(gòu)基于OpenStack云化的實(shí)踐，文章從云平臺選型、核心應(yīng)用模式、數(shù)據(jù)存儲及管理、資源調(diào)度以及敏捷開發(fā)實(shí)踐等多角度全方位詮釋。

【編者按】本文來自《程序員》電子刊1511A期封面報(bào)道，介紹傳統(tǒng)企業(yè)IT應(yīng)用架構(gòu)基于OpenStack云化的實(shí)踐，文章從云平臺選型、核心應(yīng)用模式、數(shù)據(jù)存儲及管理、資源調(diào)度以及敏捷開發(fā)實(shí)踐等多角度全方位詮釋。

傳統(tǒng)企業(yè)IT應(yīng)用架構(gòu)升級走入“深水區(qū)”

圖1 ?企業(yè)IT架構(gòu)的驅(qū)動力

如圖1所示，隨著云計(jì)算、大數(shù)據(jù)等新興IT技術(shù)對傳統(tǒng)IT應(yīng)用架構(gòu)的沖擊越來越明顯，傳統(tǒng)企業(yè)對IT信息化的態(tài)度由被動轉(zhuǎn)變?yōu)橹鲃?#xff0c;IT應(yīng)用架構(gòu)的升級與建設(shè)正逐漸“常態(tài)化”。這種沖擊主要體現(xiàn)在2個(gè)方面：

IT規(guī)劃建設(shè)碰到問題逐漸復(fù)雜與深入，現(xiàn)有的煙囪式多套應(yīng)用系統(tǒng)并立局面與現(xiàn)代IT治理、業(yè)務(wù)流程優(yōu)化出現(xiàn)不匹配的矛盾。比如眾多IT系統(tǒng)如何整合？現(xiàn)有系統(tǒng)問題較多，是替換還是升級？企業(yè)的戰(zhàn)略到管理、到IT信息化都存在斷層，如何重構(gòu)業(yè)務(wù)匹配鏈條？

數(shù)據(jù)的價(jià)值正日益明顯，企業(yè)需要數(shù)據(jù)如何為企業(yè)的經(jīng)營決策所服務(wù)，數(shù)據(jù)如何打破各個(gè)系統(tǒng)的分散組織，做到數(shù)據(jù)集中與管理。比如每個(gè)業(yè)務(wù)系統(tǒng)中不同的信息如何集中抽取？數(shù)據(jù)分散、數(shù)據(jù)質(zhì)量、數(shù)據(jù)安全等眾多問題導(dǎo)致難以為企業(yè)決策所服務(wù)，甚至帶來錯(cuò)誤的決策？

在傳統(tǒng)的零售行業(yè)的大企業(yè)，正面臨著如此的業(yè)務(wù)O2O轉(zhuǎn)型及全面的業(yè)務(wù)運(yùn)營的難題。以筆者經(jīng)歷過的國內(nèi)某大型零售集團(tuán)企業(yè)的實(shí)踐為例，集團(tuán)旗下有龐大的線下電器零售商。隨著公司業(yè)務(wù)的戰(zhàn)略轉(zhuǎn)型，它依托線上線下平臺優(yōu)勢，推行O2O模式。目前其電商門戶已是國內(nèi)流量排名前5的電商平臺。

配合集團(tuán)的業(yè)務(wù)戰(zhàn)略轉(zhuǎn)型過程中，O2O目標(biāo)要求從IT戰(zhàn)略、IT治理及應(yīng)用系統(tǒng)架構(gòu)都依賴云計(jì)算模式的整體支撐。特別是線上業(yè)務(wù)的快速發(fā)展，電商平臺底層基礎(chǔ)需要大量穩(wěn)定可靠的云主機(jī)、虛擬網(wǎng)絡(luò)、云硬盤、對象存儲，以及支撐云商城的數(shù)據(jù)庫、數(shù)據(jù)分析、應(yīng)用中心、金融服務(wù)，還為CRM、ERP、SRM、PDM等生產(chǎn)系統(tǒng)提供IT能力。經(jīng)過大量的評估后，公司選定OpenStack作為底層的基礎(chǔ)架構(gòu)云平臺支撐集團(tuán)業(yè)務(wù)。

2014年開始，該公司開始組建研發(fā)團(tuán)隊(duì)并實(shí)踐OpenStack云平臺。在近1年半的時(shí)間，公司已經(jīng)形成了核心業(yè)務(wù)的積累，打通了研發(fā)測試、金融、電商核心交易等業(yè)務(wù)的所有環(huán)節(jié)技術(shù)通道，擁有多個(gè)區(qū)域的OpenStack生產(chǎn)集群，最大的集群規(guī)模在300+物理節(jié)點(diǎn)，運(yùn)行了數(shù)千KVM和容器。

企業(yè)IT應(yīng)用架構(gòu)之基礎(chǔ)云平臺選型

圖2 ?企業(yè)云計(jì)算產(chǎn)品周期

從應(yīng)用的垂直技術(shù)棧來看，云計(jì)算的產(chǎn)品周期也需要經(jīng)歷需求分析、技術(shù)選型、產(chǎn)品開發(fā)、項(xiàng)目實(shí)施上線、業(yè)務(wù)運(yùn)營、運(yùn)維及優(yōu)化等步驟，如圖2所示。其 中，對云平臺的技術(shù)選型是面臨的一個(gè)大難題。

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

對于任何一個(gè)云平臺來說，下面功能都是應(yīng)當(dāng)具有的：

• 云主機(jī)
• 云存儲

企業(yè)存儲、數(shù)據(jù)分析也是需要考慮的重大問題。在設(shè)計(jì)規(guī)劃云平臺時(shí)，對此予以考慮，則云平臺將可滿足 未來相當(dāng)一段時(shí)間的需要，這種考慮既包括技術(shù)選型、時(shí)間節(jié)點(diǎn)，也包括與上述云平臺基本功能的聯(lián)通性、物理規(guī)劃、硬件采購等。

不容忽視的還有容器。這并不是為了追趕潮流，而是因?yàn)槿萜骷夹g(shù)確實(shí)帶來巨大的便利性。事實(shí)上，幾乎大部分的輕型應(yīng)用都可以移植到容器里來， 這樣既節(jié)省物理資源，又易于實(shí)現(xiàn)DevOps等。

圖3 ?企業(yè)云平臺邏輯功能

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

圖4 ?技術(shù)選型的考量

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

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

對外提供服務(wù)，由于容器與宿主機(jī)共享內(nèi)核，而存在安全隱患。

于是，OpenStack成為首要選擇。另外OpenStack由于已經(jīng)得到廣泛應(yīng)用，互聯(lián)網(wǎng)上資料眾多，其部署和維護(hù)也不存在太大技術(shù)難題。

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

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

企業(yè)IT應(yīng)用架構(gòu)之核心應(yīng)用模式

圖5 ?企業(yè)應(yīng)用的基本模式

絕大多數(shù)企業(yè)應(yīng)用，基本呈現(xiàn)出一些固定的模式來，如圖5所示，包括：

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

應(yīng)用的功能可以容易更換、新增，然而應(yīng)用的架構(gòu)通 常保持長期的穩(wěn)定性，企業(yè)應(yīng)用需要選擇成熟的、而且適合公司/開發(fā)團(tuán)隊(duì)的技術(shù)和工具；再考慮到線上大 量的應(yīng)用和快速迭代，應(yīng)用構(gòu)件的演進(jìn)是一個(gè)長期的過程。

圖6 ?企業(yè)應(yīng)用的縱橫向關(guān)聯(lián)

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

■ 第一個(gè)維度，從縱向角度，不同層之間需要關(guān)聯(lián)，包括：

• 動態(tài)發(fā)現(xiàn)
• 實(shí)時(shí)注冊
• 事務(wù)分發(fā)

■ 第二個(gè)維度，從橫向角度，同一層內(nèi)部實(shí)例之間也包含如下關(guān)聯(lián)：

• 服務(wù)集群之間的管理關(guān)系；
• 同一宿主機(jī)上服務(wù)的管理關(guān)系；
• 服務(wù)自身的配置管理關(guān)系等。

■ 第三個(gè)維度，則與云平臺本身特性密切相關(guān)：

• 服務(wù)的自擴(kuò)展（或縮容）；
• 調(diào)度規(guī)則；
• 自動化部署、配置與升級。

■ 第四個(gè)維度，企業(yè)IT管理需求：

• 企業(yè)ITIL流程系統(tǒng)；
• 監(jiān)控、審計(jì)、安全；
• 研發(fā)團(tuán)隊(duì)、版本、環(huán)境的管理對應(yīng)關(guān)系等。

企業(yè)IT應(yīng)用架構(gòu)之?dāng)?shù)據(jù)存儲及管理

除了Web層之外，應(yīng)用層和數(shù)據(jù)存儲層都呈現(xiàn)復(fù)雜的特點(diǎn)，這里以數(shù)據(jù)存儲層為例。

眾所周知，數(shù)據(jù)庫在企業(yè)應(yīng)用中一般以單實(shí)例或集群為主。以MySQL集群為例，主要為一主多從形態(tài)。少數(shù)企業(yè)已經(jīng)在嘗試多活的方案，例如，OpenStack三節(jié)點(diǎn)的控制集群本身，最主要的數(shù)據(jù)庫模式就是基于MySQL、Galera和HAProxy的多活方案。

考慮一個(gè)復(fù)雜的MySQL互聯(lián)網(wǎng)應(yīng)用，由于預(yù)計(jì)會有千萬級到億級數(shù)量的用戶，在數(shù)據(jù)庫設(shè)計(jì)時(shí)候，使 用了分庫分表，那么不同用戶進(jìn)來，根據(jù)手機(jī)號或其他ID，用戶信息根據(jù)Hash算法會訪問到后端不同數(shù)據(jù)庫。

圖7 ?基于MySQL的數(shù)據(jù)持久化層

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

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

在這里，本身又包括幾個(gè)集群，一起協(xié)同工作：

MySQL主從集群；

多個(gè)MySQL主從集群組成的集群，提供數(shù)據(jù)存儲 后端；

MyCat集群；

ZK集群。

圖8 ?基于Redis的數(shù)據(jù)緩存層

另外一個(gè)重要組件是數(shù)據(jù)緩存，如圖8所示，數(shù)據(jù)緩存通常以Redis來實(shí)現(xiàn)。Redis也呈現(xiàn)上述MySQL服務(wù)類似的特點(diǎn)。

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

• 服務(wù)的自擴(kuò)展/自縮容；
• 集群服務(wù)的自動注冊，無論是擴(kuò)容還是縮容；
• 調(diào)度規(guī)則；
• 自動部署、配置、升級；
• 監(jiān)控、安全、審計(jì)；
• 以應(yīng)用無感知的形式，在主/從節(jié)點(diǎn)失效（服務(wù)實(shí)例失效、虛擬機(jī)/容器失效、宿主機(jī)失效、交換機(jī)/電源失效）的服務(wù)自動切換。

最后的服務(wù)自動切換又至少包括：

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

其中，應(yīng)用無感知的處理是難中之難。當(dāng)單個(gè)服務(wù)失效，一般好處理，萬一是多個(gè)服務(wù)失效呢？

企業(yè)IT應(yīng)用架構(gòu)之應(yīng)用資源的調(diào)度

圖9 ?企業(yè)應(yīng)用服務(wù)的調(diào)度

如圖9所示，調(diào)度通常應(yīng)包括以下層次：

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

然而，事情往往比想象的復(fù)雜，如：

• 有限的物理資源，并不足以保證我們能將應(yīng)用盡可能分布開；
• 實(shí)際環(huán)境還包括物理機(jī)上運(yùn)行的應(yīng)用、容器和虛擬機(jī)；
• 用戶在創(chuàng)建完初始環(huán)境之后，還要擴(kuò)容（調(diào)度多次）等；
• ……

因此，調(diào)度并不能按理想行事，許多時(shí)候需要折中和遷就，調(diào)度邏輯需要將各種復(fù)雜的現(xiàn)實(shí)情況考慮在內(nèi)，對每種情況進(jìn)行演繹，才能得到較為理想的結(jié)果 （現(xiàn)實(shí)世界中，完美并不存在）。

企業(yè)IT應(yīng)用架構(gòu)之敏捷的產(chǎn)品開發(fā)

“老生常談”的產(chǎn)品開發(fā)的痛

如何破，讓老板和工程師都認(rèn)可？老板希望實(shí)現(xiàn)產(chǎn)品開發(fā)價(jià)值的最大化，縮短開發(fā)時(shí)間，提高開發(fā)效率，但擔(dān)心形而上學(xué)；工程師需要的是簡單有效，而不是忽悠，繞圈的折磨人，做無用功。

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

OpenStack項(xiàng)目帶來的CI/CD的啟示

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

■ 移動應(yīng)用開發(fā)設(shè)計(jì)：

• ? VM/容器，按需提供
• ? 集成開發(fā)環(huán)境（定制鏡像包/軟件包）
• ? 內(nèi)嵌應(yīng)用開發(fā)市場

■ 移動應(yīng)用集成測試：

• ? 持續(xù)集成（CI），快速迭代
• ? 協(xié)同測試環(huán)境
• ? 類生產(chǎn)環(huán)境，灰度發(fā)布
• ? APP客戶端測試環(huán)境

從實(shí)踐來看，敏捷開發(fā)的優(yōu)勢是顯而易見的。以某互聯(lián)網(wǎng)消費(fèi)金融產(chǎn)品為例，通過敏捷開發(fā)實(shí)踐彌補(bǔ)項(xiàng)目開發(fā)周期過長、需求變更復(fù)雜的弊端，產(chǎn)品需求的反饋周期能從6個(gè)月左右縮短至半個(gè)月；產(chǎn)品變更的需求，能從1個(gè)月縮短至1周。這些都是真實(shí)的開發(fā)能力提升。

僅僅有一些方法和工具是不夠的，真正對產(chǎn)品開發(fā)帶來價(jià)值，是如何完成產(chǎn)品的敏捷創(chuàng)新、降低風(fēng)險(xiǎn)、并根據(jù)市場反饋及時(shí)適配產(chǎn)品。但實(shí)際情況往往并不如想象中的美好。因?yàn)閭鹘y(tǒng)的產(chǎn)品開發(fā)模式中，企業(yè)需 要協(xié)調(diào)大量的內(nèi)部資源，牽涉到跨部門的業(yè)務(wù)邏輯、數(shù)據(jù)共享服務(wù)，往往會有多個(gè)部門要配合產(chǎn)品開發(fā)進(jìn)行協(xié)作和業(yè)務(wù)審計(jì)。這些對小步迭代、自組織的敏捷開發(fā)來講，是真實(shí)的風(fēng)險(xiǎn)所在。

所以我們從OpenStack的CI/CD框架方法入手，借鑒了CI和CD等方法，來應(yīng)用到自身的業(yè)務(wù)系統(tǒng)中。通過CI在開發(fā)階段，對項(xiàng)目進(jìn)行持續(xù)性自動化編譯、測試，達(dá)到控制代碼質(zhì)量的手段，持續(xù)提升開發(fā)效率；同時(shí)利用CD可以保證在短周期內(nèi)生產(chǎn)有價(jià)值的產(chǎn)品，并且保證能夠可靠地在任何時(shí)間發(fā)布。

當(dāng)然OpenStack CI/CD框架并不是萬靈丹，因?yàn)槠髽I(yè)應(yīng)用、Web應(yīng)用、大數(shù)據(jù)分析等各類項(xiàng)目，從需求分析到項(xiàng)目管理、代碼質(zhì)量、測試部署、開發(fā)環(huán)境和生產(chǎn)環(huán)境等，差異很大。唯一不變的就是軟件工程持續(xù)敏捷的思路，真正解決問題的思路！只有踏踏實(shí)實(shí)去實(shí)踐敏捷開發(fā)的思路，才可能開啟產(chǎn)品開發(fā)的破冰之旅。

項(xiàng)目團(tuán)隊(duì)引入敏捷開發(fā)的步驟

■?組織架構(gòu)的變革

首先要說服老板來做這個(gè)敏捷決定，最合適的辦法就是讓老板認(rèn)清風(fēng)險(xiǎn)，提前做好應(yīng)對風(fēng)險(xiǎn)的預(yù)案，并證明敏捷帶來的業(yè)務(wù)價(jià)值。

接下來，發(fā)揮領(lǐng)導(dǎo)者所起的導(dǎo)向作用，讓團(tuán)隊(duì)參與其中，以敏捷和Scrum為基礎(chǔ)，探索具體的工作模式。

■?團(tuán)隊(duì)人員分工優(yōu)化

傳統(tǒng)的人員需盡快從組織職能上轉(zhuǎn)入敏捷，要明確各種成員的角色，比如一些中層IT主管適合平臺經(jīng)理、交付經(jīng)理；傳統(tǒng)的供應(yīng)鏈、采購、人力、法務(wù)、財(cái)務(wù)等職能成員，需要以獨(dú)立的輔助部門引入；對于一線員工中資深的骨干，可以考慮以架構(gòu)師、領(lǐng)域?qū)＜医巧珔⑴c。

■?流程重定義與風(fēng)險(xiǎn)評估

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

• 立項(xiàng)階段：與現(xiàn)有的研發(fā)需求流程進(jìn)行連接，將關(guān)鍵的執(zhí)行者進(jìn)行確定；
• 架構(gòu)階段：在團(tuán)隊(duì)組建完畢后，將項(xiàng)目架構(gòu)進(jìn)行合理優(yōu)化，與業(yè)務(wù)規(guī)劃保持一致；
• 發(fā)布計(jì)劃：團(tuán)隊(duì)配置成型后，形成項(xiàng)目與產(chǎn)品的整體規(guī)劃；
• 產(chǎn)品開發(fā)：在業(yè)務(wù)和IT構(gòu)建階段開始就實(shí)現(xiàn)緊密交互，每個(gè)迭代可產(chǎn)生交付件；
• 配置與交付：獲取產(chǎn)品配置的反饋；并形成最小化單次部署的環(huán)境。

■?管理優(yōu)化及團(tuán)隊(duì)的協(xié)作

在傳統(tǒng)的管理方式中，計(jì)劃與決定由項(xiàng)目經(jīng)理制定，需求與分析由架構(gòu)師制定，團(tuán)隊(duì)所做的只能做實(shí)現(xiàn)。改為敏捷模式后，重心由流程向人轉(zhuǎn)移。計(jì)劃由團(tuán)隊(duì)制定，決定由團(tuán)隊(duì)制定。這樣發(fā)揮團(tuán)隊(duì)主動與協(xié)同性。

OpenStack CI/CD任務(wù)分解及經(jīng)驗(yàn)

■?OpenStack CI/CD流程設(shè)計(jì)

OpenStack社區(qū)開發(fā)和CI/CD進(jìn)行了緊密的集成，其中核心組件包括：Jenkins配置管理、Github代碼管理及Launchpad項(xiàng)目管理等。

圖10 ?OpenStack社區(qū)Zuul流程

以O(shè)penStack Zuul項(xiàng)目為例，如圖10所示，簡要的CI/ CD步驟如下：

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

■?OpenStack CI/CD核心工具

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

CI核心工具，以Jenkins為中心的自動化測試、集成和發(fā)布的平臺，實(shí)現(xiàn)持續(xù)集成。團(tuán)隊(duì)開發(fā)成員可以經(jīng)常集成他們的工作，而每次的集成都是通過自動化的構(gòu)建來驗(yàn)證，包括自動編譯、發(fā)布和測試，從而盡快地發(fā)現(xiàn)集成錯(cuò)誤。

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

■?企業(yè)IT應(yīng)用以O(shè)penStack CI/CD開發(fā)模式的導(dǎo)入

借鑒OpenStack開發(fā)經(jīng)驗(yàn)，自有業(yè)務(wù)系統(tǒng)的敏捷開發(fā)流程設(shè)計(jì)：

• 項(xiàng)目開發(fā)準(zhǔn)備All in One開發(fā)環(huán)境，業(yè)務(wù)系統(tǒng)保證源碼安裝，開發(fā)者鏈接Git版本庫的開發(fā)目錄；
• 開發(fā)者利用Gitlab本地提交，并上傳到Gerrit觸發(fā) code review，然后發(fā)送給Jenkins構(gòu)建任務(wù)；
• 正常的產(chǎn)品發(fā)布，在合并主干代碼，自動生成RPM，生成軟件鏡像分發(fā)；然后自動化安裝部署，交由測試人員進(jìn)行相關(guān)測試；
• 在產(chǎn)品bug fix流程中，首先實(shí)現(xiàn)bug在all in one環(huán)境重現(xiàn)，開發(fā)人員完成bugfix，打包RPM，并提交bug驗(yàn)證環(huán)境進(jìn)行確認(rèn)；待在bugfix確認(rèn)后，進(jìn)入正常Git流程。

導(dǎo)入敏捷開發(fā)的移動應(yīng)用的實(shí)踐

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

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

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

作者簡介

張小斌，思源科技集團(tuán)云服務(wù)中心副總經(jīng)理，擁有近20年的計(jì)算機(jī)軟件設(shè)計(jì)、開發(fā)和管理經(jīng)驗(yàn)，在硅谷和國內(nèi)多家企業(yè)擔(dān)任過工程師、技術(shù)經(jīng)理、研發(fā)經(jīng)理和研發(fā)總監(jiān)職位，負(fù)責(zé)電信網(wǎng)管系統(tǒng)、企業(yè)解決方案、郵件安全、移動安全、移動互聯(lián)網(wǎng)搜索引擎、云計(jì)算等的研發(fā)管理工作。著有《OpenStack企業(yè)云平臺架構(gòu)與實(shí)踐》。

肖何，云計(jì)算/大數(shù)據(jù)思科資深架構(gòu)師，擅長虛擬化技術(shù)/分布式系統(tǒng)/容器技術(shù)/SDN/云數(shù)據(jù)中心/OpenStack云平臺/Hadoop大數(shù)據(jù)平臺/企業(yè)數(shù)據(jù)分析及商業(yè)智能等方案咨詢和設(shè)計(jì)，以及結(jié)合IT/OT創(chuàng)新的等行業(yè)解決方案。

謝超，云途騰科技有限責(zé)任公司T2Cloud云平臺高級研發(fā)工程師，從事過多年Linux內(nèi)核的開發(fā)，DPDK用戶態(tài)防火墻及安全審計(jì)產(chǎn)品的研發(fā)工作，目前從事T2Cloud云平臺產(chǎn)品的研發(fā)，領(lǐng)導(dǎo)公司參與社區(qū)的貢獻(xiàn)和技術(shù)跟蹤，主要技術(shù)方向是網(wǎng)絡(luò)虛擬化項(xiàng)目Neutron。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。