这么阔怕？那要的价高不高？

可以看看 [metallb]( https://github.com/metallb/metallb) / [porter]( https://github.com/kubesphere/porter) 这两个 bare-metal 的 LoadBalancer Service 实现，需要搭配支持 BGP 协议的路由器使用，而且路由器本身也需要做高可用，更底层还有链路层高可用要做。门槛比较高。

家庭 Homelab 等玩具网络可以用 https://github.com/kube-vip/kube-vip ，它提供基于 ARP 协议的高可用。

.NET 起来了还是喜闻乐见的，该给 Java 点压力了

@GopherDaily 嗯嗯，理解理解~

@YzSama 是这样，我这边业务侧为了平衡成本跟流量的可观测性、流控等需求，曾经在加 sidecar 跟不加 sidecar 间反复横跳。
但是去掉了 sidecar ，它们业务服务内部又没有做完善的监控告警的话，出了问题流量降级了根本没人知道，因为出了这么次大问题，后来业务侧的领导就拍板全给加上了 sidecar emmm

Istio Sidecar 默认的资源 requests 很小，QPS 稍微高一点基本就会用超，相当于说加了个 Sidecar 还帮我们提升了节点资源利用率 emmm
不过这个是我们集群资源利用率优化不够带来的，往下讨论又是另外一个问题了，就不展开了。

另外一个现象是，我们的节点 CPU 利用率其实一直不高，加了个 Sidecar 看着涨了 50% 的 CPU ，但是对成本的影响并不大...

我这边为了避免性能问题，关掉了 mTLS.
不过我刚到公司就是 Istio 了，没专门跟无 Sidecar 模式做过对比。
不过我们业务场景下加了 Sidecar QPS 降低肯定没这么夸张，上 Istio 成本要涨十倍的话，业务团队肯定不会接的，老板不得骂死。

我印象中 QPS 高的服务，纯 HTTP ，无调优情况下 sidecar : app 的 cpu 比值为 1:2 ，延迟增加了 3ms.

但是有了 Sidecar 后很多事情就好做了，比如说我们因此得以快速上线 gRPC ，把增加的损耗又全砍掉了。
接口改造为 gRPC 后，服务流量下降 70%，延迟下降 30% ~ 50%，第二步优化给 gRPC 上再加了层 gzip ，流量又降了 70%，而 CPU/延迟 基本没啥增加（砍流量主要是为了省 AWS 跨区流量费）。

总的来说多了个 Sidecar 性能有损耗很正常，加它的目的不就是为了拿性能换开发迭代效率嘛。

至于差了 10 倍 QPS 这么离谱的现象，我觉得肯定是有别的问题。

运维转 DevOps 是比较合适的出路，DevOps 再进阶到 SRE

非 Windows 系统没啥必要单独装 powershell 用，真要装还不如装这个：

https://www.nushell.sh/

大佬跟我是一年的，不过早我一年毕业，看了你的 github ，很牛哇

我也分享下我去年裸辞的一点体会，跟你有些类似，都觉得辞职后心情也好了，身体棒了哈哈

https://thiscute.world/posts/end-of-the-first-round/

@cwcauc 看个人兴趣吧，双拼+形也不是什么必须会的东西，有兴趣有时间可以学学。

vim 得看你的工作方向吧，不过基础的命令最好是学一学，在命令行下改些东西会方便很多。

不过 vim 更高级的用法就看个人兴趣了，像 neovim 啥的 VS Code 基本都能取代。属于是有时间有兴趣可以去折腾，不折腾也无所谓。