格子衫已上身

有点辣眼睛

只有两个分支的同一个文件都有修改，合并才会有冲突，所以理想情况下是不允许两个分支同时去修改同一个文件的。你们组长的分支策略没错，但不同 feature 居然会修改很多相同文件，显然是项目的模块划分有很大的问题。

MacBook Pro (15-inch, 2018)，2.9 GHz 六核 Intel Core i9，Safari13.0.2 得分 131，Chrome 76.0.3809.100 得分 110

我司是一家互联网小厂，业务规模也比较小。这是背景
微服务在我司的实践也有 2 年多了，和单体架构相比，好处还是不少的。最大的好处，就是业务复杂度的降低。刚入职的新人我就敢让他独立负责一个新项目，只要花几分钟了解我们的项目模板，就能直接上手，真正做到了只需要关注业务。其余的例如方便水平扩展，局部更新，项目组织灵活等等就不多说了。
在实践中，最大的问题是服务边界的界定问题。总有人见风就是雨，看问题只看表面，不能把代码写对地方。其实这个问题在单体架构中也是存在的，模块没有边界，代码到处乱写也很常见。单体架构设计不好，微服务照样搞不好。

楼主你这个其实就是各种维度的报表而已，但产品硬生生把报表搞成了查询，我猜他们在统计之外，还要看到各种明细吧，而且还要实时的，这个就尴尬了。

@UserNameisNull 双检锁了解一下。B 获取到锁不是直接去更新，而是先检查一下 Token 是否可用。

分布式锁，更新的时候加锁就行了

vmware 没问题，其他没装过

应该是包的版本不对，没有 checkArgument 这个方法。

上面说得不是很准确，不是自己实现 feignClient，是自己构建 feignClient，就像这样：
TaskClient taskClient = Feign.builder().decoder(decoder).encoder(encoder)
.requestInterceptor(template -> {
Map<String, String> map = call.getHeaders();
for (String k : map.keySet()) {
String v = map.get(k);
template.header(k, v);
}
}).target(TaskClient.class, getServiceUrl(call.getService()));

没能理解楼主的问题在哪？ Ribbon 的路由策略和拦截有啥关系？正常配自定义路由策略就好了吧。feign 请求加请求头的问题？是的话自己实现 feignClient 就行了。

Apollo 搞得有点复杂了，我选择自己撸一个简单的恰好够用的轮子

ZenTermLite

@crclz 分布式锁可以帮到你呢，亲！

想了一下，还有一种间接的办法，就是给你的原始数据加一列 group_id，让每一对 IN_OUT 拥有相同且唯一的 id 就行了。然后你就能按 group_id 进行 group by 配对了。

非要 SQL 处理，只能存储过程用游标。这种方法严重不推荐！

这个数据 SQL 没办法做到一一配对。如果数据是有序的，你还能写代码用循环来处理。