azure 最佳实践 -- 保持冗余
保持冗余
确保你的应用的部署体系是有冗余的，以避免单一节点失败的情况。
一个弹性良好的系统可以灵活的绕过系统故障。找出应用中（请求执行）的关键路径。路径中的每个节点是否都有冗余？子系统失败时，系统能否有效的转移故障？
也要考虑到业务需求。每个（节点的）冗余都会导致额外的开销和复杂度。你的架构应该考虑到业务需求的标准，例如，目标恢复时间（Recovery time objective）。再如，多区域部署肯定比单区域部署开销大，并且更难管理。需要有相应的故障转移和故障恢复的方案。对于特殊业务需求，额外的开销是合理的。
把虚拟机部署在负载均衡器后面。不要使用单一节点来处理关键任务，要确保虚拟机的部署有负载均衡机制。如果任何一台虚拟机不可用，负载均衡器会把请求发送到现有的其他虚拟机上。关于部署的详细配置，可参见Multiple VMs for scalability and availability（https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/virtual-machines-windows/multi-vm）
复制数据库。azure SQL数据库和Cosmos DB会自动对区域内的数据进行复制，你也可以选择开启地理区域复制选项。如果你正在使用IAAS(infrastructure as a service)数据库方案，可以选择支持复制和故障转移的数据库，例如SQL SERVER Always On Availability Groups（https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server）.
启用地理复制。azure SQL数据库（https://docs.microsoft.com/en-us/azure/sql-database/sql-database-geo-replication-overview）和Cosmos DB（https://docs.microsoft.com/en-us/azure/cosmos-db/distribute-data-globally）的地理复制功能会在一个或多个备用区域中创建备用副本。在中断情况下，数据库会自动切换到备用区域写数据。
根据可用性进行分区。数据库分区经常用于提高可扩展性，但是它也用于提高可用性。如果一个（数据库）分片失败，其他分片可以使用。一个分片的失败只会影响到整个事务的一部分。
部署到多区域。对于要求极高可用的系统，需要进行多区域部署。这样一来，当这个区域出问题的时候（虽然很少见），就可以把应用切换到可用的区域。下图展示了一个多区域部署的应用是如何使用azure traffic manager进行故障转移的。
同步前后端的故障切换。使用azure traffic manager来转移前端故障。如果前端在一个区域不可达，traffic manager就会把请求转移到备用区域。对于不同的数据库方案，可能还需要对数据库故障进行转移。
自动故障转移，手动故障恢复。使用traffic manager进行自动故障转移，而不是自动故障恢复。自动复制恢复是有风险的，在确保主区域完全正常之前，可能被（自动故障恢复）进行了区域切换。在进行手动恢复之前，要确保所有应用的子系统都是正常的。针对不同数据库，在进行恢复之前，可能要验证数据一致性。
为traffic manager加入冗余。traffic manager是容易发生失败的节点。要审查traffic manager的SLA，并考虑使用单一节点traffic manager是否满足高可用的业务需求。如果否，考虑为traffic manager添加冗余节点以备故障恢复。如果azure traffic manager服务失败了，修改你的DNS中CNAME记录，指向其他的traffic management服务即可。
确保你的应用的部署体系是有冗余的，以避免单一节点失败的情况。
一个弹性良好的系统可以灵活的绕过系统故障。找出应用中（请求执行）的关键路径。路径中的每个节点是否都有冗余？子系统失败时，系统能否有效的转移故障？
也要考虑到业务需求。每个（节点的）冗余都会导致额外的开销和复杂度。你的架构应该考虑到业务需求的标准，例如，目标恢复时间（Recovery time objective）。再如，多区域部署肯定比单区域部署开销大，并且更难管理。需要有相应的故障转移和故障恢复的方案。对于特殊业务需求，额外的开销是合理的。
把虚拟机部署在负载均衡器后面。不要使用单一节点来处理关键任务，要确保虚拟机的部署有负载均衡机制。如果任何一台虚拟机不可用，负载均衡器会把请求发送到现有的其他虚拟机上。关于部署的详细配置，可参见Multiple VMs for scalability and availability（https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/virtual-machines-windows/multi-vm）
复制数据库。azure SQL数据库和Cosmos DB会自动对区域内的数据进行复制，你也可以选择开启地理区域复制选项。如果你正在使用IAAS(infrastructure as a service)数据库方案，可以选择支持复制和故障转移的数据库，例如SQL SERVER Always On Availability Groups（https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server）.
启用地理复制。azure SQL数据库（https://docs.microsoft.com/en-us/azure/sql-database/sql-database-geo-replication-overview）和Cosmos DB（https://docs.microsoft.com/en-us/azure/cosmos-db/distribute-data-globally）的地理复制功能会在一个或多个备用区域中创建备用副本。在中断情况下，数据库会自动切换到备用区域写数据。
根据可用性进行分区。数据库分区经常用于提高可扩展性，但是它也用于提高可用性。如果一个（数据库）分片失败，其他分片可以使用。一个分片的失败只会影响到整个事务的一部分。
部署到多区域。对于要求极高可用的系统，需要进行多区域部署。这样一来，当这个区域出问题的时候（虽然很少见），就可以把应用切换到可用的区域。下图展示了一个多区域部署的应用是如何使用azure traffic manager进行故障转移的。
同步前后端的故障切换。使用azure traffic manager来转移前端故障。如果前端在一个区域不可达，traffic manager就会把请求转移到备用区域。对于不同的数据库方案，可能还需要对数据库故障进行转移。
自动故障转移，手动故障恢复。使用traffic manager进行自动故障转移，而不是自动故障恢复。自动复制恢复是有风险的，在确保主区域完全正常之前，可能被（自动故障恢复）进行了区域切换。在进行手动恢复之前，要确保所有应用的子系统都是正常的。针对不同数据库，在进行恢复之前，可能要验证数据一致性。
为traffic manager加入冗余。traffic manager是容易发生失败的节点。要审查traffic manager的SLA，并考虑使用单一节点traffic manager是否满足高可用的业务需求。如果否，考虑为traffic manager添加冗余节点以备故障恢复。如果azure traffic manager服务失败了，修改你的DNS中CNAME记录，指向其他的traffic management服务即可。