引言

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

庞大的单体应用

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

单体应用硬拆为微服务

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

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

缺乏自动化能力的微服务

软件架构中非常重要的一个维度就是处理软件复杂度的问题，一旦问题规模提升了很多，那就必须重新考虑与之适应的新方案。在很多软件组织中，开发、测试和运维的工作都是以进程为单位的，比如把整个用户管理作为一个单独的模块进行打包、发布和运行；而进行了微服务拆分后，这个用户管理模块可能被分为用户管理信息，基本信息管理，积分管理，订单管理等多个模块，由于仍然是每个模块分别打包、发布和运行，开发、测试和运维人员的人均负责模块就指数上升，造成人均工作量增加，增加了软件的开发成本。