1. 前言
随着云计算的不断普及，很多传统行业也都在转型，笔者在传统银行和互联网电商都经历过从传统IDC迁移到公有云或者私有云的过程，如果没有深入了解过云计算的架构师来说，可能觉得传统IDC的迁移上云只不过是将应用系统和中间件、数据库部署到云虚拟资源上就可以了，这其实没那么简单，按照笔者和同行做过迁移公有云操作的员工交流也基本得出一致的结果，那就是如果只是将云资源作为原来的基础IDC来使用，那么整体的使用效果不会太好，因为如果应用在不做任何改造的前提下，只能将应用和相关中间件数据库简单部署在虚拟资源上，但是公有云的虚拟资源在很多方面是没办法和我们私有的IDC来比拟的，从网络速度、系统隔离、数据安全、负载均衡、硬件加密等很多方面都会存在问题，原先在私有IDC可能都不存在的问题，在公有云环境都会是很大的问题，都需要有很好的解决方案。为了能利用好云服务商的云资源，一定要充分利用好云服务商提供的其他配套的PaaS、DaaS产品，才能在帮助我们节约硬件成本、运维成本的同时，提高我们的整体开发、测试和Devops的效率。
下面就抛砖引玉的介绍下传统IDC上云的经验和过渡期的不同级别系统的架构方案。
2. 上云的经验之谈
对于系统上云这里也总结了一些经验，有些是自己总结的，有些是和朋友交流了解到的一些经验。
2.1上云顺序
上云采取循序渐进和系统重要性的原则分批上云。
1）开发测试环境优先上公有云；
2）边缘非交易系统上云；
3）选取一个关键业务交易系统上云试点；
4）大面积推广业务系统上云；
5）搭建私有云，将公有云和私有云组成混合云。
2.2应对监管
监管对金融机构的监管要求较明确，保证客户4要素信息不上云，为了应对监管采取的措施是监管定期检查的系统采取分区部署和域名隔离，将一个系统中小部分应用节点还是部署在公司内数据中心，大部分应用服务器节点还是部署在公有云，采用不同域名在DNS分流，如果有监管检查，引导监管检查公司内数据中心部署的系统和交易数据。
对监管不进行主动报备。
2.3网络性能和成本
保证访问性能采取的是关键系统近云方案，例如公司的核心交易系统都部署在万国数据中心，阿里云的华东2机房也在万国，直接与万国签署协议在万国内部将部署在阿里云华东2的机器和公司自有机器网络内部专线打通。这样一方面可以大幅降低专线成本，还能保证和内网一样的网络访问速度。
2.4安全下云方案
为了保证后续安全下云采用了私有云+PaaS中间件隔离层两个手段来保证，如果后续监管要求不能有系统上云或者云供应商倒闭等极端情况，也可以保证交易在降级的情况下使用私有云继续提供服务。因为大面积使用了云供应商的PaaS中间件和数据库产品，为了以后能安全下云和不被一家云供应商绑架，对应用层代码和云PaaS中间件之间自己开发了一套中间件隔离层，这样后续换供应商或者迁移私有云都可以不涉及到应用层代码的改动，可以比较简单的迁移系统。
2.5中间件使用
中间件在使用过程中，阿里云经常更新中间件版本，导致经常在生产上遇到一些阿里中间件导致的问题，不过阿里在过程中修复比较及时。
中间件推荐使用云服务商现成产品，这样可以让项目组不用关心中间件数据库的高可用、高性能等基础问题，直接拿来就用，但是为了安全下云，可以在中间件之间做一层隔离层解耦。
尽量不要使用云服务商的开发框架尤其是微服务框架，容易导致强耦合后续无法下云或更换服务商。
2.6容器化经验
在开发测试环境使用容器化，这样可以大幅降低环境使用成本，通过定期检查监控环境使用率来督促项目组回收资源，对于使用率低的环境让项目组自己备份docker镜像，后续在需要使用的时候直接恢复，这样在保证资源利用率的情况下，还可以让项目组后续要使用的时候能够做到秒级环境恢复，大幅节约资源成本。容器资源都通过公司内的k8s去管理，不使用阿里云的容器管理平台，大幅降低使用成本。
2.7成本
采用公有云每年资源硬件和维护成本降低30%，采用团体云方案成本会比公有云增加80%成本，采用私有云基础设施搭建费用4000w。
2.8多地多中心
通过云服务商多地数据中心很方便的实现3地5中心，减少灾备环境的资源浪费采用多中心多活方案充分利用资源。
3. 传统IDC迁移阿里云的过渡方案
对于将IDC进行云环境迁移，其实整个过程是需要有过渡期的，除了一些边缘非交易系统可以做到一次性环境迁移，对于大多数业务系统来说是无法做到一次性迁移的，都要有合理的云迁移过渡方案，下面就按照业务重要性分为两类系统介绍下迁移方案。
我们按照业务优先级将系统分为两大类，一类是系统出现故障后也不会导致全公司业务全部中止，只会影响到部分用户或者是部分业务渠道；另一类是系统出现故障后将会导致全渠道核心业务无法办理。下面笔者就拿银行系统来举例，渠道类的系统例如移动银行、开放平台、柜面等等这些渠道系统优先级就可以定义为重要性低一级的系统，而像客户信息系统（ECIF）就是重要性非常高的一级系统，一旦系统出现严重故障那么将导致全行所有渠道都无法开立客户，作为一家银行无法开客户开卡，那么这将是非常严重的生产事故。可以按照例子中的系统重要性进行分析系统在自己公司中的重要性，对于像银行、证券这些金融机构，监管会对系统和数据安全有一定的要求，这里在迁移的过程中也需要考虑这些监管问题，对于保存了客户核心信息和关键交易信息的系统可能要分多次进行迁移。
3.1 低重要性系统迁移过渡方案
这里直接通过例子来表达会更加直观：
低重要性系统这里拿移动银行来举例，对于移动银行系统来说主要有几部分组成，web服务器、应用服务器、数据库，移动银行的web服务器主要是用来存放一些页面静态资源和作为反向代理，应用服务器其实承担了移动银行渠道网关的职责主要是进行报文的加解密、token管理等职责，移动银行的核心业务逻辑都在渠道中台，在渠道中台进行了复杂业务逻辑的组合。
根据移动银行的特性我们分为两阶段进行云环境迁移：
第一阶段：移动银行Web服务器和应用服务器上云，数据库使用云服务商的RDS（需要单独采购云数据库加密产品对持久化数据进行加密），数据库中不涉及交易信息和客户敏感信息。
第二阶段：在监管报备允许的前提下，将全渠道中台应用服务器上云，数据库使用云服务商的RDS（需要单独采购云数据库加密产品对持久化数据进行加密）。
3.2 重要性系统迁移过渡方案
对于重要性高的系统的云迁移过渡方案我们用客户信息系统来举例，客户信息系统在银行中是非常重要的一级系统，如果客户信息系统出现问题，那么将导致严重的生产事故。
因为ECIF系统属于重要一级系统，在保证高可用和客户数据安全的前提下分3阶段实施：
一阶段：将部分应用服务器部署在云上，部分应用服务器部署在行内数据中心；调用方通过SLB进行负载分流到云上和云下的ECIF应用服务器；ECIF所有数据统一保存在行内数据中心的数据库中，云上应用服务器的数据库连接通过专线连接到行内ECIF数据库。这样实施的目的可以防止在云供应商出现系统性事故的时候，可以将请求负载分流到行内服务器来提供服务，数据还是统一保存在IDC机房的数据库中，这样可以保证客户数据在行内满足监管需求。
二阶段：将所有应用服务器部署在云上；ECIF所有数据统一保存在行内数据中心的数据库中，云上应用服务器的数据库连接通过专线连接到行内ECIF数据库。第二阶段客户数据还是保存在IDC的数据库中，目的还是为了应对监管，对于没有监管的行业可以省略第二步直接到第三阶段，完全使用云服务商的RDS。
三阶段：在监管允许客户数据上云的前提下，将ECIF应用服务器和数据库全部上云。对于不涉及监管的系统可以直接从第一阶段迈进第三阶段，第一阶段的云上云下分散部署的目的还是给运维和云服务商产品能够有个适应踩坑的过程，目前随着云服务商技术的不断迭代更新，出故障的几率也在逐步下降，所以第三阶段实现的应用系统全部上云也是一个趋势，不然还是要安排人去维护IDC的设备和软件。
总结
传统数据中心搭建和维持正常运营的成本较高，所以现在不单单是小的创业公司将系统使用公有云来降低成本，很多大型互联网公司和银行、支付公司这些金融机构也都在将原来部署在IDC机房里的系统往云上迁移，一方面是为了降低成本，另一方面是能够在交易出现潮汐的场景下能够快速弹性伸缩。总的来说系统上云将是一个未来数据中心发展的大趋势。
