复杂性高:一个百万行级别的单体应用,整个项目包含的模块非常多,模块之间的边界、依赖关系容易模糊。可能添加一个简单功能都会带来隐藏的BUG
技术债务:随着时间推移、需求变更和人员更迭,会逐渐形成技术债务,已经使用的系统设计或代码难以被修改,因为应用程序种的其他模块可能会以意料之外的方式使用它
部署频率低:每次功能的变更或者缺陷的修复都会导致重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高,这使得单体应用项目上线部署的频率较低。部署频率低又会导致两次发布之间会有大量的功能变更和缺陷修复,出错率比较高
可靠性差:某个应用BUG,如死循环、内存泄露,可能会导致整个应用崩溃
扩展能力受限:单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。应用中有的模块是计算密集型,需要强劲的CPU;有的模块是IO密集型,需要更多的IO资源以及内存。这些模块部署在一起的话,不得不在硬件上做出妥协
阻碍技术创新:单体应用往往使用统一的技术平台和方案,使用相同的开发语言和框架,想要引入新框架或技术平台较难
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。