@kingcanfish 这个文章真不错

可以，我们大项目的，核心业务会分开用，其他周边的业务也都是塞到一个实例里面。

账号：yibaiben

感谢！

和 2 楼差不多，不给 sudo 权限，每个人自己用 conda 管理自己的环境就行，驱动管理员负责更新。
然后大家去抢就好了 10 个人。

同时要看你买的什么配置的 MySQL ，跑在什么硬盘上。我们之前几亿的数据常规业务操作基本 100ms 以内完成。

支付完之后，指数退避去查状态，设置一个几分钟的最大上限就可以了。或者从业务逻辑去看有没有让整个交易重入的办法，用同一个订单号去对方支付系统里重试支付。

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

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

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

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

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

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

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

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

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

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

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

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

vscode

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

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

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