微服务架构：Spring Cloud

Posted 2021-04-14 Programaper

微服务架构

微服务架构是一种面向分布式的程序架构。微服务应用架构是相对单体应用架构而言的。

 

一个JavaWeb应用，通常把UI和各业务模块一起打成一个War，放入Tomcat这样的Web容器运行。这样的一个War包，包裹的就是一个单体应用。

单体应用架构存在的问题：

• 复杂性高：各业务模块可能混杂在一起，系统包含的模块可能非常多，边界模糊，依赖关系不清晰，代码质量参差不齐，每次修改代码都有可能带来隐形的Bug。

• 技术债务：随着时间推移，需求变更，人员更迭，会逐渐形成技术债务。

• 部署频率低：随着代码增多，构建和部署系统的时间增加，单体应用通常要在系统启动阶段进行一系列的初始化操作，大量的初始化操作会增加系统的启动时间，加重各模块的耦合。形成“不坏不修”的循环，造成系统臃肿，不利于系统的更新和迭代。

• 可靠性差：当某个模块出现问题，例如OOM，死锁等，会导致整个系统宕机，影响其他应用。

 

微服务架构是将单体应用拆解为多个小型服务，每个服务是一个进程，服务间采用轻量级通信机制。

微服务的特点：

• 每个微服务运行在自己的进程中，单个微服务故障只影响部分功能；

• 多个微服务共同构成一个系统，对外提供服务；

• 微服务之间使用轻量级的通信机制，例如RESTful API；

• 每个微服务可以根据业务需要选择不同的数据库，例如处理事务可以选用关系数据库mysql，需要进行图计算可以使用Neo4j；

• 每个微服务可以根据开发团队，选择不同的开发技术栈，如java，node.js等；

• 微服务可以冗余部署，使用基础架构服务实现故障切换，提高整个系统的可靠性；

• 系统选择性的切分功能模块，将并发量大的功能模块独立成微服务并作冗余部署，当系统负载增大时，冗余部署微服务，通过增加内存，升级CPU或者增加服务节点等方式扩展系统。

 

微服务架构的挑战：

• 运维成本高，使用微服务架构意味着要开发和维护更多的模块，除了与业务模块相关的核心服务外，还要维护基础设施服务，如：服务发现、网关、负载均衡器、断路器等服务，要保证各个服务正常运行与协作，这增加了开发成本、调试难度和运维成本。

• 分布式固有的复杂性：微服务架构构建的是分布式系统，分布式系统本身的系统容错、网络延迟、分布式事务等问题使系统复杂度变得很高。

• 重复劳动：各个微服务可能都需要某个功能，但功能没有达到分解为一个微服务的程度，这时每个服务都要开发这一功能，从而形成代码重复。

 

微服务架构的适用场景

架构应该适应项目需求。只要当项目有分布式的应用场景和需求时，再考虑使用微服务架构。如果项目的业务并不复杂，并发度不高，系统的迭代不快，开发团队应该把精力集中在实现业务逻辑上；使用微服务，将系统的层次分得过细，模块过多，反而会造成开发成本过高，开发周期增长等弊端。

 

 

Eureka、Zuul、微服务的关系：

Eureka是服务发现的一种实现，Zuul是网关服务的一种实现，这里的微服务指与业务相关的服务模块。

系统部署和启动阶段：

0’‘阶段：Eureka开始监听各微服务的状态，进行心跳检测。

系统对外提供服务阶段：

1阶段：客户端向统一的网关服务发起请求，Zuul接收服务请求；

4阶段：Zuul将服务请求转发给对应的微服务；

5阶段：业务微服务处理Zuul转发来的服务请求，返回结果。

6阶段：Zuul向客户端返回服务请求结果。

 

SpringCloud的学习曲线：

语言基础：SpringCloud技术栈是基于Java的，需要先学习Java基础，如果项目是Web应用，还要掌握JavaWeb开发相关的知识。

框架基础：SpringCloud是基于Springboot，它延续了spring boot的契约模式以及开发方式。

项目管理和构建工具：主流的项目管理和构建工具有Maven和Gradle。