一般不会有什么系统一上来就采用分布式微服务，会先采用单体的形式，这时候数据库和应用完全是有可能部署在同一台服务器中的，接下来随着业务发展，数据量也会随之增多，为了适应数据量，提高用户体验，会选择适当的升级服务器的配置，比如增大CPU的核数，扩大服务器内存，使用固态硬盘等，这种提高单台机器性能的做法叫做垂直扩容。但是单体机器的升级是有极限的，当垂直扩容到一定极限的时候，再往上升级，成本会越来越高，投入与产出不成正比，这时候可以引入水平扩容。
水平扩容简单的理解就是加机器，通过加机器，做集群，配合负载均衡，分流减压，同时如果数据库也存在着瓶颈，那么可以考虑做数据库主从，采用读写分离，实现读数据时读取读数据库，写数据时写主数据库，然后主从同步。到了这步，如果业务还是持续增长，可以开始往分布式上走了。
分布式可以说是一种思想，分而治之，具体落地还是做技术选型的。如Spring Cloud，Dubbo。想要做成微服务，关键的第一步是做好应用的拆分，把一个大的单体系统拆分成多个子系统，每个子系统的业务分界线要划分明显，也有种单一职责的原则在里面。通过改造成微服务，多个子系统间可以实现并发开发，同时配合微服务框架提供的各个组件功能，实现低耦合，高内聚的目标。系统微服务化后，每个子系统都会有自己对应的数据库，随着时间的推移，数据量会日益增多，数据库的瓶颈会越来越明显，这时候可以尝试做分库分表。
分库分表是一种水平拆分数据的思路，可以根据业务需求按照id，时间等不同纬度来拆分，而既然做了数据的拆分，那么查询数据时肯定也是要用相同的规则去查找，简单的说，就是算法要相同，而拆分算法可以用hash，取模，路由等等。关于分库分表，也有许多技术可供选择，如mycat中间件，sharding-jdbc以及最近刚成为Apache历史上第一个分布式数据库中间件项目的shardingSphere等，分库分表被拆分后，很多单库里能做的操作就不好实现了，比如表join，数据排序分页，分布式事务等，这时候可以参试着做数据异构。
数据异构的话，可以把这方式想象成为了满足某种业务的要求，对数据做了另一个结构的改造和展示，比如一个订单表，原来是按照id分类的，但是业务要求还要能根据用户和商家这两个维度来处理数据，那么就可以根据用户和商家这两个维度来异构数据库，分为商家维护的订单分库和用户维度的订单分库。而有时候因为分库分表了，一个页面的展示数据需要查询好多个分库后才能正常展示，那么一旦有一个数据分库出现了问题，就会影响整个页面的体验，这时候可以把多个分库的数据聚合异构存储在KV存储集群中，这样只需要一次查询就能够获取到所有的数据。