Hunter的大杂烩

October 23, 2008

可伸缩性原则

Filed under: 架构 — hunter @ 11:03 pm

from: http://www.infoq.com/cn/articles/scalability-principles

来自Simon Brown的笔记:

1. 减少处理时间

    并置(含义):将相关数据放到一起

    缓存

    池化

    并行化

    分区处理

    远程处理:

          减少访问远程服务所花费的时间,比如可以通过更粗粒度地划分接口。远程还是本地是明确的设计决策,不能随意来回更动,这一点应当牢记。还要考虑分布式计算的第一准则——不要分布你的对象

            ^^^^^^^^^难难难,如何平衡,还在探索中 

          …尤其是在每层的数据表示之间都需要转换的情况下…

                                       ^^^^^^^^^^^^PO 2 DO ?

          …对于我们视为理所当然的运行时服务,有必要理解其成本,因为除非它们提供了特定的服务水平协议,否则很有可能最终会成为应用中的瓶颈…

2. 分区

    — SNA架构中,认为更小的数据单元可以更大的提升系统的性能…如果你的数据全部内存化了,那么单个数据单元的吞吐量就是你的网卡吞吐量…

3. 可伸缩性在于并发

    • 如果你确实需要持有锁(比如本地对象、数据库对象等),试着尽可能短地持有它们。
    • 设法减少对共享资源的争用,并尽可能是争用避开关键处理路径(比如通过异步调度工作)。
    • 任何针对并发的设计都需要预先完成,以便能被充分地理解哪些资源可以被安全共享、哪里可能会是潜在的可伸缩性瓶颈。  

         — 用SEDA架构,每个处理单元都异步化,减少单元中同步等待的session数,也可以低成本增加并发性,只是会增加代码的复杂性

    4. 必须知道需求

      • 目标平均性能和峰值性能(即响应时间、延迟等)。
      • 目标平均负荷和峰值负荷(即并发用户、信息量等)。
      • 性能和可伸缩性可接受的极限。  

            — 值得学习。系统小的时候,可能业务导向会多一些,系统大了之后,每个业务研发都需要把技术优化时间计算进去

            — 设计的时候,需要估算业务模块未来增长趋势

      5. 持续测试

          …应当从项目一开始就收集和审核这些证据,此后也要一直继续…

           ^^^^^让我想到另外一篇文章,来自eBay的兄弟说:“所有项目都经过了严格的负载和性能测试”,而Matt则说:“不要试图在部署之前就捕获性能问题。你不可能重建真实环境中的条件,因此你不可能得到真实可靠的测量结果”…

           — 个人比较倾向后者,所以我们要灰度发布,facebook甚至在页面里面挂上一个隐藏的form来测试他们的chat项目

      6. 架构先行

           — 不过度设计,不代表不预留扩展的接口,一些针对分布式系统的设计原则必须在整个系统刚开始研发的时候,就落实下去。

           — 比如不要跨领域执行事务,不要在sql中hardcode table name等;

      7. 着眼于全局

           — 正如这篇文章内,各位与会者反复强调的一样,监控,全面的监控对互联网系统是非常重要的,我们必须发现潜在的火苗,必须比用户更早的发现问题…

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress