微服务设计思考(伴随创建)

有的时候一个操作涉及到两个微服务都要创建一个对应的Entity信息,这里分为两种情况讨论,这里先讨论第一种情况,就是现实世界中的一个实体有不同的侧面,而微服务的划分将不同侧面交给了不同微服务来处理,各自专注于处理相关的一些信息.

例如当新增一个客户时那么就生成了该客户的一个钱包信息,以及积分信息等等.按照传统的关系型数据库的设计范式,这些一对一的关系用一张表就可以解决.这个表既有性别,生日这样的基础信息,也有积分,余额这样的业务信息.对于单体应用这样没问题但是对于微服务来说就有问题.这里有两种处理方式,

方案一:共享表,还是一个客户表存所有字段

方案二,分开,各个微服务有各自的表

下面分析下利弊

方案一的缺点:如果多个微服务都还是写这个同一张表,那么就需要是同一个数据库,那么这样的微服务划分是不彻底的, 有误操作和数据库瓶颈这些问题.

方案二的缺点：数据会不一致。

关于方案二也有两个做法。

2.1 同步创建。在一个微服务创建的同时通知其他微服务创建

2.2 按需创建。如果不触发第二个微服务的功能则不创建。

2.3 异步创建.这种情况会出现A操作完成后B还未创建的情况,那么A需要代理B的请求从而确保当用户请求过来的时候B创建完毕.(否则请求直接到B上会发生未创建的情况)

两个这里还有另一个要考虑的问题就是。当调用远程服务创建一个实例的时候（例如创建订单时创建支付单，出货单等）可能在对方返回但本地数据库还没来得及保存的时候已经发生了回调，这时怎么把数据存下来。这就要求调用别人前先保存本地数据库，然后带着本地id调用远程服务，也许第二个服务也会返回一个它自己的id，但是回调时一定有第一个服务传过去的id。