接前一篇文章：软考 系统架构设计师系列知识点之云原生架构设计理论与实践（9）
所属章节：
第14章. 云原生架构设计理论与实践
第2节 云原生架构内涵
14.2 云原生架构内涵
关于云原生的定义有众多版本，对于云原生架构的理解也不尽相同。本节将根据广泛的云原生技术、产品和上云实践，给出一般性的理解。
14.2.4 典型的云原生架构反模式
技术往往像一把双刃剑，企业做云原生架构演进的时候，会充分考虑不同的场景选择不同的技术，下面是一些典型云原生架构反模式。
1. 庞大的单体应用
庞大单体应用的最大问题在于缺乏依赖隔离，包括代码耦合带来的责任不清、模块间接口缺乏治理而带来变更影响扩散、不同模块间的开发进度和发布时间要求难以协调、一个子模块不稳定导致整个应用都变慢、扩容时只能整体扩容而不能对达到瓶颈的模块单独扩容等。因此，当业务模块可能存在多人开发的时候，就需要考虑通过服务化进行一定的拆分，梳理聚合根，通过业务关系确定主要的服务模块以及这些模块的边界、清晰定义模块之间的接口，并让组织关系和架构关系匹配。
2. 单体应用“硬拆”为微服务
服务的拆分需要适度，过分服务化拆分反而会导致新架构与组织能力的不匹配，让架构升级得不到技术红利，典型的例子包括：
（1）小规模软件的服务拆分
软件规模不大，团队人数也少，但是为了微服务化，强行把耦合度高、代码量少的模块进行服务化拆分，一次性的发布需要拆分为多个模块分开发布和维护。
（2）数据依赖
服务虽然拆分为多个，但是这些服务的数据是紧密耦合的，于是让这些服务共享数据库，导致数据的变化往往被扇出到多个主服务中，造成服务间数据依赖。
（3）性能降低
当耦合性很强的模块被拆分为多个微服务后，原来的本地调用变成了分布式调用，从而让响应时间变大了上千倍，导致整个服务链路性能急剧下降。
3. 缺乏自动化能力的微服务
软件架构中非常重要的一个维度就是处理软件复杂度问题，一旦问题规模提升了很多，那就必须重新考虑与之适应的新方案。在很多软件组织中，开发、测试和运维的工作单位都是以进程为单位，比如把整个用户管理作为一个单独的模块进行打包、发布和运行；而进行了为服务拆分后，这个用户管理模块可能被分为用户信息管理、基本信息管理、积分管理、订单管理等多个模块，由于仍然是每个模块分别打包、发布和运行，开发、测试和运维人员的人均负责模块数就会直线上升，造成了人均工作量增大，也增加了软件的开发成本。
实际上，当软件规模进一步变大后，自动化能力的缺失还会带来更大的危害。由于接口增多会带来测试用例的增加，更多的软件模块排队等待测试和发布，如果缺乏自动化会造成软件发布时间变长。在多环境发布或异地发布时，更是需要专家来处理环境差异带来的影响。同时，更多的进程运行于一个环境中，缺乏自动化的人工运维容易给环境带来不可重现的影响。而一旦发生人为运维错误又不容易“快速止血”，造成了故障处理时间变长，以及使得日常运维操作都需要专家才能完成。所有这些问题都会导致软件交付时间变长、风险提升以及运维成本的增加。
至此，“14.2 云原生架构内涵”的全部内容就讲解完了。更多内容请看下回。