【IT老齐431】再见！Spring Cloud Alibaba

风间影月:
我个人页不喜欢al的一些组件，很难用，bug也多[笑哭]

【回复】坑太多了，以前有钱的时候都没修好，就更别指望现在想本增笑了
【回复】回复 @IT老齐 :dubbo，fastdfs，fastdfs，哪一个没被坑过，nacos里也有bug
【回复】回复 @风间影月 :nacos，seata，fastjson，小版本更新经常不兼容你敢信[doge]
列克星敦的奇妙冒险:
都在说小公司不要轻易上k8s，这个确实有一定道理，自己部署的k8s会耗费很多精力 但还有一种方式就是使用云服务厂商提供的k8s，我们今年上k8s，在自建和云服务之间选择了阿里云的k8s，初期花费不少时间，但迁移部署好后非常方便，现在运维发版比以前轻松多了

【回复】你一个小公司用单体就够了；再大一点你就搞个单体集群；再大一点就搞个分布式；再大一点就搞个docker swarm；再大一点才可能是这个方案。多了不说，这些方案里面每升一级起码用户得比前一级升10倍以上的用户吧！以单体百人用户计算，用k8s起码得有百万用户才行。
【回复】可以这么说90%以上的公司都不需要用k8s。
【回复】回复 @我家的狗太凶 : 百万用户也用不上K8S，之前公司500万用户，实际每天就几万活跃。搞了一套分布式，实际性能瓶颈根本不在JAVA服务端这里
四季u_:
换工作之后，k8s转alibaba，阿里降本增效的确有一定风险，但是一般公司还是不建议轻易上k8s，需要有足够强大的架构团队和运维团队支撑同时有标准的devops流程，这种情况k8s的优势非常大

【回复】k8s上不了就单体微服务没那个能力实力就别用
糯米咸饭团:
K8S这玩意，可不是一般公司能hold的住的，慎用

哗哗哗101:
国内互联网公司的开源就不能百分百信任，都是跟着KPI走的，说不定哪天就不搞了

高仿杀手:
ali-cloud 高版本向下兼容太差了，更新迭代，也不太及时，唉～ 搞得对它确实没有什么信心了

天涯de刀客:
没毛病，全面拥抱基础设施层代替微服务层

别Null了:
确实是这样 现在都是搞内部grpc 服务，只要是能提供接口服务就好 其他什么并发扩容限流都不需要操心，全部都由istio 运维管理

小杰的灵魂自省:
用了k8s感觉又可以可以换回springboot了，对cloud组件依赖降低

【回复】回复 @IT老齐 :确实，我们团队就是k8s+springboot
【回复】回复 @daaddaad :意思是说使用springboot就够了，不需要关心springcloud的一堆组件
【回复】说的cloud不用spring boot一样
马卡bug卡:
基本不喜欢用阿里的，fastjson都不喜欢用，不过同事用得很欢。。。

【回复】我看到同事引进来一个fastjson，血压都在升高
【回复】fastjson巨恶心不敢用[吃瓜]
【回复】回复 @每晚草草小pink的妈妈 :打死不冤枉！
摩洛哥魔丝:
这是完全用k8s替换掉springcloud架构吗？网关处如果存在一些复杂的转发鉴权等逻辑 ingress能实现吗

【回复】istio也不错，本身集成了服务编排。sidecar ingress outgress
shihao丶H:
那么已经在kubernetes环境下了，为啥还要springcloud呢？ springcloudkubernetes在k8s环境下比只用springbooot好在哪呢

【回复】简单一点的话，其实只需要springboot的应用服务就够了，其他的都可以使用k8s完成
【回复】感觉只需要springboot就行了
【回复】回复 @ycd123456 :feign的url配置就写service name就行，pod可以直接调用service。负载均衡和上下线就全交给k8s搞定了
暇享丿:
mmp天天都是新技术，老技术都还没学精。别卷了哥哥们，

【回复】算不上新技术，SpringCloud的新组建罢了。都遵循SpringCloud的规范，无非换几个注解。
Raven3450:
我们公司就是只用springboot + k8s，但在简历上没写spring cloud都很难有面试，没法子，还是得学一下spring cloud里的组件

【回复】回复 @ycd123456 :对啊就是这样[笑哭]
【回复】springboot + k8s顶多是多实例部署吧，微服务互调怎么办？cloud一个注解搞定了，boot可能得resttemplate硬编码吧？
【回复】回复 @胖_圆_儿 :现在行业就是这样[笑哭]只能自己包装一下，没用过也当用过了[doge]