本文共 1113 字，大约阅读时间需要 3 分钟。

正当很多知名网站都在抱怨时， Twilio的API和服务，尽管他们也严重依赖于AWS来培育并扩展自己的（cloud telephony platform）。对于Evan Cooke（的合伙创始人与CTO）而言，这不仅展现了云服务在开启当代互联网生态环境方面的惊人成功，还展现了 在构建云服务时的重要性。

当我们在Amazon Web Services上培育并扩展Twilio的时候，我们遵循了一系列的架构设计原则，以便能将底层基础设施中偶发但不可避免的问题所带来的影响降到最小。

• 故障单元是单台主机

构建由单台主机构成的简单服务，而非多依赖的主机构成的服务，可以创建复制服务实例来抵御主机故障。

• 短时间超时与快速重试

发生故障时，让软件快速识别失败并重试请求。每个服务都运行多个冗余拷贝，短时间内超时，然后绕过失败或不可访问的服务进行重试。

• 幂等的服务接口

如果所依赖服务的API是幂等的，那就意味着可以安全地对失败请求进行重试。

• 小的无状态服务

将业务逻辑分散到小的无状态服务中，这些服务可以被放到简单的同构服务池中。

• 宽松的一致性要求

在不需要严格一致性时，为要读取的数据做复制和冗余。

　　根据，Evan还解释了为什么Twilio只针对非关键和非延时敏感的任务使用EBS，因为这不需要符合“故障单元是单台主机”原则。如果EBS遇到了问题，所有依赖它的服务都会发生故障。他们转而关注于利于EC2主机上的临时磁盘来做持久化。如果临时磁盘坏了，那么故障的范围仅仅是那台主机。Evan将发表一篇后续文章来描述他们是如何跨过多个临时磁盘来做RAID0以提升I/O性能的。

　　这与是一致的，正如Don McAskill所说的那样，SmugMug也选择不用EBS。

　　Mike Kavis（M-Dot Network的CTO）认为：

Amazon拥有为数众多的服务，那些费时费力的任务都可以被简化并自动化进一次简单的调用中，开发者仅需一次调用就可以了。 （监控与自动扩展）和 （数据库管理）就是其中的两个。当你开始使用这些服务后，你就已经置身于一个PaaS场景中了，你使用了某个厂商所独有服务。

　　对他而言，此类依赖和可能发生的故障都应该被纳入架构和业务模型之中，因为要构建一个云提供商未知的架构，如果不自己重新构建这些服务，几乎就是不现实的。

　　很明显，就算在云端，计划也是必须的，架构无论现在还是以后，都会是构建基于云的解决方案的必备内容，这并不是什么新鲜观点。Twilio的原则是否足够？从中你是如何理解云架构的演进的？更多的冗余？自己开发服务？更多的架构原则？这将如何转变为基于PaaS的解决方案？

　　查看英文原文：

转载地址：http://ogzvb.baihongyu.com/