今天来复盘一下微服务中数据拆分过程中所踩过的那些坑，背过的锅。。。
添加图片注释，不超过 140 字（可选）
这里来复盘一下，传统项目改造成微服务架构时，数据库拆分所踩过的坑。
1. 数据库拆分过细
在传统的单体架构中，数据库通常是集中式的，每个服务都可以直接访问同一个数据库。对于初次从传统架构转向微服务架构而且没有有微服务经验的团队来说。微服务拆分后，摆在面前的首要问题就是数据库如何设计。
是一个微服务对应一个数据库还是可以多个微服务数据库统一在一起呢？
回头看这或许就不是什么问题，微服务架构本身就是每个服务拥有自己的数据存储。但对于初次改造的团队来说还是会有不少问题，在微服务拆分过细这个前提下，每个微服务对应一个数据库。会带很不少坑
坑点：
- 数据库拆分过细，导致频繁的跨服务数据调用，破坏了服务之间的独立性。
- 数据库拆分过细，会造成数据冗余多、查询复杂化等问题。
原本一条简单的 SQL 就可以完成一次查询，现在需要找 3~4 个人，调用他们 3~4 个接口才能完成。第一费人，第二费时间，第三费机器性能。另外别人接口要调整时影响的人也比较多了，并且有时你要调整别人还不一定会及时响应。面对这些问题，团队就会出现各种各样的解决办法。
比如自己悄悄的建个视图或存储过程，如果审查不严这项目维护成本就大大增加，这影响今后还可能被放大。
2. 数据一致性问题
在单体架构中，由于数据库是集中式的，事务的一致性通过数据库事务机制（如ACID）来保证。然而，在微服务中，多个服务可能需要同时对多个数据库进行更新，无法再使用传统的事务处理方式保证一致性。
坑点：
- 分布式事务难以管理，可能会导致数据不一致问题。
- 缺乏分布式锁机制，可能造成数据冲突或重复。
数据致性又是另一个问题，当时团队有人使用过 LCN，所以当时使用的是 LCN 来实现分布式事务，LCN 实现分布式事务的机制是锁，如果用的不好就会出现把一大片业务给锁了。
当然现在还有很多更好的方案比如：
- 通过事件驱动架构，在消息队列中传递状态变化事件，确保异步更新数据。
- 阿里巴巴开源的分布式事务组件 Seata，支持TCC、SAGA、AT（自动事务）等多种模式
3. 跨服务查询和性能问题
微服务架构要求各个服务的数据隔离，但在实际业务中，很多场景会涉及跨服务的数据查询。如果数据库拆分后频繁进行跨服务查询，将导致查询效率低下，甚至出现网络瓶颈。
坑点：
- 服务之间频繁通过API调用查询，影响系统性能和响应时间。
- 数据分布在不同数据库中，复杂查询（如多表Join）难以实现。
这个问题也是上面的提到，当时团队中有人用视图或存储过程悄悄的实现，破坏了微服务解耦性。后面规范起来最大的原则就是不能走回去，坚持拆分这条路，然后就是通过冗余一些数据减少跨微服务的调用。不过这种也是造成了不少空间的浪费和数据同步的代价，还是加重了服务之前的关联性。
总的问题还是在第一次改造把微服务拆分的过细，所以对于初次传统项目改造成微服务架构的团队来说，第一次拆分不要太细，好的架构并不是一次设计出来的，而是演变而来的。
我是栈江湖，如果你喜欢此文章，不要忘记关注+点赞哦！你的支持是我创作的动力。如果你有任何意见或建议，欢迎在下方留言。若转载，请注明文章来源。
