springcloud 及分布式组件 总览

发布时间:2022-07-02 发布网站:脚本宝典
脚本宝典收集整理的这篇文章主要介绍了springcloud 及分布式组件 总览脚本宝典觉得挺不错的,现在分享给大家,也给大家做个参考。

1 微服务的由来

这是一个普通的Nginx反向代理三个tomcat服务器的项目

springcloud 及分布式组件 总览

现在产生了新的业务需求,增加了新的功能,代码更新了,自然需要重启整个项目,但是随着项目越来越大,每次重启耗费的时间越来越多,而且重启时不仅仅是客户端无法请求,服务端之间也无法进行通讯,这就会造成损失,所以要将项目按照业务进行拆分

  • 项目拆分的目的

    1. 减少发布时间,不需要整个系统都重启

    2. 减少维护以及升级时的影响范围,只是影响小部分功能,不影响整个项目功能

  • 项目拆分要解决的问题

    目前Nginx反向代理3台服务器,每台服务器其实都是干同样的业务,如果要拆分项目,例如将1台服务器上的业务拆分到10台服务器上分别执行,那么这3台服务器最终会产生30台服务器,这就增加了Nginx配置的压力,这个配置问题需要解决

  • 解决方式

    微服务(sPRingcloud)

2 项目架构

2.1 单体结构

一些简单的项目常用这种结构,优点很明显,缺点也很明显

springcloud 及分布式组件 总览

优点

    - 开发简单

    - 部署简单

    - 维护简单

    - 成本

缺点

    - 随着用户量增多,负载越来越高,负载均衡只能横向扩展

    - 业务越来越复杂之后,导致框架结构越来越复杂,需求变动改动较大,每次提交代码时都要小心翼翼,因为一个文件几千个类,害怕把别的接口的文件改了

    - 随着数据增多/业务增多,可能导致war包/jar包体积越来越大

优化方式

    - 横向增加服务器,让单台服务器变成多台机器的集群

    - 垂直拆分模块,降低耦合度

    - 数据库缓存等技,压力也会增大,也要横向扩展

优化示意图

springcloud 及分布式组件 总览

总结

    - 适合小型创业公司

    - 一个公司产品的最初产品,后续再重构优化

    - 适合用户量较少的项目

    - 一个单体架构的项目就足以支持公司的所有业务功能

例如:用户量只有十几人的xxx管理系统,xxxAPP内容管理系统,xxx政务系统

2.2 微服务框架

当用户量比较多时,可以使用这个框架

springcloud 及分布式组件 总览

优点

    - 可扩展性强

    - 独立部署

    - 开发比较灵活

    - 复杂度可控

    - 每个微服务都可以有自己的数据库

    - 容错性高、高可用

    - 比较适合大型企业/大型项目

缺点

    - 故障排查困难,每次请求,都可能是一个请求链,涉及到多个微服务,每个微服务的日志可能独立存储,排查bug困难

    - 服务监控困难,每次测试都要启动一堆东西

    - 分布式的复杂性,调用其他的服务器上的服务,网络出错概率增加,延迟增高,连接超时情况增加

    - 服务的互相依赖,导致修改接口/服务其他模块报错

    - 运维成本增高

    - 服务器成本增高

总结

    - 适合成本预算充足的大型项目

    - 适合高并发的互联网项目

    - 适合用户体量较大的项目

    - 不适合小型项目

2.3 两种架构对比

一个公司的项目,除非一开始就定位为大用户量,否则都是先做单体结构,随着用户量增大才慢慢改为微服务的。

如果体量很小的项目一上来就用微服务就是给开发找事,服务器也浪费资金,还增加了运维的工作压力

是什么项目都适合微服务的

3 微服务的注册中心

微服务的注册中心

4 微服务的远程调用

微服务的远程调用

5 微服务的配置中心

微服务的配置中心

6 微服务的网关

微服务的网关

7 微服务的限流

微服务的限流

8 微服务的中间件

8.1 说明

实际工作中需要用springcloud时,也不是一定会把所有中间件都用到,也并不需要我们一个个去搭建微服务的中间件,讲这么多只是让我们知道微服务的中间件分别是干什么的

实际开发搭建这些的是架构师,参数也不能随便乱动的,一般去到公司,application.yML里的参数都是不用改的,参数都在配置中心被统一设定好了

作为初级程序员,只需要游走于搭建好的项目中的各个业务模块,在其中写controller、service和mapPEr

但我们必须知道这些组件启动是有顺序的,什么服务端依赖于什么,所以以后去公司,如果是微服务项目,直接问这些组件启动顺序,让别人给你列个表就完事了

这么多中间件,无论是阿里提供的还是spring官方的,都是为了实现特定的功能(路由调用zuul、服务注册eureka、远程调用feign、负载ribbon、熔断Hystrxi、配置中心config、限流sentinel)

如果使用了阿里提供的中间件,那么一般就要用一整套阿里提供的springcloud解决策略

8.2 微服务的中间件分类及作用

整体分类如下,具体一类可用的组件太多了,学不完,官网上列表给出了很长一串

  • 注册中心:

    Eureka,Nacos,Consul,Zookeeper

    注册和发现服务,有很多注册中心可选用,无非区别就是怎么启动和怎么调用,要实现的功能都一样

  • 远程调用:

    基于http的远程调用feign,集成了ribbon实现客户端负载均衡(基于随机、轮询、并发数等),还集成了Hystrxi来做服务熔断(但是sentinel也可以做)

    基于RPC协议调用Dubbo,这是另一套路线,用这个的话,整个项目就都用alibaba提供的组件就行了

  • 配置中心:

    SpringCloud Config , Nacos

    集中管理配置,所有的客户端项目都需要连接配置中心服务器,其中的nacos优越点就是有一个页面

  • 网关:

    Zuul网关,可以在Nginx调用时进行注册中心服务分流

    Nacos网关,也可以实现

    gateway等等

    网关可选项非常多,但是这些网关要解决的问题就是分流

  • 限流:

    sentinel,实现服务降级和熔断,无非是保证服务节点的安全

9 微服务引擎MSE

百度搜索Nacos时,可以看到一个广告,进入广告页面可以看到链接到的是阿里的MSE

springcloud 及分布式组件 总览

这是阿里云提供的一种服务,用户花钱够买微服务的相关配置,这些配置部署在阿里云上并且已经配置完毕,用户可以直接使用,不用考虑部署和配置,需要再加更多的注册中心等微服务设施时,就再花钱即可

脚本宝典总结

以上是脚本宝典为你收集整理的springcloud 及分布式组件 总览全部内容,希望文章能够帮你解决springcloud 及分布式组件 总览所遇到的问题。

如果觉得脚本宝典网站内容还不错,欢迎将脚本宝典推荐好友。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。