三五互联网站后台,网站运营有什么用,网站的优化方案,长沙网站seo推广公司哪家好文章目录 引言一、初创互联网公司架构演化案例1. 万级日订单级别架构2. 十万级日订单级别架构3. 百万级日订单级别架构 二、分布式存储系统 Doris 架构案例三、反应式编程框架架构案例总结 引言
分布式架构
今天我们将探讨三种不同类型的架构案例#xff0c;分别探讨
一个初… 文章目录 引言一、初创互联网公司架构演化案例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 ServerDoris 的数据存储采用分片存储并通过一致性哈希和虚拟节点结合的路由算法来实现数据均匀分布。在扩容时只需要调整虚拟节点和物理节点之间的映射关系大大降低了集群扩容的复杂性。
Doris 提供高可用性和故障容错机制。在集群发生故障时Doris 会自动进行故障转移保证数据的高可用性。对于临时失效如硬件故障或程序升级系统仍然可以保证数据的多份写入确保数据的完整性。在永久性失效的情况下Doris 会通过恢复正常服务器中的数据来替代失效节点保证系统的稳定运行。 三、反应式编程框架架构案例 Flower 是一个基于 Akka 构建的反应式编程框架它支持开发者使用传统的命令式编程方式构建反应式系统。Flower 具备四个主要特性
即时响应系统可以即时响应用户请求不会阻塞线程。回弹性系统能够自我修复当部分功能失效时系统仍能正常运行。弹性系统根据负载自动伸缩适应不同的请求压力。消息驱动服务之间通过异步消息进行驱动避免了阻塞式的同步调用。
Flower 的设计目标是使开发者能够更容易地创建反应式系统而无需深入了解反应式编程的细节。与传统的阻塞式编程不同Flower 使用有限数量的线程处理大量并发请求极大提高了吞吐量和响应时间。Flower 的服务之间通过异步消息传递利用 Akka 的 Actor 模型来实现非阻塞的消息处理。异步数据库驱动让数据库操作不会阻塞线程进一步提高了系统的效率。
在高并发情况下Flower 能够通过少量的线程处理大量的用户请求避免了传统阻塞式编程中因线程资源耗尽导致的性能瓶颈。通过这种设计Flower 能够显著提升系统的吞吐量和响应能力适应更高的业务需求。 总结
通过这三个架构案例我们可以看到架构设计如何随着业务的增长和需求的变化而不断演化
互联网应用架构的演化从简单的单一系统架构到复杂的微服务架构和分布式数据库设计架构的变化反映了业务的成长和技术的不断创新。分布式存储系统设计通过合理的分区算法和高可用设计Doris 展示了如何构建一个既高效又易于扩展的分布式存储系统。反应式编程框架设计Flower 提供了一个易于使用的反应式编程框架帮助开发者构建非阻塞、高吞吐量的系统。
这三个案例从不同角度展现了架构设计的复杂性与灵活性同时也为架构师提供了多样的架构设计思路。在日常工作中架构师需要灵活应对不同的需求与挑战设计出既能满足当前业务需求又具备良好扩展性的架构。
