🎉欢迎来系统设计专栏:单体服务到微服务架构的演进
📜其他专栏:java面试?数据结构?源码解读?故障分析?Sping
🎬作者简介:大家好,我是小徐🥇
??博客首页:CSDN主页小徐的博客
🌄每日一句:好学而不勤非真好学者📜 欢迎大家关注! ??
随着企业业务的发展,传统的单体架构受到越来越多的瓶颈,因此微服务架构的改造已经成为了一种趋势
本文以订单系统为例,探讨单体架构如何从单体项目演进到微服务架构,主要解决什么问题。
订单系统的演进路线是:子模块->子系统->微服务->单化
在这个过程中,平台化从低到高也是个重要发展方向。
单元化、平台化比较复杂,值得单独开个帖子,所以本帖只聊从单体项目到微服务架构的演进路线。
(1)业务背景:初创期[天使轮]订单量比较小,日均 100+
(2)单核心问题:要求快速迭代、快速试错,频繁发版是常态
(3)技术架构:类似 ruoyi-vue-pro 项目的 trade 模块
?
(1) 业务阶段: 成长期[A轮融资] 订单量开始增长,日均 2w+ 单
(2)核心问题:业务复杂度逐渐增大,逻辑耦合导致订单不稳定
(3) 技术架构:类似 yudao-cloud 项目的 trade 服务
(1) 业务阶段: 爆发期[B/C 轮融资],订单量开始腾飞,日均 100w+ 单
? (2) 核心问题:系统面临瓶颈,服务和存储的读写压力过大,线上事故不断
? (3) 技术架构:
?1、微服务化
?2、存储分片:
?3、逻辑异步化: 核心逻辑同步处理,非核心逻辑异步解耦
题外话: 分享这个话题的目的,大家在日常做架构设计时,要去思考可以分成几个阶段,每个阶段的数据规模是多大,面临的核心问题是什么,需要做什么样的技术改造,每个改造的关键点是什么。
另外,大家从 V2.0 和 V3.0 的演进中,思考微服务应该基于什么原则拆分? 应该拆分的多细?
SOA 和微服务有什么区别?
一百个架构师眼中,有100种微服务拆分的方式,那么我简单总结几个我在做类似的事情的时候会参考的一些原则:
1、职责。我们学面向对象的第一天,就被告知要职责单一,而一个微服务也一样,他应该聚焦干一件事儿,否则他就不够"微”,至少在电商中,我们要把用户和交易拆分开。
2、业务。我们说技术是为了业务服务的,所以微服务的构建需要围绕着业务来做,不同的业务需要独立出来,比如保险业务中,投保和理赔,就是不同的业务,那么就可以把他们拆分开。
3、中台化。当我们在做业务拆分、职责划分后,可能会有一些公共的部分,这部分内容分别在各自微服务实现一份也可以,单独独立出来也是可行的,所以如果考虑中台化的思想,一些公共的部分,是可以独立拆分出来的。
3、系统保障。在做微服务拆分的时候,可能需要根据不同的系统保障级别做拆分,比如秒杀和日常交易,就可以单独拆开,针对秒杀做单独的可用性保障。还有一种就是在线任务和离线任务,也是可以拆分开的,各自做可用性保障。
在线任务:就是你应用中一直都在运行的任务,比如你的订单系统,他的下单、退款正常这些操作都是在线任务。离线任务:一般是那种异步扫表、或者定时执行的任务,比如订单的到期关闭等
技术栈。要考虑技术栈,不同的技术栈,不要硬往一起融,最后只会让这个系统无法维护。
4、依赖关系。拆分之后,各个微服务之间,不要有循环依赖。依赖应该是单向的,而不是循环的,循环依赖会给服务治理,链路追踪带来很大的挑战,并且存在循环依赖一定是拆分的不够合理
康威定律。最后一点,康威定律,应用架构要和组织架构一一对应。组织架构决定了业务架构、应用架构。说白了,就是多个团队一起维护一个微服务,一定会存在沟通、 (发布)冲突、谁来干等问题。
设计高性能的分布式系统需要考虑多个因素,包括架构设计、负载均衡、数据一致性、容错处理、消息队列、缓存、性能监控和安全性等。下面是一些可以帮助设计高性能分布式系统的方法
仅供参考,欢迎评论区留言,一起讨论~
?