架构干货：来听听架构大师 Martin Abbott 怎么说

2017 年 9 月 27 日 数据挖掘入门与实战 Boolan博览网

SA-Summit 2017全球软件架构技术大会

10月26-27日 · 上海

大会邀请到来自世界级软件架构大师 & eBay 前首席技术官 Martin Abbott，Facebook 工程经理、Uber 实时流处理系统主管、Airbnb 资深工程师、Pinterest 大数据技术主管，阿里双11系统管控调度技术专家、微信高级工程师……等众多架构领域技术专家，与大家面对面深度交流分享！

架构扩展性的13条最佳实践

以下内容节选自：世界级软件架构大师 Martin Abbott 亲研架构秘籍《突破技术领导力》。

阅读原文，可免费获取 Martin 亲研秘籍！

1. 尽可能多地使用异步的通信方式

同步调用会同时将两种不同服务的可用性捆绑在一起。如果其中一者产生错误或是堵塞，另一者也会受到影响。

2. 使用用户泳道来隔离错误

根据用户划分来创建硬件隔离的“泳道 Swim Lanes”。这可以防止因为某个客户所产生的问题而影响其他客户，同时有助于诊断问题和代码发布。

3. 使用多层次的缓存

在多个层上尽可能地使用缓存，如数据库前的对象缓存（例如：memcached），或是页面内容缓存（例如：squid），边缘缓存（例如：Akamai）。

4. 监控应用程序性能

首先要站在客户的角度去分析你的程序性能。从外部网络进行监控测试，可以模拟真实的用户体验。同时，还可以根据查询和事务操作上执行次数和耗时数据，来监控程序的内部工作情况。

5. 复制数据库

复制数据库可以帮助还原数据，同时把读取的负载分配到多个实例。

6. 使用切片（Sharding）技术

根据不同服务或（和）用户使用的量级来分割应用和数据库。虽然它会给程序带来一些轻量的复杂度，但在规模上这样做更易于扩展。

7. 尽可能少的使用关系型数据库RDBMS特性

尽可能使用OLTP(on-line transaction processing，联机事务处理 )数据库作为存储设备。因为要确保ACID属性，关系型数据库在扩展型方面会有很多挑战。你的交易越依赖关系型数据库系统（RDBMS）提供的功能，那么系统在扩展时你投入的负载就越大。建议从数据库中将主要的业务逻辑（例如存储过程）都移到应用程序或服务内。当系统需要做大规模扩展时，应该通过应用或服务来扩展，而不是通过SQL。

8. 在服务器上小批量地部署新代码

尽可能小批量地在服务器上部署新代码，而不要让整个站点关闭。这要求所有代码都要向后兼容，因为在部署时你会有两个版本的代码同时运行。这种方法可以帮助我们方便地找到应用质量或者L&P测试（负载性能测试）所遗漏的问题，同时最小化对客户的影响。

9. 在部署前执行负载与性能测试

一定要在产品部署前，执行负载与性能测试。虽然这不会发现所有问题（这也是为什么我们需要回滚 Rollback的能力），但它很值得做。

10. 不能回滚注定失败

确保所有版本的代码都有回滚能力，在准生产或者QA环境演练，必要时在生产环境中用它来解决客户的问题。如果没有经历过无法回滚代码的痛，还继续冒险地“修改-发布”代码，那么你会在未来某个时刻体会到这种痛苦。

11. 容量规划／扩展峰值

对于每一层、每一个服务，都要清楚它有多大容量。使用扩展峰值（Scalability Summits) 来规划容量的增长需求。

12. 问题根源分析

确保有强大的学习文化，当问题出现时，一定要确保找到问题根源，才能最终修复问题。

13. 从一开始就重视质量工作

架构质量从一开始设计就要考虑进去，质量不能靠测试来解决。测试只能发现研发过程中带来的问题。