@AEnjoyable "控制任务量" 可以用信号量. https://pkg.go.dev/golang.org/x/sync/semaphore

能列一下你的论据吗 ?

@shylockhg 当时买的 https://www.dell.com/zh-cn/shop/%E5%8F%B0%E5%BC%8F%E6%9C%BA/inspiron-%E7%81%B5%E8%B6%8A%E5%B0%8F%E5%9E%8B%E5%8F%B0%E5%BC%8F%E6%9C%BA/spd/inspiron-3030-small-desktop/ins3030s-d1862l?ref=variantstack 又额外花了 1k 从 jd 上买了 32Gx2 的内存条

一个小问题, 既然是 Linux 开发, 为啥选择 mac. 买了 mac 你也大概率得开 vm. 为啥不买 hp, dell 的 mini 主机装 Linux 系统, 还便宜, 1k 就能搞定 32Gx2 的内存, 500 多就能搞定 1T nvme ssd

@ladychili 有不少都是骚扰电话

带着问题看源码, 比如要了解 xx 功能是如何实现的, 最好是先自己想下如果实现 xx 功能, 有哪些小问题需要解决, 再看下他是如何解决这些问题的. 如果这部分功能有单测的话, 那可以 debug 下, 看看跟自己理解的是否一样
(我现在在看 juifcefs sync 这部分的实现 https://juicefs.com/docs/community/guide/sync, 就这个可以提出如下问题
- 看文档描述, 默认是增量同步, 如果存在同名文件, 如何确定是否需要同步 ?
- 当同步的文件比较大的时候, 如何优化性能 ?
- 如果同步时会 update 文件, 如果同步失败的话, 会不会造成文件损坏 ? 他是如何解决这个问题的 ?

第一次看的时候, 我会把非默认配置的分支都给折叠, 跳过这些逻辑
)

为楼主独立思考, 没有盲从微服务点个赞

按我的理解, 微服务为了解决单体搭便车上线翻车的问题.
单体的时代, 所有人的代码都跑在一个进程里, 你要上线的功能可能跟别人上线的功能跑在一个进程里头, 一般情况下上线完后, 如果出现异常情况, 运维会选择直接回滚, 如果别人的改动导致了回滚, 也可能会使你的那部分功能回滚. 不搭便车的话, 那就得一个功能一个功能的上线.
切分了微服务, 如果你跟别人改的服务没有相交, 可以同时上线, 即使他翻车了, 也只会回滚他的服务, 不会影响到你

当然在单体里头加 feature flag 也能避免搭便车翻车的情况, 有异常情况, 就直接禁用掉那部分功能

业务复杂并不是拆分微服务的充分条件, gitlab 业务也算复杂(工单管理, code review) 至今也就因为性能问题, 把 git 操作相关的从 rails 单体里头拆出来, 用 go 重写了 https://about.gitlab.com/blog/2022/07/06/why-were-sticking-with-ruby-on-rails/

@runlongyao2 我反驳的是 "单体架构下往往本身就是面条代码, 一条业务从入口开始就串联一大堆模块, 你不可能说这段代码你写那段代码他写吧?"

@lujiaxing "单体架构下往往本身就是面条代码, 一条业务从入口开始就串联一大堆模块, 你不可能说这段代码你写那段代码他写吧?" 为啥不可以 ? 我可以给不同的模块划分不同的维护者. 比如 tidb 进程内的每个模块都有不同的 owner: https://github.com/pingcap/tidb/blob/master/pkg/expression/OWNERS https://github.com/pingcap/tidb/blob/master/pkg/ddl/OWNERS

"难不成要变成 "你等他的模块写好, 他等另外的人的模块写好"" 为啥不能同时进行 ? 我可以抽象成接口进行 mock. 我可以约定好你这个模块产生什么样的输入, 然后两边并行开发

"还是说你先写好了结果顶着编译器报错提交代码" 微服务将接口改起来得小心翼翼, 避免变得不兼容. 单体改完接口还有编译器检查错误

"你负责订单你就一直负责订单, 订单完成后的事情, 什么加积分, 客户升星级, 结算分佣这些" 我可以在单体内划分出不同的模块, 每个人专注于不同的模块


"至于链路追踪就更搞笑了. 单体项目还需要什么链路追踪? " 为啥不需要呢 ? 比如 https://github.com/prestodb/presto, 一个 sql 打进了, 我想看到产生的逻辑/物理计划啥样, 切分成了哪些 fragment, 每个 fragment 有几个 task 打到了哪些节点上, 这不值得上个链路追踪吗 ?



"单体架构下往往本身就是面条代码, 一条业务从入口开始就串联一大堆模块," 一个服务把其他服务串联起来算是面条代码吗 ?

"生产环境哪里报错了有完整的调用堆栈. 甚至可以在错误日志里打上下文. 你拿着数据自己去调试就好了. " 你这是没被跑几百次才出现的 bug 折磨过

@lujiaxing
1. 微服务边界拆分不合理, 也会出现一个功能改多个微服务的情况. 我不明白你是咋得出"这时候微服务可以很好的让团队成员聚焦于某一个具体的模块"这个结论的. 如果把模块拆好, 一个功能只改一个模块, 就算是跑在一个进程里, 又有啥问题 ?

2. 放 docker 里

"链路追踪" 不是微服务特有的问题. 微服务比单体更容易实现 trace. 如果都在一个进程内, trace 只能靠手动埋点. 拆了微服务, 一般通过 rpc 调用, 可以用中间件的形式来统一实现 trace

@RicardoY 我在 https://v2ex.com/t/1079010?p=1#r_15371204 里头的确没提到这一点

@RicardoY 在读一遍我的问题. sidecar 上报这能无侵入的实现. 但是如何无侵入的**关联 traceCtx **, 知道这个 db 查询是哪个 rpc 请求触发的 ?

@mark2025 我的问题是 servicemesh 如何通过 sidecar 实现 trace. opentelemetry 更像是一个规范及 sdk, 从我之前的经验来看, 得需要埋点实现, 似乎没法做到侵入性的实现 trace 等功能

@mark2025 发这个连接有什么用吗 ?

@povsister 那是如何实现的 ? 用的魔改的 db 驱动 ?

@povsister 这种的 trace 能关联 rpc 跟 db 查询吗 ? 比如处理一个请求 req 的时候, 访问了服务 b, c 以及 db, 能在 UI 上看到这个 req 对 db 的访问吗 ? 预期的树形结构是这样的

|_____________________req____________|
|___b__| |__c__| |__db_|

自从 clash 爆出远程代码执行漏洞后, 就把它关在 docker 里的

@wu00 你这说了就跟没说一样. 调试工具怎么逆天了 ? "补全、感知、一键重构、代码风格等工程化配置" idea 也可以

其实也可以看下新的 java.
新的 java 也有些 python 的语法糖. 比如: https://www.infoq.com/articles/pattern-matching-for-switch/ https://www.baeldung.com/java-record-keyword