虽然一个用户有多个 openId，但这些 id 是和公共号一一对应的。你伪造的上哪里去对应？对不上就拿不到用户身份，就没法通过验证。

正在慢慢搞，这个行业大多需要定制化的，很不好搞啊。salesforce 这种很多地方是玩不转的。

@fengchang 我一个人开发也搞微服务。只需要写业务模块的代码就搞定整个项目，完全不需要关心那些和业务无关的功能，包括但不限于：用户、组织机构、权限、账务、支付、字典、报表模板、短信、邮件、消息通知、失败重试等等……

微服务属于那种一次投入终身受益的事。既然已经投入过了，我何苦不接受这个好处非得每个项目自己搞一套呢？用一套现成的他不香吗？

微服务有必要。对付这种需求变更频繁，业务组成复杂的情况，微服务就是最好的解决方案了。但搞微服务，你们要先搞定 devops，要对 ddd 有所理解，然后才能成。

至于高并发，你当他是买一送一的就行了。事实上微服务本身就是个分布式系统。搞定高并发，就是多部署几个实例的事。钱能直接解决的问题也就不是问题了。。。

rts 和 rpg 理论上可以做到全部运算都在服务端，客户端只能下指令。但 fps 只能客户端运算，所以作弊外挂屡禁不绝。

@594duck 现在也一样啊。微服务要做好是需要一些基石的，譬如 DevOps 、DDD 、Spring cloud，还有用户中心、账务中心、消息中心等业务无关的支撑服务。这些都是搞定了，就只剩下写写业务代码了。这样的微服务是很爽的，每个服务都很简单，开发快、上线快，并且易于扩展和维护。

微服务的核心优势就是把系统复杂度从开发转移给了运维，而运维靠 docker 、CI/CD 、k8s 这些技术解决了开发甩过来的复杂度，所以大家都很快乐。但如果你没有能力搞定运维，就会被干趴下，于是微服务对你就不是什么好事了。在服务拆分上面也一样，拆得不好，维护起来比单体更麻烦。

所以，是不是要上微服务，不是看规模大小，也不是看行业，而是看团队有没有这个能力。有能力就上，没能力就不要赶时髦硬上了。

@cokyhe 复制粘贴一次 2 分钟，照这样算的话，一天复制粘贴足足 240 次呢！我就不信没有重构代码的 1 小时时间。

再说，下个项目复制粘贴这次重构后的代码不香吗？

反正我写的那些 crud 项目，都是整个复制，稍稍改动下代码，重写 sql 就完成了。不说一天写完全部接口，有个 3 天的时间基本代码就写完了。反而在这之前，要花好几倍的时间做需求分析和流程梳理。

非结构化的地址自动处理成结构化地址是有一定的错误率的，楼主你把错误的抛出来人工处理或者干脆丢弃就行。

时间戳相同也有多个递增 id 的

这里建议楼主拿起法律武器维护自己的合法权益呢。当然，起诉的对象应该是恶意攻击楼主网站的人而不是腾讯云。

@sagaxu
@a719031256

现在都是这种注解写法吧……

@Results({@Result(property = "detail", column = "detail", javaType = Object.class, typeHandler = JsonTypeHandler.class)})
@Select("<script>select a.id, e.`name` as entity, a.type, a.`code`, a.`name`, a.balance, a.detail, a.is_invalid " +
"from iaf_account a join iab_entity e on e.id = a.entity_id where e.tenant_id = #{tenantId} " +
"<if test = 'key != null'>and (type = #{type} or `code` = #{key} or name like concat('%',#{key},'%')) </if>" +
"order by created_time desc</script>")
List<AccountDto> getAccounts(QueryDto dto);

压根不需要 xml

多台√
单台×

负载均衡不是一般都用 Nginx 的 upstream 吗？

华为还可以

做点自己能做的，脚踏实地一步步走。就是龟爬，爬个十年八年的总也能爬到了。

decimal 就是干这个的

淘宝找卖二手 dell 的，把 CPU 和内存买回来插上就行了。这个小偷怎么说呢……如果把你硬盘拔了，你绝逼报警了。丢个 CPU 和内存，你就会嫌麻烦不去报警。

@HUALIAN 自己记录一次轨迹，然后合理加点偏移重放就行了

爬虫改成 1920 * 1080 你不就抓瞎了？反爬要根据用户行为特征，而不是设备特征。