应该如何使用阿里云ecs进阶篇

 前情提要及概述

在基础篇中，我们介绍了如何利用阿里云的几个基础服务: ECS, SLB, RDS, OSS, CDN和OCS来构建一个高可用的业务网站系统。在本篇中，我们将进一步介绍上面这些基础工具，以及如何从单业务系统拓展到多业务系统，和日常开发和运维的一些常用技巧。

多业务系统之间的交互手段

我们从几个具体的case说起吧 :)

case #1 利用消息队列实现的固件定制系统

如上图所示，先是由一个web前端的表单系统将用户的输入参数组装为一条消息放入固件生成的请求队列中，后面由固件构建集群取得用户的配置参数，生成固件后存入OSS，再将生成的结果放入结果消息对列中，前端系统获取结果后更新RDS的状态。

我们可以利用阿里云提供的MQS服务非常方便的在两个业务系统之间实现用消息队列异步传输小尺寸数据。如果尺寸较大，亦可以通过往RDS/OCS或OSS中写入临时数据，用消息队列传输key或url来解决。

case #2 利用ODPS/RDS实现的非实时数据分析系统

ODPS是一个阿里云上的接口类似Hadoop + Hive的数据分析系统。我们可以部署多个数据收集节点，将数据存入ODPS。再搭建一个数据分析集群，定期对写入ODPS的新数据进行提取，然后将提取的结果放入RDS。最后由一个web前端系统读取RDS中的数据生成报表呈现给最终用户。

这种reader/writer的模式是两个业务系统之间通信的常见方式，只要是两个系统之间可以共享的系统资源，都可以通过一端写入，另一端读出来实现通信。而在阿里云的系统设计中，同一账户下的ECS可以共享RDS，OCS, MQS, OSS, ODPS这些资源。我们应当针对不同的应用场景选择合适的资源类型加以利用。

case #3 利用OCS/内存数据库构建实时数据分析系统

web前端系统接受用户查询请求后，先查找OCS是否有缓存的结果，如果cache命中则直接返回结果。如果cache不命中，调用后端数据存储集群的web api. web api负责查询分布式内存数据库并计算分析后返回统计结果。前端系统拿到查询结果后，用查询参数hash出一个key，将查询结果作为value存入OCS中。注意：该系统的实时性在很大程度上取决于OCS缓存的expiration. 应依据业务特点设置合适的expiration值。如果对结果的实时性要求很高并且后端数据存储集群的计算性能有充分安全边际的情况下，也可以移除OCS，每次都重新提取数据计算结果。

同样，web api系统也务必消除单点。在这里，我们可以使用内网SLB解决。

再探SLB

在基础篇中我们介绍过外网SLB，并强调一切对外服务一定要通过外网SLB开放出去以消除单点。同样的，所有的系统内部通信web api也一定要通过内网SLB访问。内网SLB和外网SLB的区别在于内网SLB只有内网IP，没有外网IP，所以无法从internet上访问到。另外，内网SLB没有实例费和流量费，所以一定要多多的用起来！

SLB有两种监听转发方式， TCP和HTTP，一般情况下，web服务都采用http的转发方式，使用cookie来保持会话，这样即使在应用中使用本地文件来保存session，也不会成为问题。唯一的例外是给网站开启CDN时，为了消除CDN回源的单点，自然的，我们不能用单台ECS来回源，应考虑使用SLB，然而，如果使用HTTP + cookie保持会话，CDN会由于页面带了cookie而拒绝缓存。这种情况下，只能使用无会话保持的HTTP转发或TCP转发。

小结

至此我们展示了几个多业务系统的具体架构。云计算的组件组合方式可以是多种多样的。然而，在构建高可用系统这个问题上，有几个基本原则可以参考:

1. 务必消除单点。(如果读到这里您仍不理解什么是单点，请再看一遍基础篇 )
2. 尽量使用阿里云提供的系统服务，不要自己用ECS进行重复建设。例如，使用RDS，而不是自己搭建mysql集群; 使用OCS， 而不是自己搭建memcached集群；使用OSS， 而不是自己搭建文件服务器；使用ODPS， 而不是自己搭建Hadoop + Hive; 使用MQS, 而不是自己架RabbitMQ... 一是可以大幅降低投入，二是尽可能的把高可用问题交给阿里云的运维团队，而不是自己的运维团队解决，会有更佳的效果。
3. 设计异常恢复机制。任何系统都有可能会出现各种异常，阿里云也不例外。例如: ECS的宕机迁移会使ECS实例重启，最好在系统启动时即自动启动服务；RDS和SLB都有可能出现闪断的情况，需要自动重连；甚至云服务节点间的内网通信也有可能中断，导致内网SLB失效以及分布式数据库brain-split这类对服务质量有很大影响的问题，所幸在这一年里我们只遇到过一次这样的故障。
4. 安全平稳的线上代码变更。不管基础系统架构多么完美稳定，如果运行在上面的业务代码剧烈震荡，系统的可用性也还是个问题。所以在本篇的最后，我再介绍一下

RippleTek的上线流程

我们的每一个服务都是通过至少一个外网SLB开放出去的。在每个SLB的后面，至少有两个主服务节点SRV1和SRV2。另外，还有一个线上引流测试节点pilot。当需要线上代码进行变更的时候，先将pilot下线 (使用slb api将它从slb中移除，或者在控制台中将它的权重设为0. 这时你可能会问两个问题: 1) 把节点的权重设为0和直接将节点从slb中移除的区别是什么? 2) 为什么不用slb api将它的权重设为0? 这两个问题的答案请见下方的Q&A)，在pilot中的代码或配置变更不会对线上服务产生影响。同时，我们有一个测试专用的SLB_TEST，后端服务器就只有一个pilot，自己测试就用SLB_TEST的IP来做。功能测试OK后，把pilot重新加入线上服务的SLB，导入5%流量，持续观察日志5分钟看是否有异常情况。如无异则一小时后再观察。如一切正常，就将变更部署到该业务的全部主服务器上。部署后密切观察线上日志和监控，如有异常，先回退变更，再结合异常日志调查原因。该流程的有效性在很大程度上依赖于pilot的环境配置和SRV1/2的一致性，务必保证它们的环境是完全一样的!

到这里我们的旅程也暂告一段落了。稍事休息，更多精彩和乐趣将在 应该如何使用阿里云？(高级篇) 中呈现。 敬请期待。

Q&A

• 把节点的权重设为0和直接将节点从slb中移除的区别是什么?

把节点A的权重设为0可以让SLB不再转发新的请求到A，但已经调度到这个服务器的连接继续保持，直到这些连接全部结束。而直接将节点A从slb中移除会导致已经调度到这个服务器的连接中断，可能会对服务质量有细微影响。