这是一个创建于 303 天前的主题，其中的信息可能已经有所发展或是发生改变。
但是目前像一般的脚手架，比如若依都是只有一个 gateway,都没有配置中心、服务注册中心的模块，那用 k8s 可以干嘛呢？
 |
1
chenPiMeiHaoChi 303 天前  10
SpringCloud 是 Java 语言的给你写分布式程序用的框架，什么熔断降级负载均衡都带了，你只要注册到 Eureka 上，再写点业务代码即可，说简单点是写程序用的。
Kubernetes 不局限于语言，并且现在也有熔断降级之类的插件，但主要还是为了集群处理和监控这些，说简单点是运维用的。 简单列几个 SpringCloud 带来的运维问题： 1. 几十个、 几百上千个节点的管理及弹性扩容； 2. 日志收集问题； 3. 某个服务不可用问题； 4. 滚动更新 /历史回退问题； 这几个问题基本上不是在 SpringCloud 层面解决的，而 Kubernetes 可以很轻松解决。 最后说个个人偏见，没事别碰阿里的开源。 |
 |
2
kevinonepiece OP @chenPiMeiHaoChi 谢谢大佬
|
 |
3
lidashuang 303 天前
两种东西
|
 |
4
adoal 302 天前 3
跟业务功能无关但又需要根据项目实施场景来定制的基础设施是放在哪里？通过库 /组件引入业务系统，还是在业务系统之外作为独立的基础设施用运维手段搞定？不同背景的人有不同的答案。
单一技术栈、以纯程序员为主的团队，用 SpringCloud 或者类似的其它能把基础设施集成到程序里的“全开发”式方案会比较顺手，而混合技术栈、运维技能全面的团队，可能更适合业务逻辑归业务逻辑，基础设施归基础设施，后者多使用运维手段来解决。 |
|
5
adoal 302 天前
Everything in Java, everything in coding……反正我是不太喜欢这样的乙方团队给我干活的。
|
 |
6
DAPTX4869 302 天前
@chenPiMeiHaoChi #1 搜了下这书的作者, 不是华为的吗, 不过连个 https 都没也是...
|
 |
7
914496397 302 天前
@chenPiMeiHaoChi 没事别碰阿里的开源。这句话真的是深有体会
|
 |
8
VoiceEXONE 302 天前
|
|
9
chenPiMeiHaoChi 302 天前
|
 |
10
jie170601 302 天前
有本书，《凤凰架构》比较系统的对比了这些东西，不过讲得对不对好不好我就没法评测了😂。
https://icyfenix.cn/exploration/projects/microservice_arch_springcloud.html |
 |
12
GopherDaily 302 天前
完全没有任何优势
|
 |
13
zcl0621 302 天前
@VoiceEXONE k8s 又不是阿里的，楼上是说阿里的开源项目
|
 |
14
ql562482472 302 天前
@adoal #5 没听明白 老哥你是不喜欢全 in java 还是全 in coding ？ 如果是后者 我想问下为什么？
|
 |
15
yimiaoxiehou 302 天前 via Android
@914496397 +1 ，dubbo ，nacos 全都是垃圾
|
|
16
yimiaoxiehou 302 天前 via Android
@ql562482472 all in coding 说的是全都自己写吧，太累了，而且代码质量甚至架构质量大概率都不太行
|
 |
17
Vraw5 302 天前
这是完全不同的俩东西，把 k8s 的 pod 当成是一个在运行的系统就行，只不过 k8s 集群能提供配置中心，自动发现这些功能给 pod 用，pod 里面跑 java 还是跑 go 或者跑 c 都无所谓，对 k8s 来说，它只是个 pod ，管理的也是 pod
spring cloud 只是 java 的框架，感觉你把 k8s 理解错了，打个比喻，你的这个问题相当于在问 Linux 系统相比于 java 语言的优势在哪 |
 |
18
xiaoranj 302 天前
@chenPiMeiHaoChi 也是我的偏见，阿里出来的东西不要碰，属于模因污染 doge
|
|
19
ql562482472 302 天前
@yimiaoxiehou #16 我是没理解这个 coding 指的是什么 ，我主要是想了解类似 IaC as Code 这种形态是否会受到甲方偏见
|
 |
20
hui9000 302 天前 1
阿里的东西不碰 那你们都用什么大佬，能给介绍一下么
比如 nacos 、rocketmq 、sentinal ， 垃圾在哪里？或者介绍介绍平替啥的 这边使用 2 年多了，确实没感觉哪垃圾，可能是我垃圾吧。 |
 |
23
buffzty 302 天前
|
|
24
adoal 302 天前 3
@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 的可配置程度，你又要在自己的项目里写多少代码来处理配置？ |
|
25
adoal 302 天前
@ql562482472 甲方一般不关心技术。我是异种。
|
 |
26
PhosphorLin 302 天前
地基相比地板优势在哪呢？
|
|
27
adoal 302 天前
不考虑一互大的秒杀这种极端需求，在普通的信息系统应用场合，绝大多数“顺手写出来”的 log 库，还不如打到 syslog 再用 logrotate 做切分更方便。用 logrotate ，至少我可以配置切分前、切分后调用自己的脚本来做预备和善后处理。而用业务纯程们自己写的日志，十有八九只有他们自己调试时用起来顺手。
|
 |
28
mmdsun 302 天前 via iPhone
@hui9000nacos 权限漏洞最早就是 v 站爆出来的吧？坑了不少人，反复修了好多次。各种硬编码代码。。而且当时很多卖课的，各种宣传说 Springcloud 停止维护！ eureka 停止维护！建议大家换成 Alibabacloud ，吃相太难看了。那个时候 spring netflix 的 BUG ，Alibabacloud 都有，负债均衡底层还是被 Spring 弃用的 Ribbon ，不知道现在有没换成 Spring loadbalancer
|
 |
30
tudou1514 302 天前
阿里的东西越来越不好用了。。。可能是初衷丢了吧
|
|
31
kevinonepiece OP @PhosphorLin 并不是地板和地基的关系，在凤凰架构中，作者用 k8s 中的发现中心和配置中心替代了 spring cloud 中的。我的理解，从架构角度，他们是 2 个有重叠的圆
|
 |
32
wangxin13g 302 天前
两个不是一个东西+1
k8s 是一整套云原生组件,能做的不只有服务发现,还有其他的组件,核心是基于容器的分布式编排管理系统 |
|
34
ql562482472 302 天前
@adoal #24
我认为你的观点 “基础设施开发和业务开发应该是两个独立的领域，由不同的团队或个体负责，需要高效利用现有的基础设施软件和运维手段”是绝对正确的，解耦基础设施和应用组件非常重要，却存在现实困难。 --- 对于"all in code"，我理解的是使用 gitops 的形式，使得基础设施能够以一个可预期的状态进行运行。这样的方式不仅提高了我们对系统状态的预测能力，也使得我们能够更容易地进行版本控制和回滚。我想你说的"code”应该是指编程语言，如果是指编程语言的话，的确是对于平台安全存在风险，应该更广泛的采用可靠的其他基础设施中间件，而不是自己开发。这个很像之前我做 devops 时的领导的观念，当时我还在 java 应用开发的角色上没有转换过来，对开源基础设施的文档的信心不足（因为 java 界开源文档质量不太行） --- 关于 spring 的 fat-jar ，我有些不同意见，就是我认为基于 springboot 的 fat-jar 应当视为一个应用程序级别的交付，将内部的 web 服务器基础设施当作应用的一部分，各个应用之间的 web 服务器应当隔离开，这样能在测试期间应用就具有更高的稳定性，同时也能提高平台的安全性。对于甲方的交付是按照应用交付的，而不是交付软件代码，还需要甲方的其他基础设施。 |
 |
37
KevinBlandy 301 天前
不会 K8S ，我是来推荐一个优质的 spring/boot/data/security/cloud 的中文文档，无广告，无须登录，无须关注，在线读。https://springdoc.cn/
|
|
38
adoal 301 天前
@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 的阿猫阿狗们实在是大概率让我想砍人。我宁肯自己累一点，作为甲方拔拔里的苦逼运维人员，自己来负责基础设施的调校，而不是看着写业务代码的阿猫阿狗们自以为是地重复造烂轮子实现各种非业务的基础设施功能各种不靠谱而我却眼睁睁无能为力。 |
|
39
adoal 301 天前
@ql562482472
至于你提到的“同时也能提高平台的安全性”什么的……当然也许在你所在的行业和场景里是这样的。 但我遇到上级信息化主管部门通报过来的安全事件里，有不少案例，但凡乙方的技术团队里有懂运维的，但凡少自作多情写点基础设施代码，但凡老老实实用成熟的基础设施（不论是甲方已经熟悉的还是已经打包在 Linux distro 里的其它第三方组件），就特喵的不会出事！ |
|
40
adoal 301 天前
简单说来我是在总结我的愤怒。对别人没啥参考价值。
|
 |
41
litchinn 301 天前
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 就写业务就行了。 |
Select Language