是时候回归短信和 email 了

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

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

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

op 了解一下 dapr

上班 c#，下班 c#

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

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

偏 Restful 但无需完全照搬，比如下单前检测是否可以下单是查询请求，与创建订单接口要提交的数据很接近，如果非用 Get 那么接收查询参数将是个挑战以及比较恶心。这时候"无脑"Post 就带来好处了。

幸好我提前开始适应系统自带输入法，当时用搜狗。

放香港即可

他们管这个叫低代码 /零代码。

@zzzkkk 能是能，但跟 c#难度不是一个级别的。就像 c++也能，但比 java 更难。因为用的企业太少。

想当年我大二学 Java 好不容易入门了，结果实习公司改.net 了，我跟着一转就是十几年。现在已经靠 c#润出来十来年了。我们这边 c#占大头更好润。无意间的成就。

喂饱

方案 3 ，同时加上版本号，这样使用对应的版本加载就可以。

好东西，尤其是不收流量费用。还没有和 b2 对比