k8s 相比 Spring Cloud 优势在哪呢？

SpringCloud 是 Java 语言的给你写分布式程序用的框架，什么熔断降级负载均衡都带了，你只要注册到 Eureka 上，再写点业务代码即可，说简单点是写程序用的。

Kubernetes 不局限于语言，并且现在也有熔断降级之类的插件，但主要还是为了集群处理和监控这些，说简单点是运维用的。

简单列几个 SpringCloud 带来的运维问题：
1. 几十个、 几百上千个节点的管理及弹性扩容；
2. 日志收集问题；
3. 某个服务不可用问题；
4. 滚动更新 /历史回退问题；
这几个问题基本上不是在 SpringCloud 层面解决的，而 Kubernetes 可以很轻松解决。

最后说个个人偏见，没事别碰阿里的开源。

@chenPiMeiHaoChi 谢谢大佬

两种东西

跟业务功能无关但又需要根据项目实施场景来定制的基础设施是放在哪里？通过库 /组件引入业务系统，还是在业务系统之外作为独立的基础设施用运维手段搞定？不同背景的人有不同的答案。

单一技术栈、以纯程序员为主的团队，用 SpringCloud 或者类似的其它能把基础设施集成到程序里的“全开发”式方案会比较顺手，而混合技术栈、运维技能全面的团队，可能更适合业务逻辑归业务逻辑，基础设施归基础设施，后者多使用运维手段来解决。

Everything in Java, everything in coding……反正我是不太喜欢这样的乙方团队给我干活的。

@chenPiMeiHaoChi #1 搜了下这书的作者, 不是华为的吗, 不过连个 https 都没也是...

@chenPiMeiHaoChi
@914496397
不碰怕是难，现在后端高级到资深、架构师等，面试动不动就问 K8s

@DAPTX4869
@VoiceEXONE
我这里指的是阿里的 SpringCloud 的开源组件和其他的开源，就像 Nacos 那些。

有本书，《凤凰架构》比较系统的对比了这些东西，不过讲得对不对好不好我就没法评测了。

https://icyfenix.cn/exploration/projects/microservice_arch_springcloud.html

@jie170601 额就看了标题，没看内容，撤不回吗，社死

完全没有任何优势

@VoiceEXONE k8s 又不是阿里的，楼上是说阿里的开源项目

@adoal #5 没听明白 老哥你是不喜欢全 in java 还是全 in coding ？ 如果是后者 我想问下为什么？

@914496397 +1 ，dubbo ，nacos 全都是垃圾

@ql562482472 all in coding 说的是全都自己写吧，太累了，而且代码质量甚至架构质量大概率都不太行

这是完全不同的俩东西，把 k8s 的 pod 当成是一个在运行的系统就行，只不过 k8s 集群能提供配置中心，自动发现这些功能给 pod 用，pod 里面跑 java 还是跑 go 或者跑 c 都无所谓，对 k8s 来说，它只是个 pod ，管理的也是 pod

spring cloud 只是 java 的框架，感觉你把 k8s 理解错了，打个比喻，你的这个问题相当于在问 Linux 系统相比于 java 语言的优势在哪

@chenPiMeiHaoChi 也是我的偏见，阿里出来的东西不要碰，属于模因污染 doge

@yimiaoxiehou #16 我是没理解这个 coding 指的是什么 ，我主要是想了解类似 IaC as Code 这种形态是否会受到甲方偏见

阿里的东西不碰 那你们都用什么大佬，能给介绍一下么
比如 nacos 、rocketmq 、sentinal ，
垃圾在哪里？或者介绍介绍平替啥的
这边使用 2 年多了，确实没感觉哪垃圾，可能是我垃圾吧。

@hui9000 阿里的东西不讲规范，写的随心所欲，迭代的随心所欲。没有测试。没有文档。没人维护。

@hui9000 apollo 就比 nacos 好用，nacos 的说明文档和代码示例都对不上，网上一搜写法天花乱坠，最后都不知道哪个是对的

@kerb15 nacos 没法细分权限 我们根本用不了 我两年前给他提了个 issue 到今天还开着呢
https://github.com/alibaba/nacos/issues/7328

@ql562482472 主要是后者。

因为面向行业信息化的软件系统里，业务功能和基础设施功能可以看作是两个不同的领域。既然是不同领域，就有不同的知识模型。不排除做行业信息化的公司里也有相当的专家熟悉基础设施领域的知识，但因为做行业信息化的公司其核心价值是解决客户的业务发展需求，所以首要的关注点、投入最大技术人力成本的方向是实现业务功能。而基础设施领域里则有更擅长的参与者。对于做行业信息化的公司来讲，要业务功能开发人员兼顾基础设施开发，实际上是逆分工而行，出力不讨好。尤其是，相当一大部分程序员是没有能力写高质量的基础设施的。

给你举个我遇到的真实例子。上级信息主管部门发来安全通告，某个业务系统的后台管理模使用的开源组件老版本爆出 CVE ，要求限期内处理。问供应商，答曰我们用的这个业务系统已经是老版本了，他们公司现在主推新版，老版不再更新，而且那个开源组件直接换成新版的可能不兼容……可以给我们安装新版本的业务系统并迁移数据，不额外收钱。但是新版本安装实施时间挺长的，超过处理期限了。我说你们老系统的 web server 是 IIS 这种通用的玩意，你后台管理模块路径是确定的，在 IIS 里配一个 ACL 规则，先把后台管理限制在我们单位的 IP 范围内，对最终用户还是全部开放，这样不行么？对方说，加上限制 IP 的功能要排期做开发，旧版系统他们不改动了。我说这是运维手段解决问题，不需要你们程序员改代码。对方还是坚持这是功能变更。吵了好几轮，最终还是我放弃了。先停掉有问题的旧版系统再说。

举这个例子是想说明，像分模块做 IP ACL 之类的功能，其实是和客户的“业务”功能没有关系的基础设施功能。做基础设施软件的开发商（不论是 IIS 开发者微软这种真的“商”，还是免费的 Apache 、Nginx ）早就把基础设施功能玩得溜溜转，你能想到的基础设施功能需求很可能就是用现成软件做做配置就好了，你没想到的，他们也都早替你想到了。而他们在基础设施领域的经验、技术能力、成本投入，都不是做业务系统的开发商在完成客户业务功能开发这一核心价值之外顺便来开发基础设施功能所能比拟的。善用成熟的第三方基础设施软件，善用运维手段解决非业务方面的功能需求，这在某种意义上也是解耦，不次于“开发”中所做的解耦。尤其是复杂的软件系统会跨越不同编程语言、运行在不同进程甚至不同机器上，用好成熟基础设施，往往能比业务纯程们在写业务功能之余自己去造基础设施的轮子，甚至比起用现成的基础设施库或框架嵌到自己写的程序里调用，都有更好的收效。据说 Spring Boot 时代，主流的做法是构建一个巨大的 jar 用 java 命令启动，不提倡构建成 war 放到 tomcat 之类容器里运行。这种做法当然有其应用场合和原因。但是我想问一下，从来不碰生产环境运维配置的纯程们，是否知道只靠修改 tomcat 的 server.conf 、不自己写代码，能对 tomcat 的行为做多少控制，能解决多少你们第一反应是写代码实现的非业务功能需求？这些如果都靠业务纯程们来写，要多少工作量？代码质量如何，是否能担得起“基础设施”的质量要求？即使不自己写，靠项目里 embed 一个 tomcat 或者 jetty 的核心包，如果要达到打包好的 tomcat/jetty 的可配置程度，你又要在自己的项目里写多少代码来处理配置？

@ql562482472 甲方一般不关心技术。我是异种。

地基相比地板优势在哪呢？

不考虑一互大的秒杀这种极端需求，在普通的信息系统应用场合，绝大多数“顺手写出来”的 log 库，还不如打到 syslog 再用 logrotate 做切分更方便。用 logrotate ，至少我可以配置切分前、切分后调用自己的脚本来做预备和善后处理。而用业务纯程们自己写的日志，十有八九只有他们自己调试时用起来顺手。

@hui9000nacos 权限漏洞最早就是 v 站爆出来的吧？坑了不少人，反复修了好多次。各种硬编码代码。。而且当时很多卖课的，各种宣传说 Springcloud 停止维护！ eureka 停止维护！建议大家换成 Alibabacloud ，吃相太难看了。那个时候 spring netflix 的 BUG ，Alibabacloud 都有，负债均衡底层还是被 Spring 弃用的 Ribbon ，不知道现在有没换成 Spring loadbalancer

@mmdsun @hui9000
没 at 成功再发一次，看 28 楼。

阿里的东西越来越不好用了。。。可能是初衷丢了吧

@PhosphorLin 并不是地板和地基的关系，在凤凰架构中，作者用 k8s 中的发现中心和配置中心替代了 spring cloud 中的。我的理解，从架构角度，他们是 2 个有重叠的圆

两个不是一个东西+1
k8s 是一整套云原生组件,能做的不只有服务发现,还有其他的组件,核心是基于容器的分布式编排管理系统

@914496397 可以再看看百度的开源看着文档又大又全，真正做起来哪哪都是坑

@hui9000 #20 对的，就目前这，相比其他组件来说，这几个是比较好用

@ZeroDu #35 还有一点，这些组件方便上云，可以直接买阿里云的服务。这点对小公司来说很方便。不用考虑自建的稳定性

不会 K8S ，我是来推荐一个优质的 spring/boot/data/security/cloud 的中文文档，无广告，无须登录，无须关注，在线读。https://springdoc.cn/

@ql562482472

2. 我说的不是 all in code （代码） 而是 all in coding （写代码），是个动名词，我想表达的是（念着咒语祭起粗壮高大的巨型 IDE ，用久经产业考验的软工领域热爱的编程语言）来写（业务功能之外的、已有很多“进程外”基础设施组件的）（基础设施功能）代码这个行为。

3. 对于信息化岗位上的人没有技术能力或者没有技术意愿，甚至可能没有专门的信息化部门，只是归在综合管理办公室里的一个科员岗的“文科式”甲方信息化人员来说，可能不管技术细节的 turn key 工程是最好的。而我只是作为一个懂技术也想去考虑技术细节的苦逼又装逼的甲方信息化小主管，希望，乙方能有真正的能通盘做技术考虑的人跟我对应。而不是让 all in coding 蔓延。提到 fat jar 并不是说我认为 fat jar 不好，war 好，而是我遇到的太多阿猫阿狗做的技术“选择”（甚至可能并不是有意选择，而是师傅怎么带我的我就怎么做，网上的 tutorial 怎么写的我就怎么做）图省事，并不是像你说的经过了利弊分析思考的结果。
另外 1 ，如果乙方在文科式甲方只提功能要求的情况下交付了软件代码，要求甲方提供其他基础设施，当然是很扯鸡九蛋的，哪怕是 all in coding 的结果交付了也比这样做好；另外 2 ，在甲方有自己积累下来的 best practice 基础设施意向的情况下，应用交付也应该涵盖对甲方基础设施意向的适配。
再重复一遍，我不是说 fat jar 不好，而是我特喵的特氖氖的特烙烙的遇到的只会用 fat jar 的阿猫阿狗们实在是大概率让我想砍人。我宁肯自己累一点，作为甲方拔拔里的苦逼运维人员，自己来负责基础设施的调校，而不是看着写业务代码的阿猫阿狗们自以为是地重复造烂轮子实现各种非业务的基础设施功能各种不靠谱而我却眼睁睁无能为力。

@ql562482472
至于你提到的“同时也能提高平台的安全性”什么的……当然也许在你所在的行业和场景里是这样的。
但我遇到上级信息化主管部门通报过来的安全事件里，有不少案例，但凡乙方的技术团队里有懂运维的，但凡少自作多情写点基础设施代码，但凡老老实实用成熟的基础设施（不论是甲方已经熟悉的还是已经打包在 Linux distro 里的其它第三方组件），就特喵的不会出事！

简单说来我是在总结我的愤怒。对别人没啥参考价值。

k8s 和 spring cloud 的本质上并不是一个东西，所以并不能直接比较优劣。
k8s 是容器编排工具，现在也不单是编排了，更是一个大的平台。
spring cloud 是微服务的一个实现。

《凤凰架构》文中将这两放在一起是为了体现系统架构的演进，即 spring cloud 原本使用的组件如配置中心、注册中心、网关等现在正在往云原生方向发展。文中做对比的更多是一般的 spring cloud 和 spring-cloud-kubernetes ( https://spring.io/projects/spring-cloud-kubernetes )。

要理解为什么是这样的发展趋势得结合整个架构演进来看，也就是看书中的下一章“演进中的架构”，微服务对比单体服务而且带来了极为便捷的横向扩展能力，但随之而来的是复杂度，以及为了应对这些复杂度引入的新的组件，例如：因为有了多个实例，导致需要负载均衡，导致要有 ribbon 等。随着发展，目前主流趋势是希望把这部分不属于业务的内容下沉到更底层中去，而不需要业务代码层面上关心。所以有了 service mesh ，再往下 serverless 。

spring cloud kubernetes 就是将配置中心等交给 k8s 来负责。

所以如果从整体角度来看，他们也并没有本质区别，甚至对于大部分中小企业来说复杂度在不断上升，但是对于大型企业来说，让专门的人员负责专门的事是有效率提升的，业务 coder 就写业务就行了。

@914496397 #7 为什么都这么说啊， 最近我们也要重构整合成微服务，就是用 springcloudalibaba nacos

@yudoo 我被坑的原因好几次是因为安全事件，面上看用起来都不错，响应也很快，貌似没啥问题。
但是漏扫时候一堆漏洞，要不勤快点每周盯着，升级版本，有时候阿里实现底层是写死的，一旦升级可能就要重新调试。

@914496397 #43 啊， 那还有什么好的办法么， 有点烦人了， 日志每周一两个 T 有什么解决方案么，es 感觉有点扛不住

@yudoo 我专门搞了个服务器做日志记录和管理，然后 nacos 和系统产生的日志定期自动清理