Spring Cloud Alibaba 进阶(一)——微服务和单体架构的区别

前言

现在各个公司中，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、迭代周期相对较长，发版频率较低的项目

参考资料

微服务