查看原文

本文作者在 AWS 干了十年，总结了十个觉得有用的注意的地方，例如拥抱失败，避免本地状态，不可变式的架构，架构即代码，异步与事件驱动，数据库 Sharding，测量，应急预案，写代码的人负责运行，等等。

• EMBRACE FAILURE: 学东西，只看书看博客，不如弄脏自己的手，搞出几个错误来！不过在线上的服务，需要确保有回滚或者服务降级控制等机制，这样线上的失效才是可控的。Chaos Engineering 是作者认为这辈子最值的做的十件事之一。
• LOCAL STATE IS A CLOUD ANTI-PATTERN: Local State 在这里意味着有数据会因为应用被杀掉而丢失，解决办法就是将 state 放到 Memcached / Redis 中供所有实例中共享。迁移服务到云平台上，可能首要解决的问题便是处理 state。另外提到的一点是：看清场景，有些 state 数据生命周期短暂（比如计数器），放在 Redis 更好，如果放在数据库里，就是杀鸡用牛刀，甚至会拖坏数据库。
• IMMUTABLE INFRASTRUCTURE: 每次部署上去的应用都是全新的，而不是原地更新。provision 新的 instances 以后，慢慢把流量迁移过去，，一旦出问题就回切流量。
• INFRASTRUCTURE AS CODE: 所有组件的配置都可以用代码或者模板来描述。
• ASYNCHRONOUS AND EVENT-DRIVEN PATTERNS WILL HELP YOU SCALE: 异步和消息传递让系统变得可扩展。这个架构的最大的好处是，不管业务 state 怎么变化，整套架构都可以一套开黑到底。
• DON’T FORGET TO SCALE THE DATABASE: 区分清楚用 SQL 和 NoSQL 的场景，做好读写分离，做好分库分区和 Sharding！
• MEASURE, MEASURE, AND MEASURE: 给团队成员养成一个习惯：监控所有东西！可能开始的时候不觉得，有一天需要的时候，会发现真的是太需要了。（反正硬盘比较便宜）。在代码层面，最好就加一行代码的功夫就能做好监控。另外，给监控项增加报警。（作者遇到过因为邮件到上限导致没能继续收邮件）。另外，报警对应的回应也可以做到自动化。跟 DevOps 团队不停地沟通看如何改进监控指标和报警。（作者提到了一个有趣的指标“一个用户会花多少钱”，后来成为很多团队用的指标）。监控要有目标才行，除了服务，业务，还可以是进度。
• PLAN FOR THE WORST, PREPARE FOR THE UNEXPECTED: 紧急预案，第一是保留数据。只要留得青山在，不怕没柴烧。这意味着，定期备份+测试备份是成功。
• YOU BUILD IT, YOU RUN IT! 开发团队也要有运维团队的担当，从运维的角度去思考系统设计。
• BE HUMBLE, LEARN FROM OTHERS. 你同事很可能总是比你知道的多，所以你要多问，多学！