可伸缩行最佳实践：来自 eBay 的经验
by Randy Shoup
1.按功能分割
不相关的功能之间耦合度越松散，就越能灵活地独立伸缩其中的一部分
在数据库层面上，eBay 没有无所不包的单一数据库，而是采取一组数据库主机放用户数据、一组放商品数据、一组存放购买数据……1000 多个逻辑数据库分布在 400 台物理主机上。
2.水平分割
在应用层面上，eBay 将各种交互都设计成无状态的，所以水平分割是轻而易举之事。用标准的负载均衡服务器来路由进入的流量，所有的应用服务器都是均等的，任何服务器都不会维持事务性的状态，负载均衡可以选择应用服务器。处理能力可以水平扩展。
数据库层面的问题在水平分割方面比较有挑战，因为数据天生就是有状态的。而总的思想是支持数据分割及重分割的基础设施在可伸缩性上远比不支持的优越。
3.避免分布式事务
广为人知的答案是：建立跨资源的分布式事务，用两段式提交来保证“要么所有者资源全部更新，要么全都不更新”。这种方案的成本很可观，伸缩、性能和响应延迟都受到协调成本的方面影响，随着资源数量和客户数量的上升，这些指标都会以几何级数恶化。实用主义的答案是：对于不相关的系统，放宽对它们的跨系统事务的保证。保证多个系统或分区之间的即时的一致性，通常既无必要，也不现实。
Inktomi 的 Eric Brewer：
分布式系统三项重要指标，即一致性(Consistency)、可用性(Availability)、分区耐受性(Partition-tolerance)，在任意时刻，只有两项能同时成立。
对于高流量的网站，必须选择分区耐受性。而 7*24 运行的网站选择可用性也是理所应当的。所以，要根据实际的业务来量体裁衣。
4.用异步策略解耦程序
提高可伸缩性的另一项关键措施就是积极采取异步策略。降低组件之间的同步调用的紧耦合，因为紧耦合的系统的可伸缩性是各部分必须共进共退的。组件之间应该尽量避免同步代码的耦合，将系统间、系统内部的组件异步地连接起来是实现伸缩的关键。
5.将过程转变为异步的流
用异步的原则解耦程序，尽可能将过程变为异步的。对于要求快速响应的系统，这样做可以从根本上减少请求者所经历的响应延迟。任何可以晚点再做的事情都应该晚点再做。
还有一个同等重要的方面能认识到的人不多：异步性可以从根本上降低基础设施的成本。同步地执行操作箔是你必须按照负载的峰值来配备基础设施——即使任务最重的那一秒，设施也必须有能力立即完成处理。而对于异步的流来说，基础设施就不需要按照峰值来配备，只需要满足平均负载，异步队列可以将处理任务分摊到较长的时间里，从而起到削峰的作用。系统的负载变化越大，曲线越多尖峰，就越能从异步处理中获益。
6.虚拟化所有层次
虚拟化和抽象化无所不在，有句老话；所有问题都可以通过增加一个间接层次来解决。操作系统是对硬件的抽象，现代语言的虚拟机又是对操作系统的抽象。
应用与逻辑数据库交互，逻辑数据库再按照配置映射到特定的物理机器和数据库实例。路由逻辑会把特定的记录分配到指定的分区。这样子方便物理主机上重新分配逻辑主机——分离、合并、移动，而完全不需要接触应用程序代码。
搜索引擎同样是虚拟化的。聚合器组件会从多个分区上执行并行的查询，但这个高度分割的搜索网格在用户看来只是单一的逻辑索引。
虚拟化使基础设施的伸缩成为可能，因为它使伸缩变成可管理的。
7.适当地使用缓存
对于缓存，说到底，要在存储约束、可用性的需求、对陈旧数据的容忍层度等条件下最大化缓存的命中率，这是一个高效的缓存系统的最重目标。经验证明，要平衡众多因素是极其困难的，即使暂时达到的目标，情况也极可能随着时间而改变。
最适合缓存的是很少改变、以读为主的数据，比如元数据、配置信息和静态数据。不缓存会话数据、应用层缓存共享业务对象，能够换取可用性和正确性。
缓存是个好东西，但是缓存分配的内存越多，用来服务单个请求的内存越少。应用层常常有内存不足的压力，这点需要权衡。不要太依赖缓存，离不开缓存就糟糕了。比如重新配置缓存资源、把缓存移动到别的机器、冷启动缓存服务器，都有可能引发严重的问题。
总结
可伸缩性是功能的先决条件，是优先级为 0 的需求，比一切需求的优先级都要高。
五年 Skype 架构师之路的感言
by Andres Kutt
技术方面
在技术方面，经验法则不使用。总有一些新的模式慢慢出现，而就的东西慢慢淘汰。往往这些是由技术能力的突破产生的。
所有的技术变化来源于功能上的变化。相当多的架构师没有仔细考量技术变化，结果导致混乱。
简单的东西是强大的。任何需要超过三句话来解释给其他人听的事情，都不会实际有效地工作。制定架构需要根据业务功能而定，同时设计应该趋向于简单化。
技术技能是架构师的必备条件。技术技能能够获取这个职位，情商和理解组织业务的能力决定了你有多优秀。
潘磊谈阿里巴巴国际展发展历程
数据库的拆分分为水平和垂直拆分。
全球业务需要考虑到跨洲际的部署问题。
所有的网站设计都应该从业务的角度出发，不能纯粹去追求完美的技术目标；其次，要尽量选择一些业界比较成熟的技术作为自己的基础架构。
架构的事情不能纯粹地看作一个技术的事情，因为一个好的系统如果没有业务系统去配合，是很难成长或者演化成一个相对完善的系统的。
所以，架构师首先要熟悉业务，甚至要擅长做一些系统业务的建模；其次，业务和技术的关系就是一个成本和收益的问题，业务是我们的收益，技术就是我们的成本，应该从两个方面去充分评估，来决定用什么样的技术解决问题。
涉及到技术选型时，第一件事要明确目标，要知道我们要什么(包括业务需求、非功能需求等)。
成为一名架构师，要对技术有很强的意愿，其次是要善于学习、交流。同样，业务分析也是架构师很重要的一个方面。
- JavaScript 的强大就在于它的原型机制。
- 服务器的并发控制是很重要的一块。
- 前端快速响应用户需求，后端提供持续稳定的服务。 通过 SOA 实现真正的业务敏捷。
- 对业务的理解是很多技术架构师所忽视的地方，理解了业务需求才能让技术更好地发挥作用。
- 架构师要统筹全局。根据当前实际的业务设计架构，同时需要放眼未来，在 1.0 的时候考虑到 2.0 或者更长期的架构演变。这需要架构师平衡投资与风险之间的关系，以适当的风险来换取最大的利益。
- 创业公司最大的优势就在于没有历史。开发、运维喝业务一块推动企业文化的发展。
- 负载均衡，可以在发布时派上用场。
Scrum 敏捷团队的必备技能
- 建立设置开发环境的相关文档，避免在设置环境缓解浪费时间。
- 使用自动构建，避免手工构建。
- 持续集成，尽早识别出集成的错误，就能越快地解决这些问题。
- 单元测试。确保昨日可以运行的东西今天也能运行。
- 重构。重构的本质归结为修改代码以改善代码的结构和清晰度，但不改变代码的功能。
End by Robin on February 08, 2017 at Office, a fine morning!