关于云原生-cloud-native:流量暴增掌门教育如何基于-Spring-Cloud-Alibaba-构建微服务体系

44次阅读

共计 9388 个字符，预计需要花费 24 分钟才能阅读完成。

作者 | 童子龙  掌门教育基础架构部架构师

导读： 本文整顿自作者于 2020 年云原生微服务大会上的分享《掌门教育云原生落地实际》，本文次要介绍了掌门教育云原生落地实际，次要围绕 Spring Cloud Alibaba & Nacos & Sentinel & Arthas 等微服务云原生技术栈施行构建，基于 Docker 和 阿里云 Kubernetes 云原生容器的实现落地，着重介绍 Nacos 服务器高可用性部署、监控，Nacos 和 Eureka 同步服务器高可用双向同步和容灾，以及和 DevOps 运维公布平台的整合。

阿里巴巴云原生公众号后盾回复 818 即可获取直播回看地址和大会 PPT 合集。

背景

掌门教育自 2014 年正式转型在线教育以来，秉承“让教育共享智能，让学习高效高兴”的主旨和愿景，经验云计算、大数据、人工智能、AR / VR / MR 以及现今最火的 5G，始终保持用科技赋能教育。掌门教育的业务近几年失去了疾速倒退，特地是往年的疫情，使在线教育成为了新的风口，也给掌门教育新的时机。

随着业务规模进一步扩充，流量进一步暴增，微服务数目进一步增长，使老的微服务体系所采纳的注册核心 Eureka 不堪重负，同时 Spring Cloud 体系曾经演进到第二代，第一代的 Eureka 注册核心曾经不大适宜当初的业务逻辑和规模，同时它目前被 Spring Cloud 官网置于保护模式，将不再向前倒退。如何抉择一个更为优良和实用的注册核心，这个课题就摆在了掌门人的背后。

为什么抉择 Spring Cloud Alibaba&Nacos

通过对 Alibaba Nacos、HashiCorp Consul 等开源注册核心做了深刻的调研和比拟，以下是各个注册核心的个性比照：

  • Nacos

    • 反对 AP+CP 一致性共识协定
    • 反对 Agent DNS-F 服务注册发现形式，跨语言
    • 反对负载平衡，雪崩爱护机制
    • 反对多数据中心，跨注册核心迁徙

  • Consul

    • 只反对 CP 协定
    • 反对 HTTP/DNS 协定

  • K8s CoreDns

    • 反对 DNS 协定

论断：Nacos 满足目前掌门的服务治理技术栈，能实现注册核心的平滑迁徙，社区倒退十分沉闷，所提供的个性，使得围绕 Spring Cloud Alibaba&Nacos 可能十分不便的构建云原生利用的动静服务注册发现。

一.Nacos server 落地

1. Nacos Server 部署


（Nacos Server 部署概览图）

  • Nacos Server 环境和域名

掌门的应用环境分为 4 套，DEV、FAT、UAT、PROD 别离对应开发、测试、准生产环境、生产环境，因而 Nacos Server 也分为 4 套独立环境。除了 DEV 环境是单机部署外，其余是集群形式部署。对外均以域名形式拜访，SLB 做负载平衡，包含 SDK 形式连贯 Nacos Server 和拜访 Nacos Server Dashboard 控制台页面。

  • Nacos Server 环境隔离和调用隔离

Nacos 数据模型由 namespace / group / service 形成。能够通过创立不同的命名空间，做到同一个应用环境的根底上更细粒度的划分，隔离服务注册和发现。在某些场景下，开发本地有须要连贯测试环境的 Nacos Server，但其余测试服务不能调用到开发本地，这时候能够将 NacosDiscoveryProperties 的 enabled 属性设置为 false。

  • Nacos Server 集成 Ldap

Nacos Server Dashboard 集成公司的 Ldap 服务，并在用户首次登录时记录用户信息。

2. Nacos Server 界面

 

  • Nacos 界面权限

Nacos Server Dashboard 用户首次登陆时，默认调配普通用户（即非 ROLE_ADMIN）角色，对查问以外的按钮均无操作权限，免得呈现误操作导致服务非正常高低线。

  • Nacos 界面显示服务概览

Nacos Server Dashboard 页面减少服务总数及实例总数的统计，该信息每 5 秒刷新一次。


 

3. Nacos 监控

 

  • 规范监控

基于公司现有的 Prometheus、Grafana、AlertManager 从零碎层监控 Nacos。

  • 高级监控

依据 Nacos 监控手册，联合 Prometheus 和 Grafana 监控 Nacos 指标。

  • 服务实例状态监控

  • 监听实例下线事件
  • 监听实例登记事件
  • 监听实例注册事件
  • 监听实例上线事件
  • 监听实例心跳超时事件

4. Nacos 日志

 

  • 日志合并及 JSON 格式化

将 Nacos 多模块的日志对立按 info、warn、error 级别合并，定义 schema 字段标记不同模块，按 JSON 格局滚动输入到文件，供 ELK 采集展现。

5. Nacos 告警

 

  • 业务服务高低线的告警

  • 服务名大写告警

6. Nacos 性能测试

 

  • 外围脚本 
def registry(ip):
    fo = open("service_name.txt", "r")
    str = fo.read()
    service_name_list = str.split(";")
    service_name = service_name_list[random.randint(0,len(service_name_list) - 1)]
    fo.close()
    client = nacos.NacosClient(nacos_host, namespace='')
    print(client.add_naming_instance(service_name,ip,333,"default",1.0,{'preserved.ip.delete.timeout':86400000},True,True))
    while True:
      print(client.send_heartbeat(service_name,ip,333,"default",1.0,"{}"))
      time.sleep(5)
  • 压测数据

  • 压测后果图

总结：Nacos Server 是 3 台 1C4G 集群，同时接受 1499 个服务和 12715 个实例注册，而且 CPU 和内存长期保持在一个适合的范畴内，果然 Nacos 性能是相当 OK 的。

二.Nacos Eureka Sync 落地

 

1. Nacos Eureka Sync 计划选型

 

① Sync 官网计划

通过钻研，咱们采取了官网的 Nacos Eureka Sync 计划，在小范畴试用了一下，成果良好，但一部署到 FAT 环境后，发现基本不行，一台同步服务器无奈抗住将近 660 个服务（非实例数）的频繁心跳，同时该计划不具备高可用特点。
 

② Sync 高可用一致性 Hash + Zookeeper 计划

既然一台不行，那么就多几台，但如何做高可用呢？

咱们率先想到的是一致性 Hash 形式。当一台或者几台同步服务器挂掉后，采纳 Zookeeper 长期节点的 Watch 机制监听同步服务器挂掉状况，告诉残余同步服务器执行 reHash，挂掉服务的工作由残余的同步服务器来承当。通过一致性 Hash 实现被同步的业务服务列表的平均分配，基于对业务服务名的二进制转换作为 Hash 的 Key 实现一致性 Hash 的算法。咱们自研了这套算法，发现平均分配的很不现实，第一工夫狐疑是否算法有问题，于是找来 Kafka 自带的算法（见 Utils.murmur2），发现成果仍旧不现实，起因还是业务服务名的自身散布就是不均匀的，于是又回到自研算法上进行了优化，根本达到预期，下文会具体讲到。但说实话，直到现在仍旧无奈做到十分良好的相对均匀。

③ Sync 高可用主备 + Zookeeper 计划

这个计划是个小插曲，当一台同步服务器挂掉后，由它的“备”顶上，当然主备切换也是基于 Zookeeper 长期节点的 Watch 机制来实现的。前面探讨下来，主备计划，机器的老本很高，实现也不如一致性 Hash 优雅，最初没采纳。

④ Sync 高可用一致性 Hash + Etcd 计划

折腾了这么几次后，发现同步业务服务列表是长久化在数据库，同步服务器挂掉后 ReHash 告诉机制是由 Zookeeper 来负责，两者是否能够合并到一个中间件上以降低成本？于是咱们想到了 Etcd 计划，即通过它实现同步业务服务列表长久化 + 业务服务列表增减的告诉 + 同步服务器挂掉后 ReHash 告诉。至此计划最终确定，即两个注册核心（Eureka 和 Nacos）的双向同步计划，通过 Etcd 来做桥梁。

2. Nacos Eureka Sync 落地实际

① Nacos Eureka Sync 指标准则

注册核心迁徙指标：

  • 过程并非欲速不达的，业务服务逐渐迁徙的过程要保障线上调用不受影响，例如，A 业务服务注册到 Eureka 上，B 业务服务迁徙到 Nacos，A 业务服务和 B 业务服务的相互调用必须失常；
  • 过程必须保障双注册核心都存在这两个业务服务，并且指标注册核心的业务服务实例必须与源注册核心的业务服务实例数目和状态放弃实时严格统一。

注册核心迁徙准则：

  • 一个业务服务只能往一个注册核心注册，不能同时双向注册；
  • 一个业务服务无论注册到 Eureka 或者 Nacos，最终后果都是等效的；
  • 一个业务服务在绝大多数状况下，个别只存在一个同步工作，如果是注册到 Eureka 的业务服务须要同步到 Nacos，那就有一个 Eureka -> Nacos 的同步工作，反之亦然；在平滑迁徙中，一个业务服务一部分实例在 Eureka 上，另一部分实例在 Nacos 上，那么会产生两个双向同步的工作；
  • 一个业务服务的同步方向，是依据业务服务实例元数据（Metadata）的标记 syncSource 来决定。

② Nacos Eureka Sync 问题痛点

  • Nacos Eureka Sync 同步节点须要代理业务服务实例和 Nacos Server 间的心跳上报。Nacos Eureka Sync 将心跳上报申请放入队列，以固定线程生产，一个同步业务服务节点解决的服务实例数超过肯定的阈值会造成业务服务实例的心跳发送不及时，从而造成业务服务实例的意外失落；
  • Nacos Eureka Sync 节点宕机，下面解决的心跳工作会全副失落，会造成线上调用大面积失败，结果不堪设想；
  • Nacos Eureka Sync 曾经开始工作的时候，从 Eureka 或者 Nacos 上，新上线或者下线一个业务服务（非实例），都须要让 Nacos Eureka Sync 实时感知。

③ Nacos Eureka Sync 架构思维

  • 从各个注册核心获取业务服务列表，初始化业务服务同步工作列表，并长久化到 Etcd 集群中；
  • 后续迁徙过程增量业务服务通过 API 接口长久化到 Etcd 集群中，业务服务迁徙过程整合 DevOps 公布平台。整个迁徙过程全自动化，躲避人为操作造成的脱漏；
  • 同步服务订阅 Etcd 集群获取工作列表，并监听同步集群的节点状态；
  • 同步服务依据存活节点的一致性 Hash 算法，找到解决工作节点，后端接口通过 SLB 负载平衡，删除工作指令轮询到的节点。如果是本人解决工作则移除心跳，否则找到解决节点，代理进来；
  • 同步服务监听源注册核心每个业务服务实例状态，将失常的业务服务实例同步到指标注册核心，保障单方注册核心的业务服务实例状态实时同步；
  • 业务服务所有实例从 Eureka 到 Nacos 后，须要业务部门告诉基础架构部手动从 Nacos Eureka Sync 同步界面摘除该同步工作。

④ Nacos Eureka Sync 集群分片及高可用计划

服务一致性 Hash 分片路由：

  • 依据如上图 1 多集群部署，为每个节点设置可配置的虚构节点数，使其在 Hash 环上能均匀分布；
  • 依据业务服务名的 FNV1_32_HASH 算法计算每个业务服务的哈希值，计算该 Hash 值顺时针最近的节点，将工作代理到该节点。

同步节点宕机故障转移：

  • 节点监听：监听其它节点存活状态，配置 Etcd 集群租约 TTL，TTL 内至多发送 5 个续约心跳以保障一旦呈现网络稳定防止造成节点失落；
  • 节点宕机：其中某个节点宕机，其工作转移到其它节点，因为有虚构节点的缘曾经故，所以此节点的工作会平衡 ReSharding 到其它节点，那么，集群在任何时候，工作解决都是分片平衡的，如上图 2 中，B 节点宕机，##1、##2 虚构节点的工作会别离转移到 C 和 A 节点，这样防止一个节点承当宕机节点的所有工作造成残余节点间断雪崩；
  • 节点复原：如图 3，节点的虚构节点从新增加到 Hash 环中，Sharding 规定变更，复原的节点会依据新的 Hash 环规定承当其它节点的一部分工作，心跳工作一旦在节点产生都不会主动隐没，这时须要清理其它节点的多余工作（即重新分配给复苏节点的工作），给其它节点减负（这一步十分要害，不然也可能会引发集群的间断雪崩），保障集群复原到最后失常工作同步状态；
  • 节点容灾：如果 Etcd 集群连贯不上，则存活节点从配置文件中获取，集群失常运作，然而会失去容灾能力。

3. Nacos Eureka Sync 保障伎俩

 

① Nacos Eureka Sync 同步界面

从如下界面能够保障，从 Eureka 或者 Nacos 上，新上线或者下线一个业务服务（非实例），都能让 Nacos Eureka Sync 实时感知。但咱们做了更进一层的智能化和自动化：

  • 新增同步：联合 DevOps 公布平台，当一个业务服务（非实例）新上线的时候，智能判断它是从哪个注册核心上线的，而后回调 Nacos Eureka Sync 接口，主动增加同步接口，例如，A 业务服务注册到 Eureka 上，DevOps 公布平台会主动增加它的 Eureka -> Nacos 的同步工作，反之亦然。当然从如下界面的操作也可实现该性能；
  • 删除同步：因为 DevOps 公布平台无奈判断一个业务服务（非实例）下线，或者曾经迁徙到另一个注册核心，曾经全副结束（有同学会反诘，能够判断的，即查看那个业务服务的实例数是否是零为规范，但咱们应该思考，实例数为零在网络故障的时候也会产生，即心跳全副失落，所以这个判断根据是不谨严的），交由业务人员来判断，同时配合钉钉机器人告警揭示，由基础架构部同学从如下界面的操作实现该性能。

② Nacos Eureka Sync Etcd 监控

从如下界面能够监控到，业务服务列表是否在同步服务的集群上出现一致性 Hash 平衡散布。

③ Nacos Eureka Sync 告警

  • Nacos Eureka Sync 告警

  • 业务服务同步结束的告警

4.Nacos Eureka Sync 降级演练

  • 7 月某天早晨 10 点开始，FAT 环境进行演练，通过自动化运维工具 Ansible 两次执行一键降级和回滚均没问题；
  • 早晨 11 点 30 开始，执行灾难性操作，察看智能复原情况，9 台 Nacos Eureka Sync 挂掉 3 台的操作，只失落一个实例，但 5 分钟后复原（经考察，问题定位在 Eureka 上某个业务服务实例状态异样）；
  • 早晨 11 点 45 开始，持续挂掉 2 台，只剩 4 台，故障转移，同步失常；
  • 早晨 11 点 52 开始，复原 2 台，Nacos Eureka Sync 集群从新平衡 ReHash，同步失常；
  • 早晨 11 点 55 开始，全副复原，Nacos Eureka Sync 集群从新平衡 ReHash，同步失常；
  • 12 点 14 分，极限劫难演练，9 台挂掉 8 台，剩 1 台也能抗住，故障转移，同步失常；
  • 凌晨 12 点 22 分，降级 UAT 环境顺利；
  • 凌晨 1 点 22，降级 PROD 环境顺利；
  • 容灾复原中的 ReHash 工夫小于 1 分钟，即 Nacos Eureka Sync 服务大面积故障产生时，复原工夫小于 1 分钟。

三.Solar 云原生微服务实际


（Solar 云原生微服务体系）

Solar 微服务体系，囊括微服务治理组件，中间件以及根底组件易用性封装，告警监控体系等，连贯着掌门业务服务和底层基础设施，每项服务都恪守强有力的合约，向着云原生微服务架构方向演进。 

1. 基于 Spring Cloud Alibaba、Nacos、Sentinel 等 SDK

① Alibaba Nacos

  • Solar Nacos SDK 内置 DEV | FAT | UAT | PROD 四个环境的域名，业务零碎无感知 Solar Nacos SDK 基于 Spring Cloud Alibaba 整合携程 VI Cornerstone 实现微服务点火熄火拉入拉出；
  • Solar Nacos SDK 在 Nacos 和 Eureka 双注册核心过渡状态下，反对跨注册核心调用的蓝绿灰度公布和子环境性能；
  • Solar Nacos SDK 集成灰度蓝绿埋点到 SkyWalking；
  • Solar Nacos SDK 通过 @EnableSolarService，@EnableSolarGateway 封装了规范 Spring Boot / Spring Cloud / Apollo / Zuul 等大量注解，升高业务的应用老本；
  • Solar Nacos SDK 和 Solar Eureka SDK 降级和回滚；
  • Solar Nacos SDK 联合 Java Agent 形式，解决异步调用场景下的跨线程调用的上下文失落。

②  Alibaba Sentinel

  • Solar Sentinel SDK 内置 DEV | FAT | UAT | PROD 四个环境的域名，业务零碎无感知

    • SDK 通过获取以后机器所在的环境，适配以后所要连贯的 Sentinel 地址

  • Solar Sentinel SDK 深度集成 Apollo SDK

    • Sentinel 配置，长久化到服务的 apollo 的 namespace 上面，下次重启从 apollo 获取配置加载到内存
    • 以 appId 的维度配置利用熔断限流规定

  • Solar Sentinel SDK 整合 OpenTracing & SkyWalking，输入 Sentinel 埋点到 SkyWalking

    • 通过 SkyWalking 提供的 OpenTracing 工具包，手动埋点，获取 span 信息，推送到 SkyWalking 长久化到 ES

  • Solar Sentinel SDK Dashboard 长久化革新，集成 InfluxDB & Grafana

    • 将 Sentinel Metrics 数据长久化到时序数据库 InfluxDB 中，而后通过 Grafana 展现

  • Solar Sentinel SDK Limit-App 熔断扩大（特色性能：灰度蓝绿公布指标的熔断）

    • 灰度蓝绿调用时，如果探测到版本匹配失败时，则抛 BlockException

  • Solar Sentinel SDK 网关流控，微服务单机限流

    • 全链路压测帮忙理解服务能承载流量峰值
    • 信号量隔离 /QPS, 并发线程数限流 / 均匀响应工夫、秒级异样比率、分钟级异样数熔断
    • 基于 TCP BBR 的零碎爱护算法，主动探测系统瓶颈，爱护零碎稳定性

  • Solar Sentinel SDK 集群限流

    • 通过集群限流来解决集群各个机器的流量不均导致整体限流成果不准确的问题

2. 灰度蓝绿和环境隔离

  • 基于 Spring Cloud Alibaba、Nacos SDK、Nepxion Discovery 开源框架（https://github.com/Nepxion/Discovery）
  • 蓝绿灰度公布：版本匹配灰度公布、版本权重灰度公布
  • 多区域路由：区域匹配灰度路由、区域权重灰度路由
  • 环境隔离：环境隔离、环境路由

3. 基于 DevOps 公布平台的智能化和半自动化灰度蓝绿

 

  • 智能化公布入口界面 

  • 蓝绿条件驱动模式界面

  • 蓝绿权重放量模式界面

 

  • 全量公布和回滚界面

4. 基于 DevOps 公布平台的滚动无损公布

  1. 运维 CD 公布平台，先将实例状态设置 disabled，实例从注册核心拉出；
  2. 消费者订阅注册核心，告诉消费者实例处于不可用状态；
  3. 消费者进行路由转发到不可用实例；
  4. 服务下面流量持续解决，30S 后才会启动实例公布脚本；
  5. 实例重启胜利后，CD 平台通过申请寄宿在业务 Web 容器里的 VI 接口检测实例衰弱状态；
  6. 状态检测衰弱后，注册到 Nacos 注册核心；
  7. 消费者订阅到新的实例，申请失常负载。

5. 分布式追踪和 APM 零碎 SkyWalking

  • 所有服务异样监控大盘

 

  • 接口性能指标

  • 服务维度的异样监控看板，聚合链路中异样数量，帮忙业务疾速定位问题

 

  • 集成 Solar 全链路灰度蓝绿埋点

  • 集成 Sentinel 限流降级熔断埋点

  • 整合服务、实例、接口维度性能指标
  • 疾速定位异样、慢 SQL、熔断链路
  • 整合链路与日志
  • 服务、实例、接口、链路维度拓扑图
  • 整合利用诊断系统（Arthas & Bistoury)

6. 利用诊断系统 Arthas & Bistoury

  • 无需登录机器
  • 整合 Arthas，Web 化控制台  从 CPU、线程、内存、JVM 等方面对利用进行诊断
  • 热点办法剖析
  • 在线 Debug 

四. Solar 云原生容器化实际

1. CI/CD 继续公布

  • CD Platform 通过 jinkens 编译打包生成 Jar 包和 Docker img，通过 Harbor 上传镜像到 OSS 平台，Harbor 通过 SLB 做高可用；
  • 自研 Hyperion 两头服务，作为连贯 Harbor 和阿里云 K8s 的 API 调用中间层；
  • CD Platform 通过 Hyperion 调用阿里云 K8s API 公布镜像，K8s 从 Harbor 拉取镜像，deploy 到物理节点；
  • 阿里云 K8s 推送状态事件给 Hyperion，Hyperion 将数据推送给 .CD Platform 实时展现公布状态信息。

2. 日志收集

  1. Pod 将日志写到容器内的门路 /opt/logs/{appid}/xxx；
  2. 建设软连贯指向 Node 门路 /var/log/{appid}/{podid}/xxx；
  3. 一个物理节点启动一个 FileBeat 过程收集此物理节点上所有 Pod 日志信息；

PS：通过全面的压测，一个物理节点上启动一个 FileBeat 过程收集所有 Pod 日志，性能没有问题
如果存在日志收集不及时问题，则能够一个 Pod 挂载一个 FileBeat 过程来解决，这样的毛病是会占用更多系统资源。

  1. FileBeat 将日志信息推送到 Kafka；
  2. GoHangout 并发生产 Kafka 中数据，长久化到 ES 集群中；

GoHangout 并发生产 Kafka 音讯性能比拟好。

  1. Kibana 显示 ES 中所有日志索引数据。

3. 微服务弹性扩容和自愈

  • CPU 负载
  • Memory
  • Metrics：依据熔断、限流、监控等组件提供的 Metric 指标做弹性伸缩和自愈；
  • 依据课堂排课信息的容量布局：如下图掌门上课状况十分法则，流量峰值也法则散布，依据排课信息等数据来布局将来几小时内微服务须要承载容量，并依照打算，调配 Pod 数量

4. 平滑迁徙网络解决方案

 

  • 阿里云 Terway Kubernetes 集群提供 CNI Plugin 实现 Pod IP、Node IP 处于同一立体；
  • Pod 每次公布 IP 都会发生变化，内网沿用虚拟机时代的拜访和治理计划；
  • 外网拜访通过阿里云 SLB，SLB 能主动探测 IP 变动；
  • 基础架构在微服务构建下面曾经有很深的积攒，充分利用 Spring Cloud Alibaba 以及 Nacos 等一系列服务治理计划，使咱们云原生容器化过程可能平滑迁徙到阿里云 K8s。

结语：以上就是掌门教育围绕 Spring Cloud Alibaba 构建云原生微服务技术体系的一个全貌，掌门教育也会追随社区技术倒退的脚步，朝着微服务 Service Mesh 网格化，serverless 函数计算的方向一直演进，很多年前，大家可能在探讨服务上云的危险，随着云原生技术的一直成熟，当初大家更多的是探讨服务不上云的危险，心愿此次分享能给那些筹备应用 Spring Cloud Alibaba 微服务系上云的或者正在上云的同学一些实用性的参考和指引，谢谢大家！

Spring Cloud Alibaba 七天训练营炽热开营！

PC 端点击链接理解详情：https://developer.aliyun.com/learning/trainingcamp/spring/1

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术畛域、聚焦云原生风行技术趋势、云原生大规模的落地实际，做最懂云原生开发者的公众号。”

正文完
云原生-cloud-native
2020-09-10
 0
关于云原生-cloud-native:突围数字化转型让特步同比增长248的全渠道中台
关于云原生-cloud-native:深入解读KubeVela-与-PaaS-有何不同
关于云原生-cloud-native:SpringCloud-应用在-Kubernetes-上的最佳实践-诊断线上联调
关于云原生-cloud-native:云原生时代应用架构将如何演进