阿忠伯的特别放送 | 答疑解惑01
胡忠想
该思维导图由 AI 生成，仅供参考
你好，我是胡忠想，我的专栏虽然已经结束了，但我还会一直在专栏里为同学们答疑解惑。所以，即使你现在刚加入到专栏学习中，也可以随时留下你的疑问。同学们问得比较多的问题我会记录下来专门写成一期答疑文章，希望和你一起详细讨论。
今天是答疑的第一期，我选取了前面几期比较有代表性的问题，其中很多也是我在实践过程中踩过的坑，针对这些问题我来分享一下我的体会。
这三个问题都是关于服务拆分的，下面我就从微服务拆分粒度、拆分方式以及微博微服务拆分实践三个方面来谈谈服务拆分那些事儿。
首先来看微服务拆分粒度。微服务拆分的粒度可以很粗也可以很细，具体要视团队的规模和业务复杂度而定。通常来讲，当团队的规模逐渐变大时，一个业务模块同时就会有多个开发人员修改，在需求研发期间，经常需要协调合并代码，沟通打包上线，研发成本越来越高，这时就需要对这个业务进行微服务拆分了，变成多个独立的微服务，分别进行代码开发、打包上线，实现研发的解耦。但是也要避免一个极端，就是把微服务拆分得太细，出现一个开发需要维护十几个以上服务的情况，这样的话团队维护的成本太高也不可取。
再来看下微服务拆分方式。在具体进行微服务拆分时，通常有两种方式，一种是按照服务的关联维度进行拆分，一种是按照数据库隔离维度进行拆分。按照服务关联维度拆分指的是两个服务是否具有紧密耦合的业务逻辑，如果能从业务逻辑上进行解耦的话，不同的业务逻辑就可以拆分为单独的微服务。按照数据库隔离维度拆分是指如果两个业务逻辑依赖的数据库不同，那么就可以把它们拆分为两个微服务，分别依赖各自的数据库。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文围绕微服务拆分展开讨论，介绍了微服务拆分的粒度和方式，强调了避免拆分得太细或太粗。以微博业务为例，详细阐述了按照服务关联维度和数据库隔离维度进行拆分的实践。此外，还探讨了微服务拆分后的性能影响和接口定义方式，包括Swagger和PB文件。最后，介绍了服务化框架集成监控日志功能和数据处理的实时操作，以及服务追踪在快速定位线上服务问题和确定用户请求失败原因中的应用。整体内容涵盖了微服务拆分的方方面面，对于想要深入了解微服务拆分实践的读者具有很高的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《从 0 开始学微服务》，新⼈⾸单¥59
《从 0 开始学微服务》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(8)
- 最新
- 精选
每天晒白牙很荣幸看到自己的留言出现在上面，看来我要二刷了，更认真看，继续留言，期待老师的更新作者回复: OK
2018-12-1133
Typing...您好，我们公司现在用的motan版本是0.2.1, motan-memoryStatistic打出的log显示内存会不断上涨直到占满eden区，然后eden会频繁的进行gc，请问该版本是否有bug？为何内存会一直上涨？作者回复: 是最新版本吗，旧的版本可能会有bug，建议更新到最新版本
2018-12-12
breezeQian老师，之前说的微博的基础架构的文章分享，后期会写吗？期待着作者回复: 答疑之后会写，不定期
2018-12-11
brqi
可以用DDD做领域划分，后用微服务承接实现。2022-12-27归属地：广东
惘 闻为什么批量删除会解决僵尸节点的问题呢？增加了有分阶段事务控制功能还是重试功能吗2021-01-29- infancy微服务实践的第一个课程，理论结合实践，物有所值2020-03-27
钱答疑很认真呀😄 给老师点赞👍2019-06-16
shine“并在下一次调用的时候选择平均响应时间最快的节点”和“另一方面客户端并不是每一次都选择平均响应时间最快的节点发起调用” ，这二句话是不是矛盾的？2019-02-23
收起评论
