一、什么是单体应用架构?
以下是官方给出的解释:
一个归档包(可以是JAR、WAR、EAR或其他归档格式)包含所有功能代码的应用程序,通常称为单体应用。
而单体应用架构的方法论,就是单体应用架构。
简单粗暴理解就是:所谓的单体应用就是指一个war包(或jar等)包含了项目的所有功能。
二、单体应用有什么优缺点?
1.优点
- 方便部署:不容置疑,整个项目也就一个war包(或jar等),部署起来特别方便。
- 方便调试:单体应用一旦部署,只需要在测试阶段启动一个war包(或jar等)即可。
- 便于共享:单个归档文件包含所有功能,便于在团队之间以及不同的部署阶段之间共享。
2.缺点
- 复杂性高:由于是单个归档文件,所以整个项目文件包含的模块非常多,使得整个项目非常复杂。以致于每一次修改代码或者修改一个bug都会带来隐藏的缺陷(修水管233)。
- 技术更替:随着时间的推移,需求的变更和技术人员的更替,会逐渐形成应用程序的技术债务,并且越积越多(现在你把10年流行的ssh项目替换成现如今流行ssm项目试试,看不整死你)。
- 版本管理难:当项目规模变大时,代码容易产生冲突。
- 稳定性差:局部服务有问题时,可能会影响整个整体。
- 可维护性差:规模扩大复杂性直线上升,造成系统不易理解。
- 可扩展性差:无法满足高并发下对应用的要求,不利于横向扩展。
三、什么是微服务架构?
以下是官方给出的解释:
微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理,服务可用不同的语言开发,使用不同的数据存储技术。
简单粗暴理解就是:微服务就是将一个完整的项目划分为一个个独立的运行单元(也就是服务单元),服务之间使用HTTP协议进行通信。
四、微服务有什么优缺点?
1.优点
- 易于开发和维护:一个微服务只会关注一个特定的业务功能,所以业务清晰、代码量较少。开发和维护单个微服务相对简单。
- 单个微服务启动较快
- 局部修改容易部署:单体应用只要有修改,就得重新部署整个应用。微服务解决了这样的问题。一般来说,对某个微服务进行修改,只需要重新部署这个服务即可。
- 技术栈不受限制:在微服务架构中,可以结合项目业务及团队的特点,合理的选择技术栈。
- 按需伸缩:可根据需求,实现细粒度的扩展。
2.缺点
- 可维护性差:应用流程常常垮多个微服务,不易进行问题的定位。
- 运维要求高:更多的服务意味着要投入更多的运维。
- 效率相对低:团队依赖强,一个服务的版本延迟会拖慢整个应用的开发周期。
- 开发难度大:垮服务的调用通常是不同的机器,甚至是不同的机房,开发人员需要处理超时、网络异常等问题。
- 分布式固有的复杂性:使用微服务构建的是分布式系统。对于一个分布式系统,系统容错、网络延迟、分布式事务等都会带来巨大的问题。