小编带您看世界。
架构演变过程：
阶段一、单机集中构建网站
阶段二、应用服务器集群
随着访问量增加，单台应用服务器无法满足需求，假设数据库服务器没有压力的情况下，我们可以把应用服务器从一台变成两台甚至多台，把用户的请求分散到不同的服务器中，从而提高负载。
但是有几个问题，我们不得不知道：
用户由谁来转发到具体的应用服务器呢？
用的什么转发算法？
应用服务器如何返回用户请求？
用户每次访问到的服务器如果不一样，那么如何维护session的一致性？
对，用的Nginx：反向代理+动静分离+负载均衡
那么如何保证Nginx的HA（高可用）呢？我们用了nginx一主一备，LVS实现负载均衡，使用Keepalived来实现，我们看阶段三：
阶段三、负载均衡服务器配置集群
阶段四、CDN+Varnish服务器配置集群
动静分离后，一部分动态内容，如联系方式、后台登录网站等等很少有变更，我们把这些内容放到Varnish中，这样Nginx不用直接到tomcat获取，而是去Varnish（反向代理服务器的加速器），进一步减轻tomcat负担。
阶段五、数据库读写分离
当数据库访问量到很大时，我们要考虑读写分离了。
阶段六、nosql+分布式搜索引擎
随着用户大量查询数据库，我们可以在tomcat服务器和数据库之间加入redis，做缓存服务器，减轻直接访问数据库，进一步对数据库的压力。另外加入分布式搜索引擎，如elasticsearch，我们使用的是solr。
阶段七、nosql（HA）+分库分表+MyCat
为达到redis高可用，我们采用codis（分布式Reids解决方案）；
当数据量继续加大，我们要考虑使用mycat分库分表：
阶段八、分布式文件系统
当一些静态资源，类似图片的存储，以前直接放在tomcat，nginx轮询访问tomcat，用户体验性不好，而且上传图片和项目耦合在一起，可维护性上考虑，我们考虑采用FastDFS。
阶段九、应用服务化拆分+消息中间件
随着业务逐渐复杂，我们会拆分服务，分而治之，采用Dubbo+zk做服务发现。
有些业务如订单系统，随着业务的订单量增长，需要提升系统服务的性能，可以使用MQ，扣减库存、生成单据后发一条消息到MQ让主流程快速完结，另外的线程拉取MQ的消息，当发现MQ中有发短信的消息时，执行相应的业务逻辑；它还可以做到流量削峰等。
阶段十、微服务架构
Dubbo做不到的，微服务可以。
服务调用链监控，社区活跃度很高，学习难度中等，文档丰富等优点。
总结：
架构的演变，大家也看到了，哪里出事补哪里，但是我们不企图用技术解决所有的问题，几年前12306就是个案例。