由 dawei 这张图并不包含某个特定领域的具体架构，属于一个整体性的概括。我们从数据库容量的瓶颈说起，看一下微服务在其中的比重。
数据库
用户数据要存储，就存在数据库。过去这么多年，NoSQL并不能消除开发人员的恐惧，所以，MySQL之类还是大多数公司的首选存储。
假设你的业务增长的很好，这个就有意思多了。项目开始，你的sql玩的越6，那么给后人埋的坑，越多。因为sql的功能太丰富了，一不小心，就炫技了。你会发现，林子越大，对sql的规范要求越高。一些官宣的特性，在公司内是严格禁止的。
市场发展很好，终于来报应了。以前的技巧变成了现在的累赘。慢查询、全文扫描，招招毙命。想要加缓存，结果发现无从下手;想要分库分表，结果发现表关系错综复杂。
小表和宽表
所以第一步，还是得去填坑。一个超过3个表的联合查询业务，大概率是不合理的。在加缓存和分库分表之前，还是得重新设计一下数据表。
忘掉什么数据库范式，我们将存在两类表：小表和宽表。
小表提供了最基本的数据，可能一个简单的KV就完成了。一些联合查询，是直接可以在程序里进行循环拼接的。程序里循环1000次10毫秒的查询，比单次查询耗费6秒要强的多。这就是分布式系统的特点，小耗时的批量查询，比hang在那里更加有生命力。
宽表通过冗余的方式，提供了某个重要功能常用的分析数据。这种表的字段一般都特别多，在写入时通过拼接获取冗余数据，一般用在读多写少的场景。
完成了这一步，接下来的工作才能进行。
