引言

　　经过了二十多年的粗放式快速发展，中国的制鞋业经历了高速发展阶段，当前以出口为主的制鞋产业，面对国际市场的萎缩，又加上来自主要市场国的反倾销等贸易保护措施下行压力较大，制鞋行业进入调整期。
　　目前鞋服类企业主要面临的挑战是：
　　1、 新的销售渠道崛起：随着年轻一代成长为消费主力，线上销售渠道受到追捧，而传统百货渠道的客流量近年来则面临衰减，部分鞋类品牌*对终端渠道进行调整，频频关店。
　　2、消费者需求的转变：伴随着消费观念的变化，消费者的品牌忠诚度出现下降，逐渐把注意力放在设计感和性价比上，而不像以往一味追求品牌。同时部分中国鞋业品牌对市场发展趋势的反应滞后，对市场趋势的认识不足，多家企业均出现了利润大幅度下滑的现象。
　　3、生产模式的变化：国际品牌多已逐渐走向做小量化、个性化、定制化的订单模式，然而多数中国鞋业品牌依然执着于大批量、同质化产品的生产模式。在无法适应生产模式的表象下，它所真正体现的是鞋类品牌公司对终端市场情况判断不准确，对市场发展趋势预期不足，导致库存层层积压，最终影响后续的产品更新及公司运作，使得品牌缺乏市场竞争力。
　　从销售渠道的转变，到终端消费者的需求改变，乃至生产模式的变化，都需要新型的、敏捷的商业模式和生产方式来应对，决定了背后做支撑的传统IT架构不再适用，必须转变成为一种弹性的、灵活的IT基础架构。于是，上云就成为了鞋服类企业迫在眉睫的需求和必然选择。

客户现状

　　B集团是一家规模较大的鞋业公司，年销售额超过400亿元人民币，在国内的鞋服类企业中属于当之无愧的领军人物。目前客户的业务分布在深圳和北京等地，其主要的业务系统示意图如图一。主要分为四个体系：

• 企业规划决策体系：围绕企业战略管控和企业级数据决策打造的经营计划与全国预算平台、企业绩效管理平台、大数据应用平台和BI平台等。
• 供应链协同体系：以供应链为主体，以市场和渠道进行协同，同时对外提供电商、移动社交和零售门店等全渠道营销体系。
• 工厂体系：包括本厂和外厂的核心生产系统，如生产计划与库存控制系统和生产执行系统等。
• 共享支撑体系：对于以上业务的支撑系统，如人力资源、协同办公、财务管理、呼叫中心等系统。
  

图一

　　业务系统之间的调用关系可以参考图二。业务系统，如供应链、市场和门店系统等，围绕零售交易和零售货品这两个核心系统进行数据的交互，确保业务的协同进行和数据的一致同步。

图二

客户上云诉求

　　通过对客户深度调研与沟通，我们归纳出客户对于新的IT架构主要的诉求为以下几点：

• 降低成本：能够降低客户一次性在机房、网络、服务器等硬件上的成本投入，同时优化成本结构，降低维护人员的数量。
• 提高系统弹性：为了应对618、双11等大促的大流量、高并发的场景，需要从服务器、存储到数据库都具备灵活的弹性，以面对各种业务突发的需求。
• 增强系统可用性：原有的深圳机房环境较差，服务器陈旧，经常面临断网断电的情况，导致无法正常提供服务，严重影响业务的开展。新的IT架构应该具备高可用性，不仅可以解决单机房面临的风险，还必须从系统架构上进行提升，具备跨机房的容灾备份能力，提高风险抵御能力。

云上优化方案及价值

服务器虚拟化优化方案

　　客户在现有的服务器系统中使用了大量的虚拟机，主要应用在北京新零售、上海体总、会员、零售货品部和零售交易部等多个部门。现在流量的特点是内存占有率较高，但是CPU占用率比较低，一般在10-20%上下，原有的虚拟化系统也采用了CPU超分的技术，超分的比例为1:8。
　　针对客户的虚拟化系统，阿里云推荐了DDH的云上虚拟化方案，并且针对客户的实际配置，对比了线下IDC和DDH的TCO。

　　虽然云上虚拟化部分的TCO相对线下有一定程度的增加，但是有效的提高了资源利用率，总体上节省了成本（见后续分析），还给客户带来更多提升：

• 下降99%的宕机率
• 灵活的虚拟化管理，有效提升系统支撑能力
• 弹性的计算资源，适应敏捷的业务模式
• 自动宕机迁移能力，避免业务中断带来的损失
• 更高的数据安全能力

数据库优化方案

　　目前客户在部分对外的业务中使用了MySQL数据库。在日常的使用过程中，往往面临性能和可用性的瓶颈，会导致业务受到影响。综合客户的反馈来看，其数据库主要的优化点如下：

• 没有独立备库，读库压力大，复制延迟时，主库宕机数据丢失风险大
• 很多实例采用SAS磁盘，IO性能较弱，一旦有非预期的慢查询容易导致实例hang死
• 数据库部署在一个机房，机房故障会导致数据不可用
• 较多实例服务器资源利用率仅有5%-10%，计算和存储资源浪费
  针对以上客户的痛点，使用阿里云的RDS数据库，可以解决以上问题：
• RDS主实例自带备库，不提供服务，专为高可用，保证了低复制延迟
• 全面升级为SSD本地磁盘RDS实例，IO性能提升一个数量级
• RDS均为多可用区高可用部署，单机房故障无忧
• 根据业务维度和资源利用率进行整合，提升利用率同时，RDS均为独占资源部署，留出了充分的性能裕度
  结合运动城的实际使用情况，对比了TCO：

　　对比来看，云上RDS相对客户自建数据库，总体TCO下降38%，并且还可以带来的提升有：

• 跨可用区容灾备份
• 自带备库，可用性高
• 全SSD提高性能
• 专业的数据库管理方案

中间件优化方案

　　客户目前的中间件主要是部署在线下的服务器上，日常使用过程中，也时常面临着扩展能力低、灵活性不强的问题。综合对比了云上Redis托管配合其他自建，以及客户完全在云上自建，两种方案的成本等因素，我们推荐了前者。主要对比的方案优劣如下：

　　综合来看，采用云上Redis托管配合其他中间件自建的方案，总体TCO下降了7%，与此同时，还可以带来的提升有：

• 缓存类采用高性能托管，其他中间件平迁ECS
• CPU高主频实例集约化
• 高可用中间件架构

大数据系统优化方案

　　客户现有的大数据系统是利用开源系统自己构建的数据分析系统，日常面临着性能不足的问题。阿里云设计了三条路径，路径一是基于ECS大数据机型的迁移方案，即客户自建方案；路径二是基于EMR的开源Hadoop全兼容迁移方案，即客户半托管方案；路径三是基于阿里云自研产品的迁移方案，即客户全托管方案。从迁移复杂度、运维投入和集群扩展能力等多个维度来看，最终推荐了路径二。

　　云上与云下的数据库TCO大致相同，但是可以给用户带来的提升有：

• 计算存储分离：灵活的扩容，缩容；计算资源可以通过弹性伸缩优化计算成本；EMR可以使用动态的task节点，按需快速的临时增减节点
• 存储分层：支持低成本的OSS，降低存储成本和运维复杂度（无需提前预规划数据增长）
• 工作流的调度：除兼容oozie之外，EMR还提供了自演工作流调度EMR-flow，对于大客户，可以完成无缝迁移，以及更高效的工作流调度和管理。
• 集群的监控能力：支持集群、主机、服务和作业多层面维度的监控报警。
• 数据安全：支持ranger和MIT Kerberos，支持细粒度权限控制。

总TCO对比分析

　　综合服务器虚拟化、数据库、中间件和大数据系统等子系统来看，总体TCO下降8.5%。

　　与此同时，如上文所述，虚拟化系统在灵活性和可用性、数据库系统在性能和可用性、大数据系统在性能和运维能力上，都得到了不同程度的提升。如果加上考虑扩容成本、数据异地灾备风险成本、一次性投入资金成本，实际给客户带来的TCO优化幅度更大。

迁移

迁移路径

　　迁移之前，需要根据应用类型决定迁移策略和优先级。例如可以分为可以轻松迁移的应用，例如开发／测试应用、Web应用（电商、官网、公众号）、视频直播／点播、在线培训和知识管理等，以及需要详细设计迁移方案的应用，例如非Linux/Windows操作系统的应用、CS架构的应用、垂直扩展的大型应用和有强依赖的复杂应用等。
结合客户的现状与迁移的迫切程度，按照前台、中台和后台的迁移顺序，可以大致分为三个迁移阶段：
　　阶段一：前台业务迁移

• 北京新零售/商城：提高弹性和业务连续性
• CRM、订货会、卡券等：提高业务连续性和架构可扩展性
• 呼叫中心：提高业务连续性
  阶段二：中台业务迁移
• 大数据系统：提高弹性和可运维性
• 供应链管理：提高可扩展性和业务连续性
  阶段三：后台业务迁移
• 企业管控：保证稳定性、安全
• 生产系统：保证安全性、提高稳定性
• 人力资源、协同办公、财务管理、信息管理、研发管理：保证安全性

迁移示例

　　以北京新零售业务系统作为迁移的示例。原系统包括了应用层后端服务、数据服务层和业务数据库层，其流量模型是逐层进行访问的。系统架构图如图三：

图三 北京新零售系统架构图

　　结合之前的产品建议和优化方案，每一层的部署建议和优化方案如下

• 应用接入层：ECS+DDH部署，兼顾成本与扩展性
• 负载均衡层：SLB部署，节省网络成本，同时提升网络接入质量
• API层：ECS+DDH部署，兼顾成本与扩展性
• 数据库层：采用RDS+云Redis部署，容灾架构提升业务连续性，完善的数据备份体系，持续降低成本
• 文件存储层：OSS冷热数据分离，配合CDN提供高质量访问能力
• 网络层：高速专线配合云企业网接入IDC，解决迁移过程中间态网络访问
  最终，迁移后的北京新零售在云上的业务架构图如图四：

图四 北京新零售业务云上架构图

上阿里云给客户带来的价值

通过对于迁云前后的各项子系统的成本、性能等诸方面对比，可以看到对于用户迁移的价值有：

• TCO成本的降低
• 性能上的提升
• 可用性得到极大的提升，包括单机房的高可用性和跨可用区的灾备能力
• 数据安全性的提升
• 运维和自动化能力的提升
• 未来更加便捷和快速的业务扩展能力

本案例中客户上云涉及的产品

场景	涉及产品
应用接入层	ECS+DDH部署
负载均衡层	SLB部署
API层	ECS+DDH部署
数据库层	采用RDS+云Redis部署
文件存储层	OSS冷热数据分离
大数据系统	EMR部署