“分布式”与“集群”初学者的技术总结

往事不堪回首..

已于 2023-08-25 15:20:21 修改

阅读量1.6k

点赞数

文章标签：分布式

于 2023-08-25 15:13:00 首次发布

本文链接：https://blog.csdn.net/qq3892997/article/details/132495003

版权

一、“分布式”与“集群”的解释：

分布式：把一个囊肿的系统分成无数个单独可运行的功能模块

集群：把相同的项目复制进行多次部署（可以是一台服务器多次部署，例如使用8080部署一个，8081部署一个，也可以是a服务器部署一个，b服务器上部署一个，使用nginx类似的软件做负载均衡并轮询转发）

二、为什么要用分布式？

首先是项目工程无节制的变得臃肿庞大，今天增加一个业务，明天扩展一个模块，系统复杂度增加，大几十万行代码，几十个开发人员，service层，dao层代码大量被copy使用，经常有各种代码合并冲突要处理，非常耗时间。经常是我改动了自己的代码，但别人调用了我的接口，导致他的代码也出现问题，需要重新测试，很麻烦。
每次发布都是几十万行代码的系统一起发布，大家都提心吊胆准备上线，几十万行代码的上线每次要做很多检查，需要处理很多异常问题，每个人都高度紧张，被搞得几乎崩溃。
而且我现在有个新业务，打算把相关依赖升级一下，比如升级到最新的spring版本，还不行，因为可能会导致别人的代码报错，不敢随便改技术。并且一个web工程每次启动都需要好几分钟时间，本地IDE里面调试一次代码都很痛苦。
其次随着用户访问流量的增加，系统负载压力加大，变得不堪重负，通过增加实例数，增加硬件扩容能够带来的效果已经微乎其微，故障频发，效率低下。系统质量也越来越难以保证，测试周期也变得越来越长，无法满足公司业务的发展需要。

三、主流分布式框架的现状与选择

1. 为什么要用Dubbo或springcloud

1.1 目前国内主流的分布式框架是Dubbo和spring cloud，国外Spring Cloud 基本已经统一国外的微服务体系，国内老的系统使用 Dubbo 较多，新的系统使用 Spring Cloud 较多。不用Dubbo和spring cloud等服务框架当然也是可以的，但是这就需要自己处理很多事情了。比如，各个子系统走restful接口调用，那么就是http调用，这时比如传送过去一个对象，就要自己搞成一个json，然后一次调用失败后重试怎么做？
   另外，一般来说都是集群部署，目标系统有多个实例，那么自己还要写一个负载均衡算法，如何每次随机从多个目标机器中挑选一个来调用？
   还有，目标系统扩容新部署一个实例，或者服务器故障下线了一个实例，如何动态让调用方感知到呢？诸如此类很多问题，如果不用服务框架的话，自己这么瞎搞，会遇到各种各样的问题。
   俗话说的好站在巨人的肩膀上才能看的更远，有现成的技术不用白不用

2. Dubbo的由来以及现状

2.1 Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现，可以和Spring框架无缝集成。

2.2 交给Apache开源社区维护后，维护版本叫springcloud Alibaba，Spring Cloud Alibaba的出现，将Dubbo生态完美的与Spring Cloud生态融合在一起。不用再纠结选择Dubbo还是Spring Cloud，两者可以兼容的很好

3. 原生springcloud与springcloudAlibaba怎么选择？

3.1我们现在所使用的 Spring Cloud 技术体系，实际上是 Spring Cloud Netflix 为主，例如说：

Netflix Eureka 注册中心
Spring Cloud Config 配置中心
Netflix Hystrix 熔断组件
Netflix Ribbon 负载均衡
Netflix Zuul 网关服务 
Feign是声明式的web service客户端,它让微服务之间的调用变得更简单了,类似controller调用service

随着Spring Cloud Netflix 不再开发新的组件,项目进入维护模式

3.2 目前 Alibaba 基于开源组件和多个阿里云产品组成以及Spring Cloud 对的接口，实现了一套 Spring Cloud Alibaba 技术体系，并且已经获得 Spring Cloud 的认可，目前在国内使用人数很多了。组件如下：

Nacos 注册中心 + 配置中心，对标 Eureka + Spring Cloud Config 。
Sentinel 服务保障，对标 Hystrix熔断组件 。
Dubbo 服务调用( 包括负载均衡 )，对标 Ribbon + Feign 。
Gateway 网关服务。

四、服务调用，该模块主要功能为负责各微服务之间的通讯，实现服务端的远程调用，常用技术对比RestTemplate、Feign、OpenFeign。

五、2 张图对比目前的注册中心组件

六、负载均衡模块对比。

该模块主要功能是负责将请求经过一定策略均衡的分配到服务端，当我们的服务提供端同一个服务配置额多个实例（集群）时，就需要负载均衡模块协助分配请求到对应服务实例，如果服务配置单个，就不要此模块，但是为了保证高可用都会配置多个实例。

常见负载均衡策略：轮询、随机、权重轮询、ip hash、根据响应时间计算、最优策略等。

七、服务降级、熔断（容错）

服务降级、熔断、限流是微服务架构保证高可用的得力助手，之所以出现这三兄弟，是因为我们的微服务与微服务直接相互调用，错综复杂，调用链路很长，如果微服务体系中某个服务宕机，就会造成微服务系统瘫痪

服务降级：在服务调用（消费）端做的一种兜底措施，当服务器处理结果不符合预期（服务响应超时、服务出错、宕机等），就把兜底的结果返回客户，以此保证服务消费方正常运行，不至于死等服务器结果，链路积压崩溃。

服务熔断：发生在服务提供方，包含三个状态，降级->熔断->恢复。当满足熔断条件时就会触发熔断，触发熔断首先会降级处理，返回兜底数据，然后开启熔断，熔断开启后，不管三七二十一，请求正确与否，都会在一段时间内返回兜底数据，然后尝试恢复，也就是放行请求，如果请求处理正常，就会关闭熔断。（后面章节会代码演示）

服务限流：服务限流是为了让服务器平稳的处理请求，也是对服务的一种保护措施，不至于把服务拖死，比如我的服务10S内最多同时处理50个请求，突然间来了100个请求，50个以外要么排队要么丢弃，同一时间内我的服务只处理50个请求，如果不做限流，100个请求压在服务端，服务器忙不过来的！就有崩溃风险。

常见主流的技术： HyStrix、Sentinel、Resilience4j（国外使用）

八、网关

网关的功能
针对所有请求进行登陆统一鉴权（登录态）、限流、缓存、日志（用户打点）。
可以根据不同的请求路径pattern，来进行请求的鉴权、转发、和拒绝。
协议转化。针对后段多种不同的协议，在网关层统一处理后以HTTP对外提供服务。
提供统一的错误码。
请求转发，并且可以基于网关实现内网与外网的隔离。Gateway(网关-Gateway - 知乎)
目前主流的网关(Gateway,与zuul)

Gateway和ZUUL介绍:网关-Gateway - 知乎

目前主流技术为getway,zuul已经跟不上时代步伐了，因为他底层采用的是servlet，servlet是一种阻塞io，满足不了高并发场景，而且不支持任何长连接，而getway后期新秀，底层采用netty做支撑，是一种异步非阻塞io，处理请求能力远远强于 servlet