xuanbg

@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 吗？

华为还可以