雪球基础架构梳理

本文主要是介绍雪球基础架构梳理，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

服务发现

为什么不要把ZooKeeper用于服务发现为什么不要把ZooKeeper用于服务发现_java的平凡之路-CSDN博客

问题：

在ZooKeeper中，网络分区中的客户端节点无法到达Quorum时，就会与ZooKeeper失去联系，从而也就无法使用其服务发现机制。因此，在用于服务发现时，ZooKeeper无法很好地处理网络分区问题。作为一个协调服务，这没问题。但对于服务发现来说，信息中可能包含错误要好于没有信息。虽然可以通过客户端缓存和其它技术弥补这种缺陷，像Pinterest和Airbnb等公司所做的那样，但这并不能从根本上解决问题，如果Quorum完全不可用，或者集群分区和客户端都恰好连接到了不属于这个Quorum但仍然健康的节点，那么客户端状态仍将丢失。

更重要地，上述做法的本质是试图用缓存提高一个一致性系统的可用性，即在一个CP系统之上构建AP系统，这根本就是错误的方法。服务发现系统从设计之初就应该针对可用性而设计。

由于这些问题的存在，他们切换到了Eureka。这是一个由Netflix开发的、开源的服务发现解决方案，具有可用性高、恢复能力强的特点。

相比之下，它有如下优点：

如果一个服务器出现问题，Eureka不需要任何类型的选举，客户端会自动切换并连接到一个新的Eureka服务器。当它恢复时，可以自动加入Eureka节点集群。而且，按照设计，它可以在零停机的情况下处理更广泛的网络分区问题。在出现网络分区的情况下，Eureka将继续接受新的注册并发布。这可以确保新增服务仍然可以供分区同侧的任意客户端使用。

Eureka有一个服务心跳的概念，可以阻止过期数据：如果一个服务长时间没有发送心跳，那么Eureka将从服务注册中将其删除。但在出现网络分区、Eureka在短时间内丢失过多客户端时，它会停用这一机制，进入“自我保护模式”。网络恢复后，它又会自动退出该模式。这样，虽然它保留的数据中可能存在错误，却不会丢失任何有效数据。

Eureka在客户端会有缓存。即使所有Eureka服务器不可用，服务注册信息也不会丢失。缓存在这里是恰当的，因为它只在所有的Eureka服务器都没响应的情况下才会用到。

Eureka就是为服务发现而构建的。它提供了一个客户端库，该库提供了服务心跳、服务健康检查、自动发布及缓存刷新等功能。使用ZooKeeper，这些功能都需要自己实现。

管理简单，很容易添加和删除节点。它还提供了一个清晰简洁的网页，上面列出了所有的服务及其健康状况。

Eureka还提供了REST API，使用户可以将其集成到其它可能的用途和查询机制。

Spring-Cloud 支持Eureka、Zookeeper、Consul多种服务发现机制，不过Euraka 显然更活跃。

zookeeper动态配置

雪球当前版本：3.4.6不满足

zookeeper动态配置应用 - 后端技术小屋

在zookeeper 3.5.0版本之前，其配置不支持动态加载，只能通过重启加载新配置。因此在老版本中如果要对zk集群进行扩缩容，需要滚动重启集群中所有节点，以使新的配置生效。而在zookeeper 3.5.0版本之后(包含3.5.0)，引入了动态配置的特性，即zk节点运行时可动态加载zk成员配置，这样可在保持数据一致性的同时不会中断业务。

总结起来，zk动态配置可解决之前zk集群日常扩缩容过程中的如下痛点：

zk集群短时间内不可用：zk节点滚动重启导致重新选举，选举周期内zk集群对外不可用；
依赖zk client端重连：zk节点滚动重启导致已建立的客户端连接被断开，客户端需主动重连其他节点；
扩缩容过程繁琐易出错：在静态配置版本下，扩容操作包括：配置新节点、启动新节点、配置老节点、滚动重启老节点。操作繁琐，步骤冗长，依赖人工容易出错。

升级流程：ClickHouse平台跨国无感迁移Zookeeper实践

版本升级路线：静态版本 -> (不带config version检查的)静态版本 -> 动态版本

注册中心

分布式领域最重要的一篇论文，到底讲了什么？

其他内容见：雪球中间件技术分享_阿拉斯加大闸蟹的博客-CSDN博客

服务网关

初衷：

1.治理东西流量

eg：gPRC基于uid灰度，分流

2.grpc的服务注册、发现

eg：替代现有的zookeeper注册中心

背景：

为什么不选择客户端负载均衡方式？
使用gRPC客户端负载均衡器，该负载均衡器被嵌入到gRPC客户端库中。
这样，每个客户端微服务都可以执行自己的负载均衡。
但是，最终的客户非常脆弱，需要大量的自定义代码来提供任何形式的弹性，指标或日志记录，所有这些我们的变更都会需要业务系统配合。

ProxyClient Side优势客户端可以专心业务逻辑，无需感知后端

其他厂商：

vivo 微服务 API 网关架构实践

美团-百亿规模API网关服务Shepherd的设计与实现

长亮科技-企业级微服务架构中的API网关设计

Uber API 网关的架构

腾讯云 API 网关实现多维度精细化限流

京东API网关实践之路！

爱奇艺微服务平台 API 网关实战

自如闭门会之API网关的落地实践

API网关在微博的实践

API网关包含统一接入、流量监控、协议适配、安全防护等四项基本能力。

中心化：缺点是链路变长带来的rt增高、流量集中不可控；从注册中心、配置中心、共享存储、解密协议、接口白名单等多个角度，讲解如何设计去中心化的SDK。

自如网关演进之路

选择基于zuul，依赖nginx解决服务发现问题来实现自如网关1.0。

1.0有rt响应延迟、依赖nginx熔断不及时、流量治理功能缺失等问题。

vivo 微服务 API 网关架构实践（主要调研了Zuul1、Zuul2、Spring Cloud Gateway、Dromara Soul。）

1 服务注册发现

2 动态路由：机房就近路由、灰度路由

3 负载均衡

4 动态配置

5 API管理

6 协议转换

7 安全机制

8 监控/告警

9 限流/熔断

10 无损发布

11 网关集群分组隔离

服务没有清晰的path前缀、独立的域名拆分，虽然是微服务体系，但是大家共用一个域名，接口前缀也没有良好的划分，混用在一起：客户端请求传递过来的时候，需要在请求Header传递 scTag 参数，scTag用来标记是哪个微服务集

美团-百亿规模API网关服务Shepherd的设计与实现（将Jetty容器全面替换为Netty网络框架，性能提升10%以上，Shepherd端到端的QPS成功提升到15000以上。）

1 协议转换&服务调用

2 集群隔离&请求隔离支持请求的快慢线程池隔离

3 流量管控&请求缓存&超时管理&熔断降级

4 请求安全用户鉴权Passport、商家鉴权EPassport、商家权益鉴权、反爬等等

5 可灰度

6 立体化监控&多维度告警

7 故障自愈

8 易用性设计&自动生成DSL&快速创建API

9 可扩展性设计&自定义组件&服务编排

对于一些已经在对外提供API的Web服务，对于一些非核心API，可以考虑使用Oceanus的灰度发布功能直接迁移；对于一些核心API，提供了一个灰度SDK

未来一年，Shepherd的规划重点包括有云原生架构演进、静态网站托管、组件市场等。

目前接入Shepherd API网关的API数量超过18000多个，线上运行的集群数量90多个，日均总调用次数在百亿以上。

长亮科技API网关总体设计（用当前主流技术栈Spring Boot,Spring Cloud体系。）

1 接入接出扩展

2 加解密扩展

3 网关请求响应二次扩展

4 扩展网关响应码及响应信息

5 API限流&熔断降级&API路由

6 协议安全&访问安全&权限控制&签名认证&黑白名单&JWT认证

7 报文安全&流量安全

Uber API 网关的架构（https://github.com/uber/zanzibar）golang

1 协议管理器

2 中间件层

3 端点处理程序层&客户端

4 审计管道可以跨特定的 SDK 版本、应用程序、地理位置或互联网提供商快速捕获 Bug、问题和异常。

5 挑战和教训：语言&序列化格式&配置存储&网关 UI&了解有效载荷

在 Uber，我们正基于 Envoy 开发一种 API 网关运行时，用于从应用程序到后端服务的 gRPC 请求，我们的自助服务 UI 在用户体验上没有很大的变化。

腾讯云 API 网关实现多维度精细化限流（github.com/serverless）js

支持设置三种资源维度（API、应用、ClientIP）和四种时间维度（秒、分钟、小时、天）的限流

1.通过 API 网关服务区分不同业务模块

2. 通过 API 网关 API 区分不同业务模块

支持的监控指标包括请求数、出流量、响应时间、错误数等，所有监控指标都支持 1 分钟、5 分钟、1 小时、1 天四种时间维度

京东API网关实践之路！（利用NIO多路复用，达到请求接收最大化。）

1）高性能：在高吞吐量下保证低延迟。

2）安全稳定：身份认证、精细化流量控制、大数据实时分析等多种手段保障服务质量。

3）平台化：进行各项数据监控，提供数据分析、监控告警、故障定位等服务。

4）灰度：灰度发布，支持按设备、PIN、自定义比例方式在不影响正常用户的情况下，保障后端服务平稳过渡。

5）方便快捷：支持http、jsf服务快捷接入，mock功能加快协同开发。

精细化流控：

授权及签名认证：

跨域效验：

灰度发布：

1 独立部署与快速扩展

2 数据分析与监控告警

3 线上环境故障定位

爱奇艺微服务平台 API 网关实战（Kong 基于 Nginx 实现，成熟稳定且性能可靠，并拥有灵活强大的插件机制）

1 服务解析

2 定向路由

3 容灾：API 开发者认为某集群流量处理异常时，也可以利用虚拟网关域名自助切走流量。

4 API性能追踪

现已维护超过 4000 个 API，持续吸引新旧业务接入。API 网关当前平均单日 API 访问量超过 300 亿、峰值QPS 近 100 万。

服务治理

解决问题

问题类型	问题示例	解决方案
安全	被调方如何判断是否允许某个主调方访问	访问鉴权
故障容错	当被调方的部分实例异常时，如何屏蔽异常实例，屏蔽之后如何恢复	熔断降级
服务可见	主调方如何知道被调方的服务地址	注册发现
流量控制	被调方包含多个实例，主调方如何确定请求发送到哪个实例，如何保证请求均衡	负载均衡
	当某些主调方的请求量过多时，如何限制这些主调方的请求，避免影响其他主调方的请求	访问限流
	如何实现按地域就近、单元化隔离、金丝雀发布等各种请求调度策略	动态路由

业内应用：

腾讯北极星

美团基于Service Mesh的服务治理系统详解

阿里-在 Dubbo3.0 上服务治理的实践

快手服务治理平台 KESS 的设计理念和实战

字节跳动：超复杂调用网下的服务治理新思路

用户规模5亿+的余额宝是如何做服务治理的？

服务治理在猫眼娱乐的演进之路

天弘基金-余额宝背后的服务治理架构

然而雪球毛都没

流量回放平台

流量回放是什么

流量回放是系统重构、拆分、中台化时重要的自动化回归手段。通过采集可录制流量，在指定环境回放，再逐一对比每个调用和子调用差异来发现接口代码是否存在问题。因为线上流量大、场景全面，可以有效弥补人工评估测试范围的局限性，进而降低业务快速迭代带来的风险。

业内应用：

有赞流量回放在中台营销的实践

海量流量下，淘宝如何进行稳定的流量回放

干货 | 高效率低成本，携程流量回放平台实践

哔哩哔哩「会员购」在流量回放上的探索

【好未来网校事业部】基于线上流量回放的质量保障方案

字节跳动自研线上引流回放系统的架构演进

然而雪球毛都没

全链路压测

Takin

doc：数列科技 - Powered by MinDoc

code：https://github.com/shulieTech/Takin

ApacheBench
Apache 服务器自带，简单易用，但不支持场景编排、不支持分布式，二次开发难度较大
JMeter
JMeter 支持上述很多特性，如分布式、良好的压测报告等，但其基于 GUI 的使用方式，使得当我们的压测场景非常复杂并包含很多请求时，使用上不够灵活；此外在流量控制方面的支持也一般
nGrinder
基于 Grinder 二次开发的开源项目，支持分布式，测试报告良好，但和 JMeter 一样，在场景编排和流量控制方面支持一般
Gatling
支持场景编排、流量控制、压力控制，测试报告良好，且提供了强大的 DSL（领域特定语言）方便编写压测脚本，但不支持分布式，且使用 Scala 开发，有一定开发成本

参考资料：

阿里全链路压测

有赞全链路压测

京东全链路压测

饿了么全链路压测

滴滴全链路压测解决之道

美团全链路压测自动化实践

逻辑思维在全链路压测方面的实践

然而雪球毛都没

当然了没有就是机会，创造适合雪球业务体量的机会，毕竟把apisix服务网关都上了，而且grpc已经使用了7、8年了，come on！！

这篇关于雪球基础架构梳理的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！