这是一个创建于 1258 天前的主题，其中的信息可能已经有所发展或是发生改变。
真有服务挂了,eureka 下线其实还挺慢的,就算警报受到了,我也没法在 euraka 的监控面板让它主动下线
然后其实 spring gateway 内部还有缓存机制,重新拉 eureka 也要时间,感觉恢复太慢了
然后其实 spring gateway 内部还有缓存机制,重新拉 eureka 也要时间,感觉恢复太慢了
 |
1
myCupOfTea OP 如果在这套基础上玩弹性伸缩,岂不是延迟很高
|
 |
2
pigbug 2021-07-22 09:15:24 +08:00
@myCupOfTea 只能说能用，弹性伸缩 spring cloud 不支持把。要么 k8s 要么自研
|
 |
3
RichardYyf 2021-07-22 09:24:17 +08:00 via Android
用 spring cloud 这套到了后期一般都需要定制某些组件模块的。既然觉得有问题，就去改呗。我们服务治理就是自研的，然后配套 k8s 做弹性伸缩
|
 |
4
cclander 2021-07-22 09:28:59 +08:00
1.有命令可以让注册在 euraka 上的服务主动下线的。
2.spring cloud 也不是银弹，根据需求开发符合自己的东西才是王道 |
 |
5
securityCoding 2021-07-22 09:31:31 +08:00
这套东西是很烂 ，尤其是那个 loadbalance 模块的代码简直是坨屎，内部缓存刷新机制真的很烦人
|
 |
6
abcbuzhiming 2021-07-22 09:45:37 +08:00
spring cloud 这玩意这不是银弹，它的很多基础组件其实也仅仅是 [开发出来了] 而已，netflix 的那套其实是有点东西的，可是 netflix 后来直接说我不更新了，2.0 闭源，其实微服务的基础组件是有研发难度的。也是比较有价值的东西，真大路货的话 netflix 也不会突然就说不更新了
|
 |
7
cheng6563 2021-07-22 09:46:44 +08:00
然后你会发现，就算你在 Eureka 上把服务下线了，过一会服务自己又注册回来。
|
 |
8
linbiaye 2021-07-22 09:48:51 +08:00
这玩意儿胜在简单，
|
 |
9
buliugu 2021-07-22 10:06:09 +08:00
我们换了 nacos，实时性感觉还可以
|
 |
10
wdlth 2021-07-22 10:09:26 +08:00  2
Spring Boot 和 Spring Cloud 有很多代码都是偷懒的，美名其曰“约定大于配置”，其实一用起来还得自己写配置。
|
 |
11
realrojeralone 2021-07-22 10:17:35 +08:00
要想保证高可用，不能只依赖注册中心，负载均衡器内部也要做服务探活，如果探活失败，就不加到可访问的结点里，即使注册中心告诉你它是活的
|
 |
12
xwayway 2021-07-22 10:19:42 +08:00
我们用的 nacos，然后 gateway 自研的，感觉还行，蓝绿，灰度这种流量控制做得比较好
|
|
13
myCupOfTea OP |
|
14
abcbuzhiming 2021-07-22 11:21:14 +08:00
@myCupOfTea 行呗，老板这不已经发话了，既然老板都不怕死，你怕什么，照着他说的弄。反正手上随时准备后路，老板要死就让他死好了。
|
 |
15
Kyle18Tang 2021-07-22 11:48:36 +08:00
网关和各个微服务可以配置重试机制, 这样拿到已经下线的服务 IP 请求报错就会试其他的.
|
 |
16
anubu 2021-07-22 12:28:16 +08:00
在 k8s 上套的 spring cloud，内部缓存特别烦人，有时间研究的话优先把 eureka 踢出去。
|
 |
17
mmdsun 2021-07-22 13:22:48 +08:00 via Android
记得 eureka 可以 毫秒级的吧。
估计是缓存没关。 另外 eureka spring 还在更新并没有放弃。 netflix 系列除了 eureka，其他的 spring 只是维护了没有更新了。 |
 |
18
yalin 2021-07-22 13:24:33 +08:00
一主二从 传统 HA
|
 |
19
nekoneko 2021-07-22 17:02:00 +08:00
eureka 换 consul 吧,naco 真不推荐
|
 |
20
xuanbg 2021-07-22 21:15:27 +08:00
eureka 换 consul 吧,naco 真心不推荐
|
 |
21
tyit 2021-07-23 00:30:52 +08:00 via iPhone
说说我这边遇到的问题。
对于请求通过 k8s 的 service 层到达 pod 容器的情况，可以通过 k8s 优雅机制来确保 pod 容器在上线滚动更新期间，做到业务"无感知"。但是目前线上 pod 容器服务主动注册到 nacos 配置中心，业务方通过 nacos 网关调用 pod 容器服务，即调用请求绕过了 k8s 的 service 层。 这就出现了一个问题：pod 容器更新期间，老 pod 已经优雅终止掉了，但是其 ip 和端口还在 nacos 的网关缓存里，调用请求会在 nacos 网关缓存未完全更新之前打到已经终止掉的 pod 地址，这就会出现连接超时，调用失败错误，从而造成业务流量损失。 |
 |
22
passerbytiny 2021-07-23 00:56:48 +08:00 via Android
spring cloud 是开源非商业集成器，貌似连可选的商业服务都没有。这是管送不管养的东西，你不能拿来直接用。
|
|
25
securityCoding 2021-07-23 09:30:47 +08:00 via Android
@tyit 我也遇到了，在解决中。k8s 分批更新 nacos 客户端能及时收到推送更新，应该不是 nacos 的问题。我猜应该是 loadbalance 组件的内部缓存，它是自己定时刷新机制，解决思路 1.魔改 loadbalance 源码 2.路由策略支持失败转移
|
Select Language