系列文章目录

微服务 | Spring Cloud(一):从单体SSM 到 Spring Cloud

目录

前言

在微服务如火如荼的情况下,越来越多的项目开始尝试改造成微服务架构,微服务即带来了项目开发的方便性,又提高了运维难度以及网络不可靠的概率.

在说微服务的优缺点时,一定要对比一下单体式机构,有对比才会更加明显。

首先说一下单体式结构

单体式架构

在单体式架构中,系统通常采用分层架构模式(MVC),持久化层、表示层,业务逻辑层。架构主要存在以下问题:

  1. 系统内部互相访问,耦合紧密导致难以维护;
  2. 各业务领域需要采用相同的技术栈,难以快速应用新技术(例如使用SSH很难向SSM改造);
  3. 对系统的任何修改都必须整个系统一起重新部署/升级;
  4. 在系统负载增加时,难以进行水平扩展;
  5. 当系统中一处出现问题,会影响整个系统;

在参加第一份工作的时候,因为项目比较小, 用户也比较小,所有的功能写在同一个项目里面,部署的时候也只部署一个实例。简化了开发中遇到的并发问题,同时也完美的命中了上面的一些问题,每次功能上线都需要项目重启。

在常见的方案中,我们可以对服务进行拆分,通过配置域名来进行两个服务间的通信,这样也能减小单个项目的规模,配置域名这种方式费事费力每增加一个服务实例都需要手动配置 Nginx 配置,每增加一个项目,又需要进行域名配置,配置繁琐且容易出错

为了克服以上缺点,微服务架构应运而生。微服务,又叫微服务架构。微服务就是一些协同工作的小而自治的服务.

微服务架构

优点

1. 技术异构性

在不同的服务中,可以使用不同的技术来各自开发,只要保证服务间能相互协作即可

2. 弹性

当微服务中的某一个服务不可用时,不会影响整个系统,只会影响相关功能不可用

3. 扩展

易于扩展,使用小的多个服务,更加易于扩展新的功能

4. 简化部署

某个服务的更新部署,不需要重新部署整个应用

5. 可组合

通过组合多个服务,可以提供一些新的功能

6. 可替代

因为每个微服务都比较小,重新实现某一个服务或者直接删除该服务都是可操作的

缺点

1. 复杂度高

微服务间通过REST、RPC等形式交互,相对于单体模式,需要考虑被调用方故障、过载、消息丢失等各种异常情况,代码逻辑更加复杂。

对于微服务间的事务性操作,因为不同的微服务采用了不同的数据库,将无法利用数据库本身的事务机制保证一致性,需要引入二阶段提交等技术。

同时,在微服务间存在少部分共用功能但又无法提取成微服务时,各个微服务对于这部分功能通常需要重复开发,或至少要做代码复制,以避免微服务间的耦合,增加了开发成本。

2. 运维复杂

在采用微服务架构时,系统由多个独立运行的微服务构成,需要一个设计良好的监控系统对各个微服务的运行状态进行监控。运维人员需要对系统有细致的了解才对够更好的运维系统。

3. 影响性能

相对于单体架构,微服务的间通过REST、RPC等形式进行交互,通信的时延会受到较大的影响。

服务发现与弹性扩展

正如前面介绍单体式架构的那样,当我们想扩展项目的时候,我们可以在单个项目上继续添加功能代码,也可以根据功能创建一个新的项目,并对项目配置域名,然后通过域名来回调用

未完待续

参考

  1. 微服务设计(Sam Newman)

1246875 20200822203040972 1191312426 - 微服务 | Spring Cloud(一):从单体SSM 到 Spring Cloud

微服务 | Spring Cloud(一):从单体SSM 到 Spring Cloud

微服务 | Spring Cloud(一):从单体SSM 到 Spring Cloud插图