SpringCloud框架(1)---------------系统框架演变

什么是SpringCloud

Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。
Spring Cloud并没有重复制造轮子,它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

API网关(API Gateway)和反向代理有什么区别?

** 反向代理:** 通常来说,反向代理服务器只具备负载均衡、转发基本功能,若要需要其他功能,需要增加扩展或提供脚本来实现。
** API网关:** 在API Gateway部署模式中,API Gateway可以看作特殊的反向代理,是对反向代理服务器功能的扩充,同时API Gateway仅局限于服务API层面,对API做进一步的管理,保护。API Gateway不仅提供了负载均衡,转发功能,还提供了灰度发布,统一认证,熔断,消息转换,访问日志等丰富的功能。

系统架构的演变

1.单体应用架构—>2.垂直应用架构---->3.分布式架构----4.微服务架构

1 集中式架构

在软件设计中,经常使用的经典的 3 层模型,即表示层、业务逻辑层和数据访问层。
**表示层:**通常是网页、UI等主要用于和用户交互,也称为交互层。
**业务逻辑层:**主要是用于处理业务逻辑,例如登录的时候根据用户输入的信息经过业务逻辑层的处理之后才能展现给用户。
数据访问层:用于操作数据库,用户在表示层会产生大量的数据,通过数据访问层对数据库进行读写操作。
虽然在软件设计中划分了经典的 3 层模型,但是对业务场景没有划分。一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程中,最终经过编译、打包,部署在一台服务器上。
简单来说集中式架
构就是一个应用把所有功能都部署在一起。

在这里插入图片描述
优点:
• 系统开发速度快
• 易于测试、部署
• 适用于并发要求较低的系统
缺点:
• 代码耦合度高(你调用我,我调用你),后期维护困难
• 扩展能力受限
• 单点容错率低,并发能力差
很多传统的互联网公司或者创业型公司早期都会使用这样的架构,因为这样的架构足够简单并且能够快速开发和上线.
适合管理类的 进销存系统 OA系统 办公系统

2 垂直架构

当访问量逐渐增大,单一应用无法满足需求,此时为了应对高并发和业务需求,我们根据业务功能对系统进行拆分。这种架构就是垂直架构,相比于集中式架构,垂直架构将应用分解成了多个小模块,它们相互独立,互不影响
在这里插入图片描述
优点:
• 可以把单台机器变成多台机器的集群,解决了并发问题
• 可以针对不同模块进行优化
• 方便扩展,容错率提高
• 系统间相互独立,减少业务的耦合度
缺点:
• 服务之间相互调用,如果某个服务的端口或者ip地址发生改变,系统调用需要手动更改
• 搭建集群之后,实现负载均衡比较复杂
• 有数据冗余
当服务器的负载越来越高,场景越来越复杂集中式架构不能满足我们需求的时候可以选择垂直架构

3 分布式架构

当垂直应用越来越多,应用之间交互不可避免,这时候我们就需要将核心的业务提取出来作为独立的服务,并逐渐使其形成稳定的服务中心,从而使前端应用能够更快的响市场的需求。
在这里插入图片描述
优点:
• 将基础服务进行了抽取,系统间相互调用,提高了代码复用和开发效率
缺点:
系统间耦合度变高,调用关系错综复杂,难以维护并不被人们常用

5 微服务架构

微服务架构就是这样一种解决方案,从名字上来看,微服务就是针对可重用业务服务的更进一步优化,比如用户服务拆分的更细,如用户注册服务,用户鉴权服务等。
在这里插入图片描述
优点:
复杂度可控:因为体积小,复杂度低**,开发,维护会更加简单。**
技术选型更灵活: 因为每一个微服务属于独立的项目,所以可以结合业务特性选择相应的技术栈。
独立部署: 由于每个微服务都是一个独立运行的进程,所以可以实现独立部署。

缺点:
• 微服务架构整个应用分散成多个服务,定位故障点非常困难
稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大,并且一个服务故障可能导致整个系统挂掉。事实上,在大访问量的生产场景下,故障总是会出现的。
• 服务数量非常多,部署、管理的工作量很大
• 开发方面:如何保证各个服务在持续开发的情况下仍然保持协同合作。
• 测试方面:服务拆分后,几乎所有功能都会涉及多个服务。原本单个程序的测试变为服务间调用的测试。测试变得更加复杂。

  1. 这么多小服务,如何管理他们? ---->服务注册中心

  2. 这么多小服务,他们之间如何通讯?—>基于TCP协议Dubbo 基于Http协议 springcloud。

  3. 这么多小服务,客户端怎么访问他们?—>网关API

  4. 这么多小服务,一旦出现问题了,应该如何自我保护?—>熔断

  5. 这么多小服务,一旦出现问题了,应该如何排错? —>链路追踪。

注册中心 nacos|eureka -------->服务之间的调用 openfeign---------->网关gateway-------->熔断器sentinel-------->链路追踪sleuth+zipkin

毕业版本依赖关系(推荐使用)

在这里插入图片描述

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值