V2EX › mightybruce 的所有回复 › 第 19 页 / 共 28 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 11 12 13 14 15 16 17 18 19 20 ... 28

❮

❯

337 天前

回复了 yinlei212 创建的主题 › Go 编程语言 › 感觉国外 Golang 语言很火，反而国内一般

现在的语言就是绑定各种领域，这不是 10 年前，大家都是做 web 和互联网 1.0 的时代。另外专业领域的知识远比一些通用的业务知识要值钱，不要限于 crud 和 web 程序员里面

337 天前

回复了 yinlei212 创建的主题 › Go 编程语言 › 感觉国外 Golang 语言很火，反而国内一般

别整什么语言火啦，难道不知道国内越火就等于越内卷，你们也不看看 java 内卷到什么程度，想不想卷八股文
golang 的确是各种基建的主力语言，而不是业务开发的首选语言。
国外都是各种基建比如
k8s 和多数云原生设施以及 cicd
数据库比如分布式数据库 CockroachDB, tidb 的控制层、
时序数据库如 Influxdb 、VictoriaMetrics
负载均衡的控制层比如 istio
各种分布式存储比如 Seaweed FS 、glusterfs 、juicefs 、MinIO
区块链和 web3 的项目如 ethernum 、hyberledger

国内用 go 做业务的的确是比较有钱的公司或一些科技初创公司

340 天前

回复了 joyanhui 创建的主题 › 程序员 › 写多读少的大量 kv 数据用云厂商的啥方案比较合理？

如果你可以花钱的话，可以使用 EMQX 企业版，兼容多种数据库存储。
还支持大文件数据上传。
它提供了 MQTT 协议文件传输能力，允许设备上传大文件数据并将其存储到本地磁盘或 S3 存储

341 天前

回复了 wkong 创建的主题 › 程序员 › 个人觉得 Go 的 error 设计的非常好，为什么还那么多人吐槽？

@buffzty try catch 不是 goto 的封装，在 C 中实现 try catch 也不是一种方式，简单一点是 setjmp longjmp,
很多代码是从汇编的方式实现的。
try catch 这些和对象资源也是绑定的，在 C 中实现的也是个模拟的语法糖，对象资源回收是不好实现的

Rust ，它里面也是满屏幕的.unwrap()，这实际上跟 Go 的 if err != nil 一样
写业务的还是太闲了，天天讨论这些。

341 天前

回复了 wkong 创建的主题 › 程序员 › 个人觉得 Go 的 error 设计的非常好，为什么还那么多人吐槽？

另外 try catch exception 还涉及到 RAII 机制，go 连对象都没有，谈 try catch 在 go 里面是没什么意义的，最多也只是语法糖。

341 天前

回复了 wkong 创建的主题 › 程序员 › 个人觉得 Go 的 error 设计的非常好，为什么还那么多人吐槽？

因为大多数这种人都是写 java 的，喜欢这种 try catch 异常处理，对于非业务开发，懒散和滥用 try catch 处理可以导致致命的 bug ，
linux 内核和 c 那么多库都没有 try catch, 方式比 go 还原始也没啥人说什么，都是业务开发太闲了。
go 的哲学就是错误就是要显示检查处理的，异常处理的不可见错误检查所带来的问题其实是很大的。不少业务开发才不管那么多，还不是能跑就行，最多加个单元测试。

345 天前

回复了 isno 创建的主题 › 程序员 › 拙作 5000 star 了

thebytebook 挺不错的，内容没有过时，挺一下。

354 天前

回复了 hzzhzzdogee 创建的主题 › 程序员 › 各位 DevOps 大佬们, 最适合 Kubernetes 的 CICD 是什么呀?

上面说的都是 ci, 只有 argocd 是 cd 。
一般来说中小公司 ci 自动化比如 gitlab ci 、github action 、jenkins ，cd 多数还是手动或写配置文件比如 yaml/helm/kustomize
terraform, argocd 直接使用也是满足一些简单配置。

尽管 K8S 统一了底层基础架构（提到应用交付、部署，大部分都是指往 k8s 上部署），但是它并没有在混合的分布式部署环境之上提供应用层的软件交付模型和抽象，对于复杂的多集群，很多公司用了 Kubevela(cuelang)
cuelang 动态配置语言比较强大但不如 KCL 有强类型和更多扩展.

354 天前

回复了 limpo 创建的主题 › Go 编程语言 › Go-Spring v1.2.0 发布，新增 Web 开发支持

个人观点：非常不喜欢这种被限制的方式，就算是 aop ，那么也要精简，而不是做全。
让 gin 、echo 、iris 能够接入就行，或者参考 kratos 做成插件形式。

362 天前

回复了 zhoudaiyu 创建的主题 › Kubernetes › 请教大家一下： K8s 的 Static Pod 的使用场景除了作为 bootstrap 集群的某些特殊组件的容器化部署方式，还有哪些常见使用场景？

static pod 是不受 kubernetes 调度的，属于 Kubelet 直接管理。只有少数情况下需要用，这个是和节点绑定的
1.只有要在宿主机运行的 daemon
2. 需要和节点绑定的 Pod
直接和 kubernetes 节点相关的修改和组件需要, 其他情况下用这个基本要被开除。

362 天前

回复了 cwjwgg 创建的主题 › Linux › 国产系统一天时间 ./xsession-errors 就 100G 如何排查

xsession 错误大多数并不是很重要，基本上它是一个相当低级的 X11 的错误日志，xwindows Linux 远程桌面的东西。
定期删除

363 天前

回复了 sud0day 创建的主题 › Kubernetes › 滴滴史上最严重服务故障是因为“k8s”版本升级错误？

k8s 是包含服务注册、降级、也是很多服务配置中心以及元数据存储的地方
滴滴技术在文章里写原地大版本升级，艺高人胆大，链接在下
https://mp.weixin.qq.com/s/nMSIsS72fSXGqJO9Vy_Pfw

364 天前

回复了 ucyo 创建的主题 › 程序员 › 滴滴事故的起因是底层系统软件发生故障，并非网传的“遭受攻击”

K8s 跨版本升级是很危险的，除非集群里没有任何第三方的 Operator 完全是自研的而且充分考虑到兼容度，代码全部改过了，你无法保证各种依赖的兼容性。
一般都是升级到高一个版本，中间版本慢慢过渡，1.12 到 1.20 属于艺高人胆大。

364 天前

回复了 ucyo 创建的主题 › 程序员 › 滴滴事故的起因是底层系统软件发生故障，并非网传的“遭受攻击”

滴滴技术自己写的 k8s 升级
https://mp.weixin.qq.com/s/nMSIsS72fSXGqJO9Vy_Pfw

像大厂商都会自建 IDC, 不然投资人为什么愿意在当年投资那么多钱给它，你只有花得多，才会有更多的投资。

364 天前

回复了 ucyo 创建的主题 › 程序员 › 滴滴事故的起因是底层系统软件发生故障，并非网传的“遭受攻击”

k8s 跨版本升级是有很多坑的，像滴滴 K8s 版本这么久还没升级估计就是在做很多测试。结果版本还升级错了。

364 天前

回复了 ucyo 创建的主题 › 程序员 › 滴滴事故的起因是底层系统软件发生故障，并非网传的“遭受攻击”

@pandaPapa 如果是集群所有的 master 高可用节点都挂了, 想调度都调度不了。这种错误真的是极其少见。

364 天前

回复了 ucyo 创建的主题 › 程序员 › 滴滴事故的起因是底层系统软件发生故障，并非网传的“遭受攻击”

基础设施才会导致这种大规模问题，否则软件版本回滚还是很快的。难道降本增效到了深水区了。

364 天前

回复了 ucyo 创建的主题 › 程序员 › 滴滴事故的起因是底层系统软件发生故障，并非网传的“遭受攻击”

已经在一些网站上公布了，是因为 K8s 版本升级升错了，造成基础设施问题。
https://www.oschina.net/news/268635

364 天前

回复了 cookii 创建的主题 › Kubernetes › 开发环境使用宿主机部署，测试和生产使用 k8s。会有什么坑吗？

telepresence 或者 kt-connect 都可以将集群内的请求流量劫持到本机进行处理
https://github.com/telepresenceio/telepresence
https://github.com/alibaba/kt-connect

364 天前

回复了 olin6520 创建的主题 › 程序员 › ARM64 公开课推荐

我有时候看这个 low level learning 的油管博主，他有一些粗浅的入门介绍。
https://www.youtube.com/@LowLevelLearning/search?query=arm

1 ... 11 12 13 14 15 16 17 18 19 20 ... 28

❮

❯