外国网站域名在哪查,phonegap wordpress,陶瓷 网站模板,胶州收电脑号码是多少一、“分布式”与“集群”的解释#xff1a; 分布式#xff1a;把一个囊肿的系统分成无数个单独可运行的功能模块 集群#xff1a; 把相同的项目复制进行多次部署#xff08;可以是一台服务器多次部署#xff0c;例如使用8080部署一个#xff0c;8081部署一个#xff0c…一、“分布式”与“集群”的解释 分布式把一个囊肿的系统分成无数个单独可运行的功能模块 集群 把相同的项目复制进行多次部署可以是一台服务器多次部署例如使用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 AlibabaSpring 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已经跟不上时代步伐了因为他底层采用的是servletservlet是一种阻塞io满足不了高并发场景而且不支持任何长连接而getway后期新秀底层采用netty做支撑是一种异步非阻塞io处理请求能力远远强于 servlet
九、配置中心
配置中心的存在主要是为了解决大量微服务下的公共配置以及动态配置问题我们都知道每个微服务是由springboot做支撑每个springboot项目都会有一个application的配置文件如果某些配置发生变化得一个一个服务去修改这样加大维护工作量特别是运维老哥 另外每次修改配置还得重启服务因此对动态配置也有强烈需求基于这样的背景而产生配置中心模块。
常见配置中心技术支持有 springCloud confignacos(主流并替换个config)。
十、服务总线
服务总线顾名思义他是为我们所有服务提供服务在微服务体系中通常会有一些公共的消息比如上步骤提到的动态配置就需要服务总线的支撑各个微服务向服务总线订阅消息进而监听总线当总线发生变动时订阅的服务可以感知然后同步更新自己服务总线一般搭配着消息中间件如RabbitMqMQ、kafka等此外服务总线还具有定点通知某个或多个服务的功能
总之服务总线就像一个妈妈管着一群孩子一样通过妈妈向所有孩子或者某个孩子传达消息从而改变孩子的某些行为或功能。 十一、分布式框架的最终选型 所以说不管是从微服务一站式解决方面来说还是从项目长期维护上面来说alibaba替代springcloud已经成为了一种必然趋势 总结技术栈* 反向代理nginx可做动静分离部署 统一网关基于spring-cloud-gateway配合JWT进行的简单的验权操作 分布式事务Spring Cloud Alibaba Seata阿里内部分布式事务产品不断迭代演进而来。 降级、限流hysrix/Spring Cloud Alibaba Sentinel 服务注册\发现Spring Cloud Alibaba Nacos 分布式配置中心Spring Cloud Alibaba Nacos 客户端负载均衡openFeign 异步消息RocketMQ阿里开源交由Apache孵化 链路跟踪Skywalking华为开源交由Apache孵化 分布式缓存Redis基础数据缓存 健康监控spring-boot-admin 分布式锁Redission 代码简化Lambokmybatis-plusmybatis-generator RPC框架apache dubbo
