服务发现
为什么不要把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 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优势客户端可以专心业务逻辑，无需感知后端
其他厂商：
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 网关的架构（github.com/uber/zanzib…
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 万。
服务治理
解决问题
| 问题类型 | 问题示例 | 解决方案 |
|---|---|---|
| 安全 | 被调方如何判断是否允许某个主调方访问 | 访问鉴权 |
| 故障容错 | 当被调方的部分实例异常时，如何屏蔽异常实例，屏蔽之后如何恢复 | 熔断降级 |
| 服务可见 | 主调方如何知道被调方的服务地址 | 注册发现 |
| 流量控制 | 被调方包含多个实例，主调方如何确定请求发送到哪个实例，如何保证请求均衡 | 负载均衡 |
| 当某些主调方的请求量过多时，如何限制这些主调方的请求，避免影响其他主调方的请求 | 访问限流 | |
| 如何实现按地域就近、单元化隔离、金丝雀发布等各种请求调度策略 | 动态路由 |
业内应用：
然而雪球毛都没
流量回放平台
流量回放是什么
流量回放是系统重构、拆分、中台化时重要的自动化回归手段。通过采集可录制流量，在指定环境回放，再逐一对比每个调用和子调用差异来发现接口代码是否存在问题。因为线上流量大、场景全面，可以有效弥补人工评估测试范围的局限性，进而降低业务快速迭代带来的风险。
业内应用：
然而雪球毛都没
全链路压测
Takin
- ApacheBench
Apache 服务器自带，简单易用，但不支持场景编排、不支持分布式，二次开发难度较大 - JMeter
JMeter 支持上述很多特性，如分布式、良好的压测报告等，但其基于 GUI 的使用方式，使得当我们的压测场景非常复杂并包含很多请求时，使用上不够灵活；此外在流量控制方面的支持也一般 - nGrinder
基于 Grinder 二次开发的开源项目，支持分布式，测试报告良好，但和 JMeter 一样，在场景编排和流量控制方面支持一般 - Gatling
支持场景编排、流量控制、压力控制，测试报告良好，且提供了强大的 DSL（领域特定语言）方便编写压测脚本，但不支持分布式，且使用 Scala 开发，有一定开发成本
参考资料：
然而雪球毛都没
当然了 没有就是机会，创造适合雪球业务体量的机会，毕竟把apisix服务网关都上了，而且grpc已经使用了7、8年了，come on！！
