Java最全DDD 领域驱动设计落地实践系列：微服务拆分之道，进阶学习工作最全指南

最新推荐文章于 2024-05-10 16:51:37 发布

2401_84558508

最新推荐文章于 2024-05-10 16:51:37 发布

阅读量429

点赞数 3

分类专栏：程序员文章标签： java 面试学习

本文链接：https://blog.csdn.net/2401_84558508/article/details/138646804

版权

程序员专栏收录该内容

130 篇文章 0 订阅

订阅专栏

总结：绘上一张Kakfa架构思维大纲脑图（xmind）

其实关于Kafka，能问的问题实在是太多了，扒了几天，最终筛选出44问：基础篇17问、进阶篇15问、高级篇12问，个个直戳痛点，不知道如果你不着急看答案，又能答出几个呢？

若是对Kafka的知识还回忆不起来，不妨先看我手绘的知识总结脑图（xmind不能上传，文章里用的是图片版）进行整体架构的梳理

梳理了知识，刷完了面试，如若你还想进一步的深入学习解读kafka以及源码，那么接下来的这份《手写“kafka”》将会是个不错的选择。

Kafka入门
为什么选择Kafka
Kafka的安装、管理和配置
Kafka的集群
第一个Kafka程序
Kafka的生产者
Kafka的消费者
深入理解Kafka
可靠的数据传递
Spring和Kafka的整合
SpringBoot和Kafka的整合
Kafka实战之削峰填谷
数据管道和流式处理(了解即可)

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

为什么要进行微服务拆分？

在进行微服务拆分之前，我们首先应该搞清楚为什么要进行微服务拆分？微服务拆分后会带来怎样的业务价值？在后期维护上面会不会比以前的维护成本更低？我想这些问题都是架构师在实现微服务拆分之前需要回答的问题。那么我们就来先看看单体应用在业务不断发展的过程中会遇到怎样的问题。

维护难

随着业务的不断发展，单体应用的功能越来越多，需求不断变化，修改不断进行，单个应用多团队维护就会出现各种团队协作问题，不知不觉中降低了产品的研发效能。而且由于各个业务模块杂糅在一起，一个需求过来后，到底改哪个团队来做，经常在开会的时候吵得脸红脖子粗，增加了时间以及沟通成本。

更新难

进行需求迭代的时候，也许只修改了某个模块的功能，但是每次发布都是一整个大的包进行发布，其中构建、发包的时间成本会随着应用的迭代逐渐增加，导致整个需求上线过程变更显得十分笨重，不利于进行团队规模的敏捷开发。

稳定难

由于单体应用故障隔离范围只是线程级别的，单体应用可能会由于某个模块的功能有问题而导致整个服务平台的不可用，因此平台稳定性方面显然不能满足经常变化的业务发展的需要。

鉴于上述问题，我们需要对大泥球似的单体大应用进行合理拆分，以便于适用业务的快速发展。微服务架构拆分之后，团队成员不用都围绕一个大泥球应用转了，根据拆分的不同的业务域，各自负责自己的业务域，维护起来相对来说更加方便。同事如果有需求迭代，没有功能修改的业务域可以不用发生变更，不需要进行重新部署，大大降低了修改变更导致的平台稳定性性问题。另外由于是微服务分布式架构，不再是单点应用，不再存在单点问题，性能方面也会有所提升。

微服务到底该怎么拆？

当我们想清楚为什么进行微服务拆分之后，团队 Boss 也同意进行微服务拆分了。于是我们准备撸起袖子加油干的时候，另外一个问题又挡在我们前面，微服务到底应该怎么拆呢？或者换句话说，我们应该按照怎样的标准来进行拆分呢？如果拆分的不好，逻辑混乱的微服务还不如逻辑清晰的单体应用。这时候天空飘来了三个大字—DDD。

DDD 的理论中提供了我们进行领域驱动设计的指导方针，对于我们进行微服务的拆分具备天然的指导意义。比如 DDD 指导我们首先要对当前系统平台的业务进行全面的分析，可以通过用例分析法、事件风暴法以及四色建模法来进行业务分析，使用统一的业务语言进行业务领域划分以及边界上下文的划定，当然在这个过程中还包含了领域模型的构建，在业务分析中找到对应的实体、值对象以及聚合根，从而形成聚合，将聚合划分到边界上下文中。后面我们就可以根据边界上下文来进行具体的微服务的划分了。

笔者在实践微服务拆分的过程中主要按照业务能力、通用能力两个维度来进行具体的拆分。接下来给大家详细说明下。

业务能力

所谓业务能力就是平台的具体实现的业务功能是什么，这就好比在电商业务中物流域我们按照业务可以划分为仓储、运输、配送、计费等业务领域。大的领域划分出来之后，我们可以用真实的业务流程来串联这些业务领域。当业务流程经过这些业务领域的时候，必定会触发一些领域事件，经历一些业务流程，那么在这个过程中我们就可以梳理出对应的实体、值对象以及聚合根，我们将具有紧密业务逻辑关系的实体以及值对象收敛在聚合根的周围，从而形成聚合。例如在仓储领域中就会涉及到入库、库内操作以及出库这三大流程，其中入库主要包括质检、收货以及上架。这其中涉及到的实体主要用入库单、货品、操作员等，其中入库单就是聚合根，通过它可以将货品、操作员等实体以及值对象聚合起来，形成入库聚合。

在这里插入图片描述

通用能力

这里的通用能力其实包含两个意思，对于微服务本身来说，通用能力就是将各个微服务都涉及到的通用能力进行抽象形成单独的微服务。但是对于整个业务平台来说，通用能力实际就是业务中台。

1、通用服务

所谓通用服务就是在各个微服务之间都会碰到的问题，比如说接口的鉴权、日志的监控和管理、服务状态的监控和管理以及服务幂等等分布式系统问题。因此，我们需要将这些微服务的通用服务进行统一的抽象，形成通用的基础服务，这样微服务本身只需要关注自身的业务，这些微服务通用的能力由单独的基础服务来进行实现就 OK 了。

2、业务中台

我们还是拿大家最熟悉的电商业务来举个栗子吧，电商的业务形态有很多种，就阿里巴巴来说，有淘宝、天猫、主打生鲜的盒马、天猫超市等等。不管上层的业务形态有怎样的变化，实际上他们都是有比较核心的业务域是通用的，比如用户、支付、仓储、物流等等。那么实际上这些通用的业务对于整个电商平台来说实际就是通用能力，因此我们需要将这些通用的公共的能力进行下沉，形成业务中台，实现企业级的通用业务能力复用。

在这里插入图片描述