@ziqingnanyi 我不看抖音和热搜什么的，对于我来说就只有朋友圈了。自从上海封城开始我就关朋友圈了（关闭功能但没有设置三天可见）发现还真有用，现在也适应了

正确的做法是先躺一会儿，哈哈，别问我为什么知道。

手持 7P 感觉都不应该留言 哈哈

@huangmingyou #56
🈶️

没什么限制，建议香港节点。国内偶尔不稳定，我就在这么做。

可以考虑下载 app 自学，买个电钢琴就可以。我家小孩之前找老师学，后来学不下去了。我们大人也想学就买了 app ，这几天开始学，挺好的。包括小孩也开始跟着学了。app store：simple piano 。

于是我关了朋友圈，得以清净

如果已经在使用 azure devops 则可以使用里面的 wiki 。

普通人也就是技术 Run 了，要么先留学，要么有机会直接工作。而后者是成本最低的方式。比如我就是通过 WHV 签证来的新西兰，然后这个签证允许工作，我就找到 IT 相关工作，申请的移民。我没在大公司待过，211 大学，考雅思 6.5 分用了半年时间，在技术圈算是普通人吧，也是有方案的。

@ihciah cf 也出数据库了，还有存储。op 的需求都可以在 cf 那边实现

@SamShaw 手机起码还有真人客服或者实体店可以申诉

正在挖屎山，成就或者成仁

是时候回归短信和 email 了

@v2byy 而且我这边是海外公司，To B ，数据量大但用户访问量没那么大。我们做了大量第三方对接，都在一个项目直接引用难以管理。将每个对接方独立成服务使用 Dapr 隔离开，是一个很不错的方案。

@v2byy #7
Dapr 是用 Go 开发的，Sidecar 比较小。至于对于性能的影响，官方的说法是 1000/s 的请求只需 0.5 核 CPU 。使用微服务本身就是进一步隔离不同服务但同时降低了单个服务实例的性能。我选 Dapr 主要是它将分布式开发所需模块都集成，比如服务发现、状态存储、事件等等。它还有自动重试以及保证到达，Actor 模型等有用的功能。以及切换中间件都无需修改代码，大大简化了微服务的开发。

至于性能影响还是以实际测试为主，比如测试一下带不带 Sidecar 的影响。我们现在都没上微服务，准备将一个传统应用迁移到 Dapr 。

op 了解一下 dapr

上班 c#，下班 c#

办卡可以，不告诉他密码。

头饰弄成独立微服务，然后对于头像这种查询过于频繁的，可以考虑在用户那边做冗余处理，这样用户购买后通过事件将购买的头饰同步到用户的头像扩展属性中。然后前端通过扩展属性知道购买了头饰再加载头饰信息。