传统到云端的挑战
传统经典架构：
在从传统IT架构最终向云计算平台技术架构转移的过程中，主要面临以下几个技术挑战。
可用性：脱离小型机和高端存储的高冗余机制，采用基于PC服务器的分布式架构的云计算平台能否做到高可用。
一致性：Oracle基于RAC和共享存储实现的物理级别一致性，云上ORACLE能否达到同样的效果。
高性能：高端存储的I/O能力很强，基于PC服务器的数据库能否提供同样甚至更高的I/O处理能力，RDS和OLTP数据库（如Oracle）对SQL的处理性能是否相同。
扩展性：业务逻辑如何拆分，如何服务化，数据分多少库分多少表，什么维度分，后期二次拆分如何更方便等。
基于阿里云计算平台，通过采用合适的技术策略和最佳实践，包括：应用无状态，有效使用缓存（浏览器缓存、反向代理缓存、页面缓存、局部页面缓存、对象缓存和读写分离），服务原子化，数据库分割，异步解决性能问题，最小化事物单元，适当放弃一致性。以及自动化监控/运维手段包括监控预警、配置统一管理，基础服务器监控，URL监控，网络监控，模块间调用监控，智能分析监控，综合故障管理平台，容量管理。可以很好地解决以上问题，从而达到整体系统的高可扩展性、更低的成本、更高的性能和可用性的实现效果。
云上的技术解决方案
传统与云上对应关系：
应用服务(Weblogic、Apache、Tomcat、Websphere)：
对于应用服务服务器，传统架构上倾向于依赖单台或多台PC服务器的架构方式，云上可通过SLB（负载均衡）+多台云主机（ECS）组合替代传统的应用部署模式，通过SLB将多台云服务器（ECS）资源虚拟成一个高性能、高可用的应用服务池，根据应用指定的方式，将来自客户端的服务请求分发到云服务器池中，可随时根据系统运行的压力情况，通过灵活的添加或是缩减ECS机器资源，进行快速的业务能力扩展或缩容。
负载均衡设备（F5、LVS、Proxy、Redware）：
建议采用应用层负载均衡(SLB)替代，负载均衡（Server Load Balancer，简称SLB）是对多台云服务器进行流量分发的负载均衡服务，SLB服务通过设置虚拟服务地址（IP），将位于同一Region的多台云服务器（Elastic Compute Service，简称ECS）资源虚拟成一个高性能、高可用的应用服务池。
SLB服务支持4层或7层协议，SLB服务会检查云服务器池中ECS的健康状态，自动隔离异常状态的ECS，能提高应用高可用、高性能的整体服务能力。
云上的系统部署，考虑到后续可扩展性和高可用，尽量使用SLB加多台ECS的部署模式，类似下面。
文件存储（OSS）：
对于文件存储方式，云上可以直接用OSS来取代存储，NAS等实现海量数据文件的存储，OSS存储最大容量可以达40PB，同时由于OSS是分布式存储方式，无单点，可以通过多个节点的并行读写显著提高数据访问性能。对于大文件，还可以通过Multipart Upload的方式，将大文件分块并行传输与存储，实现高性能。
对于OLAP应用，可采用ODPS/ADS等解决方案取代传统的小型机方案，如下图。
整体来看，不管是传统架构还是云平台，都有自身的优缺点，应用系统架构要因地适宜的去匹配这两种基础平台，做到平台和应用之间的最佳结合。下图是云平台的架构方案，我们针对具体业务系统做迁云方案，根据实际情况进行分析和合理选择。
系统迁云策略和流程
迁云原则
业务系统是否适合迁移至云平台，首先需要根据业务特性、特点、定位等方面进行初步评估，对业务系统进行详细梳理，具体梳理内容可参照下表所示。
业务系统评估表
系统是否存在严重故障隐患；
同时在线用户比例；
系统资源利用率；
是否支持系统优化/改造；
是否支持平滑迁移上云
同时，向云平台迁移的业务系统还应具有如下特点：
- 应用系统对硬件无特殊依赖性。
- 应用服务器可通过增加节点的方式提高处理能力。
- 应用系统与数据存储能有效分离，模块化设计，且模块之间通信实时性要求不高。
除此以外，还需要考虑业务系统迁移至云平台可以获得的收益和可能的风险。改用云计算技术的部署方式，是否可以满足工程建设需要、是否可以实现业务平台整合和资源共享等预期收益。最后还要从技术方面、初始建设成本、运维管理等方面评估迁移至云平台的风险，且要充分考虑回退方案。
迁云策略
现有业务系统向云平台迁移方案比较复杂，需要考虑的因素比较多。尽量避免或减少对业务带来影响，保护原有设备的投资，减少投资浪费等。
系统迁移上云需要根据系统类型和重要性选择合适的迁移方式，而对于复杂系统的迁移上云，需要根据实际情况采用定制化的迁移技术及方法。具体的迁移策略：
迁移到云平台：将业务系统迁移到IaaS，部署到云平台虚拟化资源（例如虚拟服务器、虚拟存储、虚拟网络）至上，并采用统一运营管理平台进行管理；
选择最佳的应用程序迁移上云方式，不是单纯的迁移问题，而是一个真正的优化问题，不能孤立地作出决定。任何迁移上云的决策本质上是应用程序或基础设施走向现代化的决定，需要在相关的应用程序组合管理和基础设施组合管理的大背景下进行处理。
迁云评估流程
在梳理上述内容后，各业务系统可参考下图所示的流程进行迁移上云的评估 
迁移的典型流程如上图：
（1）系统是否会长期使用：该系统是否还将继续长期使用，如是否还会继续使用超过一年。
（2）系统是否存在故障隐患：该系统是否存在验证的故障隐患，如数据安全、架构缺陷等。
（3）设备利用率是否在60%与80%之间：该系统是否能够有效的利用基础设施硬件资源，如CPU利用率、存储利用率过低或过高。
（4）同时在线用户比例是否大于等于50%：该系统用户的平均使用率(平均使用率指总体而言，同时在线的用户占全部预期用户的比例)大于等于50%。
（5）系统是否随着压力增长而扩展：该系统是否能够进行平滑扩展以满足预期内或预期外的业务需求。
（6）系统是否能够移植：该系统是否能够消除隐患以进行移植，并满足业务使用需求。
（7）系统是否支持快速移植：该系是否能够进行快速移植。
（8）系统是否近期停用：该系统是否由于技术原因或业务的原因在近期将被停用。
（9）是否有能力进行系统迁移及测试：系统维护团队是否有足够的能力对系统进行测试及迁移。
（10）是否能够进行虚拟化：该系统平台是否有合适的技术支持虚拟化。
（11）是否有业务驱动力进行系统迁移：该系统是否有足够的业务驱动力移植到云平台。
（12）是否有业务驱动力进行虚拟化：该系统是否有足够的业务驱动力对基础设施（服务器或存储）进行虚拟化。
（13）是否有业务驱动力进行平台转换：该系统是否有足够的业务驱动力转换至云平台。
系统迁云路线
应用系统迁移上云因其实际需求和应用特征的不同，有不同的迁移上云技术路径，不同的路径对应不同的迁移上云解决方案，下图列出了应用系统总体的迁移上云路径，供参考。
直接迁移上云
对于应用系统是否可直接迁移上云主要看数据库是否将数据库改造成RDS for MySQL或RDS For SQL Server，是沿用原有的数据库还是采用云上oracle，主要从以下几个方面判断：
系统的复杂度。应用对数据库特征强依赖，以及应用层对数据库的强耦合会导致改造数据库的难度和风险增加。如果改造数据库的难度和风险达到不可控范围，则可以考虑直接迁移上云；
迁移周期要求。应用系统改造数据库会带来更长的迁移周期，若对应用系统迁移上云迁移的周期有严格的要求，则可以选择直接迁移上云；
性能要求。相对而言，采用直接迁移上云的方式对数据库的性能会有所限制，同时数据库的性能扩展空间有限，所以选择直接迁移上云方式的应用必须考虑在规划的系统运行周期内性能上无较大规模的扩展要求。
高可用要求。采用直接迁移上云方式是在ECS上部署Oracle数据库，数据库的高可用由用户来保障；若采用阿里云产品，则数据库的高可用可有阿里云保障。所以，直接迁移上云后数据库的高可用级别是否能够达到实际应用的运行要求也是判断应用是否直接迁移上云的重要方面。
低性能要求
应用系统对数据库的IOPS性能在500~1000范围内，Latency>10ms,认为是低性能要求的。在迁移上云方案上采用在ECS（存储采用云磁盘）上直接部署Oracle或其他数据库，具体迁移上云方法：
1) 应用层基于ECS部署运行环境，应用程序直接迁移，同时修改应用程序的数据库连接；
2) 数据层基于ECS部署Oracle或其他数据库，数据存储采用ECS提供的云磁盘。数据库的迁移直接通过RMAN实现快速迁移。
高性能要求
应用系统对数据库的IOPS性能在[1000,15000]范围内, Latency<10ms，认为是高性能要求的，在迁移上云方案上考虑采用ECS（采用SSD存储）上直接部署Oracle或其他数据库构建数据库服务，具体迁移上云方法：
1) 应用层基于ECS部署运行环境，应用程序直接迁移，同时修改应用程序的数据库连接；
2) 数据层基于SSD ECS部署数据库，数据存储采用ECS提供的SSD磁盘。数据库的迁移直接通过备份工具（RMAN）实现快速迁移。
如果考虑到高可用的要求，可以配置一个相同的ECS实例为数据库的备机，主备之间通过数据复制技术（如：Oracle Data Guard）做数据同步，当主机宕机后，备机可以接管服务，切换时间通常在分钟级别。
