【云原生】云原生架构的反模式

引言

技术是都有 两面性，企业在信息化过程中，在进行云原生演化时，会出现过分云原生而不根据系统的实际情况，在此举出一些典型的云原生架构反模式的例子，希望后续的开发过程中不要犯错误。

庞大的单体应用

庞大单体应用的最大问题在于缺乏依赖隔离，包括代码耦合带来的责任不清，模块间接口缺乏治理而带来的变更范围影响扩散，不同模块间的开发进度和发布时间要求难以协调，一个子模块不稳定导致整个应用都变慢，扩容时只能整体扩容而不能对达到瓶颈的模块单独扩容等。因此当模块可能存在多人开发时，就需要考虑通过服务化进行一定的拆分，梳理聚合根，通过业务关系确定主要的服务模块以及这些模块的边界，清晰定义模块之间的接口，并让组织关系和架构关系匹配。

单体应用硬拆为微服务

服务的拆分需要适度，过分服务化拆分反而会导致新架构与组织能力不匹配，让架构升级得不到技术红利，典型的例子有：

1. 小规模软件的服务拆分：软件规模不大，团队人数不少，但为了微服务化，强行把耦合度高，代码量少的模块进行服务化拆分，一次性的发布需要拆分为多个模块分开发布和维护。
2. 数据依赖：服务虽然拆分为多个，但是这些服务的数据是紧密耦合的，于是让这些服务共享数据库，导致数据的变化往往被扇分到多个服务中，造成服务间数据依赖。
3. 性能降低：当耦合度强的模块被拆分为多个微服务后，原来的本地调用变成了分布式调用，从而让相应时间变大上千倍，导致整个服务链路性能急剧下降。