微服务划分问题，大家进来交流一下

[simonlu9]

• 最近在做积分商城，用户可以用积分购买头饰佩戴在自己的头像上面，涉及到头像的地方都会出现这个头饰

• 遇到的问题是，这个业务写在用户服务这边还是积分服务这边

• 如果写在用户服务这边，对代码侵入性挺大的，比如说在用户表这边记录一个头饰 ID

• 如果写在积分服务这边，积分这边要记录在用户佩戴着那个头饰 ID ，用户显示的时候要调用积分服务查询用户是否有佩戴头饰进行显示，

• 用户完成某些任务可以获取积分，目前是通过消息队列解决这个问题。

大家会选择哪个方案

[ChoateYao]

在增加一个饰品服务解决问题

[eote]

用户侧新开张表，主键(uid, 头饰 id)，要么用户查询的时候 left join 一下，要么新开个查头饰的接口

[libook]

单开饰品服务（或者头像服务）。

商城服务里面做 SKU 管理，用来管理多少积分兑换啥东西，需要对接饰品服务及其他用户可以兑换的实体所负责的服务。

商城服务只记录积分消费订单，不负责管理积分兑换的东西，用户兑换订单的时候通知饰品服务来给用户加饰品。

积分你可以单独作为一个微服务（比如积分钱包）被商城服务调用，也可以把积分服务扩展成积分商城服务，取决于你积分的主要使用场景是不是商城。

[simonlu9]

@libook 流程是不是可以这样理解，用户兑换积分购买头饰的时候，积分服务调用饰品服务，给用户加头饰，然后用户信息查询是否有佩戴头饰的时候，需要调用头饰服务判断，相当于多了一个中间服务，这样理解没错吧

[jorneyr]

给头饰专门搞个微服务，完美解决。

[Chad0000]

头饰弄成独立微服务，然后对于头像这种查询过于频繁的，可以考虑在用户那边做冗余处理，这样用户购买后通过事件将购买的头饰同步到用户的头像扩展属性中。然后前端通过扩展属性知道购买了头饰再加载头饰信息。

[libook]

@simonlu9 #4 就是头饰的事都交给头饰服务来做，积分的事都交给积分服务来做。

积分兑换头饰的时候，积分服务只完成积分的核验、花费的部分，成功后通知头饰服务；头饰服务接到通知后专门有个给用户加头饰的过程。

展示用户头饰的时候，是直接调用头饰服务，来看用户拥有哪些头饰，已经目前正穿戴什么头饰。

[qingshuang]

多加一个服务，成本是不是太高了。。
如果读场景的触发频率远远大于写场景，就写在用户服务好了。
单独开个表的好处是以后功能变多了，把饰品拆出去作为微服务的时候更方便

[simonlu9]

@qingshuang 我也觉得，不考虑成本，拆的话肯定最理想，只是机器有限，成本有点高，现在打算流量大的服务才拆出来

[sss495088732]

..遇到过这个需求...用户量少.选择了直接并在用户表里

[stach]

@simonlu9 你不想单独划分一个 “头饰服务” 没什么问题，可以把它划入 “用户服务”，作为用户的扩展属性来对待。
至于你说的侵入性大，那就是你的思路错了，“单体服务” 依然可以内部划分和隔离，隔离的程度取决与你的需求。

[rabbbit]

单分个装扮服务出来？以后有什么头饰 铭牌 勋章啥的都扔进去。
要是只有头饰那还是塞用户服务里吧。。。

[rabbbit]

小公司就算了还是塞一个里吧，我这后端拆了一堆，搞得我起个后端服务调样式，直接一半内存没了。

[lingalonely]

从逻辑来说，放在用户服务比较合理，饰品是装饰用户的，可以表示为用户的一个拓展属性，形成用户饰品表，一直跟着用户走，另外用户的饰品应该可以切换吧，如果可以更应该和用户绑定，另外拆分也行，不过为这么小的功能拆分不值当，除非后面有类似虚拟人物的业务，涉及大量装扮功能的实现就要考虑拆分了

[xuanbg]

这是写在用户服务还是积分服务里的问题吗？这是缺一个会员服务的问题！头像要玩花样，或者搞什么用户勋章之类的玩意，就必须要有个会员服务。

[simonlu9]

@lingalonely 其实就像现实中超市积分兑换礼品一样，超市肯定那边有记录你兑换了什么，然后我们就得到一份随身物品，这个物品用户身上也可以记录的，所以最好两边都有这层关系，所以现在打算就这么做了

[simonlu9]

@stach 嗯，现在另开一张表记录这个佩戴信息