一个成熟的大型分布式系统，并不是在其开始时，就设计为这样，而是在之后的不断优化，迭代而不断的进化成熟的。
在一个系统刚开始运行时，可能用户数，业务处理等都还比较简单，因此由一台服务器就能支撑起其正常的业务处理。其系统架构模型可能如下所示：
1，单应用架构
其应用服务和数据库服务，都部署在同一台服务器上。此时应用的实现简单，能够快速上线，为用户提供服务。比如很简单的可以使用Tomcat+Mysql部署在同一台机器上，提供服务。
但是随着用户数量的增加，业务内容的不断增加。其应用服务器的响应可能会慢慢变得迟缓，此时需要提升应用服务器的负载能力，保证用户的使用体验。因此需要采用更好的系统架构：
2，应用服务器和数据库服务器分离：
应用服务器和数据库服务器的分离，使得应用能够获得整个服务器的CPU资源来响应用户请求。应用服务器和数据库服务器的分离，也大大减少了应用的宕机风险。此时我们开始关注服务器的管理了。
3，应用服务器集群：
随着用户量的继续增加，一台应用服务器可能不能满足系统的需求，因此我们需要采用应用服务器的集群架构。
通过将用户的请求分流到不同的应用服务器，从而提高整个系统的负载能力，保证用户的使用体验。
但是当应用服务器采用集群结构后，遇到了之前不存在的新问题，比如：
（1）：用户的请求由谁来决定，分发给哪个服务器来处理(负载均衡问题)。
（2）：用户在使用网站的过程中，如何维护用户session，保证不同的服务器响应请求时，能保证用户Session数据共享。
因此这个应用集群架构中，需要在应用服务器之上，新增一层进行负载均衡。
负载均衡器，可以分为软负载和硬负载。
软负载： Nginx或Apache等。
硬负载：F5等.
Session共享，可通过配置Tomcat的session共享来解决。但是由于Session在服务器间的复制，占用浪费带宽比较严重，此时建议Tomcat的实例不能过多。
4，数据库服务器读写分离：
在完成了应用服务器的集群分布后，此时的系统瓶颈就卡在数据库服务这块了。在对数据库服务器进行分布式集群时，很容易碰到多个数据库实例上的数据不一致的问题，因此一般我们会根据提供的应用服务具体类型，综合考虑应用提供的读写服务频率等特点。可以考虑先把数据库服务的读写进行分离。
此时，系统遇到的问题是：
（1）：主从服务器上的数据同步。可以使用Mysql自带的主从复制。
（2）：可以根据业务选择对应的数据库中间件，屏蔽具体的数据库访问细节，如mycat等。
5，使用搜索引擎，缓解数据库读库压力
根据具体的业务类型，如果设计到很多模糊查询，而且数据量比较大，此时可以引入搜索引擎，如Elasticsearch。
引入了搜索引擎，则需要额外的工作，如维护索引的构建，数据同步到搜索引擎等。
6，引入缓存机制
随着用户请求数量的增加，有一些热点数据，可能会不断的被用户访问，此时，可以把这些数据放进内存中，既避免访问数据库，又能加速响应用户请求。此时可以开始使用缓存技术，比如Redis,Memcache等。
使用缓存机制，能够缓存读库压力，提升应用性能，与读库相比，从缓存中读取数据，也能够更快的响应用户请求。
在有些使用场景中，可能需要使用一些数据，这些数据放在内存中不太合适，而放到数据库中又太麻烦，此时可以考虑使用NoSql产品，来代替传统的关系型数据库，保持这些数据。
在分布式系统中，使用NoSql时，也需要考虑缓存是否支持分布式集群。
7，数据库的水平/垂直拆分
随着业务量和数据量的持续增加，由于所有的数据都在同一个数据库中，数据库表非常多且杂，有些一个表中的数据记录已经达到了很大的数量。尽管采取了读写分离，缓存机制等，但是单个数据库中的并发连接数有一个上限，因此对数据库的访问依然会成为一个瓶颈。
因此需要考虑对数据库进行拆分。
垂直拆分：把不同的业务数据拆分到不同的数据库中。
水平拆分：把同一张表中的数据，拆分到不同的数据库中，水平拆分的原因是某些表中的数据量记录太大，达到了单个数据库的瓶颈。
8，应用的拆分
随着业务越来越多，整个应用越来越复杂，工程规模也越来越大。此时的管理维护工作量会越来越复杂。可以考虑根据领域模型，对系统进行拆分
对应用进行拆分后，可能有一些基本的操作，在每个子系统中，都会使用到，比如访问用户数据等，此时可以把这些相同的操作，抽象出来，通过提供服务的方式，提供给各个子系统使用。
因此此时遇到的一些新问题是，多个子系统之间如何进行远程通信。比如通过RPC技术(dubbo,webservice,hession,heep,RMI等)，解决远程通信问题。
在系统不断进化时，整个系统也变得越来越复杂，管理难度越来越大，同时也会不断的出现新的技术，来解决不断出现的新问题，如微服务，Docker容器技术，容器编排等。
最重要的是，根据应用的实际情况，如用户量，并发数，数据量等采用最合适的架构。
