微服务不是所有，只是特定领域的子集

这张图并不包含某个特定领域的具体架构，属于一个整体性的概括。我们从数据库容量的瓶颈说起，看一下微服务在其中的比重。

数据库

用户数据要存储，就存在数据库。过去这么多年，NoSQL并不能消除开发人员的恐惧，所以，MySQL之类还是大多数公司的首选存储。

假设你的业务增长的很好，这个就有意思多了。项目开始，你的sql玩的越6，那么给后人埋的坑，越多。因为sql的功能太丰富了，一不小心，就炫技了。你会发现，林子越大，对sql的规范要求越高。一些官宣的特性，在公司内是严格禁止的。

市场发展很好，终于来报应了。以前的技巧变成了现在的累赘。慢查询、全文扫描，招招毙命。想要加缓存，结果发现无从下手;想要分库分表，结果发现表关系错综复杂。

小表和宽表

所以第一步，还是得去填坑。一个超过3个表的联合查询业务，大概率是不合理的。在加缓存和分库分表之前，还是得重新设计一下数据表。

忘掉什么数据库范式，我们将存在两类表：小表和宽表。

小表提供了最基本的数据，可能一个简单的KV就完成了。一些联合查询，是直接可以在程序里进行循环拼接的。程序里循环1000次10毫秒的查询，比单次查询耗费6秒要强的多。这就是分布式系统的特点，小耗时的批量查询，比hang在那里更加有生命力。

宽表通过冗余的方式，提供了某个重要功能常用的分析数据。这种表的字段一般都特别多，在写入时通过拼接获取冗余数据，一般用在读多写少的场景。

完成了这一步，接下来的工作才能进行。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!