从秒杀架构引起的一些思考

从秒杀架构引起的一些思考

作者：链上研发-欧阳
时间：2016-08-18

本周的命题分享题目是秒杀架构。秒杀是大规模分布式系统最激烈的一种方式，对系统的承压能力是一个极大的考验。

先看看国内最著名的两个例子（数据来源于网络）：

• 2015-12-17 当天pv 25,900,000,000，卖出900多万张票
• 2015-11-11 高峰qps600,000，订单140,000/s,交易85,900/s,缓存20,000,000/s,其中最高的减库存红米1,500/s。

各类分析秒杀相关的技术文章特别多，归结起是因为并发特别特别高、流量特别特别大。设计方案大多是在保持数据一致性的前提下，一层一层的降低流量、降低数据量，下图描述了层次结构。

下降趋势一般情况下不是图中的一次方式，而是指数方程，最终到DB的时候已经很小很小了，这个图描述了秒杀架构的战略方向。具体的战术就是各种丰富异常的交互点、技术点了，这一类的讨论也有很多。有很多文章《秒杀系统架构分析与实战》，《淘宝大秒系统设计详解》，等等，大体思路方案都是这一些。

我们先来看一张来源于网络的某电商架构设计图：

这个架构图描述了整个系统的架构，秒杀原则上也是电商的一部分，只是并发高了，流量大了。淘宝2009年第一次双十一秒杀的时期，高峰的订单和交易量分别是400和200，现在的淘宝系统，日常达到这个数值肯定是没有问题的。

对于有的系统来说是秒杀，对于有的系统来说只是是日常行为。秒杀系统架构可以一步一步来，先转化为普通的电商系统，而不是被秒杀两个字带走了一切。

如果架构师给出这样的一个万金油的架构图，感觉上并没有什么问题，描述了理想中的架构。

技术开发人员，更关注技术架构。对于实际的技术架构，自己团队真实架构可能更加有说服力，下面看看上海链家房源系统的技术架构图，说来其实大同小异。

我们可以看的更加细致一些，其中DB存取架构。

如果想想，秒杀系统的架构就用上面别人的架构行不行呢？大家可能会选择一些不同战术来解决同样的问题。做不同的技术选型，选择一些优秀的开发者来完成。就好像很多人春运前夕，来帮12306做技术方案一样。

前面这一些架构的描述，看起来解决了最核心的问题，其实仅仅只描述了一点点。

这里，先介绍一个人，叫做Nick Rozanski，毕业于剑桥大学，曾就职于Sybase（Sybase出过一款列式存储关系型数据库产品Sybase IO，这几年比较火的Hbase也是列式存储）。他写过一本书，叫做《Software Systems Architecture》，里面描述了软件的架构设计。

• 每个系统(system)都有一个架构(architecture)
• 架构由架构元素以及相互之间的关系构成
• 系统是为了满足利益相关者（stakeholder）的需求而构建的
• 利益相关者都有自己的关注点（concerns）
• 架构由架构文档描述
• 架构文档描述了一系列的架构视角
• 每个视角都解决并且对应到利益相关者的关注点。

Nick列举了这些利益相关者：

stakeholder	desc
Acquirers	Oversee the procurement of the system or product
Assessors	Oversee the system’s conformance to standards and legal regulation
Communicators	Explain the system to other stakeholders via its documentation and training materials
Developers	Construct and deploy the system from specifications (or lead the teams that do this)
Maintainers	Manage the evolution of the system once it is operational
Production Engineers	Design, deploy, and manage the hardware and software environments in which the system will be built, tested, and run
Suppliers	Build and/or supply the hardware, software, or infrastructure on which the system will run
Support Staff	Provide support to users for the product or system when it is running
System Administrators	Run the system once it has been deployed
Testers	Test the system to ensure that it is suitable for use
Users	Define the system’s functionality and ultimately make use of it

系统的架构设计，应该首先找出利益的相关人，针对不同的利益的相关人给出架构设计。包含黑色利益的相关人，比如刷、抓、攻击。

所以，比较全面的架构的描述一定是不同利益的相关人描述。

那么，这里该描述多少，是10张，还是100张，还是更多。

前面提到了上海链家房源系统的架构图，其实一开始是这样的。

2010年底的时候业务量日pv1万左右，经过了爆发式的增长到日pv2000万，真实的情况是经过不断演化的。

淘宝从2009年到现在，可以参照《淘宝技术这十年》看看，技术和架构也一定是不断的演化过来。12306从2010年开始网上售票的惨不忍睹，到现在也是血与泪的演化。

关于架构演化之路的文章也有很多，可以自行搜索。或者关注精益、敏捷开发，描述了很多类似的问题。

这里再介绍一个最近很火的老人， Melvin Conway（康威），加利福尼亚理工学院物理学硕士学位，1961年获得数学博士学位，Pascal编译器核心开发之一。1967年，他写了一篇后来非常著名的的论文《How do committees invent》。这篇文章最初投到《哈佛商业评论》，虽然文章里面的系统按Conway的意思并不局限于软件系统，结果屌丝程序员的文章不入商业人士的法眼，无情被拒，Conway就投到了一个当时非常有名的IT杂志，所以被误解为是针对软件开发的。最初这篇文章显然不敢自称定律（law），只是描述了作者自己的发现和总结。后来，在Brooks Law著名的《人月神话》中，引用这个论点，并将其“吹捧”成了现在我们熟知Conway’ s Law（康威定律），这段话是：

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure

设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构

从下图可以看到40多年前的文章，最近引用越来越活跃。

这个定律说的是人力组织的架构往往决定了设计的架构，比如说如果组织了4个软件团队开发编译器，那么结果很可能是编译器有4个部分，或者有4步完成编译。

架构的设计，有的时候是包含人力组织的结构。架构设计完成后， 需要按照架构更改人力资源组织结构。看看下面这个很有意思图：

很形象。

有人说，我找一个产品大牛过来，就能把产品做好，但事实上并非如此，就是你找到了张小龙，最后做出来的产品反映的还是你所在组织的架构、沟通方式。因为张小龙想做的产品根本不会有机会出来。想做好产品，想通过招聘一位产品大牛来解决是没戏的，唯有从源头，从组织架构和沟通方式动手才有机会做出伟大产品。

再来说说Martin Fowler提出的微服务。很多人觉得微服务是个技术架构，他实际上更偏向于康威定律，是个组织架构。

Martin Fowler在提出微服务概念后，很是火了一段时间，后来他又写了一篇MicroservicePremium，里面有张图。

对比下康威定律的要点和微服务解决的问题

康威定律可以归纳为：

• 人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分组织来达成对沟通效率的管理
• 组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计
• 如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更合理高效
• 复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的

微服务

• 分布式服务组成的系统
• 按照业务而不是技术来划分组织
• 做有生命的产品而不是项目
• Smart endpoints and dumb pipes（我的理解是强服务个体和弱通信）
• 自动化运维（DevOps）
• 容错
• 快速演化

微服务提出了对系统架构组织的概念，属于理论基础，下面看看具体的实施和应用。

Java世界的同学们对Spring是充满了敬意的,很多人可能会忽略下图的小文字：

Pivotal还是很有实力的，它在2016-04-20发表的一篇博客，为雅虎日本的数据宣传自己。

Pivotal倡导《Migrating to Cloud Native Application Architectures》。Cloud Native Application指的是：

• The Twelve-Factor App: A collection of cloud native app architecture patterns
• Microservices: Independently deployable services that do one thing well
• Self-Service Agile Infrastructure: Platforms for rapid, repeatable, and consistent provisioning of app environments and backing services
• API-based Collaboration: Published and versioned APIs that allow interaction between services in a cloud native app architecture
• Anti-Fragility: Systems that get stronger when subjected to stress

其中有个理论叫12factor（http://12factor.net/zh_cn/）

• 基准代码 一份基准代码，多份部署
• 依赖 显式声明依赖关系
• 配置 在环境中存储配置
• 后端服务 把后端服务当作附加资源
• 构建，发布，运行 严格分离构建和运行
• 进程 以一个或多个无状态进程运行应用
• 端口绑定 通过端口绑定提供服务
• 并发 通过进程模型进行扩展
• 易处理 快速启动和优雅终止可最大化健壮性
• 开发环境与线上环境等价 尽可能的保持开发，预发布，线上环境相同
• 日志 把日志当作事件流
• 管理进程 后台管理任务当作一次性进程运行

作者：链上研发-欧阳
版权声明：本文为链家上海研发中心原创文章，转载请注明出处。

最后再提一下，也是Martin Fowler提出的概念无服务架构（http://martinfowler.com/articles/serverless.html）。里面介绍了可以仔细看看。infoq有个中文翻译。

就像很多软件发展趋势一样，业界并没有对“无服务器”有一个明确的说法，即使它真的表示以下两个不同而又重叠的领域也不会对此有所帮助：

• 无服务器先用来描述那些显著或完全依赖于第三方应用或服务（“在云端”）的应用程序。这些应用程序依赖于第三方来管理服务器端逻辑和状态，它们都是典型“富客户端”的应用程序（你可以想象为单一页面的Web应用程序或移动应用），并采用云平台提供的生态系统，包括可访问的数据库（如Parse、Firebase）、认证服务（Auth0、AWS Cognito）等。这些类型的服务以前被描述为“（移动）后端即服务”。我在文中会用“BaaS”缩写来代替这样的服务。
• 无服务器还表示那些有服务器端逻辑的应用仍然需要由开发者来编写。不同于传统的架构，它运行在无状态计算的容器中，这些容器由事件触发的、是短暂的（也许仅仅只是一次调用）、并且完全由第三方管理。（感谢ThoughtWorks在他们最近的技术雷达的定义。）理解这个观点的另一种方式是“函数即服务（FaaS）”，其中AWS Lambda是目前最流行的FaaS实现之一。

大意总结下来，如果你的PaaS能够有效地在20毫秒内启动一个要跑半秒的实例，那么就可以称之为无服务器化。

AWS Lambda已经提供这样的服务支持了。我相信，未来一定有适用的技术和场景，尽管现在还不是很成熟。

总结一下，尽管主题不太明确，大体描述了不要低估了架构的难度，架构应该关注那些关注者，架构是逐渐演化的，架构设计符合组织。