应该如何使用阿里云-第二版 持续更新中

2014年10-12月，小博无线 (www.rippletek.com) 在阿里云开发者论坛上分享了“应该如何使用阿里云”系列

如今又是一年过去，随着阿里云平台不断推出的新功能，我们在阿里云的平台上又多了哪些新的玩法，以及掌握了哪些更好的实践？ 我会陆续总结更新在这个帖子里。希望大家多多关注，回帖支持。谢谢~

我们先回顾一下去年年底编写完成的第一版，看看一年过去后，随着阿里云推出的功能的增多增强，以及我们的经验积累，里面提到的一些实践方法，到今天可以有哪些改进?

对于第一版中的一些实践的改进
1. ecs购买按流量付费的1Mbit公网带宽 - ecs流量的按量付费是2015才推出的计费方式。使用这个新的计费方式，可以进一步降低降低成本。1Mbit的固定带宽是21元/月，但是我们的业务流量都是走slb出去，并且ssh的管理流量可以通过ssh网关节点中转，ecs自身的公网上行流量仅用于三方服务器的api调用，这样的话，ecs自身的流量费用可以拉低到接近于0
2. 使用redis, 而不是ocs作为缓存服务 - 云端redis也是2015年推出的新服务。redis和ocs相比，有两个明显的优势: 1)redis有非常丰富的数据结构支持，ocs仅支持string ; 2)ocs的value size最大仅支持1MB, redis无value size限制
3. 使用redis, 而不是mqs作为队列服务 - redis的存取性能比mqs要好很多，而且redis sdk的选择面也比mqs大很多
4. 在oss+cdn的存储解决方案中，建议在oss的bucket属性设置中打开‘cdn缓存刷新’，该功能也是2015年才出现的新功能
5. 关于slb的配置，建议仅使用tcp转发，如果后端业务提供的是web服务，则在slb和业务节点之间应加入nginx节点作为反向代理层。主要有下面几个原因: 1)http转发配置比较麻烦，需要设置健康检查的专用接口; 2)http健康检查的请求相当高频，qps约10-20，会在访问日志中留下大量记录 (虽然可以通过配置过滤掉无效日志，但毕竟又多一件麻烦事); 3)反向代理可以为业务的后期发展提供很多的灵活性，如http转https，缓存或权限策略调整，消除跨域访问问题等; 4)‘基础篇’中建议使用http转发并设置粘性cookie来绑定用户请求和后端业务节点的方式并不好，业务的正常推进不应依赖用户请求被分发到同一节点，不应使用本地文件存储动态数据，应该使用mysql或redis来保持业务计算节点的无状态性
6. slb api在2015年已支持后端节点的权重设置，可以用来实现无感知上线
7. ’高级篇‘中'docker as VM'实践的痛点和解决办法
8. 是否应该使用数据盘？在基础盘中不建议使用本地数据盘，因为静态数据应使用oss存储，动态数据应使用mysql存储。并且，在2014年底的时间点，如果docker image存储在数据盘上，甚至无法正常运行。这一点在2015年得到改善，现在数据盘也可以运行docker. 同时，当一个ecs需要运行多个docker时，多个服务的image和日志可能让20G的系统盘尺寸非常吃紧，在这种情况下，挂一块尺寸更大的云磁盘会使情况有较大改观。不过云磁盘存储的价格不菲，普通磁盘的价格为1G 0.3元/月，而SSD盘的价格为1G 1元/月。折算下来，240G的磁盘一年的使用费为240*0.3*12=864元，同样尺寸的ssd盘一年的使用费为240*12=2880元。

'docker as VM'实践的痛点和解决办法
2014年我们最初在阿里云上使用docker的时候采用的是'docker as VM'的策略，在一个ecs上运行多个docker的长进程，采用scp+ssh的方式更新服务。这种方式的问题在于代码和配置不是作为一个整体部署，而是需要分开部署 (当然，把线上配置放入代码仓库维护也能解决这个问题，但是由于线上配置可能有访问密码或key等敏感信息，一般无法这么做)。那么，当需要回滚的时候问题就来了: 到底是先回滚代码还是先回滚配置？同时，配置也需要建立版本控制并且和代码版本关联，实在是麻烦。
2015年我们切换到了将代码和配置整体打包为一个docker image, 然后给每个docker image打上一个版本tag。在部署更新时采用先pull一个新版的docker image， 然后停止并销毁当前容器并用新的image来启动一个新的docker container的方式来完成服务更新。这样每次更新就指定最新的image tag来部署即可，如果需要回滚，就指定成上一个版本的tag并使用同样的部署动作，完全不用考虑代码和配置之间的版本依赖。


"无感知上线"的实现方式
上一节提到，我们在部署更新时采用先pull一个新版的docker image， 然后停止并销毁当前容器并用新的image来启动一个新的docker container的方式来完成服务更新。这样的话，在停止旧的服务容器时，如果该容器正在处理一些线上流量，会让终端用户感觉到网站服务出现抖动。另外，有些web应用框架(例如rails)可能需要一段时间才能完成启动，在应用服务没有启动完成前，接入的流量无法得到及时响应，也影响用户体验。
我们可以通过调用阿里云slb api的后端节点权重设置接口来做到整个上线部署过程对于终端用户无感知，步骤如下:
1. docker pull new image
2. 调用slb api取得节点A的权重V，然后将它设为0，等待一小段冷却时间(如3秒)。权重为0生效后，slb就不会转发新的请求到该节点，冷却时间是让节点A将当前正在处理的请求处理完毕
3. restart docker with new image
4. 等待一段时间，需确保该时间段不小于后端业务框架的典型启动时间5. 调用slb api将节点A的的权重重置为调整之间的值V
6. 对其他的节点重复1-5