架构案例：从初创互联网公司到分布式存储与反应式编程框架的架构设计

文章目录

引言
一、初创互联网公司架构演化案例
- 1. 万级日订单级别架构
- 2. 十万级日订单级别架构
- 3. 百万级日订单级别架构
二、分布式存储系统 Doris 架构案例
三、反应式编程框架架构案例
总结

在这里插入图片描述

引言

分布式架构

今天我们将探讨三种不同类型的架构案例，分别探讨

一个初创互联网公司如何从简单架构发展到百万级订单的架构演化
一个分布式存储系统（Doris）的架构设计
一个反应式编程框架的架构设计

这三类架构代表了不同领域和技术背景下的架构设计，分别考验着架构师在不同场景下的技术能力和架构思维。

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

1. 万级日订单级别架构

在初创互联网公司开始时，系统架构较为简单。系统主要包括前端（移动端应用）通过负载均衡访问 Web 服务器集群，前端服务器再将请求分发到应用服务器集群。每个应用服务器集群（买家系统、卖家系统、供应链系统和运营系统）连接到一台 MySQL 服务器。当订单量达到万级时，架构仍能承受高负载，但随着交易活跃度的增加，系统开始暴露出性能瓶颈。

在这里插入图片描述

2. 十万级日订单级别架构

随着订单量的增加，系统架构经历了一次重构。引入了 CDN 服务来加速静态资源的加载，使用分布式文件系统管理商品图片，提高了访问效率。同时，添加了 Redis 集群用于缓存，优化了数据存取速度。数据库也进行了主从分离，读写分离和数据分析分离，以减轻数据库压力。大数据平台通过 Kafka 消息队列与 MySQL 数据库进行数据同步，支撑着更复杂的统计分析与运营需求。

在这里插入图片描述

3. 百万级日订单级别架构

当订单量突破百万级时，主要的挑战来自于复杂的业务和庞大的数据存储需求。为了解决这些问题，系统进行了微服务化重构，把一些独立的业务模块拆分成单独的服务，进行分布式部署，这大大简化了功能扩展与维护。数据库的冷热分离进一步提升了性能，将已完成的订单数据迁移到 MongoDB 中，减轻 MySQL 的存储压力。微服务架构不仅提升了系统的可扩展性，还提升了团队开发效率。

在这里插入图片描述

微服务拆分

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

重构以后，红包服务作为一个独立的功能，独立部署，其他的所有系统都通过远程调用的方式访问红包服务。红包的发放使用，以及红包的各种记录都通过红包服务进行管理，其他的应用只需要调用服务接口就可以了。如果要修改红包服务相关的功能，进行业务变更，那么大多数情况下只需要修改红包服务就可以。这样使业务系统开发变得更加的简单，因为红包功能相对比较集中，也更容易实施和落地。

数据库冷热分离

另一方面是，对数据库在原来的主从分离的基础上又做了一次冷热分离。因为我们刚才提到经过主从分离后的数据库，读写访问压力已经可以接受，这时候，主要压力来自于订单的持续不断增长和数据表记录的不断扩展，带来的存储方面的压力。而订单的一个特点是当订单已经完成，订单状态被关闭以后，订单就是只读的。这个时候只需要能够对订单提供查询、读服务就可以了，无需为它提供事务性写操作，那么我们就可以从比较宝贵的 MySQL 数据库资源中，把这些已经关闭了的订单分离出来，存储到更容易进行分步式存储的其他的 NoSQL 系统上。

可以选择MongoDB 作为订单数据的冷存储。每天夜里运行批处理任务，执行一个冷订单备份的迁移操作，将已经关闭一个月以上的订单数据，从 MySQL 数据库中迁移到了 MongoDB 中。而订单服务在进行订单操作的时候，所有的写操作依然访问 MySQL 数据库。对于读操作，如果要是查询一个月以内的订单，也还是访问 MySQL 从数据库，而如果是需要查询一个月以上的订单，那么就访问 MongoDB 数据库就好了。

通过这样一个冷热分离来设计数据库，只存储最近一个月的数据，存储访问的压力、数据存储的压力大大的减轻。

二、分布式存储系统 Doris 架构案例

Doris 是一个高性能的分布式存储系统，其设计目标主要包括高可用、线性伸缩、高性能以及低运维成本。

在这里插入图片描述

Doris 的架构包括三个主要部分：

客户端（KV Client）：应用程序通过 Doris SDK 进行数据的读写操作。客户端连接到集群的控制中心，获取配置信息，并根据路由算法将数据请求发送到具体的存储节点。
控制中心（Administration）：负责集群的故障管理和扩容管理，确保系统的高可用性。
数据存储（Data Server）：Doris 的数据存储采用分片存储，并通过一致性哈希和虚拟节点结合的路由算法来实现数据均匀分布。在扩容时，只需要调整虚拟节点和物理节点之间的映射关系，大大降低了集群扩容的复杂性。

Doris 提供高可用性和故障容错机制。在集群发生故障时，Doris 会自动进行故障转移，保证数据的高可用性。对于临时失效（如硬件故障或程序升级），系统仍然可以保证数据的多份写入，确保数据的完整性。在永久性失效的情况下，Doris 会通过恢复正常服务器中的数据来替代失效节点，保证系统的稳定运行。

三、反应式编程框架架构案例

在这里插入图片描述

Flower 是一个基于 Akka 构建的反应式编程框架，它支持开发者使用传统的命令式编程方式构建反应式系统。Flower 具备四个主要特性：

即时响应：系统可以即时响应用户请求，不会阻塞线程。
回弹性：系统能够自我修复，当部分功能失效时，系统仍能正常运行。
弹性：系统根据负载自动伸缩，适应不同的请求压力。
消息驱动：服务之间通过异步消息进行驱动，避免了阻塞式的同步调用。

Flower 的设计目标是使开发者能够更容易地创建反应式系统，而无需深入了解反应式编程的细节。与传统的阻塞式编程不同，Flower 使用有限数量的线程处理大量并发请求，极大提高了吞吐量和响应时间。Flower 的服务之间通过异步消息传递，利用 Akka 的 Actor 模型来实现非阻塞的消息处理。异步数据库驱动让数据库操作不会阻塞线程，进一步提高了系统的效率。

在高并发情况下，Flower 能够通过少量的线程处理大量的用户请求，避免了传统阻塞式编程中因线程资源耗尽导致的性能瓶颈。通过这种设计，Flower 能够显著提升系统的吞吐量和响应能力，适应更高的业务需求。