认识达内从这里开始

认真做教育专心促就业

如何判断微服务设计是否合理

发布：太原达内教育官网
来源：互联网
时间：2021-01-15 08:25

随着互联网的不断发展，越来越多的程序员都掌握了微服务开发架构技术，而今天我们就通过案例分析来了解一下，如何判断微服务设计是否合理。

如何判断微服务设计是否合理

其实很简单，你只需看它是否满足这样的情形：随着业务的发展或需求变更，在领域模型和微服务不断被重新拆分，或者组合成新的微服务过程中，不会大幅度增加软件开发或维护的成本，并且这个架构演进的过程是非常轻松和简单的。这才是微服务设计的重点，更是微服务设计时应该关系的问题。

在微服务设计时，很多团队在将集中式单体应用拆分微服务时，单纯按照业务功能将原来的单体应用，从一个部署包拆分成多个所谓的“微服务”部署包。这些“微服务”内的代码却仍然采用传统三层架构的设计模式，即这些代码依旧高度耦合，逻辑边界不清晰，我们暂且称它为“小单体微服务”。

三层架构：表现层、业务层、数据访问层。

在从单体架构向微服务架构演进的过程中，我们是需要边界清晰的微服务呢?还是需要很多很多的小单体微服务呢?

随着新需求的提出和业务的不断发展，这些“小单体微服务”会慢慢膨胀起来，变得错综复杂。

当有一天需要将这些膨胀的“小单体微服务”中的部分业务功能拆分出去，或者部分功能需要与其他微服务进行合并重组时，你会发现这些看似边界清晰的微服务，很难再度拆分，不知不觉中它已经变成了一个“臃肿油腻”的大单体了。这个时候你又需要一遍又一遍地，重复着大单体向小单体的重构过程，重构过程可能非常痛苦，难以取舍，甚至会让你摒弃好多之前自认为很合理的代码。

看到这里，问题已经很明显了，虽然业务边界很清晰，但是却忽略了代码边界。这种单体式微服务只是定义了一个维度的边界，即：微服务之间的业务物理边界。虽然完成了微服务架构的升级改造，但本质上依旧停留在单体架构的设计思维上，在微服务化不断演进过程中，很有可能不断会有一种反问：“微服务化真的有必要么?微服务化还不如传统单体应用呢……”

微服务设计时要考虑的，不仅仅只有微服务之间的业务物理边界，还需要定义好微服务内的逻辑边界和代码边界。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请在707945861群中学习了解。

< 上一篇：数据库事务隔离都有哪些类型

下一篇：太原软件开发微服务架构拆分原则分析 >