我的英文站点：https://iorilan.medium.com/

如何设计你的应用，能够在系统错误时做到自我修复？在分布式系统中，会经常遇到错误。硬件也会遇到异常情况。网络有时会出现短暂的错误。整个地区出现了服务中断。即便如此，关于这些问题的方案也是要提前规划的。因此，需要设计一个能够在错误出现时完成自我修复的系统，主要包括以下3个部分：发现错误。正确的对待错误。使用日志并监控错误，提高可操控性。对故障类型的响应取决于应用的可用性的需求。例如，如果你需要系统是高

自动缩放是动态分配资源来满足性能需求的过程。当工作负载增大时，应用程序可能会需要额外的资源来维持所需的性能级别并满足服务级别协议(SLA)。当需求降低并不再需要额外的资源时，可以取消资源分配以最大程度地降低成本。自动缩放可以使用云托管环境的弹性的同时降低管理开销。不再需要操作员对系统性能持续监视，然后做出添加删除资源的决策。应用程序伸缩主要有两种方式：垂直缩放，也称为增加和减少，表示改变资源容量。...

内容交付网络 (CDN) 是高效地向用户交付 Web 内容的分布式服务器网络。 CDN 将缓存的内容存储在靠近最终用户的边缘服务器上，以最大程度地降低延迟。CDN 通常用来交付静态内容，例如图像、样式表、文档、客户端脚本和 HTML 页面。 使用 CDN 的主要优点是延迟较低且能更快地将内容交付给用户，而与托管应用程序的数据中心的地理位置无关。 CDN 还可以帮助降低 Web 应用程序上的负载，因...

设计良好的REST-API会限制客户端可访问的资源、关系和导航方案。在实现和部署WebAPI时，应考虑到托管WebAPI物理环境的要求以及构造WebAPI的方式，而不是考虑数据的逻辑结构。本文重点介绍如何实现WebAPI，公开给客户端应用程序。有关WebAPI设计的详细信息，请参阅API设计指南。（https://docs.microsoft.com/en-us/azure/architectur...

随业务演化的架构每项设计决策必须考虑到业务这项设计原则虽然看起来很明显，但在设计解决方案时要牢记这一点。你有数百万的用户，还是几千？一小时服务中断是否可以接受？系统会有大并发，还是流量始终比较小并且是可预测的？最终的每个设计决策都必须由业务需求进行说明。建议做法定义业务目标，包括恢复时间目标（RTO），恢复点目标（RPO）和容许中断的最大值（MTO）。这些数字应该关系到架构的确定。例如，要实现低R

为演化而设计为演化而设计是持续创新的关键。所有成功的应用程序都在随时间的推移而演变，无论是错误修复，添加新功能，引入新技术，还是提高现有系统的可扩展性和弹性。如果应用程序的所有部分都紧密耦合，则导致系统将很难更改。应用程序的一部分更改可能会影响另一部分，或导致整个代码库大幅度改动。这个问题并不局限于单一应用程序。应用程序可以分解为服务，但仍存在使系统刚性和脆弱的紧耦合。但是当服务而演化而设计时，团

使用正确的数据存储选择最佳的数据存储方案并正确使用把所有的数据都放入一个很大的关系型SQL数据库的时代已经过去。关系数据库所擅长做的-为关系数据交易提供ACID保证。但同时也有一些代价：- 查询可能会包含昂贵的联接。- 数据必须被归一化并符合预定义的模式（写入模式）。- 锁可能会影响性能。在大型解决方案中，单一的数据存储技术可能无法满足所有需求。关系数据库的替代方案主要有键/值存储，文档数据库，搜

尽量使用托管服务如果可能，使用平台即服务（PaaS）而不是基础架构即服务（IaaS）。IaaS就像有一盒散件。你可以建造任何东西，但必须自己组装。而托管服务更易于配置和管理。您不需要配置VM，设置VNets，管理修补程序和更新，以及运行在VM之上的所有软件相关的开销。例如，假设你的应用程序需要一个消息队列。你可以使用类似RabbitMQ这样的组件在VM上配置自己的消息传递服务。但是Azure服务总

系统运维方案对应用程序进行设计，使运维团队拥有他们需要的工具，云已经大大影响了运维所扮演的角色。他们不再负责管理托管应用程序的硬件以及基础架构。然而，运维仍然在运行成功云应用程序中扮演着关键角色。运维团队的一些重要职能包括：部署监控系统升级对异常的响应安全审计完整的日志和跟踪追踪机制在云应用中尤为重要。需要运维团队参与设计，以确保应用程序为他们提供需要有帮助的数据和见解。建议做法使一切都是可监控的

使用分区解决限制使用分区来解决数据库，网络和计算的限制。在云中，所有服务的扩展能力都有限制。Azure服务的具体限制记录在Azure订阅和服务限制，配额和约束中包括核数量，数据库大小，查询和网络流量吞吐量。如果你的系统增长到足够大，就可能会遇到这些限制中的一个或多个。可使用分区来解决这些限制。有很多方法来对系统进行分区：分区数据库以解决数据库大小、I/O或并发会话数量的限制。对队列或消息总线分区，

可水平扩展的设计设计您的应用程序，使其可以水平扩展。云的主要优点是系统可根据需要可伸缩 - 容量的大小随需求可变，系统随负载的增加可水平扩展，并且在不需要时进行收缩。对应用程序进行设计，使其可以根据需要进行水平伸缩。推荐做法避免粘（有状态）实例。粘性或会话关联性是指，当来自同一客户端的请求总是（需要）被路由到相同的服务器。粘性限制了应用程序的扩展能力。例如，大并发的流量不会将压力均发到实例上。粘性

保持冗余确保你的应用的部署体系是有冗余的，以避免单一节点失败的情况。一个弹性良好的系统可以灵活的绕过系统故障。找出应用中（请求执行）的关键路径。路径中的每个节点是否都有冗余？子系统失败时，系统能否有效的转移故障？也要考虑到业务需求。每个（节点的）冗余都会导致额外的开销和复杂度。你的架构应该考虑到业务需求的标准，例如，目标恢复时间（Recovery time objective）。再如，多区域部署肯

最小化协同操作最小化应用服务之间的协同，提高可扩展性。大多数云应用程序包含多个服务 - Web前端，数据库，业务，报表以及高级分析等等。为了可扩展性和可靠性，这些服务应该在多个实例上运行。当两个实例尝试执行影响某些共享状态的并发操作时会发生什么？在某些情况下，例如，为了保持ACID原则就必须在节点之间进行协同操作。在下图中，节点2正在等待节点1释放数据库锁：协同限制了水平扩展并制造了瓶颈。在此示例

许多类型的应用程序需要运行与用户界面 (UI) 无关的后台任务。 示例包括批处理作业、密集处理型任务，以及长时间运行的过程，例如工作流。 后台作业无需用户交互就可执行 -- 应用程序可以启动作业，并继续处理来自用户的交互请求。 这有助于减少应用程序 UI 上的负载，从而提高可用性，降低交互响应时间。例如，如果应用程序需要生成用户上传的图像缩图，可以后台作业的形式执行此操作，并在完成时会缩图保存到存...