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周。这些都是真实的开发能力提升。
仅仅有一些方法和工具是不够的，真正对产品开发带来价值，是如何完成产品的敏捷创新、降低风险、并根据市场反馈及时适配产品。但实际情况往往并不如想象中的美好。因为传统的产品开发模式中，企业需 要协调大量的内部资源，牵涉到跨部门的业务逻辑、数据共享服务，往往会有多个部门要配合产品开发进行协作和业务审计。这些对小步迭代、自组织的敏捷开发来讲，是真实的风险所在。