您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

可伸缩性清单Scalability checklist

可伸缩性是系统处理更大负载的能力,它是软件质量的构成要素之一。Scalability is the ability of a system to handle increased load, and is one of the pillars of software quality. 使用此核对清单可以从可伸缩性的角度审查应用程序的体系结构。Use this checklist to review your application architecture from a scalability standpoint.

应用程序设计Application design

对工作负荷进行分区Partition the workload. 将流程的各部分设计为相互独立且可以分解。Design parts of the process to be discrete and decomposable. 最大程度地缩小各部分的大小,同时应遵循进行问题隔离所需的常用规则,以及单独责任原则。Minimize the size of each part, while following the usual rules for separation of concerns and the single responsibility principle. 这样可以让组件的各部分采用适当的方式进行分布,从而最大程度地利用每个计算单元(例如角色或数据库服务器)。This allows the component parts to be distributed in a way that maximizes use of each compute unit (such as a role or database server). 此外,可以更方便地缩放应用程序(只需添加特定资源的更多实例即可)。It also makes it easier to scale the application by adding instances of specific resources. 对于复杂的域,请考虑采用微服务体系结构For complex domains, consider adopting a microservices architecture.

针对缩放进行设计Design for scaling. 缩放可以让应用程序应对不同的负载,只需增加和减小角色、队列和所使用的其他服务的实例数目即可。Scaling allows applications to react to variable load by increasing and decreasing the number of instances of roles, queues, and other services they use. 但是,应用程序在设计时必须充分考虑这一点。However, the application must be designed with this in mind. 例如,应用程序及其使用的服务必须是无状态的,这样才能将请求路由到任何实例。For example, the application and the services it uses must be stateless, to allow requests to be routed to any instance. 这也会阻止添加或删除特定实例,从而对当前用户造成不利影响。This also prevents the addition or removal of specific instances from adversely affecting current users. 还应该在添加和删除实例时实现实例的配置或自动检测,以便应用程序中的代码可以执行所需的路由。You should also implement configuration or autodetection of instances as they are added and removed, so that code in the application can perform the necessary routing. 例如,Web 应用程序可能会通过轮循方法使用一组队列来路由请求,将请求路由到通过辅助角色运行的后台服务。For example, a web application might use a set of queues in a round-robin approach to route requests to background services running in worker roles. 若要成功地路由请求并对应用程序上的负载进行平衡,该 Web 应用程序必须能够检测到队列数目的变化。The web application must be able to detect changes in the number of queues, to successfully route requests and balance the load on the application.

按单元进行缩放Scale as a unit. 为了应对业务增长情况,需要按计划添加更多资源。Plan for additional resources to accommodate growth. 对于每个资源,应该知道缩放上限,并使用分片或分解方式来应对这些限制。For each resource, know the upper scaling limits, and use sharding or decomposition to go beyond these limits. 按照定义好的资源集来确定系统的缩放单元。Determine the scale units for the system in terms of well-defined sets of resources. 这会使横向扩展操作更加容易,不容易对应用程序造成不利影响(整个系统的某些部分缺乏资源时,会对应用程序施加限制)。This makes applying scale-out operations easier, and less prone to negative impact on the application through limitations imposed by lack of resources in some part of the overall system. 例如,添加 x 个 Web 和辅助角色可能需要使用 y 个额外的队列和 z 个存储帐户来处理这些角色所造成的额外工作负荷。For example, adding x number of web and worker roles might require y number of additional queues and z number of storage accounts to handle the additional workload generated by the roles. 因此缩放单元可能包含 x 个 Web 和辅助角色、y 个队列和 z 个存储帐户。So a scale unit could consist of x web and worker roles, y queues, and z storage accounts. 设计应用程序时,应确保其能够轻松地通过添加一个或多个缩放单元来进行缩放。Design the application so that it's easily scaled by adding one or more scale units.

避免客户端关联Avoid client affinity. 在可能的情况下,应确保应用程序不需要关联。Where possible, ensure that the application does not require affinity. 因此,请求能够路由到任何实例,与实例的数目无关。Requests can thus be routed to any instance, and the number of instances is irrelevant. 这样还可以避免为每个用户存储、检索和维护状态信息的开销。This also avoids the overhead of storing, retrieving, and maintaining state information for each user.

充分利用平台自动缩放功能Take advantage of platform autoscaling features. 在托管平台支持自动缩放功能(例如 Azure 自动缩放)的情况下,应尽量使用该功能而不使用自定义机制或第三方机制,除非内在机制无法满足要求。Where the hosting platform supports an autoscaling capability, such as Azure Autoscale, prefer it to custom or third-party mechanisms unless the built-in mechanism can't fulfill your requirements. 尽可能使用计划的缩放规则,确保资源在开始使用时没有延迟,但应根据需要向规则中添加反应性的自动缩放,以应对需求方面的意外变化。Use scheduled scaling rules where possible to ensure resources are available without a start-up delay, but add reactive autoscaling to the rules where appropriate to cope with unexpected changes in demand. 可以在服务管理 API 中使用自动缩放操作来调整自动缩放,并可向规则中添加自定义计数器。You can use the autoscaling operations in the Service Management API to adjust autoscaling, and to add custom counters to rules. 有关详细信息,请参阅 Auto-scaling guidance(自动缩放指南)。For more information, see Auto-scaling guidance.

将占用大量CPU 和 i/o 的任务作为后台任务卸载Offload CPU-intensive and I/O-intensive tasks as background tasks. 如果某项服务请求预计需要较长时间才能运行完毕或需要使用大量的资源,则应将该请求的处理操作卸载到单独的任务中。If a request to a service is expected to take a long time to run or absorb considerable resources, offload the processing for this request to a separate task. 使用辅助角色或后台作业(具体取决于托管平台)来执行这些任务。Use worker roles or background jobs (depending on the hosting platform) to execute these tasks. 此策略使服务能够继续接收更多的请求并保持响应状态。This strategy enables the service to continue receiving further requests and remain responsive. 有关详细信息,请参阅后台作业指南For more information, see Background jobs guidance.

分发后台任务的工作负荷Distribute the workload for background tasks. 存在许多后台任务时,或者这些任务需要相当长的时间或相当多的资源时,可将这些工作分散到多个计算单元(例如辅助角色或后台作业)中。Where there are many background tasks, or the tasks require considerable time or resources, spread the work across multiple compute units (such as worker roles or background jobs). 如需一种可能的解决方案,请参阅使用者竞争模式For one possible solution, see the Competing Consumers pattern.

考虑转向无共享的体系结构Consider moving toward a shared-nothing architecture. 非共享体系结构使用独立的和自足的节点,这些节点不存在争用情况(例如共享服务或存储)。A shared-nothing architecture uses independent, self-sufficient nodes that have no single point of contention (such as shared services or storage). 从理论上讲,此类系统几乎可以无限地进行扩展。In theory, such a system can scale almost indefinitely. 虽然完全的非共享方法对于大多数应用程序来说并不实际,但这提供了一种思路,即如何进行设计才能获得更好的缩放性。While a fully shared-nothing approach is generally not practical for most applications, it may provide opportunities to design for better scalability. 例如,避免使用服务器端会话状态、客户端关联和数据分区,这是一个非常好的示例。For example, avoiding the use of server-side session state, client affinity, and data partitioning are good examples of moving toward a shared-nothing architecture.

数据管理Data management

使用数据分区Use data partitioning. 将数据划分到多个数据库和数据库服务器中,或者将应用程序设计为使用数据存储服务,而该服务能够以透明方式提供此分区功能(此类例子包括 Azure SQL 数据库弹性数据库和 Azure 表存储)。Divide the data across multiple databases and database servers, or design the application to use data storage services that can provide this partitioning transparently (examples include Azure SQL Database Elastic Database, and Azure Table storage). 这种方法可以使性能最大化,并使缩放更轻松。This approach can help to maximize performance and allow easier scaling. 存在各种不同的分区技术,例如水平分区、垂直分区和功能分区。There are different partitioning techniques, such as horizontal, vertical, and functional. 可以将这些技术组合起来使用,以便实现最佳效益,例如提高查询性能、简化缩放、提高管理的灵活性、提高可用性,以及使存储类型与所要存储的数据更匹配。You can use a combination of these to achieve maximum benefit from increased query performance, simpler scalability, more flexible management, better availability, and to match the type of store to the data it will hold. 另外,还需要根据不同类型的数据来使用不同类型的数据存储,而在选择存储类型时,还要看这些类型可以针对特定类型的数据优化到何种程度。Also, consider using different types of data store for different types of data, choosing the types based on how well they are optimized for the specific type of data. 例如,可以使用表存储、文档数据库或列系列的数据存储来代替关系数据库,或者在使用时像重视关系数据库一样重视这些数据库。This may include using table storage, a document database, or a column-family data store, instead of, or as well as, a relational database. 有关详细信息,请参阅数据分区指南For more information, see Data partitioning guidance.

在设计时需要考虑最终一致性Design for eventual consistency. 最终一致性可以改进缩放性能,因为在分区跨多个存储时它可以减少进行相关数据的同步所需的时间,或者根本不需要此方面的时间。Eventual consistency improves scalability by reducing or removing the time needed to synchronize related data partitioned across multiple stores. 代价是,数据在读取时并不是始终一致的,有时写入操作也会导致冲突。The cost is that data is not always consistent when it is read, and some write operations may cause conflicts. 在需要频繁读取相同的数据而不需要频繁写入这些数据的情况下,最终一致性是理想的标准。Eventual consistency is ideal for situations where the same data is read frequently but written infrequently. 有关详细信息,请参阅 Data Consistency Primer(数据一致性入门)。For more information, see the Data Consistency Primer.

减少组件和服务之间的聊天式交互Reduce chatty interactions between components and services. 避免设计交互功能,防止应用程序向服务进行多次调用(每次调用返回少量数据)而不是单次调用(一次调用返回所有数据)。Avoid designing interactions in which an application is required to make multiple calls to a service (each of which returns a small amount of data), rather than a single call that can return all of the data. 调用具有明显延迟的服务或组件时,尽可能将多个相关的操作组合到单个请求中。Where possible, combine several related operations into a single request when the call is to a service or component that has noticeable latency. 这可以更轻松地监视性能并优化复杂操作。This makes it easier to monitor performance and optimize complex operations. 例如,使用数据库中存储的过程来封装复杂的逻辑,减少往返次数和资源锁定次数。For example, use stored procedures in databases to encapsulate complex logic, and reduce the number of round trips and resource locking.

使用队列来平衡高速数据写入的负载Use queues to level the load for high velocity data writes. 对某项服务的需求激增可能会导致该服务不堪重负,引发越来越严重的故障。Surges in demand for a service can overwhelm that service and cause escalating failures. 为了防止这种情况,可考虑实施基于队列的负载均衡模式To prevent this, consider implementing the Queue-Based Load Leveling pattern. 使用队列在任务与所调用的服务之间充当缓冲。Use a queue that acts as a buffer between a task and a service that it invokes. 这可以平缓暂时性的超载,否则可能导致服务故障或任务超时。This can smooth intermittent heavy loads that may otherwise cause the service to fail or the task to time out.

最小化数据存储中的负载Minimize the load on the data store. 数据存储通常是处理瓶颈,也是一种昂贵的资源,并且通常不容易横向扩展。如果可能,请从数据存储中删除逻辑(如处理 XML 文档或 JSON 对象),并在应用程序中执行处理。The data store is commonly a processing bottleneck, a costly resource, and often not easy to scale out. Where possible, remove logic (such as processing XML documents or JSON objects) from the data store, and perform processing within the application. 例如,可以在应用程序层中对 XML 进行序列化或反序列化处理,然后将其以数据存储固有的形式进行传递,而不必将 XML 传递到数据库(不是作为用于存储的不透明字符串)。For example, instead of passing XML to the database (other than as an opaque string for storage), serialize or deserialize the XML within the application layer and pass it in a form that is native to the data store. 通常情况下,对应用程序进行向外缩放比对数据存储进行向外缩放要容易得多,因此应尽量在应用程序中进行计算密集型处理。It's typically much easier to scale out the application than the data store, so you should attempt to do as much of the compute-intensive processing as possible within the application.

最大程度减少检索的数据卷Minimize the volume of data retrieved. 仅检索你所需要的数据:指定各个列,并使用相关条件来选择行。Retrieve only the data you require by specifying columns and using criteria to select rows. 使用表值参数和适当的隔离级别。Make use of table value parameters and the appropriate isolation level. 使用实体标记等机制,以免检索不必要的数据。Use mechanisms like entity tags to avoid retrieving data unnecessarily.

充分利用缓存Aggressively use caching. 尽可能使用缓存,减少用于生成数据或交付数据的资源和服务的负载。Use caching wherever possible to reduce the load on resources and services that generate or deliver data. 缓存通常适用于相对静态的数据,或者需要进行充分处理才能获得的数据。Caching is typically suited to data that is relatively static, or that requires considerable processing to obtain. 在可能情况下,应在应用程序每个层级的所有级别进行缓存,包括在访问数据和生成用户界面时进行缓存。Caching should occur at all levels where appropriate in each layer of the application, including data access and user interface generation. 有关详细信息,请参阅缓存指南For more information, see the Caching Guidance.

处理数据增长和留存Handle data growth and retention. 随着时间的推移,应用程序所存储的数据量会逐渐增长。The amount of data stored by an application grows over time. 此增长会增加存储成本,并在访问数据时增加延迟,从而影响应用程序的吞吐量和性能。This growth increases storage costs as well as latency when accessing the data, affecting application throughput and performance. 可以定期将某些不再访问的旧数据存档,或者将很少被访问的数据移到更经济有效的长期存储中,即使后者的访问延迟较高。It may be possible to periodically archive some of the old data that is no longer accessed, or move data that is rarely accessed into long-term storage that is more cost efficient, even if the access latency is higher.

使用有效的二进制格式优化数据传输对象 (DTO)Optimize Data Transfer Objects (DTOs) using an efficient binary format. DTO 会在应用程序的各层之间传递很多次。DTOs are passed between the layers of an application many times. 最大程度地减小大小可以降低对资源和网络造成的负载压力。Minimizing the size reduces the load on resources and the network. 不过,在每个使用数据的位置将数据转换成所需格式时,需要对收益和开销进行权衡。However, balance the savings with the overhead of converting the data to the required format in each location where it is used. 采用一种互操作性最强的格式,方便组件的重复使用。Adopt a format that has the maximum interoperability to enable easy reuse of a component.

设置缓存控制Set cache control. 将应用程序设计和配置为尽可能使用输出缓存或片段缓存,以降低处理负载。Design and configure the application to use output caching or fragment caching where possible, to minimize processing load.

启用客户端缓存Enable client side caching. 对于能够缓存的内容,Web 应用程序应启用缓存设置。Web applications should enable cache settings on the content that can be cached. 通常情况下,将默认禁用此功能。This is commonly disabled by default. 将服务器配置为提供合适的缓存控制标头,以便在代理服务器和客户端上缓存内容。Configure the server to deliver the appropriate cache control headers to enable caching of content on proxy servers and clients.

使用 Azure Blob 存储和 Azure 内容分发网络减少应用程序上的负载Use Azure blob storage and the Azure Content Delivery Network to reduce the load on the application. 考虑在 Blob 存储中存储静态的或相对静态的公共内容,例如图像、资源、脚本和样式表。Consider storing static or relatively static public content, such as images, resources, scripts, and style sheets, in blob storage. 针对每个请求动态生成此类内容会导致应用程序超载,而此方法则可减轻应用程序的这种超载情况。This approach relieves the application of the load caused by dynamically generating this content for each request. 另外,请考虑使用内容分发网络来缓存此内容并将其传送到客户端。Additionally, consider using the Content Delivery Network to cache this content and deliver it to clients. 使用内容分发网络可以提高客户端的性能,因为内容是从地理位置最近且包含内容分发网络缓存的数据中心传递的。Using the Content Delivery Network can improve performance at the client because the content is delivered from the geographically closest datacenter that contains a Content Delivery Network cache. 有关详细信息,请参阅 内容分发网络指南For more information, see the Content Delivery Network Guidance.

优化和调整 SQL 查询和索引Optimize and tune SQL queries and indexes. 某些 T-sql 语句或构造可能会对性能产生负面影响,可以通过优化存储过程中的代码来降低性能。Some T-SQL statements or constructs may have an adverse effect on performance that can be reduced by optimizing the code in a stored procedure. 例如,应避免将 datetime 类型转换成 varchar 后又与 datetime 文本值进行比较。For example, avoid converting datetime types to a varchar before comparing with a datetime literal value. 应改用日期/时间比较函数。Use date/time comparison functions instead. 缺少合适的索引也会降低查询执行速度。Lack of appropriate indexes can also slow query execution. 如果使用对象/关系映射框架,则需了解其工作原理以及其可能会对数据访问层的性能造成何种影响。If you use an object/relational mapping framework, understand how it works and how it may affect performance of the data access layer. 有关详细信息,请参阅查询优化For more information, see Query Tuning.

请考虑非规范化数据Consider denormalizing data. 数据规范化有助于避免重复和不一致。Data normalization helps to avoid duplication and inconsistency. 但是,维护多个索引、检查引用完整性、对小块数据进行多次访问以及通过联接表来重组数据会造成各种开销,从而影响性能。However, maintaining multiple indexes, checking for referential integrity, performing multiple accesses to small chunks of data, and joining tables to reassemble the data imposes an overhead that can affect performance. 考虑是否可以增加存储容量并进行复制,以便降低对数据存储的负载压力。Consider if some additional storage volume and duplication is acceptable in order to reduce the load on the data store. 还应考虑是否依赖于应用程序本身(通常更易于缩放)来接管任务(如管理引用完整性)以降低数据存储的负载。Also consider if the application itself (which is typically easier to scale) can be relied on to take over tasks such as managing referential integrity in order to reduce the load on the data store. 有关详细信息,请参阅数据分区指南For more information, see Data partitioning guidance.


查看性能对立模式Review the performance antipatterns. 请参阅云应用程序的性能对立模式,了解在应用程序承受压力时,可能导致可伸缩性问题的常见做法。See Performance antipatterns for cloud applications for common practices that are likely to cause scalability problems when an application is under pressure.

使用异步调用Use asynchronous calls. 在访问可能会受 I/O 或网络带宽限制(或者存在明显延迟)的资源或服务时,尽可能使用异步代码,以免锁定调用线程。Use asynchronous code wherever possible when accessing resources or services that may be limited by I/O or network bandwidth, or that have a noticeable latency, in order to avoid locking the calling thread.

避免锁定资源,改用优化方法Avoid locking resources, and use an optimistic approach instead. 千万不要锁定具有明显延迟的资源(例如存储或其他服务)的访问权限,因为这是导致性能不佳的主要原因。Never lock access to resources such as storage or other services that have noticeable latency, because this is a primary cause of poor performance. 始终使用优化方法来管理并发操作(例如针对存储的写入)。Always use optimistic approaches to managing concurrent operations, such as writing to storage. 使用存储层的功能来管理冲突。Use features of the storage layer to manage conflicts. 在分布式应用程序中,数据可能要到最后才会一致。In distributed applications, data may be only eventually consistent.

将高延迟、低带宽网络上压缩性强的数据进行压缩Compress highly compressible data over high latency, low bandwidth networks. 在使用 Web 应用程序时,大多数情况下通过应用程序生成并通过网络传递的最大数据量来自对客户端请求的 HTTP 响应。In the majority of cases in a web application, the largest volume of data generated by the application and passed over the network is HTTP responses to client requests. HTTP 压缩可以大大减少此方面的数据量,尤其是对静态内容而言。HTTP compression can reduce this considerably, especially for static content. 这可以降低成本并减少网络的负载,虽然压缩动态内容会造成服务器上的负载部分过高。This can reduce cost as well as reducing the load on the network, though compressing dynamic content does apply a fractionally higher load on the server. 在其他更通用化的环境中,数据压缩可以降低传输的数据量,并且会最大程度地缩短传输时间和降低成本,但压缩及解压缩过程会造成开销。In other, more generalized environments, data compression can reduce the volume of data transmitted and minimize transfer time and costs, but the compression and decompression processes incur overhead. 因此,只有在性能会明显提高的情况下,才应使用压缩。As such, compression should only be used when there is a demonstrable gain in performance. 其他序列化方法(例如 JSON 或二进制编码)可以降低负载大小,同时对性能的影响较小,而 XML 则可能提高负载。Other serialization methods, such as JSON or binary encodings, may reduce the payload size while having less impact on performance, whereas XML is likely to increase it.

将使用连接和资源的时间尽可能降至最低Minimize the time that connections and resources are in use. 将连接和资源的维持时间降至所需的最低。Maintain connections and resources only for as long as you need to use them. 例如,尽可能晚地打开连接,并尽可能快地将其返回到连接池。For example, open connections as late as possible, and allow them to be returned to the connection pool as soon as possible. 尽可能晚地获取资源,并尽可能快地释放它们。Acquire resources as late as possible, and dispose of them as soon as possible.

最大程度减少所需的连接数Minimize the number of connections required. 服务连接会吸收资源。Service connections absorb resources. 限制所需的连接数,并确保尽可能重用现有连接。Limit the number that are required and ensure that existing connections are reused whenever possible. 例如,执行身份验证后可根据需要使用模拟,以便以特定身份来运行代码。For example, after performing authentication, use impersonation where appropriate to run code as a specific identity. 这种方式可以重用连接,从而充分利用连接池。This can help to make best use of the connection pool by reusing connections.


某些服务的 API 会自动重用连接,前提是遵循了特定于服务的原则。APIs for some services automatically reuse connections, provided service-specific guidelines are followed. 需要了解在什么情况下可以重用应用程序所使用的每项服务的连接,这一点很重要。It's important that you understand the conditions that enable connection reuse for each service that your application uses.

成批发送请求以优化网络使用情况Send requests in batches to optimize network use. 例如,在访问队列时成批发送和读取消息,在访问存储或缓存时成批执行多个读取或写入操作。For example, send and read messages in batches when accessing a queue, and perform multiple reads or writes as a batch when accessing storage or a cache. 这可以降低经过网络进行的调用的数目,从而最大程度地提高服务和数据存储的效率。This can help to maximize efficiency of the services and data stores by reducing the number of calls across the network.

尽可能不要求存储服务器端会话状态Avoid a requirement to store server-side session state where possible. 服务器端会话状态管理通常要求客户端关联(即,将每个请求路由到相同的服务器实例),这会影响系统的缩放能力。Server-side session state management typically requires client affinity (that is, routing each request to the same server instance), which affects the ability of the system to scale. 理想情况下,应该将客户端设计成相对于其所使用的服务器来说无状态。Ideally, you should design clients to be stateless with respect to the servers that they use. 但是,如果应用程序必须保留会话状态,则可将敏感数据或每个客户端的大量数据存储在分布式服务器端缓存中,以便应用程序的所有实例都可以访问该缓存。However, if the application must maintain session state, store sensitive data or large volumes of per-client data in a distributed server-side cache that all instances of the application can access.

优化表存储架构Optimize table storage schemas. 在使用表存储(例如 Azure 表存储,该存储要求每次查询都传递和处理表和列的名称)时,可考虑使用较短的名称以减少此开销。When using table stores that require the table and column names to be passed and processed with every query, such as Azure table storage, consider using shorter names to reduce this overhead. 不过,请不要使用过度精简的名称,否则会影响可读性或可管理性。However, do not sacrifice readability or manageability by using overly compact names.

在部署过程中或在应用程序启动时创建资源依赖关系Create resource dependencies during deployment or at application startup. 如果方法在调用时需要测试资源的存在,在资源不存在时会创建该资源,则应避免调用此类方法。Avoid repeated calls to methods that test the existence of a resource and then create the resource if it does not exist. 例如,Azure 存储客户端库中的 CloudTable.CreateIfNotExistsCloudQueue.CreateIfNotExists 方法均遵循此模式。Methods such as CloudTable.CreateIfNotExists and CloudQueue.CreateIfNotExists in the Azure Storage Client Library follow this pattern. 如果在每次访问存储表或存储队列之前都调用这些方法,则可能会产生相当大的开销。These methods can impose considerable overhead if they are invoked before each access to a storage table or storage queue. 应该:Instead:

  • 在部署应用程序时或第一次启动时创建所需的资源(在 Web 或辅助角色的启动代码中针对每项资源调用一次 CreateIfNotExists 是可以接受的)。Create the required resources when the application is deployed, or when it first starts (a single call to CreateIfNotExists for each resource in the startup code for a web or worker role is acceptable). 不过,如果代码尝试访问不存在的资源,则必须处理可能会引发的异常。However, be sure to handle exceptions that may arise if your code attempts to access a resource that doesn't exist. 遇到此类情况时,你应该记录异常,并尽可能提醒操作员某项资源缺失。In these situations, you should log the exception, and possibly alert an operator that a resource is missing.
  • 在某些情况下,可以通过异常处理代码来创建缺失的资源。Under some circumstances, it may be appropriate to create the missing resource as part of the exception handling code. 但这种方法应谨慎使用,因为该资源不存在可能意味着存在编程错误(例如,资源名称拼写错误),或者存在基础结构级的问题。But you should adopt this approach with caution as the non-existence of the resource might be indicative of a programming error (a misspelled resource name for example), or some other infrastructure-level issue.

使用轻型框架Use lightweight frameworks. 在使用 API 和框架来尽量降低资源使用率、缩短执行时间以及减轻应用程序的总体负载压力时,请仔细选择 API 和框架。Carefully choose the APIs and frameworks you use to minimize resource usage, execution time, and overall load on the application. 例如,使用 Web API 来处理服务请求可以减少应用程序占用的空间并提高执行速度,但可能不适合需要额外 Windows Communication Foundation 功能的高级方案。For example, using Web API to handle service requests can reduce the application footprint and increase execution speed, but it may not be suitable for advanced scenarios where the additional capabilities of Windows Communication Foundation are required.

考虑尽量减少服务帐户数Consider minimizing the number of service accounts. 例如,可以使用特定的帐户来访问对连接有限制(或在所维持的连接数较少的情况下性能更佳)的资源或服务。For example, use a specific account to access resources or services that impose a limit on connections, or perform better where fewer connections are maintained. 此方法常用于数据库之类的服务,但可能会影响相关功能,导致无法准确地审核操作(如果对原始用户进行了模拟)。This approach is common for services such as databases, but it can affect the ability to accurately audit operations due to the impersonation of the original user.

进行性能分析和负载测试(可以在开发过程中、测试例程中以及最终发布之前进行),确保应用程序的性能和缩放符合需要。Carry out performance profiling and load testing during development, as part of test routines, and before final release to ensure the application performs and scales as required. 此测试应在与生产平台同类的硬件上进行,其数据和用户负载的类型和数量也应与在生产环境中会遇到的情况相同。This testing should occur on the same type of hardware as the production platform, and with the same types and quantities of data and user load as it will encounter in production. 有关详细信息,请参阅 Testing the performance of a cloud service(测试云服务的性能)。For more information, see Testing the performance of a cloud service.