网站制作top,wordpress资源下载站,中国循环经济网站开发与设计,wordpress 停止Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 #xff0c;邀请了四位来自不同公司的嘉宾#xff0c;从不同角度展开了 Service Mesh 的应用实践分享#xff0c;分享涵盖来自陌陌和百度的 Servi… Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 邀请了四位来自不同公司的嘉宾从不同角度展开了 Service Mesh 的应用实践分享分享涵盖来自陌陌和百度的 Service Mesh 生产实践Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别还有如何使用 SkyWalking 来观测 Service Mesh。本文根据5月13日晚百度高级工程师罗广明的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。前言Service Mesh 在企业落地中有诸多挑战当与传统微服务应用共同部署治理时可用性挑战更为严峻。本次分享将以 Service Mesh 与 Spring Cloud 应用互联互通共同治理为前提着重介绍基于 Consul 的注册中心高可用方案通过各种限流、熔断策略保证后端服务的高可用以及通过智能路由策略负载均衡、实例容错等实现服务间调用的高可用。Service Mesh 与 Spring Cloud 应用的互通、互联微服务是时下技术热点大量互联网公司都在做微服务架构的推广和落地。同时也有很多传统企业基于微服务和容器在做互联网技术转型。而在这个技术转型中国内有一个现象以 Spring Cloud 与 Dubbo 为代表的微服务开发框架非常普及和受欢迎。近年来 新兴的 Service Mesh 技术也越来越火热受到越来越多开发者的关注大有后来居上的趋势。在听到社区里很多人谈到微服务技术选型时注意到他们讨论一个非此即彼的问题采用 Spring Cloud 还是以 Istio 为代表的 Service Mesh 技术然而这个答案并非非黑即白、非你即我一部分应用采用 Spring Cloud另一部分采用 Service MeshIstio是完全可能的。今天我就和大家一起来讨论这个问题。首先我们来看一下 Spring Cloud 这个传统侵入式微服务框架。它包含以下优点集大成者Spring Cloud 包含了微服务架构的方方面面选用目前各家公司开发的比较成熟的、经得住实践考验的服务框架轻量级组件Spring Cloud 整合的组件大多比较轻量级且都是各自领域的佼佼者开发简便Spring Cloud 对各个组件进行了大量的封装从而简化了开发开发灵活Spring Cloud 的组件都是解耦的开发人员可以灵活按需选择组件。特别感谢 Netflix 这家很早就成功实践微服务的公司几年前把自家几乎整个微服务框架栈贡献给了社区早期的 Spring Cloud 主要是对 Netflix 开源组件的进一步封装。不过近两年Spring Cloud 社区开始自研了很多新的组件也接入了其他一些互联网公司的优秀实践。接下来我们简单看一下 Service Mesh 框架。它带来了两大变革微服务治理与业务逻辑的解耦异构系统的统一治理。此外服务网格相对于传统微服务框架还拥有三大技术优势可观察性、流量控制、安全。服务网格带来了巨大变革并且拥有其强大的技术优势被称为第二代“微服务架构”。然而就像之前说的软件开发没有银弹传统微服务架构有许多痛点而服务网格也不例外也有它的局限性。这些局限性包括增加了链路与运维的复杂度、需要更专业的运维技能、带来了一定的延迟以及对平台的适配。更多关于 Spring Cloud 与 Service Mesh 的优缺点与比较请阅读 Istio-Handbook [Service Mesh 概述]。前面提到过对于传统微服务框架 Spring Cloud 与新兴微服务框架 Service Mesh并非是个非黑即白非你即我延伸到微服务与单体架构它们也是可以共存的。也可以将其与混合云相类比混合云中包含了公有云、私有云可能还有其它的自有基础设施。目前来看混合云是一种流行的实践方式实际上可能很难找到一个完全单一云模式的组织。对多数组织来说将一个单体应用完全重构为微服务的过程中对开发资源的调动是一个很严峻的问题采用混合微服务策略是一个较好的方式对开发团队来说这种方式让微服务架构触手可及否则的话开发团队可能会因为时间、经验等方面的欠缺无法接受对单体应用的重构工作。构建混合微服务架构的最佳实践最大化收益的部分优先重构非 Java 应用优先采用 Service Mesh 框架。混合微服务出现的原因是为了更好的支持平滑迁移最大限度的提升服务治理水平降低运维通信成本等并且可能会在一个较长的周期存在着。而实现这一架构的前提就是各服务的“互联互通”。要想实现上述“混合微服务架构”运行时支撑服务必不可少它主要包括服务注册中心、服务网关和集中式配置中心三个产品。传统微服务和 Service Mesh 双剑合璧双模微服务即“基于 SDK 的传统微服务”可以和“基于 Sidecar 的 Service Mesh 微服务”实现下列目标互联互通两个体系中的应用可以相互访问平滑迁移应用可以在两个体系中迁移对于调用该应用的其他应用做到透明无感知灵活演进在互联互通和平滑迁移实现之后我们就可以根据实际情况进行灵活的应用改造和架构演进。这里还包括对应用运行平台的要求即两个体系下的应用既可以运行在虚拟机之上也可以运行在容器 /K8s 之上。我们不希望把用户绑定在 K8s 上因此 Service Mesh 没有采用 K8s 的 Service 机制来做服务注册与发现这里就突出了注册中心的重要性。百度智能云 CNAP 团队实现了上述混合微服务架构即实现了两个微服务体系的应用互联互通、平滑迁移、灵活演进。上述混合微服务架构图包括以下几个组件API Server前后端解耦接口权限控制、请求转发、异常本地化处理等等微服务控制中心微服务治理的主要逻辑包括服务注册的多租户处理、治理规则路由、限流、熔断的创建和转换、微服务配置的管理监控数据存储、消息队列主要是基于 Trace 的监控方案使用的组件配置中心微服务配置中心最主要的功能是支持配置管理包括治理规则、用户配置等所有微服务配置的存储和下发微服务配置中心的特色是借助 SDK 可以实现配置/规则热更新。接下来主要看一下注册中心的服务注册和发现机制Spring Cloud 应用通过 SDK、Service Mesh 应用实现 Sidecar 分别向注册中心注册注册的请求先通过微服务控制中心进行认证处理与多租户隔离Mesh 控制面直接对接注册中心获取服务实例、Spring Cloud 应用通过 SDK 获取服务实例双模异构支持容器与虚机两种模型。注册中心与高可用方案前面提到过要想实现实现混合微服务架构注册中心很关键。谈到注册中心目前主流的开源注册中心包括ZookeeperYahoo 公司开发的分布式协调系统可用于注册中心目前仍有很多公司使用其作为注册中心EurekaNetflix 开源组件可用于服务注册发现组件被广大 Spring Cloud 开发者熟知遗憾的是目前已经不再维护也不再被 Spring Cloud 生态推荐使用ConsulHashiCorp 公司推出的产品其可作为实现注册中心也是本文介绍的重点EtcdEtcd 官方将其定义为可靠的分布式 KV 存储。我们注册中心选择了 ConsulConsul 包含了以下几个重要的功能服务发现可以注册服务也可以通过 Http 或 DNS 的方式发现已经注册的服务丰富的健康检查机制服务网格能力最新版本已经支持 Envoy 作为数据面KV 存储可以基于 Consul KV 存储实现一个分布式配置中心多数据中心借助多数据中心无需使用额外的抽象层即可构建多地域的场景支持多 DC 数据同步、异地容灾。上图是 Consul 官网提供的架构图。Consul 架构中几个核心的概念如下Agent: Agent 是运行在 Consul 集群的每个节点上的 Daemon 进程通过 Consul Agent 命令将其启动Agent 可以运行在 Client 或者 Server 模式下ClientClient 是一种 Agent其将会重定向所有的 RPC 请求到 ServerClient 是无状态的其主要参与 LAN Gossip 协议池其占用很少的资源并且消耗很少的网络带宽ServerServer 是一种 Agent其包含了一系列的责任包括参与 Raft 协议写半数Raft Quorum、维护集群状态、响应 RPC 响应、和其他 Datacenter 通过 WAN gossip 交换信息和重定向查询请求至 Leader 或者远端 DatacenterDatacenter: Datacenter 其是私有的、低延迟、高带宽的网络环境去除了在公共网络上的网络交互。注册中心作为基础组件其自身的可用性显得尤为重要高可用的设计需要对其进行分布式部署同时因在分布式环境下的复杂性节点因各种原因都有可能发生故障因此在分布式集群部署中希望在部分节点故障时集群依然能够正常对外服务。注册中心作为微服务基础设施因此对其容灾和其健壮性有一定的要求主要体现在注册中心作为微服务基础设施因此要求出现某些故障如节点挂掉、网络分区后注册中心仍然能够正常运行当注册中心的发生故障时不能影响服务间的正常调用。Consul 使用 Raft 协议作为其分布式一致性协议本身对故障节点有一定的容忍性在单个 DataCenter中 Consul 集群中节点的数量控制在 2*n 1 个节点其中 n 为可容忍的宕机个数。Quorum size: Raft 协议选举需要半数以上节点写入成功。Q1: 节点的个数是否可以为偶数个A2答案是可以的但是不建议部署偶数个节点。一方面如上表中偶数节点4和奇数节点3可容忍的故障数是一样的另一方面偶数个节点在选主节点的时候可能会出现瓜分选票的情形虽然 Consul 通过重置 election timeout 来重新选举所以还是建议选取奇数个节点。Q2: 是不是 Server 节点个数越多越好A2答案是否定的虽然上表中显示 Server 数量越多可容忍的故障数越多熟悉 Raft 协议的读者肯定熟悉 Log Replication 如上文介绍日志复制时过半写成功才返回写成功随着 Server 的数量越来越多性能就会越低所以结合实际场景一般建议 Server 部署3个节点。推荐采用三节点或五节点最为有效且能容错。注册中心设计的一个重要前提是注册中心不能因为自身的原因或故障影响服务之间的相互调用。因此在实践过程中如果注册中心本身发生了宕机故障/不可用绝对不能影响服务之间的调用。这要求对接注册中心的 SDK 针对这种特殊情况进行客户端容灾设计『客户端缓存』就是一种行之有效的手段。当注册中心发生故障无法提供服务时服务本身并不会更新本地客户端缓存利用其已经缓存的服务列表信息正常完成服务间调用。我们在设计时采用同 Datacenter 集群内部部署3个 Server 节点来保障高可用性当集群中1个节点发生故障后集群仍然能够正常运行同时这3个节点部署在不同的机房达到机房容灾的能力。在云上环境涉及多 region 环境因此在架构设计设计时我们首先将 Consul 的一个 Datacenter 对应云上一个 region这样更符合 Consul 对于 Datecenter 的定义DataCenter 数据中心是私有性、低延迟、高带宽的网络环境。中间代理层实现了服务鉴权、多租户隔离等功能还可以通过中间代理层对接多注册中心。云上环境存在多租户隔离的需求即A租户的服务只能发现A租户服务的实例。针对此场景需要在 『中间代理层』完成对多租户隔离功能的实现其主要实践思路为使用 Consul Api Feature 具备 Filtering 功能利用 Filtering 功能实现租户隔离需求减少查询注册中心接口时网络负载。通过治理策略保证服务高可用什么是高可用维基百科这么定义系统无中断地执行其功能的能力代表系统的可用性程度是进行系统设计时的准则之一。我们通常用 N 个9来定义系统的可用性如果能达到4个9则说明系统具备自动恢复能力如果能达到5个9则说明系统极其健壮具有极高可用性而能达到这个指标则是非常难的。常见的系统不可用因素包括程序和配置出 bug、机器故障、机房故障、容量不足、依赖服务出现响应超时等。高可用的抓手包括研发质量、测试质量、变更管理、监控告警、故障预案、容量规划、放火盲测、值班巡检等。这里将主要介绍通过借助治理策略采用高可用设计手段来保障高可用。高可用是一个比较复杂的命题所以设计高可用方案也涉及到了方方面面。这中间将会出现的细节是多种多样的所以我们需要对这样一个微服务高可用方案进行一个顶层的设计。比如服务冗余冗余策略每个机器每个服务都可能出现问题所以第一个考虑到的就是每个服务必须不止一份而是多份。所谓多份一致的服务就是服务的冗余这里说的服务泛指了机器的服务、容器的服务、还有微服务本身的服务。在机器服务层面需要考虑各个机器间的冗余是否有在物理空间进行隔离冗余。无状态化我们可以随时对服务进行扩容或者缩容想要对服务进行随时随地的扩缩容就要求我们的服务是一个无状态化所谓无状态化就是每个服务的服务内容和数据都是一致的。比如柔性化/异步化所谓的柔性化就是在我们业务允许的情况下做不到给予用户百分百可用的通过降级的手段给到用户尽可能多的服务而不是非得每次都交出去要么 100 分或 0 分的答卷。柔性化更多是一种思维需要对业务场景有深入的了解。异步化在每一次调用时间越长存在超时的风险就越大逻辑越复杂执行的步骤越多存在失败的风险也就越大。如果在业务允许的情况下用户调用只给用户必须要的结果不是需要同步的结果可以放在另外的地方异步去操作这就减少了超时的风险也把复杂业务进行拆分减低复杂度。上面讲到的几种提高服务高可用的手段大多需要从业务以及部署运维的角度实现。而接下来会重点介绍可以通过 SDK/Sidecar 手段提供服务高可用的治理策略这些策略往往对业务是非侵入或者弱侵入的能够让绝大多数服务轻松实现服务高可用。微服务之间一旦建立起路由就意味着会有数据在服务之间流通。由于不同服务可以提供的资源和对数据流量的承载能力不尽相同为了防止单个 Consumer 占用 Provider 过多的资源或者突发的大流量冲击导致 Provider 故障需要服务限流来保证服务的高可用。在服务治理中虽然我们可以通过限流规则尽量避免服务承受过高的流量但是在实际生产中服务故障依然难以完全避免。当整个系统中某些服务产生故障时如果不及时采取措施这种故障就有可能因为服务之间的互相访问而被传播开来最终导致故障规模的扩大甚至导致整个系统奔溃这种现象我们称之为“雪崩”。熔断降级其实不只是服务治理中在金融行业也有很广泛的应用。比如当股指的波动幅度超过规定的熔断点时交易所为了控制风险采取的暂停交易措施。负载均衡是高可用架构的一个关键组件主要用来提高性能和可用性通过负载均衡将流量分发到多个服务器同时多服务器能够消除这部分的单点故障。以上治理规则在某种程度上可以在 Spring Cloud 与 Service Mesh 两个框架上进行对齐即同一套治理配置可以通过转换分发到 Spring Cloud 应用的 SDK 上以及 Service Mesh 的 Sidecar 上。可以由 Config-server 负责规则下发也可以由 Service Mesh 的控制面负责下发取决于具体的架构方案。服务限流对于一个应用系统来说一定会有极限并发/请求数即总有一个 TPS/QPS 阀值如果超了阀值则系统就会不响应用户请求或响应的非常慢因此我们最好进行过载保护防止大量请求涌入击垮系统。限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的请求进行限速来保护系统一旦达到限制速率则可以拒绝服务或进行流量整形。常用的微服务限流架构包括接入层api-gateway限流单实例多实例分布式限流算法调用外部限流服务限流微服务收到请求后通过限流服务暴露的 RPC 接口查询是否超过阈值需单独部署限流服务切面层限流SDK限流功能集成在微服务系统切面层与业务解耦可结合远程配置中心使用常用的限流策略包括拒绝策略超过阈值直接返回错误调用方可做熔断降级处理。延迟处理前端设置一个流量缓冲池将所有的请求全部缓冲进这个池子不立即处理。然后后端真正的业务处理程序从这个池子中取出请求依次处理常见的可以用队列模式来实现MQ削峰填谷用异步的方式去减少了后端的处理压力。特权处理这个模式需要将用户进行分类通过预设的分类让系统优先处理需要高保障的用户群体其它用户群的请求就会延迟处理或者直接不处理。常用的限流算法包括固定时间窗口限流首先需要选定一个时间起点之后每次接口请求到来都累加计数器如果在当前时间窗口内根据限流规则比如每秒钟最大允许 100 次接口请求累加访问次数超过限流值则限流熔断拒绝接口请求。当进入下一个时间窗口之后计数器清零重新计数缺点在于限流策略过于粗略无法应对两个时间窗口临界时间内的突发流量。滑动时间窗口算法流量经过滑动时间窗口算法整形之后可以保证任意时间窗口内都不会超过最大允许的限流值从流量曲线上来看会更加平滑可以部分解决上面提到的临界突发流量问题是对固定时间窗口算法的一种改进缺点在于需要记录在时间窗口内每个接口请求到达的时间点对内存的占用会比较多。令牌桶算法接口限制 t 秒内最大访问次数为 n则每隔 t/n 秒会放一个 token 到桶中桶中最多可以存放 b 个 token如果 token 到达时令牌桶已经满了那么这个 token 会被丢弃接口请求会先从令牌桶中取 token拿到 token 则处理接口请求拿不到 token 就阻塞或者拒绝服务。漏桶算法对于取令牌的频率也有限制要按照 t/n 固定的速度来取令牌实现往往依赖于队列请求到达如果队列未满则直接放入队列然后有一个处理器按照固定频率从队列头取出请求进行处理。如果请求量大则会导致队列满那么新来的请求就会被抛弃令牌桶和漏桶算法的算法思想大体类似漏桶算法作为令牌桶限流算法的改进版本。令牌桶算法和漏桶算法在某些场景下内存消耗、应对突发流量这两种算法会优于时间窗口算法成为首选。熔断断路器模式是微服务架构中广泛采用的模式之一旨在将故障的影响降到最低防止级联故障和雪崩并确保端到端性能。我们将比较使用两种不同方法实现它的优缺点: Hystrix 和 Istio。在电路领域中断路器是为保护电路而设计的一种自动操作的电气开关。它的基本功能是在检测到故障后中断电流然后可以重置(手动或自动)以在故障解决后恢复正常操作。这看起来与我们的问题非常相似为了保护应用程序不受过多请求的影响最好在后端检测到重复出现的错误时立即中断前端和后端之间的通信。Michael Nygard 在他的《Release It》一书中使用了这个类比并为应用于上述超时问题的设计模式提供了一个典型案例可以用上图来总结。Istio 通过 DestinationRule 实现断路器模式或者更具体的路径 TrafficPolicy (原断路器) - OutlierDetection根据上图模型consecutiveErrors 断路器打开前的出错次数interval 断路器检查分析的时间间隔baseEjectionTime 最小的开放时间该电路将保持一段时间等于最小弹射持续时间和电路已打开的次数的乘积maxEjectionPercent 可以弹出的上游服务的负载平衡池中主机的最大百分比如果驱逐的主机数量超过阈值则主机不会被驱逐。与上述公称断路器相比有两个主要偏差:没有半开放的状态。然而断路器持续打开的时间取决于被调用服务之前失败的次数持续的故障服务将导致断路器的开路时间越来越长。在基本模式中只有一个被调用的应用程序(后端)。在更实际的生产环境中负载均衡器后面可能部署同一个应用程序的多个实例。某些情况下有些实例可能会失败而有些实例可能会工作。因为 Istio 也有负载均衡器的功能能够追踪失败的实例并把它们从负载均衡池中移除在一定程度上: ‘maxEjectionPercent’ 属性的作用是保持一小部分的实例池。Hystrix 提供了一个断路器实现允许在电路打开时执行 fallback 机制。最关键的地方就在 HystrixCommand 的方法 run() 和 getFallback()run() 是要实际执行的代码 e.g. 从报价服务中获取价格getFallback() 获取当断路器打开时的 fallback 结果 e.g. 返回缓存的价格。Spring Cloud 是建立在 Spring Boot 之上的框架它提供了与 Spring 的良好集成。它让开发者在处理 Hystrix 命令对象的实例化时只需注释所需的 fallback 方法。实现断路器的方法有两种一种是黑盒方式另一种是白盒方式。Istio 作为一种代理管理工具使用了黑盒方式它实现起来很简单不依赖于底层技术栈而且可以在事后配置。另一方面Hystrix 库使用白盒方式它允许所有不同类型的 fallback:单个默认值一个缓存调用其他服务。它还提供了级联回退cascading fallbacks。这些额外的特性是有代价的它需要在开发阶段就做出fallback 的决策。这两种方法之间的最佳匹配可能会依靠自己的上下文: 在某些情况下如引用的服务一个白盒战略后备可能是一个更好的选择而对于其他情况下快速失败可能是完全可以接受的如一个集中的远程登录服务。常用的熔断方法包括自动熔断与手动熔断。发生熔断时也可以选择 fail-fast 或者 fallback。这些用户都可以基于需求灵活使用。智能路由最后我们来看一下智能路由带来的高可用。智能路由这里包括客户端负载均衡与实例容错策略。对于 Spring Cloud 框架来说这部分能力由 Ribbon 来提供Ribbon 支持随机、轮询、响应时间权重等负载均衡算法。而对于 Service Mesh 框架这部分能力由 Envoy 提供Envoy 支持随机、轮询加权、环哈希等算法。为了实现两套系统的规则统一对齐可以采用其交集。而容错策略包括failover失败后自动切换其他服务器支持配置重试次数failfast失败立即报错不再重试failresnd将失败请求放入缓存队列、异步处理搭配 failover 使用。Istio 支持重试策略配置而 fail-fast 即对应与重试次数为0。总结微服务的高可用是一个复杂的问题往往需要从多个角度去看包括从手段看高可用。主要使用的技术手段是服务和数据的冗余备份和失效转移一组服务或一组数据都能在多节点上之间相互备份。当一台机器宕机或出现问题的时候可以从当前的服务切换到其他可用的服务不影响系统的可用性也不会导致数据丢失。从架构看高可用。保持简单的架构目前多数网站采用的是比较经典的分层架构应用层、服务层、数据层。应用层是处理一些业务逻辑服务层提供一些数据和业务紧密相关服务数据层负责对数据进行读写。简单的架构可以使应用层服务层可以保持无状态化进行水平扩展这个属于计算高可用。同时在做架构设计的时候也应该考虑 CAP 理论。从硬件看高可用。首先得确认硬件总是可能坏的网络总是不稳定的。解决它的方法也是一个服务器不够就来多几个一个机柜不够就来几个一个机房不够就来几个。从软件看高可用。软件的开发不严谨发布不规范也是导致各种不可用出现通过控制软件开发过程质量监控通过测试预发布灰度发布等手段也是减少不可用的措施。从治理看高可用。将服务规范化事前做好服务分割做好服务监控预判不可用的出现在不可用出现之前发现问题解决问题。比如在服务上线后根据经验配置服务限流规则以及自动熔断规则。以上就是本期分享的全部内容。直播回放地址https://www.bilibili.com/video/BV1WT4y1u73W分享 PPT 下载地址https://github.com/servicemesher/meetup-slides/tree/master/2020/05/virtual参考资料Service Mesh 概述https://www.servicemesher.com/istio-handbook/concepts/overview.htmlConsul 作为注册中心在云环境的实践与应用https://mp.weixin.qq.com/s/zoS-5oyfh9EV6S5PLy54yg有了这三个锦囊再也不用担心微服务治理了https://mp.weixin.qq.com/s/62237UuEEJiOP_b3xRrZog一文理解微服务高可用的常用手段https://mp.weixin.qq.com/s/oky8g1Nisdr2T4kYG-DFhg微服务断路器模式实现Istio vs Hystrixhttps://www.servicemesher.com/blog/istio-vs-hystrix-circuit-breaker/详见https://www.servicemesher.com/blog/service-mesh-webinar-1/点击 阅读原文 查看更多
