【编者按】本文来自《程序员》电子刊1511A期封面报道，介绍传统企业IT应用架构基于OpenStack云化的实践，文章从云平台选型、核心应用模式、数据存储及管理、资源调度以及敏捷开发实践等多角度全方位诠释。

传统企业IT应用架构升级走入“深水区”

图1  企业IT架构的驱动力

如图1所示，随着云计算、大数据等新兴IT技术对传统IT应用架构的冲击越来越明显，传统企业对IT信息化的态度由被动转变为主动，IT应用架构的升级与建设正逐渐“常态化”。这种冲击主要体现在2个方面：

1. IT规划建设碰到问题逐渐复杂与深入，现有的烟囱式多套应用系统并立局面与现代IT治理、业务流程优化出现不匹配的矛盾。比如众多IT系统如何整合？现有系统问题较多，是替换还是升级？企业的战略到管理、到IT信息化都存在断层，如何重构业务匹配链条？
2. 数据的价值正日益明显，企业需要数据如何为企业的经营决策所服务，数据如何打破各个系统的分散组织，做到数据集中与管理。比如每个业务系统中不同的信息如何集中抽取？数据分散、数据质量、数据安全等众多问题导致难以为企业决策所服务，甚至带来错误的决策？

在传统的零售行业的大企业，正面临着如此的业务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都能满足我们的许多需求，业界也有许多实践。但是我们还需要注意到两点：

1. 具有管理物理（裸机）需求，适用于某些工作负载 （如已经部署于物理机，且因服务原因不可迁移等）；
2. 对外提供服务，由于容器与宿主机共享内核，而存在安全隐患。

于是，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。

在这里，本身又包括几个集群，一起协同工作：

1. MySQL主从集群；
2. 多个MySQL主从集群组成的集群，提供数据存储 后端；
3. MyCat集群；
4. 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。

（责编/周建丁 zhoujd at csdn dot net）

本文为《程序员》电子刊1511A期原创文章，未经允许不得转载，如需转载请联系market#csdn.net(#换成@)