哪个先被淘汰?
作为一个微服务管理和通讯的完整解决方案,两个都不会被淘汰。但是不可否认的是,他们提供的部分功能会被基础设施所取代。比如说服务发现,服务注册的功能,如果你的微服务是部署在 kubernetes 集群上,那么利用 kubernetes 的服务注册和发现的功能会更简单。又比如说负载均衡,流量管理和 circuit breaker 之类的功能,如果用了 istio ,那么这些功能也会被自然转到 envoy 代理上。总之很多功能会从应用程序剥离出来,下沉到基础设施。
为什么是K8S?
试想下传统的后端部署办法:把程序包(包括可执行二进制文件、配置文件等)放到服务器上,接着运行启动脚本把程序跑起来,同时启动守护脚本定期检查程序运行状态、必要的话重新拉起程序。
有问题吗?显然有!最大的一个问题在于:如果服务的请求量上来,已部署的服务响应不过来怎么办?传统的做法往往是,如果请求量、内存、CPU超过阈值做了告警,运维马上再加几台服务器,部署好服务之后,接入负载均衡来分担已有服务的压力。
问题出现了:从监控告警到部署服务,中间需要人力介入!那么,有没有办法自动完成服务的部署、更新、卸载和扩容、缩容呢?
这