图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主从集群组成的集群，提供数据存储 后端;