比起当时我们为多数据中心冗余存储的开销，Amazon S3要便宜两个量级。更具革命性的是：只要一张信用卡，就可以初始化存储了。不需要为财务审批准备提案，不需要招标，不需要客户的遴选流程，不需要跟供应商谈判，不需要寻找更多数据中心的场地空间。只要注册用户，就可以开始干活了。

发布这样的产品，不是来自传统的 IT 企业厂商，不是某个盯着高毛利、困难的谈判，有时候甚至要做协议使用审计的厂商。这是非常不一样的，完全不同的供应商，完全不同的模式，更顺畅的部署过程，完全动摇以往根基的价格体系，起价就很低，随着时间变化甚至有可能降低价格，而不是不断攀升。

金句：

完成本文时，James Hamilton 还在微软，不过是服务于 Windows Live Services Platform。文中的经验，是他和团队20年大规模软件系统和互联网级大规模服务的智慧结晶，包括Exchange Hosted Services 团队、Microsoft Global Foundation Services Operations团队以及Windows Live平台多个团队的经验，有些服务的用户规模超过二亿五千万。虽然已经是将近十年前的文章，但仍然可谓字字珠玑，其中很多原则和经验放到现在依旧不过时。经典就是经典。

文中开宗明义表示，本文的目的是要帮助人们：

• 快速交付运营友好的服务；
• 避免清早电话铃声的骚扰，帮助备受运营不友好的服务侵扰的客户尽量摆脱窘境。

接下来是三条原则：

• 做好发生故障的心理准备。
• 保持简单化。
• 将所有的工作自动化。

然后文中用十个小节涵盖了设计和部署运营友好服务所必须做到的各个方面。它们是：整体服务设计；以自动化和预置（Provisioning）为目标进行设计；依赖关系管理；发布周期及测试；硬件的选择和标准化；运营和容量规划；审核、监控和警报；体面降级和管理控制；客户及媒体沟通计划；以及客户自我预置和自我帮助。

试举第一节“整体服务设计”的基础原则：

• 设计时为故障做好准备（Design for failure）
• 冗余和错误恢复（Redundancy and fault recovery）
• 廉价硬件切片（Commodity hardware slice）
• 单版本软件（Single-version software）
• 多租户（Multi-tenancy）

• 采用设计运营友好的服务的实践，包括：

  • 快速服务健康测试
  • 在完整的环境中开发
  • 对下层组件的零信任
  • 不要把同一个功能构建在多个组件中
  • 不同的集群之间不能互相影响
  • 允许（少量）在紧急情况的人工干预
  • 保持一切简单健壮
  • 全面推进准入控制
  • 给服务分区
  • 理解网络设计

其他小节的经验和原则也是层次分明，值得细细阅读。

金句：

使用已经交付的历经考验的组件。历经考验的技术通常总是要比大胆前卫地走在潮流尖端运行要好很多。稳定的软件要优于新版本的早期，不管新特性如何有价值。这条原则也适用于硬件。批量生产的稳定硬件，往往要比从早期发布的硬件所获得的些许性能提升要有价值得多。

要降低大规模互联网服务的运营成本并改善服务的可靠性，一切从编写服务时注重运营友好开始。

标签：大规模服务、架构、设计

美团为什么构建压测工具？美团内部RPC大多构建在Thrift上，需要针对日常开发服务进行压力测试来发现潜在问题。尽管可使用脚本语言或开源工具，但无论采取何种方式，因其运作的复杂性会导致压测是一种耗时费力的过程。对美团而言，一款简单好用的压测工具是必需品，美团在构建压测工具前，对现有的主流压测工具进行了调研，包括JMeter、Twitter/iago、Gatling、Grinder及Locust等常见的压测工具，但因适用场景与美团的需求不符合而排除。

美团分析了自身需求后，对新压测工具的功能提出了以下4点要求：

• 线上流量拷贝
• 简单易用的操作界面（接入压测的时间应控制在1h以内）
• 清晰的图标能反映压测应用的各项指标
• 满足包括Thrift、HTTP等服务的压测需求

明确功能需求后，那美团如何构建压测工具呢？首先介绍了典型的抽象压测过程；然后是拷贝流量，压测工具提供VCR工具拷贝流量，将线上请求序列化写到Redis里，并且为方便用户查看具体请求，选取了JSON格式作为序列化和反序列化的协议等。接下来是聚合数据，介绍了应用打压后的评估压测结果的指标，压测工具采用了 InfluxDB来完成数据的聚合工作；最后给出了打压过程的架构图。

本文针对美团的实践应用，具体对拷贝流量、压测逻辑实现、创建应用及性能指标等进行了解释。文章最后阐述了美团压测工具上线后的成果，即已接入了20多个应用，完成数百次的打压实验，应用接入时间仅需15~30min，保证了美团服务的稳定，同时节省了开发者的时间。

金句：

压测工具采用Groovy来进行编写。对每个应用来说，只需要实现runner接口就可以实现对应用的打压。

标签：压测、流量、需求

淘宝大秒系统原型是淘宝详情上的定时上架功能。卖家为吸引大量用户购买，压低商品的价格，导致系统突现访问峰值，为缓解系统的压力，设计了大秒系统，将突发流量进行隔离。小米新品抢购限流采用的就是大秒系统，本文详细介绍了大秒系统及相关典型读数据的热点问题的解决思路与实践经验。

想了解淘宝大秒系统？我们需清楚系统设计的原则是热点隔离和动静隔离。本文首先说明了热点数据隔离的方法，即针对秒杀做多个层次的隔离，包括业务隔离、系统隔离和数据隔离等，实现快速区分已识别热点和普通请求的区别；然后本文介绍了大秒系统动静分离，并分析了“刷新抢宝”和“秒杀答题”的设计思路，从而引出对大流量系统数据做分层校验也是重要的的设计原则，由此总结出大秒系统分层架构的四大设计原则：

• 把大量静态不需要检验的数据放在离用户最近的地方
• 在前端读系统中检验一些基本信息
• 在写数据系统中重复校验
• 在数据库中保证数据准确性

了解大秒系统架构的设计原则等相关内容后，如果我们采用各种方法，依然无法阻止大流量涌入怎么办？本文没有直接回答这个问题，但对此强调了大秒系统需解决的三大关键问题：

• Java处理大并发动态请求优化
• 同一商品大并发读问题
• 同一数据大并发更新问题

本文最后补充了淘宝系的其他数据热点问题，如数据访问热点和数据更新热点等。

金句：

解决大并发读问题采用Localcache和数据的分层校验的方式，但是无论如何像减库存这种大并发写还是避免不了，这也是秒杀场景下最核心的技术难题。

隔离、动态分离、分层校验，必须从整个全链路来考虑和优化每个环节，除了优化系统提升性能，做好限流和保护也是必备的功课。

标签：系统、数据、分层架构、动态分离