【编者按】本文来自《程序员》电子刊1511A期封面报道，介绍传统企业IT应用架构基于OpenStack云化的实践，文章从云平台选型、核心应用模式、数据存储及管理、资源调度以及敏捷开发实践等多角度全方位诠释。 图1 企业IT架构的驱动力 如图1所示，随着云计算、大数据等新兴IT技术对传统IT应用架构的冲击越来越明显，传统企业对IT信息化的态度由被动转变为主动，IT应用架构的升级与建设正逐渐“常态化”。这种冲击主要体现在2个方面：传统企业IT应用架构升级走入“深水区”
在传统的零售行业的大企业，正面临着如此的业务O2O转型及全面的业务运营的难题。以笔者经历过的国内某大型零售集团企业的实践为例，集团旗下有庞大的线下电器零售商。随着公司业务的战略转型，它依托线上线下平台优势，推行O2O模式。目前其电商门户已是国内流量排名前5的电商平台。
配合集团的业务战略转型过程中，O2O目标要求从IT战略、IT治理及应用系统架构都依赖云计算模式的整体支撑。特别是线上业务的快速发展，电商平台底层基础需要大量稳定可靠的云主机、虚拟网络、云硬盘、对象存储，以及支撑云商城的数据库、数据分析、应用中心、金融服务，还为CRM、ERP、SRM、PDM等生产系统提供IT能力。经过大量的评估后，公司选定OpenStack作为底层的基础架构云平台支撑集团业务。
2014年开始，该公司开始组建研发团队并实践OpenStack云平台。在近1年半的时间，公司已经形成了核心业务的积累，打通了研发测试、金融、电商核心交易等业务的所有环节技术通道，拥有多个区域的OpenStack生产集群，最大的集群规模在300+物理节点，运行了数千KVM和容器。
图2 企业云计算产品周期
从应用的垂直技术栈来看，云计算的产品周期也需要经历需求分析、技术选型、产品开发、项目实施上线、业务运营、运维及优化等步骤，如图2所示。其 中，对云平台的技术选型是面临的一个大难题。
CloudStack的产品及市场影响力正逐渐消退，其创始公司Ctrix也加入OpenStack基金会之后，容器技术又扑面而来。技术总是在推陈出新，在开源和社区两驱动力推动下，“乱花渐欲迷人眼”，然而面对企业问题的我们，还是要冷静地分析企业到底面对什么问题，需要解决什么问题，需要用什么工具来解决这些问题。“罗马不是一天建成的”，云平台也不能从零开始，好的技术选型，可以事半而功倍。
对于任何一个云平台来说，下面功能都是应当具有的：
企业存储、数据分析也是需要考虑的重大问题。在设计规划云平台时，对此予以考虑，则云平台将可满足 未来相当一段时间的需要，这种考虑既包括技术选型、时间节点，也包括与上述云平台基本功能的联通性、物理规划、硬件采购等。
不容忽视的还有容器。这并不是为了追赶潮流，而是因为容器技术确实带来巨大的便利性。事实上，几乎大部分的轻型应用都可以移植到容器里来， 这样既节省物理资源，又易于实现DevOps等。
图3 企业云平台逻辑功能
综上，如图3所示，相对完整的足以支撑我们绝大多数 企业应用的企业云平台未来架构，既要包括已经成熟的IaaS功能（未必对外提供服务，但若没有IaaS，其他 何以谈起？）和PaaS功能，我们更应该提前考虑好分布式存储（也许可以跨数据中心，用于非关键数据的同步），和基于Hadoop、Spark、Storm以及数据分析的分析即服务。
图4 技术选型的考量
如图4所示，技术选型的考量，Kubernetes、Mesos都能满足我们的许多需求，业界也有许多实践。但是我们还需要注意到两点：
于是，OpenStack成为首要选择。另外OpenStack由于已经得到广泛应用，互联网上资料众多，其部署和维护也不存在太大技术难题。
OpenStack包括如下组件和项目，足以满足我们的需要：
图5 企业应用的基本模式
绝大多数企业应用，基本呈现出一些固定的模式来，如图5所示，包括：
应用的功能可以容易更换、新增，然而应用的架构通 常保持长期的稳定性，企业应用需要选择成熟的、而且适合公司/开发团队的技术和工具；再考虑到线上大 量的应用和快速迭代，应用构件的演进是一个长期的过程。
图6 企业应用的纵横向关联
这里我们的目的，是将这类模式“复制”到云平台，然而，在基本模式之外，应用模型其实很复杂，下面从四个维度来分析，如图6所示。
■ 第一个维度，从纵向角度，不同层之间需要关联，包括：
■ 第二个维度，从横向角度，同一层内部实例之间也包含如下关联：
■ 第三个维度，则与云平台本身特性密切相关：
■ 第四个维度，企业IT管理需求：
除了Web层之外，应用层和数据存储层都呈现复杂的特点，这里以数据存储层为例。
众所周知，数据库在企业应用中一般以单实例或集群为主。以MySQL集群为例，主要为一主多从形态。少数企业已经在尝试多活的方案，例如，OpenStack三节点的控制集群本身，最主要的数据库模式就是基于MySQL、Galera和HAProxy的多活方案。
考虑一个复杂的MySQL互联网应用，由于预计会有千万级到亿级数量的用户，在数据库设计时候，使 用了分库分表，那么不同用户进来，根据手机号或其他ID，用户信息根据Hash算法会访问到后端不同数据库。
图7 基于MySQL的数据持久化层
如图7所示，这里用到另外两个开源组件：
在这里，本身又包括几个集群，一起协同工作：
图8 基于Redis的数据缓存层
另外一个重要组件是数据缓存，如图8所示，数据缓存通常以Redis来实现。Redis也呈现上述MySQL服务类似的特点。
对于上述无论是数据持久层服务，还是非持久层，从云化角度，都需要完善如下功能：
最后的服务自动切换又至少包括：
其中，应用无感知的处理是难中之难。当单个服务失效，一般好处理，万一是多个服务失效呢？
图9 企业应用服务的调度
如图9所示，调度通常应包括以下层次：
然而，事情往往比想象的复杂，如：
因此，调度并不能按理想行事，许多时候需要折中和迁就，调度逻辑需要将各种复杂的现实情况考虑在内，对每种情况进行演绎，才能得到较为理想的结果 （现实世界中，完美并不存在）。
如何破，让老板和工程师都认可？老板希望实现产品开发价值的最大化，缩短开发时间，提高开发效率，但担心形而上学；工程师需要的是简单有效，而不是忽悠，绕圈的折磨人，做无用功。
如何立，让老板和工程师都欢迎？解决现有的开发难点，不是推倒现有模式重头开始。老板欢迎引入好的方法论，并带来商业利益；工程师欢迎自动化办法， 合理使用工具，而不是通过工具来玩人。
对零售电商来说，产品的持续创新及发布流程是平台的竞争力。特别在移动端的应用，从移动应用的设计、快速上线、产品运营到可视化管理，需要有自动化测试、敏捷开发、持续集成（CI）和持续交付 （CD）等手段进行高效率支撑。其中，产品开发设计和集成上线等重要环节，对开发团队的开发效率及软件的功能迭代都有较高要求。基于这些考虑，底层的OpenStack平台做了大量的实践优化。
■ 移动应用开发设计：
■ 移动应用集成测试：
从实践来看，敏捷开发的优势是显而易见的。以某互联网消费金融产品为例，通过敏捷开发实践弥补项目开发周期过长、需求变更复杂的弊端，产品需求的反馈周期能从6个月左右缩短至半个月；产品变更的需求，能从1个月缩短至1周。这些都是真实的开发能力提升。
仅仅有一些方法和工具是不够的，真正对产品开发带来价值，是如何完成产品的敏捷创新、降低风险、并根据市场反馈及时适配产品。但实际情况往往并不如想象中的美好。因为传统的产品开发模式中，企业需 要协调大量的内部资源，牵涉到跨部门的业务逻辑、数据共享服务，往往会有多个部门要配合产品开发进行协作和业务审计。这些对小步迭代、自组织的敏捷开发来讲，是真实的风险所在。
所以我们从OpenStack的CI/CD框架方法入手，借鉴了CI和CD等方法，来应用到自身的业务系统中。通过CI在开发阶段，对项目进行持续性自动化编译、测试，达到控制代码质量的手段，持续提升开发效率；同时利用CD可以保证在短周期内生产有价值的产品，并且保证能够可靠地在任何时间发布。
当然OpenStack CI/CD框架并不是万灵丹，因为企业应用、Web应用、大数据分析等各类项目，从需求分析到项目管理、代码质量、测试部署、开发环境和生产环境等，差异很大。唯一不变的就是软件工程持续敏捷的思路，真正解决问题的思路！只有踏踏实实去实践敏捷开发的思路，才可能开启产品开发的破冰之旅。
■ 组织架构的变革
首先要说服老板来做这个敏捷决定，最合适的办法就是让老板认清风险，提前做好应对风险的预案，并证明敏捷带来的业务价值。
接下来，发挥领导者所起的导向作用，让团队参与其中，以敏捷和Scrum为基础，探索具体的工作模式。
■ 团队人员分工优化
传统的人员需尽快从组织职能上转入敏捷，要明确各种成员的角色，比如一些中层IT主管适合平台经理、交付经理；传统的供应链、采购、人力、法务、财务等职能成员，需要以独立的辅助部门引入；对于一线员工中资深的骨干，可以考虑以架构师、领域专家角色参与。
■ 流程重定义与风险评估
从企业的敏捷实践来看，必然会有一部分成员有利益牺牲，也会存在一部分成员的阻力，所谓的阵痛是必须的。所以配合敏捷开发，需要对业务流程需要进行重新梳理。
■ 管理优化及团队的协作
在传统的管理方式中，计划与决定由项目经理制定，需求与分析由架构师制定，团队所做的只能做实现。改为敏捷模式后，重心由流程向人转移。计划由团队制定，决定由团队制定。这样发挥团队主动与协同性。
■ OpenStack CI/CD流程设计
OpenStack社区开发和CI/CD进行了紧密的集成，其中核心组件包括：Jenkins配置管理、Github代码管理及Launchpad项目管理等。
图10 OpenStack社区Zuul流程
以OpenStack Zuul项目为例，如图10所示，简要的CI/ CD步骤如下：
■ OpenStack CI/CD核心工具
在OpenStack CI/CD框架中，使用到的核心工具包括：
CI核心工具，以Jenkins为中心的自动化测试、集成和发布的平台，实现持续集成。团队开发成员可以经常集成他们的工作，而每次的集成都是通过自动化的构建来验证，包括自动编译、发布和测试，从而尽快地发现集成错误。
CD核心工具，以Gitlab作为项目管理和权限管理的持续交付平台，实现一个自托管的Git项目仓库。同时配合Gerrit，它是一款开源的代码审查软件，适用提交前review。一个团队内的参与者，可以相互审阅各自修改后的代码，决定是否能够提交，退回或者继续修改。
■ 企业IT应用以OpenStack CI/CD开发模式的导入
借鉴OpenStack开发经验，自有业务系统的敏捷开发流程设计：
我们在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(#换成@)
本网页所有文字内容由 imapbox邮箱云存储,邮箱网盘, iurlBox网页地址收藏管理器 下载并得到。
ImapBox 邮箱网盘 工具地址: https://www.imapbox.com/download/ImapBox.5.5.1_Build20141205_CHS_Bit32.exe
PC6下载站地址：PC6下载站分流下载
本网页所有视频内容由 imoviebox边看边下-网页视频下载, iurlBox网页地址收藏管理器 下载并得到。
ImovieBox 网页视频 工具地址: https://www.imapbox.com/download/ImovieBox4.7.0_Build20141115_CHS.exe
本文章由: imapbox邮箱云存储,邮箱网盘,ImageBox 图片批量下载器,网页图片批量下载专家,网页图片批量下载器,获取到文章图片,imoviebox网页视频批量下载器,下载视频内容,为您提供.
阅读和此文章类似的: 全球云计算
官方软件产品操作指南 (170)
