Spring Cloud和Kubernetes + Spring Boot 用哪个？
Spring Cloud和Kubernetes + Spring Boot都是用于构建微服务架构的解决方案，它们各有优势和不足，选择哪个更好取决于你的具体需求和上下文。
Spring Cloud是一个基于Spring Boot的微服务开发框架，它提供了一套完整的微服务解决方案，包括服务注册与发现、负载均衡、熔断、智能路由等。Spring Cloud与Spring Boot集成良好，可以快速构建出生产级别的微服务应用。
Kubernetes是一个开源的容器编排引擎，它可以自动化容器的部署、扩展和管理。Kubernetes提供了一种抽象层，使得开发者可以忽略底层Docker容器引擎的具体实现细节，专注于应用的开发和部署。Spring Boot则是一个用于快速创建Spring应用的开发框架，它简化了应用的配置和部署。
对于选择哪个更好，以下是一些考虑因素：
- 技术栈：如果你已经使用了Spring框架，那么Spring Cloud和Kubernetes + Spring Boot都是不错的选择。如果你更倾向于使用其他技术栈，那么可能需要考虑其他解决方案。
- 复杂度：Spring Cloud提供了一套完整的微服务解决方案，但是相对来说也更加复杂一些。Kubernetes + Spring Boot则需要自己搭建一些基础设施，但是相对来说更加灵活和自由。
- 运维能力：如果你有一个强大的运维团队，那么Kubernetes + Spring Boot可能更适合你，因为它们提供了更多的自定义和配置选项。如果你的运维能力相对较弱，那么Spring Cloud可能更适合你，因为它提供了一套更加完整的解决方案。
综上所述，选择Spring Cloud还是Kubernetes + Spring Boot取决于你的具体需求和上下文。建议你可以先了解它们各自的优势和不足，然后结合自己的实际情况做出决策。
参考：构建微服务技术中台，SpringCloud和Kubernetes该如何选型？ (xjx100.cn)
SpringCloud和K8s，分别是Netflix和谷歌，针对微服务公共关注点给出的解，只不过它们两家的解法和侧重点有所不同。这里有两个表，通过这两个表，我们对SpringCloud vs K8s所支持的功能点，做一个全面的横向比对：
- 服务发现和LB：服务发现和LB是微服务基本问题，两家都给出了解决方案。SpringCloud的服务发现主要引用Netflix的Eureka，配合使用Ribbon实现客户端发现和软负载。K8s则直接在平台层解决这个问题，它直接在平台中引入了Service这个抽象概念，屏蔽了底层服务发现和负载均衡细节，让应用开发和服务框架都不需要关心这层细节。
- API网关：这层SpringCloud主要引用Netflix的Zuul网关，它是经过Netflix大流量考验的一个成熟产品。在K8s体系中，和网关对应的概念叫Ingress，它定义了一些规范，具体可以采用各种实现，例如Nginx、Envoy或者Traefik等，都可以做Ingress。
- 配置管理：这块SpringCloud有Spring Cloud Config对应产品，实现比较简单，后端基于git进行配置管理。K8s则在平台层内置支持ConfigMaps/Secrets等配置机制，配置可以通过环境变量注入容器中，也可以挂载到容器文件系统中。
- 限流容错：这块SpringCloud支持Netflix开源的Hystrix容错限流组件，Hystrix在Netflix平台稳定性方面发挥了巨大作用，它已经成为业界限流熔断的一个标配。K8s平台内置支持健康检查(HealthCheck)，启动就绪探针(Probe)等容错机制，如果需要细粒度流量控制，则需要引入ServiceMesh机制进行配合。
- 日志监控：这块两者都没有单独的开源产品，不过社区已经有ELK(Elasticsearch/Logstash/Kibana)这样的成熟标配解决方案，两者都可以直接集成。K8s推荐使用Fluentd进行日志采集。
- Metrics监控：SpringCloud支持MicroMeter/Actuator等机制，可以采集和暴露Metrics指标，方便对接Prometheus等监控告警系统。K8s内置支持MetricServer，可以采集K8s平台内部资源性能指标，方便对接Promethues，如果要进一步监控应用层性能指标，可以引入ServiceMesh配合支持。
- 调用链监控：这块SpringCloud提供Spring Cloud Sleuth，支持对接Zipkin调用链监控。K8s推荐采用Uber开源的Jaeger进行调用链监控，也可以使用Zipkin。
- 应用打包：SpringCloud支持嵌入式容器+Uber Jar方式打包，方便应用发布和运行。K8s则直接支持容器镜像部署，它不关心容器内部的具体应用形式。K8s还支持Helm这样的应用级打包标准，可以实现应用商店。
- 服务框架：Spring本质上是一种HTTP/REST框架，比较松散简单，开发测试都友好。K8s是一个平台，它是具体框架无关的，它只认容器，不同语言栈(Java/Go/Python/Node/Ruby等等)的各种框架都可以住在K8s里头。具体语言栈无关是K8s区别于其它服务框架的最大亮点。
- 发布和调度：这块SpringCloud没有单独考虑，而是交由运维去解决。K8s平台本身重点解决的问题就是服务发布和容器调度。
- 自动伸缩和自愈：这块SpringCloud没有单独考虑，而是交由运维去解决。K8s具备自动故障检测和自愈的能力，自动伸缩需要引入额外组件，完全实现有一定的技术门槛。
- 进程隔离：这块SpringCloud没有单独考虑。K8s通过容器进行进程隔离，同时还引入了Pod进一步对服务进行隔离。
- 环境管理：这块SpringCloud没有单独考虑。K8s内置支持Namespace进行逻辑隔离，可以实现多环境，各个环境可以单独配置认证授权机制。
- 资源配额：这块SpringCloud没有单独考虑。K8s支持对CPU/Memory进行使用量限制，也支持Namespace级别的配额管理。
- 流量治理：主要指高级流量调度，A/B和蓝绿部署等能力。这块SpringCloud没有专门方案。K8s则需要引入ServiceMesh配合支持。
Spring Cloud和Kubernetes优劣比对
SpringCloud的不足主要是仅限于JVM语言栈，其它语言栈支持非常有限。另外，SpringBoot因为封装较多，运行起来比较吃资源，尤其是跑在容器里的时候。
SpringCloud仅解决了微服务基础设施的部分问题，而K8s则是一个完整的微服务基础设施解决方案，所以，K8s是构建微服务技术中台的推荐基础方案。
我比较倾向K8s平台+SpringBoot框架，这两个是目前社区的绝对主流，可以用如日中天来形容，K8s是针对微服务公共关注点最完备的解决方案，服务框架我倾向直接用SpringBoot，我不需要SpringCloud那套，因为它支持的功能K8s已经覆盖了很大部分。另外，考虑到K8s技术门槛和运维成本高，对于一般的中小公司，我不倾向自建K8s，而是建议直接采用公有云K8s(例如阿里云K8s)，把K8s运维的活外包给阿里云(开发商)。
微服务的关注点：
可以看到，里面差不多一半关注点是和运维相关的。这么看来，似乎拿spring cloud和kubernetes比较有点不公平，spring cloud只是一个开发框架，对于应用如何部署和调度是无能为力的，而kubernetes是一个运维平台。也许用spring cloud+cloud foundry去和kubernetes比较才更加合理，但需要注意的是，即使加入了cloud foundry的paas能力，spring cloud仍然是“侵入式”的且语言相关，而kubernetes是“非侵入式”的且语言无关。
spring cloud关注的功能是kubernetes的一个子集，下面来详细对比一下：
kubernetes这边，在Istio还没出来以前，其实只能提供最基础的服务注册、服务发现能力（service只是一个4层的转发代理），istio出来以后，具有了相对完整的微服务能力。而spring cloud这边，除了发布、调度、自愈这些运维平台的功能，其他的功能也支持的比较全面。相对而言，云厂商会更喜欢kubernetes的方案，原因就是三个字：非侵入。平台能力与应用层的解耦，使得云厂商可以非常方便的升级、维护基础设施而不需要去关心应用的情况，这也是我比较看好service mesh这类技术前景的原因。
Istio主要被设计用来连接、保护、控制、观测服务
连接
主要是定义路由规则，配合virtual service和destination rule实现各种高级路由功能，能够非常细粒度的实现灰度、金丝雀、多版本路由等能力，这块是istio的最大亮点，spring cloud这部分能力完全缺失，没得比。
保护
主要是端到端的mTLS加密、服务间认证授权、终端用户认证授权，这部分Spring Cloud提供了Spring Cloud Security可以实现最终用户认证功能，但Spring Security本质上来讲是在单体应用的背景下设计出来的，运用在分布式系统上有诸多不便（例如Session同步），端到端加密和服务间认证也是没有的。
控制
主要是策略（policy），例如黑白名单、限速等各类控制能力，通过适配器（Adapter）实现，并且可以自定义适配器扩展各类个性化的控制能力。这部分由于需要通过mixer来实现，历来争议很大（Istio最新版本policy功能都是默认关闭的）。Spring Cloud可以通过Hystrix/Resillience4j来实现限速、熔断等方面的功能，理论上说istio的设计是更好的，因为适配器是可以灵活扩展的。可惜mixer的设计问题，现在处于比较尴尬的地位，mixer v2计划把policy做到sidecar里面，大方向是对的，可以期待一下。
观测
主要是遥测（telemetry）。一般我们说的可观测性（Observability），包含Logging、Tracing、Metrics 这三部分，istio也都有解决方案。Logging和Metrics不说了，都是通过envoy收集好以后上报给基础设施后端（也是通过mixer，不过这个是异步的，稍微好一点）。
在目前这个时间节点，对于中小型的技术团队来说，我推荐的组合就如文章标题所说：使用spring boot+kubernetes来实现微服务架构，这是一个比较清爽的搭配。如果是没有历史包袱的，且底层基础设施准备上k8s的技术团队来说，个人认为现在来说已经没有必要使用spring cloud了。毕竟kubernetes已经提供了比较完整的微服务解决方案，何苦再自己搞一套服务注册、服务发现、配置管理的轮子呢（况且还是语言绑定）？
基于spring boot+kubernetes的微服务架构技术选型如下：（仅代表个人观点）
服务注册与服务发现：kube-proxy+coredns
配置管理：ConfigMap
api网关：Ingress（外部网关，位于集群入口，https加密，证书管理，域名管理，限速等）+zuul（内部网关，用于服务转发，并可以开发比较灵活的各类定制化适配器）
metrics监控：prometheus+spring actuator
调用链监控：skywalking
日志收集：EFK
参考：Kubernetes 的istio可以完全替代 Spring Cloud 吗？ - 知乎 (zhihu.com)
ServiceMesh是号称可取代SpringCloud的下一代微服务技术。
Spring Cloud是微服务架构的一个解决方案，他的具体实现之一是：Spring Cloud Alibaba
Service Mesh（服务网格）也是微服务架构的一个解决方案，他的具体实现之一是：istio
然后istio是基于k8s的sidecar实现的。
然后这个问题应该是：Serivice Mesh可以完全替代Spring Cloud吗？
作者：烟雨姜囡
链接：https://www.zhihu.com/question/451313635/answer/3164717408
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
Kubernetes的Istio和Spring Cloud是两个不同的技术栈，虽然它们都可以用于构建和管理微服务架构，但它们在很多方面有着不同的设计理念和功能。因此，不能简单地说Istio可以完全替代Spring Cloud，而是应该根据具体的需求和情况来选择使用哪个技术。
以下是一些关键的比较点：
1. 范围和用途：
a. Istio是一个服务网格（Service Mesh）平台，用于管理和监控微服务之间的通信，提供流量管理、故障恢复、安全性等功能。
b. Spring Cloud是一个用于构建微服务的开发框架，提供诸如服务发现、负载均衡、配置管理等功能。
2. 功能重点：
a. Istio专注于处理服务之间的通信、安全性和监控等问题，通过Sidecar代理来实现这些功能。
b. Spring Cloud提供了更多的微服务开发支持，包括服务注册与发现、负载均衡、断路器、配置管理等功能。
3. 复杂性：
a. Istio在处理服务通信时可以提供更高级的功能，但也可能增加部署和管理的复杂性。
b. Spring Cloud相对来说更轻量级，适合小到中等规模的微服务应用。
4. 学习曲线：
a. 学习Istio可能需要更多时间，因为它涉及到服务网格的概念和技术。
b. Spring Cloud更接近传统的Java开发模式，可能对已经熟悉Spring框架的开发者更友好。
Istio和Spring Cloud各自有着自己的优势和适用场景。在某些情况下，您可能会发现Istio能够更好地满足需要，特别是当您关注服务通信、流量管理和监控等方面时。而在其他情况下，Spring Cloud可能更适合，特别是对于那些更侧重于开发和构建微服务的项目。最终的选择应该根据您的项目需求、团队技术熟练程度和偏好来做出。
要搭建基于Kubernetes、Istio和Spring Boot的微服务，您可以按照以下步骤进行操作：
- 创建Kubernetes集群：首先，您需要创建一个Kubernetes集群。您可以选择使用托管的Kubernetes服务，如AKS、GKE或Amazon EKS，或者您可以在本地机器上使用如kubeadm、kubespray等工具自行安装。对于本地开发测试，也可以使用Minikube等工具创建单节点集群。
- 安装Istio：在Kubernetes集群上安装Istio。Istio提供了丰富的微服务治理功能，如流量管理、安全性、可观察性等。您可以访问Istio的官方网站，按照其提供的指南进行安装。
- 创建Spring Boot微服务：使用Spring Boot创建您的微服务应用。Spring Boot是一个基于Java的开发框架，用于创建独立的、生产级的Spring基础应用程序。您可以根据业务需求，使用Spring Boot开发您的微服务应用。
- 部署Spring Boot微服务到Kubernetes：在完成了Spring Boot微服务的开发后，您需要将其部署到Kubernetes集群上。您可以使用Kubernetes的kubectl命令行工具，或者通过编写YAML文件来进行部署。
- 配置Istio进行微服务治理：在Spring Boot微服务成功部署到Kubernetes集群后，您可以通过Istio进行微服务的治理。例如，您可以配置Istio的VirtualService和DestinationRule等资源，来实现微服务的路由、负载均衡、熔断、故障注入等功能。