我们讨论引擎时发现的问题

1. 后管和前台耦合。
   后台运营端功能在调用前台使用的库和服务。而且后台运营端功能有很多查询很重的要求，所以会对前端产生不小的影响。（部两个服务是解决不了的，因为量主要在数据库层面）

1. Provide 和 消息处理耦合。
   有几个Provider同时作为消息消费端的情况。这样，Provider在前端压力和消息压力都大的情况下，很容易造成性能问题。

现在的处理方式是：

这导致A业务服务负担容易很重。很多微服务的控制策略都不容易做。

1. Datasource 配置不足，而且不容易处理。
   目前很多配置都是写10和读300，但Provider中有很多的service业务，“快”业务和“慢”业务之间互相影响，也不容易定扩展策略。

这样可能查询比较复杂的占用了很多资源，而要求快速的得不到资源，只能慢下来，即使库可能还没到瓶颈

1. Count/Sum等在处理线程中。
   在主业务中有调用mysql或mongo的count和sum的操作，这些操作后面都会是性能的很大风险。

1. Service中注入Service.
   在一个provider中的有一部分service，直接注入了在同一个provider中的另一个service。这种情况服务治理不容易做。

2. 圈群关系是一张表，而且没加索引。
   目前的圈群关系是一张大表，没有加索引；而且因为业务原因，也很不容易做分库分表让不同的库表来分担压力。

3. 圈子中mongo和mysql数据之间可能不一致。
   这个问题需要引起重视，也许小并发的时候发现不了。