• 我们设计的是微服务还是小单体呢?

在微服务设计和实践中,可能很多人会一致认为:“将单体应用拆分成多少个微服务,是微服务的设计重点”。很多人把大量的精力花费在如何拆分微服务上,并把微服务设计好坏全部归因于微服务拆分的好坏。可事实真是这样吗?其实并非如此!

blog-thumb

在微服务设计和实践中,可能很多人会一致认为:“将单体应用拆分成多少个微服务,是微服务的设计重点。”

很多人把大量的精力花费在如何拆分微服务上,并把微服务设计好坏全部归因于微服务拆分的好坏。

可事实真是这样吗?其实并非如此!

Martin Fowler在提出微服务时,提到过微服务的一个重要特征:演进式架构

演进式架构以支持增量、非破坏的变更作为第一原则,同时支持在应用程序结构层面的多维度变化。

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

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

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

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

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

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

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

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

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

清晰的边界人人都想要,可是究竟应该如何实现呢?

DDD?