`

为性能和可伸缩性做架构和设计上的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.
与其用可变参数,更喜欢用重载方法。

 

原文:http://hi.baidu.com/ilovehaley/blog/item/db92c382151312ae0df4d23c.html

分享到:
评论

相关推荐

    分布式系统可伸缩性研究综述_陈斌.pdf

    陈斌等人的综述为我们提供了分布式系统可伸缩性研究的全貌,从理论到实践,从传统方法到新兴技术,都做了详尽的分析和探讨。对于那些致力于构建高效、灵活、具有高可伸缩性的分布式系统的工程师而言,这些知识和指导...

    数据访问宝典-实现最优性能可伸缩性的数据库应用程序

    资源名称:数据访问宝典-实现最优性能可伸缩性的数据库应用程序内容简介:在当今的企业数据库应用程序中,性能和可伸缩性比过去任何时候更为关键,传统的数据库调整对于解决可能在这些应用程序中遇到的性能问题有些...

    深入比较MySQL与Oracle:性能、可伸缩性与最佳实践

    在数据库管理系统(DBMS)领域,MySQL和Oracle是两个备受瞩目的选择。它们各自具有独特的特点和优势,适用于不同的应用场景。...通过合理的优化和配置,两者都可以为特定的应用场景提供出色的性能和可伸缩性。

    架构风格和基于网络的软件架构设计

    软件架构设计是信息技术领域中的一个重要议题,它不仅影响软件系统的构建和维护,也影响整个系统的质量属性,如性能、可伸缩性和可靠性等。架构风格是指在软件架构设计中形成的一组共同的设计模式和解决方案,它们对...

    可伸缩服务架构:框架与中间件 第一部分

    《可伸缩服务架构:框架与中间件》以高可用服务架构为主题,侧重于讲解高可用架构设计的核心要点:可伸缩和可扩展,从应用层、数据库、缓存、消息队列、大数据查询系统、分布式定时任务调度系统、微服务等层面详细...

    开发者最佳实践日-高可用和可伸缩架构

    通过以上分析,我们可以看到,无论是提高系统的高可用性还是增强其可伸缩性,都需要从多个层面出发,综合考虑各种因素和技术方案。此外,实践中还需要不断地测试和优化,以确保系统能够在各种场景下稳定运行。

    windows可伸缩性范例

    在IT领域,尤其是在系统管理和架构设计中,"可伸缩性"是一个至关重要的概念。Windows操作系统作为广泛应用的桌面和服务器平台,同样面临着如何提供高效、灵活的可伸缩性解决方案的挑战。本篇将深入探讨"Windows可...

    《可伸缩服务架构框架与中间件》源码.zip

    本书以高可用服务架构为主题,侧重于讲解高可用架构设计的核心要点: 可伸缩和可扩展,从应用层、数据库、缓存、消息队列、大数据查询系统、分布式定时任务调度系统、微服务等层面详细讲解如何设计可伸缩、可扩展的...

    可伸缩服务架构:框架与中间件 第二部分

    《可伸缩服务架构:框架与中间件》以高可用服务架构为主题,侧重于讲解高可用架构设计的核心要点:可伸缩和可扩展,从应用层、数据库、缓存、消息队列、大数据查询系统、分布式定时任务调度系统、微服务等层面详细...

    分布式系统可伸缩性研究综述.pdf

    综上所述,可伸缩性是分布式系统设计的核心问题之一,它直接关系到系统的性能、可靠性和经济性。设计一个高度可伸缩的分布式系统需要深入理解可伸缩性的定义和度量方法,并采用有效的技术手段来实现动态资源管理。...

    源码-可伸缩服务架构-框架与中间件.zip

    在IT行业中,构建可伸缩的服务架构是现代企业级应用的关键。"源码-可伸缩服务架构-框架与中间件.zip"这个压缩包显然包含...通过研究这些源码和框架,不仅可以提升技术能力,还能为实际项目中的架构设计提供参考和灵感。

    淘宝网高性能可伸缩架构技术探秘

    总结来说,淘宝网的高性能可伸缩架构通过实现应用无状态、充分利用缓存和智能应用拆分,确保了系统的高可用性和可扩展性,适应了大规模电商系统的需求。这些技术对于其他大型互联网企业也有很高的参考价值。

    高并发高可用的可伸缩的架构设计的原则

    综上所述,高并发高可用的可伸缩架构设计涉及到多个层面的技术和策略,包括数据与计算的分离、多维度的可用性设计、合理的资源管理和优化、以及灵活的伸缩拆分等。通过综合运用这些技术和策略,可以构建出稳定可靠且...

    产品技术开发项目-软件架构设计模板

    本文档旨在为产品经理、项目经理、系统工程师、架构师及软件开发人员提供一个清晰、全面的软件架构设计模板,以帮助他们理解和执行项目的架构设计,确保后续开发工作的顺利进行,并为网站后续版本的架构提供参考。...

    架构文章集合,搜索引擎,系统可伸缩性

    这些文档涵盖了广泛的IT架构主题,特别是集中在搜索引擎技术和系统可伸缩性的实现上。让我们逐一探讨这些文件所代表的知识点。 1. **大型网站架构演变和知识体系**:这个文档可能详细介绍了互联网公司如何随着用户...

Global site tag (gtag.js) - Google Analytics