Elastisys 云平台诞生于瑞典默奥大学的分布式系统研究小组。它由一组以预测性扩展引擎为中心的工具组成，可以自动扩展云部署。近日，其官方网站发表了一篇文章，介绍他们在高可扩展分布式应用程序设计和开发方面的经验。
他们将可扩展性分成了如下四个维度：
- 性能可扩展：性能无法完全实现线性扩展，但要尽量使用具有并发性和异步性的组件。具备完成通知功能的工作队列要优于同步连接到数据库。
- 可用性可扩展： CAP 理论表明，分布式系统无法同时提供一致性、可用性和分区容错性保证。许多大规模 Web 应用程序都为了可用性和分区容错性而牺牲了强一致性，而后者则有赖于最终一致性来保证。
- 维护可扩展：软件和服务器都需要维护。在使用平台 & 工具监控和更新应用程序时，要尽可能地自动化。
- 成本可扩展：总拥有成本包括开发、维护和运营支出。在设计一个系统时，要在重用现有组件和完全新开发组件之间进行权衡。现有组件很少能完全满足需求，但修改现有组件的成本还是可能低于开发一个完全不同的方案。另外，使用符合行业标准的技术使组织更容易聘到专家，而发布独有的开源方案则可能帮助组织从社区中挖掘人才。
以上各项，他们在设计应用程序时都会考虑和权衡。下面是他们根据上述内容总结出的 10 个设计原则：
- 避免单点故障：任何东西都要有两个。这增加了成本和复杂度，但却能在可用性和负载性能上获益。而且，这有助于设计者采用一种分布式优先的思维。
- 横向扩展，而不是纵向扩展：升级服务器（纵向）的成本是指数增长的，而增加另一台商用服务器（横向）的成本是线性增长的。
- 尽量减少应用程序核心所需要完成的工作。
- API 优先：将应用程序视为一个提供 API 的服务，而且，不假定服务的客户端类型（手机应用、Web 站点、桌面应用程序）。
- 总是缓存。
- 提供尽可能新的数据：用户可能不需要立即看到最新的数据，最终一致性可以带来更高的可用性。
- 设计时要考虑维护和自动化：不要低估应用程序维护所需要的时间和工作量。软件首次公开发布是一个值得称赞的里程碑，但也标志着真正的工作要开始了。
- 宁异步，不同步。
- 努力实现无状态：状态信息要保存在尽可能少的地方，而且要保存在专门设计的组件中。
- 为故障做好准备：将故障对终端用户的影响最小化。
关于分布式系统的设计，InfoQ 曾有过一些报道（ 1 , 2 ），感兴趣的读者可以对照阅读。
感谢郭蕾对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群
）。
暂无签名
最新发布
Quora 文本语境演进分析
2015-12-21
使用 API 网关构建微服务
2015-07-21
Oracle 专家谈 MySQL Cluster 如何支持 200M 的 QPS
2015-07-02
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
大模型在华为推荐场景中的探索和应用
QCon 大会内容策划思路
高性能 Kubernetes 元数据存储 KubeBrain 的设计思路和落地效果
评论