【編者按】本文來自《程序員》電子刊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。
京公網安備 11010502049343號