ELK/EFK 这种一点都不重，几行 docker 命令就搞定

@firejoke base64 只是编码，没有加解密的功能啊

流程不懂问领导

别光想着代码怎么写，要先想明白事情怎么做。理顺关系，设计好结构，定下流程，代码只不过是表达而已。

这是运营的套路，程序员可不背这口黑锅。客服居然肯给你换成 10 块的券？看来楼主魅力至少 12 点啊。

最简单粗暴的做法就是重新请求数据。好处是简单，而且顺便把列表刷新了。缺点是费时间费流量，而且为后端所不喜。

除了上面的办法，你可以自己刷新数据。好处是不用请求接口，也就没有卡顿。缺点是不能及时刷新列表的其他数据。

你们没看到纸糊被卖课的霸屏了吗？

都改成用 token 就行了。

需要鉴权的(一般是后台管理接口)统一鉴权，可以验证身份的必须验证 token，没法验证 token 但可以验签的(开放平台接口)必须验签，连验签都不能做的(如商品浏览、注册登录)就只能限流了。

3 对外，5 对内

docker 容器的时区、mysql 的时区、jvm 的时区、tomcat 的时区，它们都不是一回事。要全统一为东八区，才能够让时间和现实保持一致。

@singerll 没有价值这话说的不对！正确的说法应该是：缺少议价的能力。

跳槽工资翻一番，怎么可能没有价值。

基本没啥问题，人家计较的话，你可以说有些分红啊福利啊什么的也算进去了。

官网，24 期免息分期真香

@realpg
@love 基本没人会这么搞，分布式系统大多采用的是最终一致性。也就是说如果出错，不是回滚数据，而是用消息队列进行补偿来保证数据的一致性。当然补偿也不能保证百分百成功，最终还可以通过肉偿(人工处理)来保证一致性。

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

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

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

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

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

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

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