为性能和可伸缩性做架构和设计上的Review
简介：上次翻译了ADO.NET在性能和可伸缩性上的CheckList，这次翻译在架构和设计上做性能和可伸缩性的Review需要注意哪些技术点和考察点，有些地方翻译的可能不对，请大家指教。
可能翻译有误或者理解不对的地方，我用红色标注出来，大家可在评论中进行指正和讨论，我最后会更新到列表中去，谢谢。
部署和体系结构
Use distributed architectures appropriately. Do not introduce distribution unnecessarily.
适当的使用分布式架构，不要在不必要的时候使用分布式（译注：这个不好把握，主要靠经验，或者讲一些具体例子大家更容易明白）。
Carefully select appropriate distributed communication mechanisms.
仔细小心的选择适当的分布式通信机制（译注：综合考虑性能，安全，兼容性等来选择用socket开发协议，还是用现成的wcf,remoting,web service,web api等）。
Locate components that interact frequently within the same boundary or as close to each other as possible.
频繁交互的组件应在相同的边界内或者尽可能的接近。（译注：翻译的有些拗口，不明白具体意思，风行说可能就是就近原则）。
Take infrastructure restrictions into account in your design.
在设计中，把基础架构的限制考虑在内。（译注：比较抽象，不懂）。
Consider network bandwidth restrictions.
考虑网络带宽的限制。
Identify resource restrictions.
明确资源的限制。
Ensure your design does not prevent you from scaling up.
确保你的设计不会阻止你的横向扩容（scaling up）。
Ensure your design does not prevent you from scaling out and it uses logical layers, does not unwittingly introduce affinity, and supports load balancing.
确保你的设计不会阻止你的纵向扩容（scaling out），并且他使用业务逻辑层，不无意中引入近亲（译注：翻译可能不对，不懂啥意思），并且支持负载均衡。（译注：不同的应用可能会有不同的负载策略，源IP负载，还是按流量负载，还是7层负载，适用于不同的场合。）
耦合性和内聚性
Ensure your design is loosely coupled.
确保你的设计是松散耦合。
Exhibit appropriate degrees of cohesion in your design and group together logically related entities, such as classes and methods.
在你的设计里显示出适当的内聚性，组合逻辑相关的实体，如类和方法（译注： group together不知道咋翻译）。
Restrict use of late binding and only use late binding where it is necessary and appropriate.
避免使用晚期绑定，并且只在必要和适当的时候使用晚期绑定（译注：晚期绑定只在vb,asp等语言才有吧，这个不是说用就能用的吧，晚期绑定是一种运行时的行为，所以可能会损耗应用的运行性能）。
通信
Interfaces do not enforce chatty communication.
接口不要定义一些无关的通讯（译注：这句不会翻译）。
Ensure your application only makes remote calls where necessary. Impact is minimized by client-side validation, client-side caching, and batching of work.
确保你的应用只在必要的时候使用远程调用，通过客户端验证，缓存和批量作业最小化不利影响。
Optimize remote data exchange.
优化远程数据交换（译注：不同具体做法）。
Choose appropriate secure communication mechanisms.
选择适当的安全通信机制。
Use message queues to decouple component parts of your system.
通过消息队列解耦你系统的一部分（译注：component parts不知道指什么）。
Mitigate the impact of long-running calls by using message queues, "fire-and forget" approaches, and asynchronous method calls.
使用消息队列减少长时间运行的调用的影响，忘记进接近的，一步的方法调用（译注：后半句可能理解的有问题）。
Do not use processes where application domains are more appropriate.
在应用程序域更合适的情况下不要使用进程（译注：创建进程比创建应用程序域开销大）。
并发
In your application do not create threads on a per-request basis, and use the common language runtime (CLR) thread pool instead.
在你的应用里不要为每个基本的请求创建线程，用CLR里的线程池代替这种做法（译注：觉得CLR的线程池不适用的情况可以自己实现线程池）。
Only types that need to be thread-safe are made thread-safe.
只把那些需要线程安全的类标识为线程安全的（译注：让一个方法线程安全需要编码实现，不知道这里的types是啥意思，是动词还是名字）。
Carefully consider lock granularity..
仔细考虑锁的粒度（译注：不是锁的粒度越小越好，太小的话会增加代码复杂度）。
Ensure your application acquires shared resources and locks late and releases them early to reduce contention.
确保你的应用获取共享资源和锁尽量的晚并且尽量早的释放他们以减少争用。
Choose appropriate synchronization primitives.
选择恰当的同步基元（译注：可能是信号量，临界区，互斥体等）。
Choose an appropriate transaction isolation level.
选择恰当的事务隔离级别。
Ensure your application uses asynchronous execution for I/O bound tasks and not for CPU bound tasks.
确保让你的应用为I/O密集任务使用异步执行，而CPU密集任务就不用异步执行了（译注：有时候计算密集任务也需要异步执行以让当前线程执行其它更重要的任务，这个往往和业务逻辑有关）。
资源管理
Ensure your design supports and makes effective use of pooling.
确保你的设计支持并有效的利用pooling（译注：不太理解资源管理里啥是pooling）。
Ensure your application acquires resources late and releases them early.
确保你的应用尽量晚的请求获取资源并尽量早的释放他们。
缓存
Use caching for data that is expensive to retrieve, compute, and render.
为那些获取、计算和呈现比较昂贵的数据使用缓存（译注：render不知道咋翻译，有些获取比较昂贵，但要求比较实施的数据可能也不能缓存，但如果并发请求量大的话，你可以缓存一秒，也会很大提高性能的，或者更新数据的时候同时更新缓存）。
Cache appropriate data such as relatively static Web pages, specific items of output data, stored procedure parameters, and query results.
缓存适当的数据，如相对静态的网页，明确的输出数据的条目，存储过程参数和查询结果集等。
Do not use caching for data that is too volatile.
不要缓存那些不太稳定的数据。
Select an appropriate cache location.
选择一个适当的缓存存取位置（译注：缓存除了保存在内存上，还能保存在磁盘上，甚至是其它机器的内存上，如分布式缓存）。
Select an appropriate cache expiration policy.
选择一个适当的缓存过期策略。
状态管理
Your design favors stateless components. Or, you considered the negative impact on scalability if you decided to use stateful components.
你的设计应更倾向于无状态组件，或者如果你考虑了在可扩展性上的负面影响，如果你决定使用状态化组件（译注：有状态组件在扩容的时候确实比无状态组件影响大，一般有状态组件要用哈希、7层负载或者源IP负载，无状态组件用按流量负载就行了，前者耗费性能大而且容易出现负载不均的情况。关于如何避免有状态组件是个大话题，回头总结下经验和大家分享）。
If you use Microsoft? .NET Framework remoting and need to support load balancing, you use single call server-activated objects (SAO).
如果你使用微软的.NET Remoting并且需要支持负载均衡，你要用single call的服务端激活（SAO）（译注：single call的服务端激活Remoting对象，为每个客户端调用创建新的服务端对象，不使用这种方式的话，很可能多次调用使用同一个远程对象，造成负载不均，个人理解）。
If you use Web services, you also use a message-based stateless programming model.
如果你使用了web服务，你同样需要使用基于消息的尽量无状态的编程模型（译注：webservice也可以为有状态的）。
If you use Enterprise Services, also use stateless components to facilitate object pooling.
如果你使用Enterprise Services，也需要用尽量无状态的组件以便让池化对象更容易。
Objects that you want to store in state stores support serialization.
那些要保存到状态的对象需要支持序列化（译注：因为状态可能要在各层传输）。
Consider the performance impact of view state.
考虑ViewState对性能的不良影响（译注：ViewState是asp.net的一种维护页面状态的机制，如果不要可以关闭它，可以在不同级别上关闭，如整个应用，某个页面，甚至某个控件）。
Use statistics relating to the number of concurrent sessions and average session data per user to help choose an appropriate session state store.
根据并发Session相关的统计数据和平均Session的数据量去选择一个合适的Session存储模式（译注：可自己实现，可在本进程，sqlserver或某台机器的SessionState服务）。
数据结构和算法
Ensure your design uses appropriate data structures.
确保你的设计使用合适的数据结构（译注：这个可能不太好把握，要对比能解决同一问题的不同数据结构的方方面面）。
Use custom collections only where absolutely necessary.
只在绝对必要的时候使用自定义的集合（译注：.NET自带有很多集合类，字典，链表，列表等）。
Extend the IEnumerable interface for your custom collections.
如果你需要实现自己的集合请实现IEnumerable接口。
数据访问
Pass data across the layers by using the most appropriate data format. Carefully consider the performance implications.
使用最合适的数据格式在多层之间传递数据，仔细考虑对性能的影响（译注：比如为了减轻流量，对数据压缩，在对端肯定解压缩的时候要耗费性能，要权衡好）。
Use stored procedures with the Parameters collection for data access.
为数据访问使用参数化集合的存储过程。
Only process the data that is required.
只处理那些你需要的数据。
Where appropriate, provide data paging solutions for large result sets.
在适当的时候，为大结果数据集提供分页解决方案。
Use Enterprise Services declarative transactions for transactions that span multiple resource managers or where you need to flow transaction context across components.
为跨越多个资源管理者的事务或者当你需要在多个组件间流动事务上下文的时候使用企业服务来declarative事务（译注：declarative不知道咋理解）。
If you manipulate binary large objects (BLOBs), use appropriate chunking techniques, and do not repeatedly move the same BLOB.
如果你要控制二进制大对象(BLOBs)，使用恰当的chunking技术，不要重复的移动相同的二进制大对象。
Consolidate repeated data access code into helper classes.
把重复的数据访问代码放到帮助类里（译注：Consolidate不知道咋翻译，整句话的意思可能是使用统一的数据存取代码，不要到处写重复的数据访问代码）。
异常处理
Do not use exceptions to control regular application flow.
不要使用异常控制应用的逻辑流程（译注：有时候自定义异常可以控制一些业务流程，个人感觉）。
Use well-defined exception handling boundaries.
采用良好定义的异常处理边界（译注：不理解，有人说异常处理边界似乎try{}大括号里面的部分）。
Structured exception handling is the preferred error handling mechanism. Do not rely on error codes.
结构化异常处理是更好的错误处理机制，不要依赖错误码（译注：有些异常类型也有错误码属性，如SocketException）。
Only catch exceptions for a specific reason and when it is required.
只捕获那些需要捕获并且有具体原因的异常。
类设计上的考虑
Classes own the data that they act upon.
类拥有它们操作的数据（译注：有些帮助类可能不维护数据，如静态类）。
Do not use explicit interfaces unnecessarily. Use explicit interfaces for versioning and for polymorphism where you have common functionality across multiple classes.
不要不必要的使用具体的接口，在你版本化或多态化跨越多个类的共同功能的时候需要时候使用具体的接口（译注：后半句太长，翻译的可能不对，explicit不知道这里咋翻译，versioning和polymorphism翻译的也不知道对不对）。
Classes do not contain virtual methods when they are not needed.
类在不必要的时候不要包含虚方法。
Prefer overloaded methods to methods that take variable parameters.
与其用可变参数，更喜欢用重载方法。