 |
lesismalV2EX 第 497905 号会员，加入于 2020-07-06 13:49:58 +08:00 |
| 第一批“天坑专业”受害者，已经改行卖烤肠了 - 程序员大军正在加入的路上 程序员 • lesismal • 32 天前 • 最后回复来自 lesismal | 2 |
| nbio 近期的一些功能更新，来骗点 star
1 Go 编程语言 • lesismal • 141 天前
|
| Gopher 苦 ORM 久矣，发布个使用 rawsql 节省体力的包，使用姿势与标准库基本相同 Go 编程语言 • lesismal • 272 天前 • 最后回复来自 lesismal | 33 |
| 吃八分饱长寿与充电 85%能保护电池
1 硬件 • lesismal • 323 天前 • 最后回复来自 julyclyde
|
22 |
| 使用默认配置可能导致连接/协程泄露，包括标准库、基于并使用标准库默认配置的框架， fasthttp 也存在类似的问题 Go 编程语言 • lesismal • 2022-03-14 13:44:00 PM • 最后回复来自 victor | 3 |
| 伸手党真是烦 程序员 • lesismal • 2022-02-16 01:05:48 AM • 最后回复来自 neoblackcap | 95 |
| 最近犯闲，想再写点啥项目，有推荐的吗？ Go 编程语言 • lesismal • 35 天前 • 最后回复来自 lesismal | 42 |
| 迫于 250，来自荐两个 golang 库
1 Go 编程语言 • lesismal • 2021-09-24 12:38:49 PM • 最后回复来自 lesismal
|
4 |
lesismal 最近回复了
6 天前 回复了 tool2d 创建的主题 › 程序员 › 微软比 google 早发明 20 年的 RPC 远程调用，然而现在市面上几乎全是 gRPC 的天下！ |
@cassyfar 先了解下为什么 Google 搞 QUIC 并被采纳作为 HTTP3.0
> 1. 即使是内网环境，所有的流量也应该加密，哪怕是 TCP 也应该套 SSL 。不搞这个你连等保都过不了。
那这么说吧，很多家其他大厂的 RPC ，是没用 TLS 的。是不是这些大厂就做错了？不是每种服务都要等保流程的，否则安妮这个所有流量都要加密的说法，是不是数据库、redis 这些基础设施都要 TLS ？但实际情况是多数这种内网基础设施都没用 TLS 连接、只是 4 层 TCP 而已，否则性能直接掉一块。
也不是哪个东西用的多就一定它是对的、别人是不好的。就像 windows 比 macos 用户多多了但微软被喷那么多，就像 HTTP1.x 目前仍然是互联网主要流量，2.0 搞这么多年也没普及反倒是委员会老爷们在 2.0 没普及的情况下直接跨过去投票点赞支持 3.0 了，为啥？因为 1.x/2.0 都是垃圾啊！
GRPC 用的最多，一是谷歌背书，二是数量占据多数的中小厂商不具备自研这种基础设施的能力，你看看大厂基础设施，几乎都有自己的轮子，为啥 GRPC 不一统江湖了？先看看性能测试数据？先区分下不同场景加密的必要性？
> 2. 线头阻塞是个啥玩意，说的是 HOL blocking ？这个一般不是翻译为队头阻塞么。
一个概念多种叫法没什么奇怪的，”队头“更偏学术一点的用词、“线头”更形象化偏口语一点而已，这里也有线头：
https://baike.baidu.com/item/%E7%BA%BF%E5%A4%B4%E9%98%BB%E5%A1%9E/1462441
也可能是年纪大一点的我们那个年代叫线头的多一些。另外有些东西是约定俗成，比如“粘包”这种错误定义，但其实提到它大家也知道是啥意思，所以约定俗成了也就不要纠结字眼
> 这里有点矛盾，因为 TCP 的队头阻塞是在丢包率比较高的网络中才有较大的影响，如果不丢包也就没什么阻塞一说了，而你之前论证不需要 SSL 说是内网环境，内网的丢包率通常是非常低的
我不是理论论证，而是就实时论事，比如你如果担心内网流量被抓包，那为什么不先担心下为什么被入侵了提权了，被入侵了难道不比被抓包更严重更可怕吗？别人有更多方法搞事情可都是比抓内网包省事多了。最常见的部署挖矿代码、勒索病毒、登入你的数据库、篡改你的服务挂马之类的，但很少听说别人都入侵了然后还靠抓包这种费时费力拐弯抹角的方式搞事情的。当然，性能不是主要需求的，内网加 TLS 也完全没问题。
还有就是自己的工作实践、以及行业实际情况，你可以随便看看各大厂相关的开源项目，RPC 不用 TLS 的场景多了去了。
> 另外 TCP 的问题和 gRPC 有啥关系，你换其他 TCP 上的 RPC 实现不是一样的问题么。连解决方法，比如 multiplexing 都是一样的，别的 RPC 能用，gRPC 也能用。
同样的，你先了解下为什么 Google 搞 QUIC 并被采纳作为 HTTP3.0
> 当然你可以换基于 UDP 的 RPC 实现，gRPC 社区我看也在做基于 QUIC 也就是 HTTP3 作为传输层的工作。
这里你自己都说了社区有在做基于 QUIC ，和上面一样，为什么不继续用 2.0 ？同样的，你先研究明白为什么 2.0 解决不了 4 层的线头阻塞就明白了。我提示一下：mutiplexing 解决不了是因为它是 7 层的策略，而 TCP 线头阻塞是 4 层，你 multiplexing 是基于别人 4 层实现的，4 层自己先堵车了，7 层动都动不了、怎么解决。。
这方面文章很多，随便找下认真看看就懂了，我就不展开说了
> 1. 即使是内网环境，所有的流量也应该加密，哪怕是 TCP 也应该套 SSL 。不搞这个你连等保都过不了。
那这么说吧，很多家其他大厂的 RPC ，是没用 TLS 的。是不是这些大厂就做错了？不是每种服务都要等保流程的，否则安妮这个所有流量都要加密的说法，是不是数据库、redis 这些基础设施都要 TLS ？但实际情况是多数这种内网基础设施都没用 TLS 连接、只是 4 层 TCP 而已，否则性能直接掉一块。
也不是哪个东西用的多就一定它是对的、别人是不好的。就像 windows 比 macos 用户多多了但微软被喷那么多，就像 HTTP1.x 目前仍然是互联网主要流量，2.0 搞这么多年也没普及反倒是委员会老爷们在 2.0 没普及的情况下直接跨过去投票点赞支持 3.0 了，为啥？因为 1.x/2.0 都是垃圾啊！
GRPC 用的最多，一是谷歌背书，二是数量占据多数的中小厂商不具备自研这种基础设施的能力，你看看大厂基础设施，几乎都有自己的轮子，为啥 GRPC 不一统江湖了？先看看性能测试数据？先区分下不同场景加密的必要性？
> 2. 线头阻塞是个啥玩意，说的是 HOL blocking ？这个一般不是翻译为队头阻塞么。
一个概念多种叫法没什么奇怪的，”队头“更偏学术一点的用词、“线头”更形象化偏口语一点而已，这里也有线头：
https://baike.baidu.com/item/%E7%BA%BF%E5%A4%B4%E9%98%BB%E5%A1%9E/1462441
也可能是年纪大一点的我们那个年代叫线头的多一些。另外有些东西是约定俗成，比如“粘包”这种错误定义，但其实提到它大家也知道是啥意思，所以约定俗成了也就不要纠结字眼
> 这里有点矛盾，因为 TCP 的队头阻塞是在丢包率比较高的网络中才有较大的影响，如果不丢包也就没什么阻塞一说了，而你之前论证不需要 SSL 说是内网环境，内网的丢包率通常是非常低的
我不是理论论证，而是就实时论事，比如你如果担心内网流量被抓包，那为什么不先担心下为什么被入侵了提权了，被入侵了难道不比被抓包更严重更可怕吗？别人有更多方法搞事情可都是比抓内网包省事多了。最常见的部署挖矿代码、勒索病毒、登入你的数据库、篡改你的服务挂马之类的，但很少听说别人都入侵了然后还靠抓包这种费时费力拐弯抹角的方式搞事情的。当然，性能不是主要需求的，内网加 TLS 也完全没问题。
还有就是自己的工作实践、以及行业实际情况，你可以随便看看各大厂相关的开源项目，RPC 不用 TLS 的场景多了去了。
> 另外 TCP 的问题和 gRPC 有啥关系，你换其他 TCP 上的 RPC 实现不是一样的问题么。连解决方法，比如 multiplexing 都是一样的，别的 RPC 能用，gRPC 也能用。
同样的，你先了解下为什么 Google 搞 QUIC 并被采纳作为 HTTP3.0
> 当然你可以换基于 UDP 的 RPC 实现，gRPC 社区我看也在做基于 QUIC 也就是 HTTP3 作为传输层的工作。
这里你自己都说了社区有在做基于 QUIC ，和上面一样，为什么不继续用 2.0 ？同样的，你先研究明白为什么 2.0 解决不了 4 层的线头阻塞就明白了。我提示一下：mutiplexing 解决不了是因为它是 7 层的策略，而 TCP 线头阻塞是 4 层，你 multiplexing 是基于别人 4 层实现的，4 层自己先堵车了，7 层动都动不了、怎么解决。。
这方面文章很多，随便找下认真看看就懂了，我就不展开说了
6 天前 回复了 dawnven 创建的主题 › 问与答 › 堂弟非法猎鸟，被老家当地派出所抓了，目前在拘留所 |
@hanqian
> 幸亏这帖里有一个真吃铁拳的老哥来科普公检法的真相，否则不知道有多少人会进来搁那假惺惺的普法，说什么活该，什么抓得好，其实这种人的心理就是，我一定要把你踩成刁民，否则我还怎么自诩良民。
1. 打鸟不对，批评这种没什么问题吧？
1. 法是恶法，但对于打鸟这个事情来说，不能因为是恶法就同情打鸟这种行为吧？
> 幸亏这帖里有一个真吃铁拳的老哥来科普公检法的真相，否则不知道有多少人会进来搁那假惺惺的普法，说什么活该，什么抓得好，其实这种人的心理就是，我一定要把你踩成刁民，否则我还怎么自诩良民。
1. 打鸟不对，批评这种没什么问题吧？
1. 法是恶法，但对于打鸟这个事情来说，不能因为是恶法就同情打鸟这种行为吧？
10 天前 回复了 tool2d 创建的主题 › 程序员 › 微软比 google 早发明 20 年的 RPC 远程调用，然而现在市面上几乎全是 gRPC 的天下！ |
gRPC 的设计其实挺一般的。基于 HTTP2.0 ，解决不了 4 层线头阻塞，对于 RPC 这种应用场景，集群内多是内网、用 HTTP2.0 是浪费不如直接 TCP 省去加密。streaming 也不是什么优秀玩意，只是相当于在 request and response 基础上前进半步。唯一优点就是多语言。
11 天前 回复了 luomao 创建的主题 › 程序员 › 在国内程序员就要重点关注业务么 |
全世界都差不多，纯技术线很难升官发财。
单就 OP 这个案例而言：
1. OP 的改造没什么问题，关注业务不多也没什么问题、毕竟之前职级可能也还没高到必须关注业务；
2. 除非是对技术需求非常非常硬的高精尖领域，但 OP 描述的这种不算，所以如果想继续向上、不管去哪家公司、多关注业务更好
3. 如果 OP 这次改造再等等，等你们原系统经常出点问题、比如需求迭代快导致停服次数多所以停服权重影响变大，或者量增加了导致原服务撑不住了天天 warning ，然后领导们老板们意识到了技术的重要性需要技术搞定（其实和 1 是一个道理，就是需要技术硬的时候），到时候你再改造、解决这些问题并且晋级述职主要讲解这些技术相关的，老板们就不会这么烦人了。
简单点说，3 就是需要天时地利人和类似的、好钢得使到刀刃上，技术再好没遇到好机会也白费，反倒会被资本家恶心
单就 OP 这个案例而言：
1. OP 的改造没什么问题，关注业务不多也没什么问题、毕竟之前职级可能也还没高到必须关注业务；
2. 除非是对技术需求非常非常硬的高精尖领域，但 OP 描述的这种不算，所以如果想继续向上、不管去哪家公司、多关注业务更好
3. 如果 OP 这次改造再等等，等你们原系统经常出点问题、比如需求迭代快导致停服次数多所以停服权重影响变大，或者量增加了导致原服务撑不住了天天 warning ，然后领导们老板们意识到了技术的重要性需要技术搞定（其实和 1 是一个道理，就是需要技术硬的时候），到时候你再改造、解决这些问题并且晋级述职主要讲解这些技术相关的，老板们就不会这么烦人了。
简单点说，3 就是需要天时地利人和类似的、好钢得使到刀刃上，技术再好没遇到好机会也白费，反倒会被资本家恶心
16 天前 回复了 cs1024 创建的主题 › 问与答 › 大家每天生活有什么开心的事吗 |
向死而生，离最终解脱又近了一天。
16 天前 回复了 tool2d 创建的主题 › SSL › 以前感觉 HTTPS 很安全，现在有一点点改变看法了。 |
先搞清楚，通信协议相关的安全算法主要是防止信道监听者。这类似战争年代无线电被监听、加密防破解。
不是用来防止具有密钥的通信两端的，因为两端本来就各自有密钥。所以这种有机器权限的就不适合 OP 讨论范围。
另外，如果想绕过，你装个虚拟机，在虚拟机里跑，应该就可以了，如果想更狠，虚拟机里再加上加密隧道、VPN 。。。
不是用来防止具有密钥的通信两端的，因为两端本来就各自有密钥。所以这种有机器权限的就不适合 OP 讨论范围。
另外，如果想绕过，你装个虚拟机，在虚拟机里跑，应该就可以了，如果想更狠，虚拟机里再加上加密隧道、VPN 。。。
Select Language