微服务之后的数据

Question

最近在学习微服务架构，但对其背后的数据架构不清楚如何处理

无论是单体应用抑或是拆分成微服务的应用，其背后都离不开对数据的操纵，无非增删改查。
在单体应用中，数据访问在同一个库或分布在几个库中，但根据业务划分，大部分业务相关的数据会在用一个库中，这就可以保证数据操作的ACID（当然，这仅仅是我个人工作中接触到的，可能数据量不够大）。

但在微服务架构中，可以有以下场景：

1. 多个不同功能的微服务都连接自己的库，也不排除多个微服务使用同一个库；
2. 同一功能服务的多个启动实例使用不同的库；

个人理解，在场景1下，如果每个服务都连接自己的库，那一个业务的不同处理阶段（不同功能服务）——比如机票预定（用户信息校验 + 生成订单 + 支付订单）都需要操作数据库，而这三个服务中的数据库操作应该划到同一个事务中，此时可以使用的方式有：

• 在用户校验里开启事务，发出事件，等从支付订单服务完成的事件返回后才最终提交事务，但原子性保证差点
• 事件表存储事件，操作业务数据的同时插入事件，一个单独的事件发布服务读取该表，发布事件，更新事件状态
• 集中式事件表，即单独的表来记录事件，几个微服务共享同一事件表，一旦事件表事件变化，那么多个服务都会知道

<font color=#FF0000 >有没有其他更好的方法，请前辈介绍一下自己项目中的经验</font>

在场景2中，假如多个服务实例连接相同的库，虽然可以保证数据一致，但毕竟单个库的读写能力有限，这样即使部署新的微服务实例，也解决不了性能。如果每个实例连接不同的数据库，由于负载均衡，每次调用的服务实例就可能不是同一个，那么，此时的数据如何处理？
(例如：一个服务起了两个实例，实例1连库1，实例2连库2，有一部分数据存到库1中，一部分数据存到库2中，当调用实例2查询时只能查到库2中的数据，调用实例1就只能查库1中的数据)，即使查询可以通过读写分离技术，通过构造单独的Reporting库来查询所有， 但如果是更新数据(写操作)调用实例1或者2也可能由于负载均衡每次访问不同库，造成更新可能成功或失败。一直不太懂这里该如何处理？，还请大神分享一下处理思想和经验。

另外，两个场景下如何更好的选择是否分库，哪种方案更有优势？

-- -- 以上观点，如有不足或错误，望不吝指正，谢谢。