- 主题:k8s和服务网格成熟之后，springcloud是不是白学了
唉…
--
FROM 123.123.40.*
个人觉得
如果要微服务，springboot之流应该太臃肿了
如果只是分布式，springboot/cloud 还是有生存空间的
【 在 Millor 的大作中提到: 】
: 唉…
:
--
FROM 111.206.87.*
【 在 hothail 的大作中提到: 】
: 个人觉得
: 如果要微服务，springboot之流应该太臃肿了
为啥？能讲讲不
: 如果只是分布式，springboot/cloud 还是有生存空间的
: ...................
--
FROM 223.104.38.*
那就看你究竟学了点啥了
服务发现，负载均衡，统一配置管理，熔断保护
所有这些问题都是需要解决的，无非手段不同
K8原生没有sidecar的话
应该还没有熔断保护这些应用层特性
【 在 Millor 的大作中提到: 】
: 唉…
:
--
FROM 39.144.105.*
真正大服务量，我之前知道的，k8s那套，现在不知道如何了。主要是k8s延迟太大，故障重启慢。比如服务状态检测，轮询。比如配置变更，重启pod是不合适的。
不知道现在如何了？
【 在 javafish 的大作中提到: 】
: 那就看你究竟学了点啥了
: 服务发现，负载均衡，统一配置管理，熔断保护
: 所有这些问题都是需要解决的，无非手段不同
: ...................
--
FROM 120.244.162.*
k8s怎么会延迟大？
【 在 lushan5436 (密如) 的大作中提到: 】
: 真正大服务量，我之前知道的，k8s那套，现在不知道如何了。主要是k8s延迟太大，故障重启慢。比如服务状态检测，轮询。比如配置变更，重启pod是不合适的。
: 不知道现在如何了？
: 【 在 javafish 的大作中提到: 】
: : 那就看你究竟学了点啥了
--
FROM 112.45.97.*
实现原理的问题吧？比如重启，原来是进程监控，kill掉后自动拉起，这个触发式肯定比轮询快。
【 在 poikilotherm 的大作中提到: 】
: k8s怎么会延迟大？
: --
: 发自xsmth (iOS版)
--
FROM 120.244.162.*
那是进程调度延迟
这个你很难说响应快就一定是对的
【 在 lushan5436 的大作中提到: 】
: 真正大服务量，我之前知道的，k8s那套，现在不知道如何了。主要是k8s延迟太大，故障重启慢。比如服务状态检测，轮询。比如配置变更，重启pod是不合适的。
: 不知道现在如何了？
--
FROM 116.233.92.*