正当很多知名网站都在抱怨自己受到了AWS 问题的影响时， Twilio 的API 和服务并未受到影响，尽管他们也严重依赖于AWS 来培育并扩展自己的云电话平台（cloud telephony platform）。对于Evan Cooke（ Twilio 的合伙创始人与 CTO）而言，这不仅展现了云服务在开启当代互联网生态环境方面的惊人成功，还展现了坚实可靠的分布式架构设计 在构建云服务时的重要性。
当我们在 Amazon Web Services 上培育并扩展 Twilio 的时候，我们遵循了一系列的架构设计原则，以便能将底层基础设施中偶发但不可避免的问题所带来的影响降到最小。
- 故障单元是单台主机
构建由单台主机构成的简单服务，而非多依赖的主机构成的服务，可以创建复制服务实例来抵御主机故障。
- 短时间超时与快速重试
发生故障时，让软件快速识别失败并重试请求。每个服务都运行多个冗余拷贝，短时间内超时，然后绕过失败或不可访问的服务进行重试。
- 幂等的服务接口
如果所依赖服务的 API 是幂等的，那就意味着可以安全地对失败请求进行重试。
- 小的无状态服务
将业务逻辑分散到小的无状态服务中，这些服务可以被放到简单的同构服务池中。
- 宽松的一致性要求
在不需要严格一致性时，为要读取的数据做复制和冗余。
根据故障的详细说明，Evan 还解释了为什么Twilio 只针对非关键和非延时敏感的任务使用EBS，因为这不需要符合“故障单元是单台主机”原则。如果EBS 遇到了问题，所有依赖它的服务都会发生故障。他们转而关注于利于EC2 主机上的临时磁盘来做持久化。如果临时磁盘坏了，那么故障的范围仅仅是那台主机。Evan 将发表一篇后续文章来描述他们是如何跨过多个临时磁盘来做RAID0 以提升I/O 性能的。
这与 SmugMug 采用的原则和方法是一致的，正如 Don McAskill 所说的那样，SmugMug 也选择不用 EBS。
Mike Kavis（M-Dot Network 的 CTO）认为 Amazon 的 IaaS 已经变成了 PaaS ：
Amazon 拥有为数众多的服务，那些费时费力的任务都可以被简化并自动化进一次简单的调用中，开发者仅需一次调用就可以了。 Cloudwatch （监控与自动扩展）和 RDS （数据库管理）就是其中的两个。当你开始使用这些服务后，你就已经置身于一个 PaaS 场景中了，你使用了某个厂商所独有服务。
对他而言，此类依赖和可能发生的故障都应该被纳入架构和业务模型之中，因为要构建一个云提供商未知的架构，如果不自己重新构建这些服务，几乎就是不现实的。
很明显，就算在云端，灾难恢复计划也是必须的，架构无论现在还是以后，都会是构建基于云的解决方案的必备内容，这并不是什么新鲜观点。Twilio 的原则是否足够？从中你是如何理解云架构的演进的？更多的冗余？自己开发服务？更多的架构原则？这将如何转变为基于PaaS 的解决方案？
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论