上云实践操作（漫步云端）之上云动力

上云之前

在选择使用阿里云之前，整个技术部门采用的是自购服务器+机房托管的方式来部署所需要的程序。并且考虑到不同区域的业务以及灾备的问题，一共在南北两个城市的IDC机房都部署有服务器来支撑日常业务的运行。在IDC模式的运维工作上面，首先带来的问题是日常的巡检和维护，当某一个机房的设备如果出现了硬件损坏的情况，运维通常可以联系机房进行临时的设备替换，并重新申请购买新的设备，并到机房去安装。 这样的话，首先就是当损害一旦产生，某些服务或者程序所提供的算力会在某一段时间内降低，而且对于设备损坏重新购买所申请的费用，在预算控制上面也是一个比较难以估计的问题。再者，当新设备回来后，还是得需要运维人员到机房现场去替换设备，这样随之而来的也就产生了一些不必要的差旅费用，这些临时费用的产生，对于整个部门的预算管理都是一种挑战。
假设上架的服务器都没有问题，稳定的渡过了3年的时间，或者因为业务做得特别好，需要对机房进行扩容，这个对于在传统机房部署上又是一个比较头疼的问题。从选择什么样的机器，机房是否有足够的机柜，机柜间的网络状况，给供应商签署合同，发货，机器到货上架，整个流程会非常的长，如何选择最经济合适的方案来采购机器以匹配现有的业务，这个应该是对决策者比较考验的问题。 如果我们把整个IDC机房的运行时间和设备采购的成本以放到5年来看，我们会发现下面的一个情况。

从上图我们可以看得出来，根据逐年的业务提升，总是会发现IDC的服务无法满足业务的要求，从而再次对IDC机房进行扩容，扩容后的某一段时间内是可以满足业务的需要，但是再某些时候IDC机房所能提供的能力又大于业务的需求，造成了资源的浪费，图形中的两条线并不是平滑匹配的。
为了解决以上的问题，我们再2018年的时候开始考虑使用云计算的方案来替代我们现有的IDC的机房结构。

准备上云

上云之需求
说到为什么要上云，其本质上并不是说要去追寻什么现在主流的上云趋势。而是要实实在在解决我们在上一个章节中遇到的问题，总结来说，上云需要解决：

• 预算控制问题
• 日常运维的快速响应问题
• 算力扩容问题
• 业务与机器平滑匹配的问题

带着以上的几个问题，我们也开始着手去调研过一些云厂商的产品与服务。最后从提供的产品，价格的方面考虑还是选择了阿里云。最初在选择的时候我们调研到了阿里云的以下几个产品能够满足我们的需求：

• ECS （提供与日常服务器一致的功能）
• EMR （提供hadoop集群功能）
• RDS （提供Mysql和Redis的功能）
  但如果只是仅仅考虑到以上的几个产品就去上云感觉无非就是把云服务当成了普通的服务器来使用，并没有什么太大的优势。但是结合到阿里云提供的一些其他产品，整个系统的结构会发生大的变化，所以我们最后选择使用的产品有：
• VPC
• NAT 网关
• RDS
• SLS
• OSS
• MaxCompute
• CDN
• PAI
• EMR
• SLB
  最终组成的业务架构图如下：

首先通过EIP按照业务的需要向外暴露服务，整个服务都装在VPC当中，通过NAT网关的DNAT和SNAT进行指向，进入的流量由SLB的规则分发到指定的ECS当中进行业务的处理，ECS当中的PHP，Python, Go 等程序可以通过读写RDS当中的数据进行处理，处理后的日志文件交由SLS统一收集并推送到Maxcompute 当中进行一些业务计算。计算后的最终结果再次写入到RDS当中供前端程序展示。计算中间结果存入OSS当中进行备份保存。
在配置沙河环境的时候同样采用了以上的思路，只是具体机器配置上比正式环境的略低几个档即可。

以上的所涉及到的各个产品与服务将在后面的章节具体介绍。