不太确定，或许你需要 istio ？不过为了这个搞 istio 感觉不划算。

serverless 从成本角度看局限相当大。从云厂商的角度看它可以融入到一些基础设置功能里面，允许用户写一部分自己的代码嵌入到标准的执行流程中价值很大。

建议不要 WSL ，直接 win 本地开发， 尝试一下 powershell ，很牛逼的！然后配置下 oh my powsh ，爽上天。Windows 现在的使用体验，要我说好过 macOS 。

本身 accept 就是告诉服务端客户端期望返回什么格式的，你的理解没有问题。但实践上来说，只响应一种稳定的格式会剩下很多麻烦，返回多种格式的情况也不是那么常见。然后又是你 leader 说的，建议听 leader 的。

实现厂商容灾的方案是一开始就将业务多活到多个云服务厂商上。

因为硬盘会坏，提高安全性的方法不是搞一个快速拷贝工具。

如果你只有两台服务器而且业务看起来不怎么增长的话，最简单的方案就是做一个中间服务取的时候两台服务器都去访问一下。

生产环境的账号我能不要就不要，都找运维操作。非要我自己登陆的我只要最小权限的账号。

看你的逻辑是想阻止新任务提交，但是已经提交的任务要继续处理完是吧？

如果可以可以控制上游，那应该把 close chan 返回回去，让上游自己停止提交。

用 IDE 很快就改了，问题不大。能很快改掉的问题都不大。就怕那种改不了的。

真的超乎你的想象。我专门开发过百万充值入账功能给土豪大把充钱。就是有这么多有钱的玩家，其他的利润来源基本没有，热门游戏托都很少，主要靠活动策划运营来刺激大 R 持续消费。游戏利润率就是这高。

vscode

正确的做法就是就地判断 error ，当场决定是否要处理。相比抛出异常，有了更合理的处理时机——在错误发生的地方，持有错误发生的上下文信息，可以自由地编写针对性的处理逻辑；而统一的异常处理节点已经丢失了错误发生的上下文信息。赞同 frodez 的说法，统一的逻辑往往就会变得既不方便也不正确。

panic 仅仅应该用在整个程序已经无法继续运行的时候，对于业务逻辑来说很少有这种情况。

产品用这个吧，输出到我们这纸和笔画一下架构就行了。

直接用网页画，pyqt 也不好用。

@pepesii 确实是这样的。遗憾的是由于容器化等让服务拆分的代价小了很多，导致很多不合格的开发者害怕对现有服务做迭代，随意拆分导致整个系统乱成一团。

有 devops 来做这些事情，然后做成自动化的流水线。

看你接触的工程有多大，我现在 1T 差不多够用。

字节就是这样啊

会，我们的业务后台和前台就是同一套账号体系，因为需要给到非厂内人员使用，比如外包运营，第三方公司的各种人员等不可能给他们公司内部的账号。但内部还是有另外一套全公司级别的账号体系打通，可以做权限更大的事情。