
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
java编程开发随着互联网的不断发展而被越来越多的程序员掌握,今天我们就通过案例分析来简单了解一下,java编程单体应用实践常见问题分析。
在开聊微服务之前,我先要你和介绍下单体应用。如果你不知道单体应用的痛,那也不会深刻理解微服务的价值。
早些年,各大互联网公司的应用技术栈大致可分为LAMP(Linux+Apache+MySQL+PHP)和MVC(Spring+iBatis/Hibernate+Tomcat)两大流派。无论是LAMP还是MVC,都是为单体应用架构设计的,其优点是学习成本低,开发上手快,测试、部署、运维也比较方便,甚至一个人就可以完成一个网站的开发与部署。
以MVC架构为例,业务通常是通过部署一个WAR包到Tomcat中,然后启动Tomcat,监听某个端口即可对外提供服务。早期在业务规模不大、开发团队人员规模较小的时候,采用单体应用架构,团队的开发和运维成本都可控。
然而随着业务规模的不断扩大,团队开发人员的不断扩张,单体应用架构就会开始出现问题。我估计经历过业务和团队快速增长的同学都会对此深有感触。从我的角度来看,大概会有以下几个方面的问题。
部署效率低下:当单体应用的代码越来越多,依赖的资源越来越多时,应用编译打包、部署测试一次,甚至需要10分钟以上。这也经常被新加入的同学吐槽说,部署测试一次的时间,都可以去楼下喝杯咖啡了。
团队协作开发成本高:早期在团队开发人员只有两三个人的时候,协作修改代码,后合并到同一个master分支,然后打包部署,尚且可控。但是一旦团队人员扩张,超过5人修改代码,然后一起打包部署,测试阶段只要有一块功能有问题,就得重新编译打包部署,然后重新预览测试,所有相关的开发人员又都得参与其中,效率低下,开发成本极高。
系统高可用性差:因为所有的功能开发后都部署到同一个WAR包里,运行在同一个Tomcat进程之中,一旦某一功能涉及的代码或者资源有问题,那就会影响整个WAR包中部署的功能。比如我经常遇到的一个问题,某段代码不断在内存中创建大对象,并且没有回收,部署到线上运行一段时间后,就会造成JVM内存泄露,异常退出,那么部署在同一个JVM进程中的所有服务都不可用,后果十分严重。
线上发布变慢。特别是对于Java应用来说,一旦代码膨胀,服务启动的时间就会变长,有些甚至超过10分钟以上,如果机器规模超过100台以上,假设每次发布的步长为10%,单次发布需要就需要100分钟之久。因此,急需一种方法能够将应用的不同模块的解耦,降低开发和部署成本。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!请读者仅作参考。