教大家如何提高AWS可用性

　　欢迎各位阅读本篇文章，本篇文章将教大家如何提高AWS可用性，课课家教育平台提醒大家：本篇文章中有许多的小细节，因此大家要仔细阅读本篇文章哦~

     可用性在公有云的范畴意味着公司必须确保自己的服务宕机时间最少。对于很多web规模的企业来说连接的丢失意味着客户的丢失。要确保可用性，重要的是在故 障变成彻底断电以前就要发现并想法减轻。使用AWS，开发人员可以采取三管齐下的方法来提高持续性，通过使用如Amazon Route 53，弹性负载均衡和自动扩展组这样的工具。

　　直接请求过程，例如视频回放的请求，不是由事件驱动的。基于这个原因，并行化在这里不像在其他后端进程那样适用。对于那些需要立刻作出反应的直接请求，开 发人员必须提供高可用性的支持。如果用户在尝试播放视频时得到一个“500错误，服务器不可用”的回应，该业务将有可能失去用户。

　　企业可以很轻松地发布一整夜维护的声明并期待客户能够接受这段时间内将不能访问服务的日子已经过去了。如果一个业务想要提供99.999%的正常运行时间，那么一个月的停机时间大约只能有40分钟。

　　为了实现这种AWS可用性，开发人员必须能预见到错误-而不只是避免错误。开发人员必须有一个适当的流程，可以从任何形式的破坏性状况下恢复，他们必须能够处理所有类型的网络和区域问题。他们还需要有位于靠近国际客户区域地点的服务器并能将客户路由到正确的地理位置。

　　开发人员应该关注三个层面来实现全球AWS可用性。在最顶层是Amazon Route 53。在地区层面，开发者可以使用弹性负载均衡(ELB)，然后在域层面，他们需要增加自动扩展组。

　　图1：典型的AWS高可靠性架构

　　该架构保护资源避免几个潜在的问题，包括地理问题，通过直接引导用户到离其最近的网络位置，用ELB解决单独域的问题，使用自动扩展组解决单独服务器的问题。开发人员可以配置自动扩展组来自动杀掉未响应ELB健康检查的任何实例。

　　经受住区域性亚马逊Web服务问题的考验

　　然而所有这些都假定AWS不会有一整个区域的断电。但并非总是如此，事实上，有很多记录在案的事件表明，亚马逊曾经有过某个具体服务的一整个区域电包括DynamoDB和弹性计算云。如果亚马逊在一个地区出现问题，一个业务可能会失去那片地区的所有客户并需要手动将流量重定向到另一个区域，除非你添加了Route 53健康检查。

　　支持地理路由和健康检查很简单，只要设置一个在故障发生时可以切换到其他端点的区域端点。例如，如果一个网站是example.com，它可以设置us- east.example.com，us-west.example.com和eu-west.example.com这三个端点。然后配置 Example.com使用在地理位置上最近的端点。但其中每个端点将被配置为使用这三个ELB之一，优先使用最近的并同时通过健康检查来转到其它端点上。

　　图2：在这张Route 53配置图中，黑色代表最理想的选择，蓝色代表次要选择，红色是第三选择。

　　图2显示了一个Route 53区，根据地理位置配置了三个独立的端点。如果我们被导向美东端点，则首选是美东负载平衡器。倘若负载平衡器不可用，它会尝试使用美西的负载平衡器。如 果美西的ELB也宕了，则会转到欧西地区。如果这三个地区都宕掉了，那么你的麻烦就很大了。在Route 53的层面适当配置健康检查将有助于减少整个区域出故障时的宕机时间。

　　这就是所谓的增加持续性-预期到个别的区域会断电，并有一个用于恢复服务的计划。但验证和支持每个区域的个体可用性很重要。例如，如果整个区域发生故障，其他区域仍然应该能够不受任何影响的工作。这可以通过使用数据库复制达到。

　　幸运的是，亚马逊已经在DynamoDB上支持跨地区复制。很多其他的数据库也支持主主复制方案，这样可以在出现问题时转到另一个域来支持区域隔离和持续性。

　　当开发者需要支持应用的高可用性访问时，多层次的持续性是必须的。幸运的是，AWS提供了三种很好的服务可以结合起来使用，以解决地区，区域和实例层面的 问题。通过添加像NewRelic这样的第三方服务来监控应用程序可以为你的业务提供各种警报并可以自动修复服务以减少停机时间。

　　知识分享：AWS应用建模

　　探讨企业通过技术来改善流程，主要有两种方法：一种是通过集成和授权来驱动传统的遗留应用系统;另一种是利用现代的BPM系统执行BPM应用。在BPM系统中，流程即为应用程序，这种可理解为流程所定义的每个步骤视为个人或其他应用系统所执行的任务，更加明确的说BPM应用包含了流程和应用程序两部分。在中国，大多数集团企业或行业客户IT建设尚处于初级磨合阶段，大量BPM应用需要进行设计或重建，AWS的应用建模工具和引擎能够为交付每个步骤的应用程序提供全过程的设计工具和执行环境。

　　值得关注的是AWS借助了MDA(Model Driven Architecture，模型驱动架构)技术，实现了业务应用需求与软件开发技术的分离，让编程技术人员有更多的时间关注在用户需求与业务敏捷性，不必考虑实现细节。透过AWS的MDA模型架构，可以让一个软件应用可视、可控的通过模型组合起来，并随时可以重新进行组合。在AWS所表达的业务系统中，应用就是由看得见、摸的着的系列模型组合而成的，大大降低了应用功能(非流程)的交付周期和难度，使经过简单培训的技术人员也能高质量、高效率的设计出足够复杂的业务应用来。同时AWS的建模工具支持与Eclipse(java编程环境)的集成，具备简单java编程经验的设计者可通过扩展各种事件接口实现更复杂的业务逻辑。

     小结：相信大家最后阅读完毕本篇文章后，一定学到了不少知识吧？当然如果大家还想要了解更多方面的详细内容的话，不妨关注课课家教育平台，这里有更深入的知识，课课家教育欢迎大家~