本文探讨了微服务架构中如何处理连表查询问题。作者建议在业务成熟且人员较多的情况下采用微服务，并强调应沿着业务逻辑进行服务划分。当需要跨服务查询时，提出了通过API接口实现查询、创建汇总服务或使用事件驱动来保持数据一致性等方法，但注意这些方案可能无法实现实时一致性。
谢邀。
首先我说一个很实际的问题，不是任何公司都需要微服务，或者说，不要上来就搞微服务，我看过北京不少创业公司的项目，这么说吧，估值在2亿美金以下的创业公司，基本上没必要搞什么微服务，总共就二十几口程序员，还都坐在一个办公室里面，费那劲赶那时髦搞什么微服务啊，组织团队赶紧出活才是正经的。
DHH曾经写过一篇文章《The Majestic Monolith》：The Majestic Monolithm.signalvnoise.com
讲的就是，应用代码写在一起(Monolith)，只要软件工程组织管理得好，人员稳定高素质，一样可以很出色。
老兵我补一句(一刀)：如果软件工程管理不好，人员不稳定，素质低，搞微服务还是啥啥服务，一样做成一坨屎。
好吧，我喷完了，发泄完爽多了，现在来上干货。
如果你这样搞微服务，说明业务比较成熟，而且人员比较多，只能分而治之。
分而治之的首要原则——沿着纹路来分割。
好比砍木头，如果沿着木头的纹理来砍，很舒服，如果非要垂直于纹路来砍，砍到手软也没什么效果。
软件之间的逻辑联系，就是好比木头的纹路，如果两个联系很紧密的模块，你把他们分开到不同的微服务，那好比垂直于纹路来砍木头，费劲不说，最
最低0.47元/天 解锁文章
扫一扫
112
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
