单体服务到微服务架构的演进

发布时间:2024年01月23日

🎉欢迎来系统设计专栏:单体服务到微服务架构的演进

📜其他专栏:java面试?数据结构?源码解读?故障分析?Sping


🎬作者简介:大家好,我是小徐🥇
??博客首页:CSDN主页小徐的博客
🌄每日一句:好学而不勤非真好学者

📜 欢迎大家关注! ??

随着企业业务的发展,传统的单体架构受到越来越多的瓶颈,因此微服务架构的改造已经成为了一种趋势

本文以订单系统为例,探讨单体架构如何从单体项目演进到微服务架构,主要解决什么问题。

订单系统的演进路线是:子模块->子系统->微服务->单化

在这个过程中,平台化从低到高也是个重要发展方向。

6a977e9af06249cb9db6596dac5f8bbf.png单元化、平台化比较复杂,值得单独开个帖子,所以本帖只聊从单体项目到微服务架构的演进路线。


V1.0:子模块

946e8b772733488486da0ffd6bd28c63.png

(1)业务背景:初创期[天使轮]订单量比较小,日均 100+

(2)单核心问题:要求快速迭代、快速试错,频繁发版是常态

(3)技术架构:类似 ruoyi-vue-pro 项目的 trade 模块

  1. ?单体架构部署简单,维护成本低
  2. 共存进程:订单作为一个 jar 包,内嵌在后端系统
  3. 共享存储: 订单共享使用商城公用数据库

    ?

V2.0: 子系统

30835d8d459e4022b0313e6b3c7de9b2.png

(1) 业务阶段: 成长期[A轮融资] 订单量开始增长,日均 2w+ 单

(2)核心问题:业务复杂度逐渐增大,逻辑耦合导致订单不稳定

(3) 技术架构:类似 yudao-cloud 项目的 trade 服务

  1. 独立服务: 订单拆分独立 order 服务,支持独立开发、部署上线
  2. 独立存储: 订单拆分独立数据库,资源隔离,避免和其它业务相互影响

V3.0: 微服务

0f64d49e1ab2413780fcffea5247eb3a.png

(1) 业务阶段: 爆发期[B/C 轮融资],订单量开始腾飞,日均 100w+ 单

? (2) 核心问题:系统面临瓶颈,服务和存储的读写压力过大,线上事故不断

? (3) 技术架构:

?1、微服务化

  • 基于职责: 拆分订单交易、履约、售后等服务
  • 基于读写:拆分“查询类”服务(订单查询服务等等)、”写入类”服务(实时交易服务等等)

?2、存储分片:

  • 分库分表: 支持更大量数据的存储、更高 QPS 的读写
  • 冷热分离: 热数据 (近 90 天) 存储 MySQL,冷数据 (超 90 天) 归档 HBase

?3、逻辑异步化: 核心逻辑同步处理,非核心逻辑异步解耦


题外话: 分享这个话题的目的,大家在日常做架构设计时,要去思考可以分成几个阶段,每个阶段的数据规模是多大,面临的核心问题是什么,需要做什么样的技术改造,每个改造的关键点是什么。
另外,大家从 V2.0 和 V3.0 的演进中,思考微服务应该基于什么原则拆分? 应该拆分的多细?
SOA 和微服务有什么区别?

扩展

1、微服务的拆分有哪些原则?

一百个架构师眼中,有100种微服务拆分的方式,那么我简单总结几个我在做类似的事情的时候会参考的一些原则:

1、职责。我们学面向对象的第一天,就被告知要职责单一,而一个微服务也一样,他应该聚焦干一件事儿,否则他就不够"微”,至少在电商中,我们要把用户和交易拆分开。

2、业务。我们说技术是为了业务服务的,所以微服务的构建需要围绕着业务来做,不同的业务需要独立出来,比如保险业务中,投保和理赔,就是不同的业务,那么就可以把他们拆分开。

3、中台化。当我们在做业务拆分、职责划分后,可能会有一些公共的部分,这部分内容分别在各自微服务实现一份也可以,单独独立出来也是可行的,所以如果考虑中台化的思想,一些公共的部分,是可以独立拆分出来的。

3、系统保障。在做微服务拆分的时候,可能需要根据不同的系统保障级别做拆分,比如秒杀和日常交易,就可以单独拆开,针对秒杀做单独的可用性保障。还有一种就是在线任务和离线任务,也是可以拆分开的,各自做可用性保障。

在线任务:就是你应用中一直都在运行的任务,比如你的订单系统,他的下单、退款正常这些操作都是在线任务。离线任务:一般是那种异步扫表、或者定时执行的任务,比如订单的到期关闭等

技术栈。要考虑技术栈,不同的技术栈,不要硬往一起融,最后只会让这个系统无法维护。

4、依赖关系。拆分之后,各个微服务之间,不要有循环依赖。依赖应该是单向的,而不是循环的,循环依赖会给服务治理,链路追踪带来很大的挑战,并且存在循环依赖一定是拆分的不够合理

康威定律。最后一点,康威定律,应用架构要和组织架构一一对应。组织架构决定了业务架构、应用架构。说白了,就是多个团队一起维护一个微服务,一定会存在沟通、 (发布)冲突、谁来干等问题。

2、如何设计一个高性能的分布式系统

设计高性能的分布式系统需要考虑多个因素,包括架构设计、负载均衡、数据一致性、容错处理、消息队列、缓存、性能监控和安全性等。下面是一些可以帮助设计高性能分布式系统的方法

  1. 架构设计: 选择合适的分布式系统架构,例如微服务架构、SOA架构等,可以有效地提高系统性能。
  2. 负载均衡:使用负载均衡技术可以将请求分布到多个节点上,提高系统的性能和可用性可以使用硬件负载均衡器或软件负载均衡器来实现。
  3. 数据一致性: 保证数据一致性是设计分布式系统的一个重要方面,可以使用一致性哈希.3副本复制、分片等技术来保证数据一致性。
  4. 容错处理: 设计分布式系统时必须考虑容错处理,以防止单点故障。可以使用备份、自动4故障转移、容器化等技术来实现容错处理。
  5. 消息队列: 使用消息队列可以解耦系统组件,提高系统的可伸缩性和性能。
  6. 缓存:使用缓存技术可以减轻数据库的负载,提高系统性能.
  7. 性能监控: 使用性能监控工具可以监测系统的性能瓶颈,提高系统的性能和可用性。
  8. 安全性:分布式系统的安全性是至关重要的,可以使用身份验证、访问控制等技术来保证系统的安全性。

仅供参考,欢迎评论区留言,一起讨论~

?

文章来源:https://blog.csdn.net/weixin_44543482/article/details/135720802
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。