C# 云模式和最佳实践

    在云中，仅允许较短的延迟或停机时间，代码必须为此做好准备，代码要包含从这些平台异常中成功恢复的逻辑。如果以前曾现场编码，或编写就地执行的程序代码，这是一个重要的思想转变。需要忘掉很多有关管理异常的东西，学会接受失败，并创建从这种失败中恢复的代码。

    需要将可移植性、可伸缩性和弹性等概念集成到在云运行中的程序里。但这里的可移植性有什么特殊含义？如果程序可在多个平台上移动或执行，例如Windows、Linux和macOS，该程序就是可移植的。一些ASP.NET Core特性位于开源技术的新堆栈上，为开发人员提供把代码编译到二进制文件中的选项，以便在这些平台上运行。传统上，开发人员使用ASP.NET编写程序，在后台运行C#，使用IIS在 Windows服务器上运行该程序。然而，从以云为核心的角度看，在没有人工干预或程序化干预的情况下，程序及其所有依赖项从一个虚拟机移动到另一个虚拟机的能力是最适用的“可移植性”。记住，云中会出现失败，运行程序的虚拟机(VM)可以在任何给定的时间消失，然后在另一台虚拟机上重新构建。因此，程序必须是可移植的，能从这样的事件中恢复。

    “可伸缩性”意味着，当多个客户使用代码时，代码能正常响应。例如，如果每分钟有1500个请求，且请求的完成和响应在1秒钟之内完成，则大约每秒有25个并发请求。如果每分钟有15000个请求，则每秒有250个并发请求。云程序能以相同的方式响应25个和250个并发请求吗？如果是2550个并发请求呢？以下是几个有效管理可伸缩性的云编程模式：

    • 命令和查询责任分离(Command and Query Responsibility Segregation, CQRS)模式——这种模式涉及把读取数据的操作与修改或更新数据的操作分离开。

    • 物化视图模式——这会修改存储结构，以便反映数据查询模式。例如，为极常用的查询创建视图可以执行更有效的查询。

    • 分片(Sharding)模式——这把数据分解到多个水平碎片中(其中包含明显不同的数据子集)，而不是通过增加硬件的容量进行垂直伸缩。

    • 管家钥匙(Valet Key)1i式一这允许客户直接访问数据存储，以传输或上传大文件。它不是让Web客户机管理数据存储的守卫工作，而是给客户提供一把管家钥匙，并允许直接访问数据存储。

    “弹性”是指程序响应和从服务故障和异常中恢复的程度。从历史上看，IT基础设施一直专注于失败的预防，其可接受的停机时间是最短的，期望值是99.99%或99.999% SLA(Service-LevelAgreement，服务水平协议)。 但在云中运行程序，可靠性需要做思维转变，我们需要拥抱失败，要更关注恢复(而不是预防)。程序有多个依赖项，如数据库、存储器、网络和第三方服务，其中一些没有SLA，所以需要转变视角。在出现中断或非正常运行的情况下，如果仍能做出用户友好的响应，会使云程序富有弹性。下面的一些云编程模式可用于将弹性嵌入云程序：

    • 断路器模式——这是一种代码设计方式，它了解远程服务的状态，只有在服务可用的情况下，才会试图连接。如果通过以前的失败知道远程服务不可用，就会避免尝试请求和浪费CPU周期。

    • 健康端点监控模式一一这会通过实现端点检测，检查基于云的应用程序是否可用。

    • 重试模式——在短暂的异常或故障后重试请求。这种模式在给定的时间段内重试多次，当重试次数到达阈值时，就停止重试。

    • 节流模式一一管理云程序的使用，以便满足SLA，而且程序在高负载下仍然可用。

    使用上述一个或多个模式，有助于更成功地实现云迁移。上述模式会提高程序的可伸缩性和弹性，从而提高程序的可用性。这反过来会带来更愉悦的用户或客户体验。