微服务的战争：按什么维度拆分服务

最新推荐文章于 2024-08-02 16:11:26 发布

煎鱼（EDDYCJY）

最新推荐文章于 2024-08-02 16:11:26 发布

阅读量292

点赞数

文章标签：数据库编程语言 java 大数据人工智能

本文链接：https://blog.csdn.net/EDDYCJY/article/details/108178013

版权

微服务，这三个字正在席卷着目前的互联网软件行业，尤其在近几年云原生迸发后，似乎人人都对微服务有了更广泛的使用和理解，张口就是各种各样的问号，有着强大的好奇心。

无独有偶，我有一个朋友鲤鱼在内部微服务的早期（每个业务组起步）就经常遇到下述的对话：

张三：为什么要拆现在的代码？
鲤鱼：因为！@）&&#@！）&#！&）@！&！的原因。
张三：那即将要做的 “微服务” 是按照什么维度去拆分的服务？
鲤鱼：常见的一般根据！@#*@！#&！（@&！@）#@ 的方式来拆分。
张三：照你这么说好像也不大对，我看每个业务组拆分的维度似乎都不大一样？
鲤鱼：嗯，每个业务组还有自己的见解，不会完全相同。
张三：。。。所以微服务的拆分维度到底是什么？

为什么想拆

为什么张三会有这个疑问呢，实际上是因为研发内部希望从原先的大单体，大仓库向微服务体系拆分转换，其原先大单体仓库结构，类 Monorepo：

但类 Monorepo 又有不少的问题，像是：

单个 Repo 体积过大：导致 Git 无法直接拉取。当你设置完再拉取时，在网速慢时还能去泡杯咖啡，并且在开发机性能不佳的情况下，IDE 会比较卡，代码运行起来也慢。
单个 Repo 存在公共函数/SDK：在代码仓库中，必然存在公共依赖。因此在解决代码冲突时，若遗留了冲突符，且在动态语言中，不涉及便运行正常。但其实在上线后却又影响到其他业务，可真是糟糕透顶，分分钟被迫抱着事故。
单个 Repo 模块职责/边界不清：在实际的软件开发中，涉及数十个业务组同时在一个大 Repo 下进行开发，没有强控边界的情况下，往往会逐渐模糊，即使在设计时管得住自己，你也不一定能 100% 防止别人模糊你的边界。
单个 Repo 包含了所有的源码：出现公司源代码泄露时，会导致整个 Repo 外泄，相当的刺激和具有教育意义。因为虽然开放和协同了，不属于你们组的业务代码你也有权限查看了。

当然，Monorepo 是否又完全不可行呢？实际上国外 Google，Facebook，Twitter 等公司都有在使用 Monorepo，并取得了一定的收益。

其实做 Monorepo 是需要相应的大量工具支撑，若单纯只是一个 Repo 塞多个模块，基本都做不好，甚至引火烧身。还不如早早拆开，至少能确保各业务线服务的相对独立性。

拆成什么样

张三在明白了拆的原因后，就出现了第二个问题，那就是 “微服务” 要按照什么样的维度去拆分服务？

张三公司内部对于这块的知识处于模糊不清的阶段，因此需要进行深入了解，便于后续的团队共识和方法论建立，理所当然，十万个为什么也就出现了。

大单体变独立服务

最常见的拆分的方式是按照业务模块进行服务的拆解，像是前文所提到的业务模块，在设计上边界非常清晰，这种情况直接拆成各个服务就可以了：

而在拆分后，又会遇到一个新的问题，也就是张三问第三个问题 “每个业务组拆分的维度似乎都不大一样？”。

因为在实际的执行过程中，严谨一些会由 SM 与 RD 一同开会探讨/规范初版的服务划分，而在持续的快速的迭代中，往往新服务的拆分都是由一线 RD 亲自操刀。

即使是架构师亲自操刀，在相对复杂的业务模型下，不同架构师划分出来的也有可能不完全一致，因此无论是哪种情况，你都会发现每个业务组拆分的维度多多少少都不一样了，毕竟人与人的思想都是不一样的，一千个人有一个千个哈姆雷特，因此张三的疑惑是正常的。

就像下图，核心是定义一只鱼，在不同人的眼中能演化出各种奇奇怪怪的鱼：

大数据库变独立数据库

在以前早期的大单体快速迭代中，往往是一个大数据库包含所有的业务数据库（甚至数据库账号都不分），这种时候就会带来各种问题。

像是某一天，你所负责的业务模块数据库莫名其妙出现了一些奇奇怪怪的值，你可能就要抓破脑袋去各种代码和 binlog 查了。更甚还有被网络攻击后，数据库配置被获取，直接跳板一拖直接整个脱裤，那可是糟糕透顶了。

因此在常见的应用设计中，应用程序在连接数据库时会指定连接特定的域名（例如：eddycjy-user），方便未来迁移。并且每个业务服务分别给予独立的数据库只读权限，进行软隔离。

而在业务量上来后，也会对业务数据库进行硬隔离，分配特定的 RDS 实例，就不会互相影响了。

环境隔离，独立

在服务拆分后，大多会采取独立部署的方式，将两者之间的环境隔离开来，互不干扰，互不影响：

像在云原生中，常见于在 Kubernetes 将一个业务服务作为一个 Service 部署发布，再根据实际的资源和调度情况进行 Pod 的扩缩容就可以了，资源也不会有直接干扰，且外部/内部调用都是有统一的入口管理。

拆分的阵痛

业务接口聚合

在服务拆分的过程中，总是会有阵痛出现。

例如在服务需要获取 “项目” 和 “房源” 信息时，到底是由谁来聚合这两个服务的信息。是不是应该由 BFF 来聚合：

或是应该新写一个胶水服务，用于聚合“项目” 和 “房源” 信息，保证其聚合性，减轻 BFF 的负担：

又或是在量级越来越多的情况下，是不是要怀疑一下，这两个服务拆分是不是有问题，“项目” 和 “房源” 在当前业务模型下是否应是一家：

显然在鲤鱼的经历中，这三种类型他都见过，不同的人总会在不同的思想和业务模型下选择了不同的解决方案，还真的没有绝对准确的准则。

分久必合，合久必分

随着对服务化的进程推进，常见的会遇到两种情况：

刚接触服务化时：服务一个没有，偶尔会有一个新的小业务，居然能拆出好好几个微型服务，并扬言要把剩余业务直接抄底重构了，都拆掉，怎么劝都劝不回头。
随着业务的不断发展：快速迭代，服务越来越多，工期压缩，多个 RD 交叉背好几个业务服务，有点力不从心，发现拆的好像有点问题，从最新的情况来看，某某几个服务似乎应该合在一起。
业务阶段性稳定：。。。这，以前这块好像有点问题，也太难拓展了，不应该这么拆，谁调了我，我的上下游是谁。

大多数的情况都是第二和第三者，但在实际操作中也不见得会合并服务，大多数 RD 会选择吞进心里，因为服务变迁所带来的工期延长和影响面无法直接预估（且存在历史代码，人员可能已经离职多年）。即使是服务拓扑也只能查看到一定时间内的服务调用，不会看到全部，因此上下游均无法 100% 确定。因此综合来看，弊大于利。

在解决方案上，更多的是在下次新服务规划时控制划分变量（因为已经有更成熟的经验了）。

实在不行了，才有可能会新起聚合服务将原本的多个服务聚合，又或是采取版本号等方式进行新老分流。甚至下定决心，蚂蚁搬家，起新服务一个个板块重构，一个个挪，持续灰度，“彻底” 解决历史包袱，完成转化。