群聊服务——代理模式OR适配器模式

The palest ink is better than best memory——好记性不如烂笔头。2014补记

---

一、业务场景：

当时，公司产品A（业务线A）准备添加群聊（群组）功能。另，预估产品B、C…也会添加此项功能（现在确实几条业务线都接入了此服务~）。

群聊初步功能有如：创建群组、修改群组信息、邀请用户入群、用户申请入群、入群审核、用户退群、踢人、群活动等基础功能。

但是，如果多条业务线接入，可能每条产品业务线一些“玩法”不同，比如：用户申请入群。可能A产品要求用户完成了个人profile资料即可申请入群，而B产品业务要求用户城市、行业等一些更具体限制，产品C业务要求入群还要扣除用户积分——即：规则不一样。

二、分析&方案：

根据“动静分离”基本原则，所以决定把基础功能作为服务。具体“玩法”有各业务线服务单独完成：

业务线系统和运营系统均通过RPC调用公共服务。

三、实现&问题：

• 1.数据库设计：
  群的数量是有限的——不会很大（即使10条业务线，目前公司不太可能~）；每个群的人数是定量。所以不 按业务分库，也没拆表的必要。所以每张表都有一个app字段标识业务数据来源。

• 2.问题：
  公共服务如何更好的知道调用来源？写入或根据这个来源标识查找指定业务相关记录数据。

  a.公共服务暴露的service每个方法都多一个APP枚举参数，让调用方传入？如：
  

  b. 还是在每个serviceImpl中注入依赖：
  

a意味着调用方每个方法都要多传入APP参数，即使整个业务线中明确肯定本业务调用只传那一个值；
b在运营系统调用时不够方便，因为来源不确定——运营系统管理着所有业务线，如入群审核。

考虑到“当前”接口不多，所以采用a方案，然后在service层加一代理层（静态代理），代理层依赖APP，业务系统调用时配置注入一次APP即可，运营系统不通过代理，直接调用。

四、思考：

静态代理，多了一层，且静态代理有明显的缺点——接口变动，代理类，实现类都要改；对外服务多时，要实现很多的代理类；

动态代理好实现吗？还是适配器模式更好？