要搞微服务，先搞 devops 。git 用起来，jenkins 自动化容器化部署搞出来先。同时 elk 或者 efk 搞起来，不要捞个日志还费死个劲。然后 maven 私服什么的也搞起来。。。

上面这些搞好了，然后把例如用户中心、消息中心这些基础服务拆出来搞起来。

最后，你去搞业务就非常轻松了。如果一上来就拆业务，累死你也搞不好微服务。

原先桌面应用没有服务端的吗？有服务端的话很好改造的呀，无非就是后端改成 rest 接口，前端改成 spa 。

@kusya 如果你的肉偿能力不被击穿，就和保证新冠肺炎保证不会击穿医疗能力一样（这就和英国搞全面免疫一个意思），就不需要由系统来保证一致性。

简单地说，就是只要人工处理不一致的能力有富余，你就让他不一致呗。

@cinlen 最终还是要靠肉偿的……只有这个才是终极可靠的兜底方案。

固定可枚举：枚举类型
需业务自定义可枚举：字典
不可枚举：运行时输入

那有什么瓶颈期，你们学习新技术都不用回顾改进再应用的吗？学而时习之，不亦说乎。

多大厂也不会全面使用分布式事务。不是被逼得没办法，谁会去做坑死人的分布式事务。

@Vimax 你这种需求，本身就和业务绑定在一起的，不用去想怎么解耦。你开一个线程异步去写日志，失败也不会让主线程崩溃的。反正日志数据又不是必需要记录成功的。其实你通过 mq 去写日志，基本可以认为不会失败了。

前端的结构是：应用-模块-功能(页面)-子页面，这样 4 级。避免臃肿很简单，合理划分模块，让应用不至于过于庞大就行。然后一个应用一个项目，发布的时候自然轻松。

接口请求日志包含了用户操作信息，所以可以在网关上面增加接口请求日志来实现。也用不到 mq 。

如果你想要比较纯粹的，数据格式更加友好的操作日志，譬如 xxx 将 yyy 修改为 zzz 这样的，就只能在业务逻辑里面调用日志工具类的静态方法来记录了。这种可以通过 mq 去异步写库。

上传音频视频不要流量的吗？手机正常使用上行流量应该很低的，自己看看套餐的流量就知道有没有了。

@murmur 我很是喜欢这种又轻又薄的手机呢……一点都不喜欢大屏幕和大电池，放口袋里坠的厉害，难受得一逼啊。

大数四则运算不是一个好的面试题。面试时间有限，没专门看过题的，大多只能给你一个小学生列竖式这种粗暴的算法。这种你能认可？真能没看过大数运算库源码的，面试这几分钟就能写得出来差不多代码的，估计万中无一。想找这样的天才，你是在想屁吃。

真工程上要用，你会自己写一个？还不是找个库解决。

折腾了一圈，然后全都不用了

@xuanbg 限流参数就 2 个，分别是单位时间内可访问次数和最小时间窗口。前者如果被设置为每天 100 次，那同一个来源的请求从第一次开始计时，24 小时内超过 100 次后就会被拒绝。后者如果被设置为 3 秒，那么在第一次访问开始计时，3 秒内除第一次外的访问都会被拒绝，过了 3 秒之后，再次访问则重新开始计时。因为你不发请求就不会开始 3 秒计时，所以不会有什么 2.9 秒后只需间隔 0.1 秒的漏洞。

网关上实现，根据 url 读取配置表中的接口配置数据，如果配了限流参数，就按限流参数来进行访问限制。