基本上任何大型的分布式应用都是从最初到单应用一步步演变过来到，并不是说不能一开始就设计一个庞大复杂的分布式系统，这与企业的初期资金投入和产品上线速度有关，要知道现在的市场都是瞬息万变到，你的开发进度跟不上，产品不能早于竞争对手上线，后期想翻盘的可能性极地，这直接关系到一个项目能成功还是失败。
项目上线后，随着用户量和访问量的逐渐增加，系统也会迎来各式各样的问题。业务逻辑问题不是这里要讨论的内容，我们主要说说系统涉及到高并发和高可用时所遇到的问题(比如过多的访问导致的系统瘫痪)，这些问题也是为什么后期要把系统架构向着分布式的方向去做改变。
这里假设一个你是一个开餐馆的，然后你很有志向，不屑于使用饿了么美团的商家服务，决定自己整个自营外卖点餐系统，暂且不考虑送餐环节。这里包含最基本的用户模块，菜品模块，订单模块。下面是我自己划分的几个演变阶段，可能不准确或者不适用于每个项目，但万变不离其宗，最后都要向着分布式架构来发展。
第一阶段：典型的单应用单机架构
这是一般系统最开始的架构，就是整个系统和数据库都在同一个服务器上。刚起步用户量不多，高峰期可能也就二三十的并发量，哪怕你的系统业务是重业务(需要较多的cpu计算资源)，单台4核8G的服务器都应该能扛的住。但随着用户量逐渐增加，高峰期并发量开始增长，应用系统的负载也随之增加。一看服务器状态，CPU/Memory/IO等系统资源都几乎消耗殆尽，应用系统跟数据库两兄弟为了抢资源打都不可开交，用户也经常反馈说app上经常转圈圈就是不显示，这让正在炒菜的你陷入了沉思......
第二阶段：应用和数据分离
为了应对第一阶段的问题，你将应用系统和数据库分别部署到两台服务器上，分别称之为应用服务器和数据库服务器，让应用系统和数据库各自住各自的房子就不会抢占系统资源了。这样我们用最简单的方式解决了系统性能问题，而且整个系统基本不用做什么修改，可能你就只需要修改一下代码里的数据库连接字符串就搞定了。随着你的生意越来越红火，你赚的钱越来越多，自然用户也越来越多，但之前但烦恼又来了：总有用户反馈查看菜品时出现无法加载内容的情况，或者下单失败/无响应等。这个时候，正在数钱的你开始意识到：应用服务器扛不住了。
第三阶段：负载均衡
既然一台应用服务器扛不住，那我们就来两台或者三台或者好多台，不差钱。你根据当前的数据量计算了一番，决定新增两台应用服务器。这里你开始使用了牛逼哄哄的负载均衡技术，所有客户端的请求都通过负载均衡分流转发至你的三台应用服务器，三台服务器干活总比一台强，一下就提升了系统的负载能力。当然这里还有一些别的问题，比如如何维护用户访问的访问状态，因为你有了三台应用服务器，你不能确保用户每次访问的都是同一台服务器，所以你要解决session共享的问题，这里不展开说了，tomcat/memcache/redis下都有对应的实现方案。
第四阶段：缓存的使用和数据库的读写分离
随着用户量的增多你也新增了几台应用服务器，但反馈之前类似问题但用户又多了起来，心思缜密的你看了看各个服务器的状态，原来是数据库服务器出了问题，本来之前只有一个应用服务器找它读写数据，现在可好，多了好几个找它读写，它忙不过来了。经过你的分析发现，大部分对于数据库的请求基本是读请求，而且重复查询的数据量较多，你决定使用缓存( 如Redis)来降低数据库的读请求压力，这相当于在应用系统跟数据库中间多了一个缓冲区，高频率被查询的数据就放在缓存中(缓存更新策略和持久化请自行了解)，就不用每次都向数据库去读取。
增加了缓存之后，你想了想，数据库之所以扛不住很大程度上是因为读写锁冲突和系统IO瓶颈的问题，你又转手把数据库做了读写分离，一台主服务器，N台从服务器，主数据库服务器负责处理写请求，从数据库服务器负责读请求，主从数据库通过数据同步来保持数据一致性。这里提一句：优先选择使用缓存集群技术和其他中间件(比如MQ)来提高系统对应高并发的能力，数据库本身的并发承载量也就几千，并不适合作为处理高并发的载体，而且数据库服务器(特别是写服务器)比较贵，不能太败家。
第五阶段：数据库的垂直拆分和水平拆分
尽管你的系统已经能够扛住很高的并发请求了，缓存也帮你过滤了一次，但是有些请求最后还是要落到数据库这一层，数据库到压力还是会越来越大，比如用户注册和点餐下单，这都是要写进数据库的。这里你就开始了数据库的垂直拆分，你把用户表和订单表独立出来分别放到了两个数据库服务器中。既然数据库架构变了，那之前的主从架构也随之变化，这里就不赘述了。
你的外卖点餐系统一直运行着，数据量越来越多，比如你的订单表，单表数据量都快达到了数据库表瓶颈，这个时候你决定进行数据库的水平拆分，把订单表拆分到多个数据库中(常用的水平拆分方案有范围拆分和哈希拆分，请自行了解)。
数据库拆分之后，提高了系统处理数据的能力，可以更快更多的处理应用系统发来的数据操作请求，减少客户端等待时间。
第六阶段：应用服务化
随着我们的用户越来越多，应用系统的压力也越来越大，同时系统功能肯定也会越来越庞大以适应用户的多元化需求，但是庞大的系统总是复杂且难以维护。这个时候你又祭出了秘术：拆！我们把用户相关的拆出来作为一个用户服务中心，把订单相关的内容拆出来作为一个订单服务中心，这个时候你就开始用上了分布式应用框架了(比如Dubbo)，因为各个服务之间需要进行通信(比如订单服务肯定需要用户的数据)，分布式应用框架可以帮你解决这个问题。具体怎么拆分根据你的项目的具体业务边界来划定。随着应用服务化带来的应用拆分，数据库架构也逃不了要进行垂直拆分，一般拆分出来的应用都有自己独立的数据库，这里怎么拆分才能达到最低的耦合是一个需要根据实际情况来决定的问题。如果不多做考虑，在我们的这个外卖点餐系统中，用户表就是单独拆出来属于用户服务的独立数据库。
实际开发中的项目演变或者使用的分布式演变过程总是多种多样的，有错误的地方谢谢指正！
