通过三种不同的系统架构案例加深理解认识

今天我们来学习一个架构案例分享，下面将分析三种不同的系统架构案例。

1. 分析初创互联网公司的架构演化案例，看一个小的系统架构是如何演化成一个较为成熟的、能够承受百万级订单的互联网系统架构。

2. 分析一个分布式存储的架构案例，看如何去设计一个分布式存储系统，底层存储系统的架构是如何设计的。

3. 分析一个反应式编程框架的架构案例，看开发框架的架构是如何设计的。

这三类系统架构是三种比较典型的架构设计，对设计的要求很不一样，对架构师能力的考验也不太相同。了解这三种不同的架构设计，可以对架构师的工作有一个比较全面的认知。

初创互联网公司架构演化案例

首先看初创互联网公司架构演化案例。

万级日订单级别架构

如下图，这是一个真实的校园互联网电商系统的架构。在早期的时候，每天处理 1万 左右的用户订单，这时候的系统架构如图所示，还是比较简单的。

分析上图架构。应用端主要是移动端的应用，通过负载均衡访问 Web 服务器集群，也就是前端集群。前端集群是两台 Nginx 服务器组成的，在 Nginx 再进行一次负载均衡，将用户请求分发到一组应用服务器集群。应用服务器集群按照应用场景分为买家系统、卖家系统、供应链系统以及运营系统四个系统集群，每个系统集群又包含了若干台服务器，所有这些系统都连接到一台 MySQL 服务器上。

十万级日订单级别架构

但是这样的系统在几千订单的时候运行还算可以，但是在交易比较活跃、并发比较高的时候，系统就会出现各种问题。在上图示例中，当时的市场总监说”我们的交易越忙，你们的系统越出问题，太邪门了。“当时我们也没敢说什么，技术部悄悄对系统做了一次改进和重构，主要优化系统架构方面。优化后的架构如下图。

主要优化点之一是在前端使用 CDN 服务，这样用户请求的各种静态资源都通过 CDN 服务返回，而所有的商品图片，再通过一个分布式文件系统进行管理。商品图片的上传和浏览，都由分布式文件系统提供。

在应用服务器集群上又加了一个 Redis 集群。我们前面说过，提升应用系统性能的第一个手段就是使用缓存。Redis 集群的使用，包括前面的 CDN 以及分布式文件系统，极大地缓解了系统在访问高峰期的访问压力。同时我们对 MySQL 数据库还做了一次主从复制的分离，构建了一个一主两从的分布式数据库。两个从服务器，一个从服务器用来给应用服务器用来做读操作服务，另一个从服务器做 SQL 数据分析，有时候也会通过 Sqoop 将数据导出到大数据平台上，做大数据计算。

在十万订单的时候，除了系统交易本身的压力比较大，公司对数据的处理的要求也比较高。除了各种各样的统计分析、竞对分析，还有各市场大区的绩效、具体到每个人的绩效都需要进行统计计算，所以专门搭建了一个大数据平台。在大数据平台上，根据业务数据进行统计分析和运营预测，还根据运营数据进行绩效考核。大数据平台上的数据一部分来自于应用服务器，通过消息队列 Kafka 导入到大数据平台，另一部分数据是来自于 MySQL 从数据库导入到大数据平台。通过这样一次系统重构，系统可以满足十万级日订单的访问压力。

百万级日订单级别架构

但是随着业务的进一步的发展，系统的订单量还在快速增长，这时候主要的挑战来自于两个方面。一个方面是随着订单的增长，业务也变得越来越复杂，开发新的功能变得越来越困难，系统的基本功能维护也越来越困难。另一个方面是，虽然经过了主从分离以及部署了多种缓存以后，高峰期的数据访问压力也可以承受了，但是数据库的存储空间难以满足要求。对于一个日订单百万级的系统，年订单量就是数亿，这样大的数据库存储对于 MySQL 而言是难以承受的。

所以我们对系统进行了进一步的重构。这次重构主要是两个方面，如下图。

• 微服务拆分

一方面是做了一个微服务方面的重构拆分，将可复用的一些业务拆分为独立的微服务，进行分布式部署，供应用系统调用，典型的就是用户服务、商品服务、订单服务、红包服务等。以前红包作为一个功能，在各个应用系统中可能都有涉及，买家需要使用红包，卖家要发放红包，而运营系统也可能发放系统级的红包，而这些红包的功能在各个子系统都有存在，所以对红包功能进行维护修改的时候，可能在很多个系统都要进行相关的代码变更和维护。产品经理需要跟几个系统开发团队进行合作，开发一个功能一不小心就可能会产生Bug。

重构以后，红包服务作为一个独立的功能，独立部署，其他的所有系统都通过远程调用的方式访问红包服务。红包的发放使用，以及红包的各种记录都通过红包服务进行管理，其他的应用只需要调用服务接口就可以了。如果要修改红包服务相关的功能，进行业务变更，那么大多数情况下只需要修改红包服务就可以。这