微服务拆分原则

最新推荐文章于 2025-09-20 16:13:18 发布

原创最新推荐文章于 2025-09-20 16:13:18 发布 · 3.4k 阅读

5 ·

CC 4.0 BY-SA版权

文章标签：

#java #微服务

面试专栏收录该内容

1 篇文章

订阅专栏

文章目录

- 微服务拆分原则

微服务拆分原则

拆分的大原则是当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过 2 个的其他服务或客户端提供数据，那么它就应该被拆分成一个独立的服务模块

单一职责、高内聚低耦合：简单来说一张表划分为一个服务
服务粒度适中：服务不要太细（有的团队甚至一个接口一个服务）
以业务模型切入：比如产品，用户，订单为一个模型来切入
演进式拆分：刚开始不要划分太细，可以随着迭代过程来逐步优化
避免环形依赖与双向依赖：尽量不要做服务之间的循环依赖

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

我要睡觉

关注关注

1
点赞
踩
5

收藏

觉得还不错? 一键收藏
2
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

微服务拆分的理论和原则及案例详细说明

03-24

一个非常好的介绍微服务拆分理论和原则，并有具体案例详细说明的文档！

微服务拆分策略和原则

许诗宇的博客

05-03

2667

注意：本文参考微服务拆分策略和原则 - 简书 微服务拆分目的不忘初心方得始终。在介绍如何拆分之前，我们需要了解下拆分的目的是什么，这样才不会在后续的拆分过程中忘了最初的目的。拆分的本质是为了将复杂的问题简单化，那么我们在单体架构阶段遇到了哪些复杂性问题呢？首先来回想下当初为什么选用了单体架构，在很多项目刚启动的时候，我们只希望能尽快地将项目搭建起来，方便将产品更早的投放市场进行快速验证。在开发初期，这种架构确实给开发和运维带来了很大的便捷，主要体现在： 1 开发简单直接，代码和项目集中...

2 条评论您还未登录，请先登录后发表或查看评论

2 条评论

_snowing_ 2022.06.15
一张表是实际意义上的一张表还是功能块意义上的一张表？
- 鸿_蒙回复_snowing_ 2022.09.09
  应该是功能吧，要是DB表一张一个服务也太扯了

微服务的拆分规范和原则

小鹏子的博客

01-26

1278

微服务拆分没有一个绝对正确的方案，服务拆分的粒度完全要根据业务场景来规划，而随着业务的发展，原先的架构方案也需要做调整。既然没有标准答案，那我们就使出“乱拳打死老师傅”的招数，想怎么拆怎么拆好了？且慢且慢，这不就成了暴力拆迁了吗，现在“扫黑除恶”正当头，我们可不能这么干。要讲解方法和原则的。拆分方案分为压力、业务压力模型拆分业务模型拆分 1 压力模型拆分压力模型简单来说就是用户访问量，我们要识别出某些超高并发量的业务，尽可能把这部分业务独立拆分出来。这么做的原因非常简单，高并发业务相当于前线战场

【微服务】微服务如何拆分、如何解决循环依赖

最新发布

xueping_wu的博客

09-20

978

微服务（Microservices）是一种软件架构风格，用于构建复杂的应用程序。它将一个大型的应用程序拆分成一组小型、独立的服务单元，每个服务单元都可以独立部署、运行和扩展。每个微服务都专注于执行一个特定的业务功能，并通过轻量级的通信机制（如HTTP、RPC、MQ等）来相互调用。微服务的目的是有效的拆分应用，实现敏捷开发和部署。比如把一个原来中心化的商城服务，拆分成产品服务、订单服务及用户服务，每一个服务把功能内聚，系统间通过远程调用解耦。实现高内聚低耦合。并且每一个服务都可以独立的提供子服务。

微服务拆分的原则

chenggang003的博客

10-19

608

高内聚低耦合（High Cohesion, Loose Coupling）：微服务应该尽可能高度内聚，即处理相似逻辑的组件应该在同一个微服务中，同时也应该尽量减少微服务之间的依赖，以降低耦合性。界限上下文（Bounded Context）：根据领域驱动设计（Domain-Driven Design）的思想，将不同的领域划分为边界明确的上下文，并使用微服务来实现各个上下文之间的通信。可部署性（Deployability）：微服务应该是独立可部署的，这样可以实现快速部署、回滚和升级，降低对整体系统的影响。

微服务拆分需要考虑的必要因素与坚持原则

优快云大数据

11-10

1231

创业公司往往因为有限的时间和投入，把系统所有的功能都聚集在一起。随着业务的不断发展，技术人员开始不断地对架构进行解耦和拆分。微服务在最近几年大行其道，很多公司的研发人员都在考虑微服务架构，或者在做微服务的路上，拆分服务是个很热的话题。那么我们应该按照什么原则将现有的业务进行拆分？是否拆分得越细就越好？这里我想谈谈系统拆分需要考虑的因素和坚持的原则。业务因素所有技术方面的考虑，包括架

微服务拆分原则1

08-08

微服务拆分原则1 微服务拆分原则是指在微服务架构中，将单体应用程序拆分成多个小的、独立的服务，以提高系统的灵活性、可扩展性和可维护性。微服务拆分原则是微服务架构的核心，决定着微服务系统的整体架构和性能...

Java微服务拆分原则深度解析：从理论到实践

2301_76867627的博客

03-28

985

例如，一个电商系统的订单模块与库存模块深度耦合，修改订单逻辑可能影响库存计算，导致测试和部署周期延长。例如，将用户管理系统拆分为用户认证服务和用户画像服务，前者处理登录鉴权，后者负责行为数据分析。例如，用户服务提供`GET /users/{id}`接口，禁止其他服务直接查询用户表。例如，订单服务通过API调用库存服务，而非直接操作库存表。垂直拆分：将单表按业务拆分，如将`orders`表拆分为`orders`（订单基础信息）和`order_details`（商品明细）高内聚：同一服务内的功能紧密相关。

SpringCloud微服务拆分原则

莫道桑榆晚，为霞尚满天

07-08

678

服务拆分一定要考虑几个问题：什么时候拆？如何拆？一般情况下，对于一个初创的项目，首先要做的是验证项目的可行性。因此这一阶段的首要任务是敏捷开发，快速产出生产可用的产品，投入市场做验证。为了达成这一目的，该阶段项目架构往往会比较简单，很多情况下会直接采用单体架构，这样开发成本比较低，可以快速产出结果，一旦发现项目不符合市场，损失较小。如果这一阶段采用复杂的微服务架构，投入大量的人力和时间成本用于架构设计，最终发现产品不符合市场需求，等于全部做了无用功。所以，对于，随着用户规模扩大、业务复杂后。

微服务设计，拆分原则

时光钟摆

08-24

3313

目录一、AKF拆分原则 1，Y轴（功能）关注应用中功能划分，基于不同的业务拆分 2，X轴（水平扩展）关注水平扩展，也就是“加速器解决问题” 3，Z轴（数据分区）关注服务与数据的优先级划分，如按地域划分二、前后端分离原则三、无状态服务原则四、RestFul 通讯风格五、现状思考一、AKF拆分原则业界对于可扩展系统架构设计有一个朴素的理念：通过加机器就可以解决容量和可用性问题。　　这一理念在云计算概念疯狂流行的今天，得到了广泛的认可，对于一个规模迅速增长的系统而言，容量和性

架构设计内容分享(一百三十八)：微服务如何拆分？原则是什么？

之乎者也·的博客

01-23

5679

2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用HTTP API通信。在腾讯视频的DDD重构案例中，在老的微服务架构中，存在分层不明确，下层服务过于理解业务逻辑，存在下层调用上层的问题，出现了代码耦合严重，调用关系混乱的 “微服务小泥球”。如果是数据驱动原则/界面驱动原则，那么，是一上来就定义数据库表结构，就去调整领域逻辑代码。

微服务拆分的原则、时机、方法以及常见问题

pantouyuchiyu的博客

04-11

1305

在平常情况下，技术架构会随着业务规模大小、团队人数多少、技术债积累速度等动态变化。当然，引起架构变化最主要的因素还是业务发展速度。在以前的单体架构到微服务架构演进历程文章2 等文章中，有一张架构演进的图，如下：（巨型单体到微服务架构的演进）这张架构演进图，说明了架构的变化和演进的总方向。演进到微服务架构，它中间有几次架构变迁和发展的过程。当然，这张架构演进图有一个缺憾，大单体应用架构后面缺一张模块化的单体架构图，也就是说把大单体拆分为模块化的大单体。

微服务的拆分有哪些原则？

weixin_51291483的博客

12-07

466

当我们在做业务拆分、职责划分后，可能会有一些公共的部分，这部分内容分别在各自微服务实现份也可以，单独独立出来也是可行的，所以如果考虑中台化的思想，一些公共的部分，是可以独立拆分出来的。：我们说技术是为了业务服务的，所以微服务的构建需要围绕着业务来做，不同的业务需要独立出来，比如保险业务中，投保和理赔，就是不同的业务，那么就可以把他们拆分开。：我们学面向对象的第一天，就被告知要职专单一，而一个微服务也一样，他应该聚焦干一件事，否则他就不够"微”，至少在电商中，我们要把用户和交易拆分开。

微服务划分的原则

来xghuang666的专栏

07-26

3950

实际的业务服务其实按照你的实际情况来进行划分的，不是说一定要按照上述的原则，一般来说，小型工程业务服务6-8个会比较合理，加上你的注册中心，网关，差不多整体的服务有11个左右，大的服务差不多12-15个，因为再继续加的话，业务的部署压力以及依赖关系的压力会非常大。我们这里可以看一下我们的业务该如何进行划分。首先，我们看我们的整体的图，我们可以将整个业务划分成为医院域以及预约平台域此时，医院域我们不用进行过度划分，因为这里是只需要对接院方的API，所以只需要对接就行。

微服务拆分原则有哪些

06-28

微服务架构的设计和拆分原则旨在保证系统的可维护性、扩展性和高可用性。以下是一些常见的微服务拆分原则： 1. **业务导向**：服务应该围绕业务功能拆分，每个服务处理特定的业务领域或业务流程。 2. **单一职责**：每个服务应该只做一件事，避免过度复杂的功能集于一身。 3. **粒度适当**：服务应该足够小，以便于独立部署和扩展。通常粒度在核心功能或业务能力上划分。 4. **接口简单清晰**：服务之间的交互应通过轻量级的API接口进行，减少耦合。 5. **自治性**：每个服务有自己的数据库，有自我管理和恢复能力，减少相互依赖。 6. **模块化**：尽量使用独立的模块或库，便于测试和故障隔离。 7. **版本管理**：服务通过明确的版本号进行升级和发布，保证高可用性的平滑过渡。 8. **重用性**：尽可能复用通用的服务和库，避免重复开发。 9. **安全性考虑**：服务之间通信应使用安全协议，如HTTPS，保护数据传输。 10. **监控和日志**：每个服务都有独立的监控和日志系统，便于问题排查。