当前位置：首页 > news >正文

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

news 来源：原创 2025/9/10 19:37:18

文章目录

引言
一、初创互联网公司架构演化案例
- 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 能够显著提升系统的吞吐量和响应能力，适应更高的业务需求。

总结

通过这三个架构案例，我们可以看到架构设计如何随着业务的增长和需求的变化而不断演化：

互联网应用架构的演化：从简单的单一系统架构到复杂的微服务架构和分布式数据库设计，架构的变化反映了业务的成长和技术的不断创新。
分布式存储系统设计：通过合理的分区算法和高可用设计，Doris 展示了如何构建一个既高效又易于扩展的分布式存储系统。
反应式编程框架设计：Flower 提供了一个易于使用的反应式编程框架，帮助开发者构建非阻塞、高吞吐量的系统。

这三个案例从不同角度展现了架构设计的复杂性与灵活性，同时也为架构师提供了多样的架构设计思路。在日常工作中，架构师需要灵活应对不同的需求与挑战，设计出既能满足当前业务需求，又具备良好扩展性的架构。

在这里插入图片描述

文章目录

引言

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

1. 万级日订单级别架构

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

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

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

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

总结

相关文章：