OpenStack架构企业IT应用的敏捷实践

  • 来源:《程序员》电子刊
  •  2015-11-15
  •   浏览 671 次

【编者按】本文来自《程序员》电子刊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。

To Top