回到单体架构：一个开源项目的重构

• 从 Maven 到 Gradle。原因是灵活的自定义 task，还有自带的增量构建等。
• 依赖库的更新。
• 系统从微服务到单体。
• 构建规范和对应的规范工具化
• 持续交付。结合 GitHub Action、Docker Hub 等一系列的 DevOps 开源基础设施，进行全自动化的构建。
• ……

其中，最有意思的一个故事莫过于：从微服务到单体架构。因为，它是一种反主流的形式，又或者是反主流的技术架构。

创新互联建站制作网站网页找三站合一网站制作公司,专注于网页设计,成都网站设计、网站建设、外贸网站建设,网站设计,企业网站搭建,网站开发,建网站业务,680元做网站,已为1000+服务,创新互联建站网站建设将一如既往的为我们的客户提供最优质的网站建设、网络营销推广服务!

遗留微服务系统的挑战

在我们经过了一系列的内部会议之后，决定了将 ArchGuard 开源。随后，看到了代码库，我们发现了一系列的挑战：

• 过多的服务/模块。这个在内部开发多年的系统，由多个微服务组成 + 代码库组成，
• 知识缺少沉淀。先前并没有留下太多的开发文档，不了解当时做的一系列技术决策，需要从 Git 历史中汲取。
• 复杂的部署架构。同样是工具，对比于 Jenkins/Sonarqube 的部署方式，相对较为复杂。
• 不一定合理的服务划分。我们需要部署一系列的服务，但是只有扫描器(Arch Scanner)才需要弹性伸缩这样的特性。

于是呢，我们重新思考合理的后端服务(微服务)的颗粒度应该是怎样的?所以，参考于过去总结的什么用微服务?以及有多少个微服务更合理?先前的一个结论，类似于：

1. 微服务的数量不超过开发人员的数量。
2. 满足康威定律。微服务与开发团队对齐。
3. 两个比萨团队原则 —— 开发团队的人员数量维护在 3 \~ 12 人。一个微服务只由一个开发团队维护。
4. 高内聚，低耦合。单个服务与其它服务依赖少。如：两个服务存在相互调用，耦合度相对较高，可以考虑合为一个服务。
5. 收益大于开销。创建服务的开销是否超过了独立成服务的好处。
6. 你不一定需要微服务。考虑采用 DDD (领域驱动设计)分层架构来划分，以方便未来拆分为微服务。

在这个场景之下，几乎违反了上面的一系列规则。所以，我就回到了上述的 6 中去，采用 DDD 的分层架构模式。每个资源/聚合/服务在各自的包下管理(common 除外)：

├── Application.kt
├── clazz
├── code
├── common
├── config
├── evaluation_bak
├── evolution
├── method
├── metrics
├── module
├── packages
├── qualitygate
├── report
├── report_bak
├── scanner
├── scanner2
└── system_info

由于是合并的代码，所以代码中除在于 _bak 还有 scanner2 这样看似重复，又或者是迁移中的代码。

为什么单体更适合当前?

再回到多年以前， Martin Fowler 写了那篇《Monolithic First》，意在告诉人们在团队微服务能力和技术不够成熟的时候，你不应该采用微服务。这里的场景和上述的这个场景并不是一样的。对于系统的最终形态来说，单体并不一定适合这个系统，但是当于当前的我们来说，单体是最合适的。原因诸如于：

• 单体部署架构决定应用架构。使用 Docker，尽管 Saas 也是更友好的。但是，作为一个刚起步的开源项目，并不会资金来支撑这种规模的 SaaS 服务。
• 最终用户是开发者。软件的使用者本身又可能成为开发者，所以能一次启动就应该一次启动。
• 开发者体验优先。开源与面向开发者决定了 ArchGuard 是一个开发者体验优先的系统。如果一个参与到 ArchGuard 项目的开发者，要在多个项目中切换， 那么这中体验是非常差的。在开源社区里，一直都是单体优先，如 Gradle、Spring 等。
• 首次部署速度。
• setup 速度。

总体来说，作为一个开源应用/工具，软件工程的模式受限于其合作模式。所以，常规的软件开发架构，并不一定适用，我们需要一些更好的模式。

那么，我们还有别的选择吗?

我们的目标架构是单体吗?

从某种意义上，就当前来说，它是的。但是，如果管理有所不善的话，它会变成一个大泥球架构。回顾一下，一个多仓库/多模块的微服务系统，它与一个单体系统在物理形态上的主要区别在于：

• 微服务使用的是进程间调用，单体是进程内调用。
• 微服务最终有多个制品包，而单体只有一个或者是插件化的一带多。

所以，只要我们用相似的形态来构建一个单体应用，那么它在部署形态上就可以变成是微服务架构。简单来说，就是：

• 代码库内，包(package、service)间的调用使用 HTTP 调用，而不是函数调用。
• 通过自定义的构建脚本，在构建时拆分代码库，生成多个服务制品，并进行部署。

从结果来说，便是将系统放置在一种临界状态。以让人们根据自己的需要，做出不同的选择。如在 SaaS 化的时候，这就可以变成微服务的形态，单体部署时，则可以变成单体的状态。唯一麻烦的是，需要开发者对于构建系统有足够的了解，并设计好充足的自动化测试设施。

如何迁移 ?

接着，我们就开始合并多个代码仓库，其中的一些

1. 保留历史提交记录的合并。主要是结合 git-filer-repo 来进行过滤和选择路径。
2. 构建配置的全集。对 Application.properties 等进行统一。
3. 使用相同的依赖版本。由于不同的年代的原因，所以选择的依赖版本也有所不同，需要尝试先统一，才能合并代码。
4. 解决冲突。因为，只合并了 src 目录下的内容，如果包名有问题，如冲突了，需要重置。类似的问题，还有：Application 重复、Bean 冲突、Service 冲突。

就迁移过程来说，它并不复杂，就是耗时。

还有其它选项吗?

相似的场景，如果一个开发人员多个微服务，并且在不考虑单机部署的情况下，Monorepo 是一个更好的选择，把所有微服务项目的代码放在一个仓库里。

毕竟，Google 都可以把所有的代码仓库放一起，我们又有什么不可以的。当然了，Google 使用的技术原理是不一样的。不过，它能提供一个足够强壮的理由。

其它

回过头来看，对于小的团队来说，单体会不会是更合适的选择?那么大的团队呢?

当前名称：回到单体架构：一个开源项目的重构
标题来源：http://www.shufengxianlan.com/qtweb/news48/408448.html

成都网站建设公司_创新互联，为您提供软件开发、网站策划、定制开发、面包屑导航、网页设计公司、品牌网站建设

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联