网站系统繁忙怎么办,深圳网站建设叶林,江苏百城建设有限公司官方网站,怎么制作个人网站微服务简介
微服务Microservices之父#xff0c;马丁.福勒#xff0c;对微服务大概的概述如下#xff1a; 就目前而言#xff0c;对于微服务业界并没有一个统一的、标准的定义#xff08;While there is no precise definition of this architectural style ) 。但通在其…微服务简介
微服务Microservices之父马丁.福勒对微服务大概的概述如下 就目前而言对于微服务业界并没有一个统一的、标准的定义While there is no precise definition of this architectural style ) 。但通在其常而言微服务架构是一种架构模式或者说是一种架构风格它提倡将单一应用程序划分成一组小的服务每个服务运行独立的自己的进程中服务之间互相协调、互相配合为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通通常是基于 HTTP 的 RESTful API ) 。每个服务都围绕着具体业务进行构建并且能够被独立地部署到生产环境、类生产环境等。另外应尽量避免统一的、集中式的服务管理机制对具体的一个服务而言应根据业务上下文选择合适的语言、工具对其进行构建可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务也可以使用不同的数据存储。 对于微服务问题有不同的、成套的“解决方案”如
Dubbo ZooKeeperSpringCloud NetFlixSpringCloud Alibaba霸王硬上弓般的直接手撸http
他们将多个中间件、框架组合在一起为构建微服务项目要面临的各种问题网关、熔断、服务注册与发现等提供成套的解决方案
SOA面向服务体系架构 微服务
服务治理服务监控是关键
通信方式http/rpc
rpc效率高 细嗦效率高
相关理论
CAP 理论
CAP 理论指出对于一个分布式计算系统来说不可能同时满足以下三点
一致性在分布式环境中一致性是指数据在多个副本之间是否能够保持一致的特性等同于所有节点访问同一份最新的数据副本。在一致性的需求下当一个系统在数据一致的状态下执行更新操作后应该保证系统的数据仍然处于一致的状态。可用性: 每次请求都能获取到正确的响应但是不保证获取的数据为最新数据。分区容错性: 分布式系统在遇到任何网络分区故障的时候仍然需要能够保证对外提供满足一致性和可用性的服务除非是整个网络环境都发生了故障。
一个分布式系统最多只能同时满足一致性Consistency、可用性Availability和分区容错性Partition tolerance这三项中的两项。
P 是必须的因此只能在 CP 和 AP 中选择
根据CAP原理将NoSQL数据库分成了满足CA原则满足CP原则和满足AP原则三大类 CA单点集群满足一致性可用性的系统通常可扩展性较差 CP满足一致性分区容错的系统通常性能不是特别高 AP满足可用性分区容错的系统通常可能对一致性要求低一些 5. 作为分布式服务注册中心Eureka比Zookeeper好在哪里 著名的CAP理论指出一个分布式系统不可能同时满足C (一致性) 、A (可用性) 、P (容错性)由于分区容错性P再分布式系统中是必须要保证的因此我们只能再A和C之间进行权衡。
Zookeeper 保证的是 CP — 满足一致性分区容错的系统通常性能不是特别高 Eureka 保证的是 AP — 满足可用性分区容错的系统通常可能对一致性要求低一些
当向注册中心查询服务列表时我们可以容忍注册中心返回的是几分钟以前的注册信息但不能接收服务直接down掉不可用。也就是说服务注册功能对可用性的要求要高于一致性。但zookeeper会出现这样一种情况当master节点因为网络故障与其他节点失去联系时剩余节点会重新进行leader选举。问题在于选举leader的时间太长30-120s且选举期间整个zookeeper集群是不可用的这就导致在选举期间注册服务瘫痪。在云部署的环境下因为网络问题使得zookeeper集群失去master节点是较大概率发生的事件虽然服务最终能够恢复但是漫长的选举时间导致注册长期不可用。
Eureka看明白了这一点因此在设计时就优先保证可用性。Eureka各个节点都是平等的几个节点挂掉不会影响正常节点的工作剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败则会自动切换至其他节点只要有一台Eureka还在就能保住注册服务的可用性只不过查到的信息可能不是最新的除此之外Eureka还有之中自我保护机制如果在15分钟内超过85%的节点都没有正常的心跳那么Eureka就认为客户端与注册中心出现了网络故障此时会出现以下几种情况
Eureka不在从注册列表中移除因为长时间没收到心跳而应该过期的服务 Eureka仍然能够接受新服务的注册和查询请求但是不会被同步到其他节点上 (即保证当前节点依然可用) 当网络稳定时当前实例新的注册信息会被同步到其他节点中 因此Eureka可以很好的应对因网络故障导致部分节点失去联系的情况而不会像zookeeper那样使整个注册服务瘫痪
BASE 理论
BASE 是 Basically Available(基本可用)、Soft-state(软状态) 和 Eventually Consistent(最终一致性) 三个短语的缩写。
**基本可用**在分布式系统出现故障允许损失部分可用性服务降级、页面降级。**软状态**允许分布式系统出现中间状态。而且中间状态不影响系统的可用性。这里的中间状态是指不同的 data replication数据备份节点之间的数据更新可以出现延时的最终一致性。**最终一致性**data replications 经过一段时间达到一致性。
BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果理论的核心思想就是我们无法做到强一致但每个应用都可以根据自身的业务特点采用适当的方式来使系统达到最终一致性。
康威定律
中文直译大概的意思就是设计系统的组织其产生的设计等同于组织之内、组织之间的沟通结构 注册中心-服务发现 zookeeper, eureka, nacos, consul 一般都分为server和client。每个服务实例都要有自己的服务名(服务id)通常写在配置文件中
spring.application.name服务中心server端要暴漏服务注册地址client在配置文件中配置注册地址在启动时向注册地址注册;
当服务调用发生时注册中心要向client端提供服务列表ribbon不知道Dubbo是怎么样的) 服务列表是谁在向中心获取ribbon还是client
服务注册中心具有以下几个功能
服务注册。服务地址的管理。服务动态感知。
配置中心
一个服务部署部署多个应用实例每个实例都要单独修改配置文件的话太麻烦了搞个配置中心统一管理
配置中心也要集群也要高可用等
配置中心也要有版本管理借助远程仓库如github
nacosconfigzookeeper 很多配置中心都集成注册中心虽然springcloud 中config 和eruka分别担任这两个功能 springclou和hadoop微服务和分布式概念上什么区别一个是java组件一个是解决分布式计算 服务调用 RPC方式 DubbogRpc Http方式: 朴素的http客户端 Ribbon,OpenFeign, Eureka-Client, Consul-Client 这里就比较复杂了因为Ribbon就是基于朴素的Http而feign和Eureka-Client, Consul-Client又集成了Ribbon所以底层都是同一个Http包但是集成了不同的功能、用法是那个包template又是哪个包 主要问题
服务雪崩
不同服务之间相互依赖假如一个被依赖的服务不能向上游的服务提供服务则很可能造成雪崩效应最后导致整个服务不可访问。
如订单-商品-库存这样的调用链然后调用库存超时导致整个超时 让我想起了流水线的游戏突然拆掉一处导致生产线堵塞 关键词调用链路 方案
出问题前预防限流、主动降级、隔离
出问题后修复熔断、被动降级
熔断_被动降级 降级处理“替身文学”为服务准备一个挡灾的替身当服务响应太慢时与其等待正常响应不如先返回“请稍后再试”这样的降级处理 比如现实生活中排队太长了提前告诉排在后面的人“商品已卖完” 如果在某段时间内调用某个服务非常慢甚至超时就可以将这个服务熔断后续其他服务再调用这个服务就直接返回告诉其他服务“已经熔断了你别调用我了过段时间再来试下吧。”
熔断有个原则 一段时间内统计失败的次数或者失败请求的占比超过一定阈值就进行熔断。
详细的原理如下图所示 熔断原理图
下面是原理介绍
6.3 统计请求的算法
请求访问到后台服务后首先判断熔断开关是否打开。如果熔断开关已打开则表明当前请求不能被处理。如果熔断开关未打开则判断时间窗口是否已满。如果时间窗口未满则请求桶中的请求数加 1。如果返回的响应有异常则失败桶的失败数加 1如果返回的响应没有异常则成功桶的成功数加 1。如果时间窗口判断统计错误率已满则开始判断是否需要熔断。
6.4 熔断的恢复算法
当熔断后开关切换到断开状态。过一段时间后开关切换为半断开状态Half-Open。半断开状态下允许对应用程序的一定数量的请求可以去调用服务如果调用成功则认为服务可以正常访问了于是将开关切换为闭合状态。如果半断开状态下还是有调用失败的情况则认为服务还没有恢复开关从半断开状态切换到断开状态。
6.5 统计失败率的时间窗口
时间窗口又分为固定窗口和滑动窗口。
固定时间窗口
原理固定时间内统计流量总量超过阀值则限制流量。
缺陷无法限制短时间之内的集中流量。
滑动窗口原理
原理统计的总时间固定但时间段是滑动的。
缺陷无法控制流量让它们更加平滑
时间窗口的原理图在这里
统计失败率的时间窗口
时间窗口可以比喻为人坐在窗户边看外面来往的车辆一定时间内从窗户外经过的车辆。每次请求都会判断时间窗口是否已满如5分钟如果时间窗口已满则重新开始计时且清理请求数/成功数/失败数。注意第一次开始的起始时间默认为当前时间。
尝试恢复服务的时间窗口
尝试恢复服务的时间窗口
开关为断开的状态经过一定时间后比如 1 分钟设置为半断开的状态尝试发送请求检测服务是否恢复。如果已恢复则切换状态为关闭状态。如果未恢复则切换状态为断开的状态经过 1 分钟后重复上面的步骤。这里的时间窗口可以根据环境的运行状态进行动态调整比如第一次是 1 分钟第二次是 3 分钟第三次是 10 分钟。
中间件 比如阿里系的 Sentinel推荐Netflix 的 Hystrix已停止更新维护阶段。
限流、主动降级
服务降级服务压力剧增的时候根据当前业务情况及流量对一些服务和页面有策略的降级以此缓解服务器的压力以保证核心任务的进行。同时保证部分甚至大部分任务能得到正确的响应如给一个默认的返回
关闭边缘服务以保证核心服务运行 对请求的流量进行控制 只放行部分请求使服务能够承担不超过自己能力的流量压力。
常见限流算法有三种时间窗口、漏桶算法、令牌桶算法。
漏桶算法
原理按照一个固定的速率将流量露出到接收端。
缺陷面对突发流量的时候采用的解决方式是缓存在漏桶中这样流量的响应时间就会增长这就与互联网业务低延迟的要求不符。 令牌桶算法
原理一秒内限制访问次数为 N 次。每隔 1/N 的时间往桶内放入一个令牌。分布式环境下用 Redis 作为令牌桶。原理图如下 总结的思维导图在这里 服务治理
分布式SOA环境下系统的依赖错综复杂。
服务治理主要分为两个方面
服务管理 服务上线下线、服务路由、限流和降级、归组、机房规则、服务授权 相关信息的收集展示 服务基本信息、容量和水准、依赖、调用统计、提供的方法和参数、负责人、统计报表运行状态加监控
依赖管理
服务间互相调用可能形成复杂的网状依赖
调用日志分析
服务分级
