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. 着眼于全局
— 正如这篇文章内，各位与会者反复强调的一样，监控，全面的监控对互联网系统是非常重要的，我们必须发现潜在的火苗，必须比用户更早的发现问题…