文章目录
- 前言
- 什么是单体架构
- 单体项目的优缺点
- 什么是微服务架构
- 微服务架构的优缺点
- 单体项目和微服务架构的扩展问题
- 微服务架构适用范围
- 参考资料
前言
现在各个公司中，Springboot 项目用的越来越多。
Springboot 精简了许多诸如Bean的配置项，让开发者能够快速的搭建一个开发架子，进行相关业务的开发。
一般情况下，单体架构使用的较多，大公司会采取Spring Cloud 或者 现在比较火的 Spring Cloud Alibaba 架构体系进行业务的开发操作。
什么是单体架构
单体架构，简而言之就是：
一个
war或者jar，包含整体项目的所有逻辑，进行服务器上的部署。
通常情况下，都是在一个 war或者一个 jar中，聚集各种功能模块以及资源，比如JSP、CSS、JS等。
针对业务呢，像用户模块、订单模块、商品模块、支付模块等，都存于一个项目中，上线时，采取整体打包方式进行部署。
单体项目的优缺点
单体项目相对微服务项目而言，具备以下几种优点：
- 1、项目简单明了。
- 2、开发、测试、部署等简单。
但任何一个架构，都是有利就有弊。单体项目通常具备以下一些缺点：
- 1、如果业务需求经常需要进行变更、增加，则会导致整体项目代码量越来越大。
如果存在多人协作开发，通常因为不同开发者不同的技术水平，导致上线出现bug时，不利于代码阅读和bug定位。
- 2、部署耗时。
所有的业务逻辑集成于一个项目结构中，导致单项目的整体代码量巨大，打包后的包的大小也会随之增大。
- 3、不利于扩展。
针对不同的模块类型，可能需要的服务器性能随之增高。
比如：假设用户模块是一个
CPU 密集型的模块 （涉及大量运算），则需要针对服务器而言提升效率，需要更换更加高效的CPU。
比如：假设订单模块是一个IO密集型的模块（涉及大量的磁盘读写），则需要针对服务器提升处理效率，需要增加增加性能更好的磁盘和内存条等。
- 4、阻碍技术的扩展
涉及到技术框架的更换，则需要改动的东西就会越多。相当于重构！
什么是微服务架构
说了这么多的单体架构，接下来就来说说什么是微服务架构体系。
微服务的核心，就是将一个庞大的单体架构化繁为简。
根据
实际的业务模块，将一整个项目进行拆分为多个微小的模块体系。
每个模块只做对应的事，每个服务都能独立部署运行，甚至每个服务都能拥有自己的数据库。
相对单体项目而言，单个服务器只需要部署独立的模块即可，启动占用内存、CPU等都相对降低。
但服务器的数量可能需要进行增加！
但是，针对单体项目而言，如果出现类似OOM的现象，则会出现一整个服务都不可用的现象。
微服务单个模块出现故障，宕机等，其他模块依旧还能继续使用。
并不会因为一个模块的原因，导致整体项目架构不可用的问题。
微服务架构是一种架构风格，通常具备以下几种要素：
- 1、将一个单一应用程序开发为一组小型服务。
- 2、每个服务运行在自己的进程中。
- 3、服务之间通过轻量级的通信机制(http rest api)。
- 4、每个服务都能够独立的部署。
- 5、每个服务甚至可以拥有自己的数据库。
【注意：】微服务以及微服务架构的是二个完全不同的概念。
微服务强调的是服务的大小和对外提供的单一功能。
微服务架构是指把一个一个的微服务组合管理起来，对外提供一套完整的服务。
微服务架构的优缺点
优点：
- 1、每个服务足够小,足够内聚，代码更加容易理解,专注一个业务功能点(对比传统应用，可能改几行代码需要了解整个系统)。
- 2、开发简单，一个服务只干一个事情。
增加新的服务模块，只需要了解对应的业务相关代码即可。
- 3、微服务能够被2-5个人的小团队开发，提高效率
- 4、按需伸缩
- 5、前后段分离, 作为java开发人员，只要关系后端接口的安全性以及性能。
不用去管理前端(web、App)的研发。
- 6、每个服务都能拥有自己的数据库，并且也能使用多种类型的数据库。
虽然可以这么用，但是涉及到分布式事务问题，还是相同类型数据库较好！
缺点：
- 1、增加了运维人员的工作量，以前只要部署一个war包，现在可能需要部署成百上千个war包 (k8s+docker+jenkis )
- 2、服务之间相互调用，增加通信成本
- 3、数据一致性问题(分布式事物问题)
- 4、问题定位问题！
单体项目和微服务架构的扩展问题
如果项目请求量大，则需要将项目进行集群部署处理。
通常，单体项目架构采取多台服务器进行部署扩展，采取Nginx做统一的门户，保证客户端的请求能采取轮询、权重、随机等方式，分配到不同的服务器上进行数据的处理。
但是，对于微服务架构体系而言，如果存在请求处理量大的模块。仅仅需要将对应的模块进行集群部署即可，采取注册中心(eureka、Nacos、Zookeper)进行各个服务之间的管理。
微服务架构适用范围
虽然，相比单体应用而言，微服务具备良多的优势。但是并非是所有的项目都需要考虑使用微服务进行开发。
考虑到维护成本和服务器成本问题。
通常来说，以下几种场景适合使用微服务：
- 1、大型复杂项目
- 2、快速迭代项目(短时间内经常更新)
- 3、并发量高的项目
通常，以下几种场景不适合使用微服务：
- 1、项目的业务功能稳定，并不需要时刻做更新
- 2、迭代周期相对较长，发版频率较低的项目
参考资料
