从公共表看架构的演化

从公共表看架构的演化

什么是公共表

不同的业务模块都需要访问到的表。

假如制作一个商城系统，对于用户表来说，会有许多业务模块访问，就可以被称为公共表。

公共表容易出现的问题

假如有一个巨庞大的用户表（上亿条数据），这时候有个像我一样菜的程序，写了一个sql，你说巧不巧，这个sql写的没能走索引。好么，太刺激了，直接上亿条数据进行全表扫描。

全表扫描就算了，这是个公共表，其它业务都访问哩，直接全给影响了。我这种菜鸟肯定不能负责的是重要模块啊，然后因为我一个边缘模块，把核心业务冲了。

解决办法（一）

进行模块拆分，把公共表拆分出来，由专门模块管理，其它模块调用它。

既然模块拆分了，那么拆分的更彻底一点吧，把数据库也拆出去，用网络请求连接。

互相不干扰，岂不美哉

但是还是有问题，A团队负责业务1，然后需要修改某一个功能，B团队负责业务2，然后B团队有业务需要请求业务1。好了，难受了，你A团队加班改业务，B团队得跟着。万一改完出个bug，可以准备好小板凳和瓜子看A团队与B团队打架了。

传说中的微服务

各个模块之间能不能不直接请求。当然可以，计算机经典操作，遇事不决加一层。加一个注册中心，大家都去注册中心找。

传说中的微服务就出现了，完美。

总结

不同架构都有适合的场景，如果业务量不大，直接单体就用就好了，快速搭建，成本还低。

不要觉得微服务架构就百分百完美，首先要是注册中心挂了不久直接全没了。再就是，如果你就一个简简单单的场景，可以说可有可无，你设计微服务，然后一计算，需要多加几台服务器，成本几十万，你看老板抽你不。

架构没有最好，只有最适合。