目录：什么是分布式架构？分布式架构的演进分布式服务面临的问题什么是分布式架构？分布式系统是建立在网络上的软件系统有两个典型特征：内聚性：每个数据库分布节点高度自治，有本地数据库管理系统透明性：每个数据库分布节点对用户应用程序是透明的是的，不清楚无论是本地还是远程。也就是说，在分布式系统中，用户感觉不到数据是分布式的，不知道数据有没有划分，有没有副本，不知道数据存在于哪个节点上。简单来说：在分布式系统中，一组独立的计算机呈现给用户的是一个统一的整体，就好像是一个系统。如上图所示，分布式系统整体为用户提供服务，整个系统的内部协作对用户是透明的，就好像用户在使用一个mysql。分布式架构的演进（1）初期架构特点：应用、数据库、文件等所有资源都放在一台服务器上。（2）应用服务、数据服务、文件服务分离说明：好景不长。随着系统访问量的再次增加，webserver机器的压力会在高峰期上升到一个比较高的水平。这时候，我们开始考虑添加一个webserver。特点：应用程序、数据库和文件部署在不同的资源上。(3)使用缓存提高性能说明：系统访问的特点遵循80%法则，即80%的业务访问集中在20%的数据上。缓存分为本地缓存和远程分布式缓存。本地缓存访问速度更快，但缓存数据量有限。同时，与应用程序存在内存争用。特点：将数据库中访问较为密集的一小部分数据存储在缓存服务器中，减少数据库访问次数，减轻数据库访问压力。(4)“应用服务器”集群使用说明：做完分库分表的工作，数据库的压力已经降低到一个比较低的水平，开始过上幸福的生活了watching访问量每天都在飙升。突然有一天，我发现访问系统的速度又开始变慢了。这时候先查了一下数据库，压力正常。然后查看了webserver，发现apache拦截了很多请求，应用服务器对每个请求都比较快，貌似是请求数多了排队等，响应速度变慢了。特点：多台服务器通过负载均衡同时对外提供服务，解决了单台服务器处理能力和存储空间受限的问题。说明：利用集群是系统解决高并发、海量数据问题的常用方法。通过向集群中添加资源，提高系统的并发处理能力，使服务器的负载压力不再成为整个系统的瓶颈。(5)数据库读写分离说明：在享受了一段时间系统访问量快速增长的快乐后，发现系统又开始变慢了。这次是什么情况？查找后，发现数据库是写入更新的。运行中部分数据库连接的资源竞争非常激烈，导致系统变慢。特点：多台服务器通过负载均衡同时对外提供服务，解决了单台服务器的处理能力和存储空间限制的问题。说明：利用集群是系统解决高并发、海量数据问题的常用方法。通过向集群中添加资源，服务器的负载压力不再是整个系统的瓶颈。(6)反向代理和CDN加速功能：利用CDN和反向代理加快系统的访问速度。说明：为应对复杂的网络环境和不同地域用户的访问，通过CDN和反向代理加快用户访问速度，同时减轻后端服务器的负载压力。CDN和反向代理的基本原理是缓存。(7)“分布式文件”系统和“分布式数据库”说明：随着系统的不断运行，数据量开始大幅增加。这时发现分库后查询还是有点慢，于是按照分库的思路开始分表的工作特点：数据库采用分布式数据库，文件系统采用分布式文件系统。说明：任何强大的单一服务器都无法满足大型系统不断增长的业务需求。随着业务的发展，数据库读写分离终将无法满足需求。需要使用分布式数据库和分布式文件系统来支持。分布式数据库是拆分系统数据库的最佳方式。只有在单表数据规模非常大的时候才会用到。数据库拆分比较常见的方式是业务分库，将不同的业务数据库部署在不同的物理服务器上。优越的。(8)使用NoSQL和搜索引擎的特点：系统引入了NoSQL数据库和搜索引擎。说明：随着业务越来越复杂，对数据存储和检索的要求也越来越复杂。系统需要使用一些非关系型数据库如NoSQL和分库查询技术如搜索引擎。应用服务器通过统一的数据访问模块访问各种数据，免去了应用程序管理众多数据源的麻烦。(9)业务拆分特点：系统按业务拆分改造，应用服务器按业务分工分别部署。说明：为了应对日益复杂的业务场景，通常采用分而治之的方式将整个系统业务划分为不同的产品线。应用程序之间的关系通过超链接建立，数据分发也可以通过消息队列进行。当然，更多的是通过访问同一个数据存储系统，形成一个关联的完整系统。垂直拆分：将一个大应用拆分成多个小应用。如果新业务比较独立，那就直接设计部署成一个独立的web应用系统。垂直拆分相对简单。通过业务梳理，可以剥离较少的相关业务。水平拆分：将复用的业务拆分出来，独立部署为分布式服务。新业务只需要调用这些分布式服务即可。横向拆分需要识别可复用业务，设计服务接口，规范服务依赖。(10)分布式服务特性：将公共应用模块抽取出来，部署在分布式服务器上，供应用服务器调用。说明：随着业务越来越小，应用系统的整体复杂度呈指数增长。由于所有的应用程序都需要连接所有的数据库系统，最终会导致数据库连接资源不足而导致服务被拒绝。分布式服务面临哪些问题？当服务越来越多时，服务URL配置管理变得非常困难，同时F5硬件负载均衡器的单点压力也越来越大。随着进一步的发展，服务间的依赖变得错位复杂，甚至分不清哪个应用先启动哪个应用，架构师也无法完整描述应用的架构关系。然后，服务调用量越来越大，服务的容量暴露出来。需要多少台机器来支持这项服务？什么时候应该添加机器？服务多了，通信成本开始上升。服务调整失败应该联系谁？?服务参数的约定是什么？当一个服务有多个业务消费者时，如何保证服务质量？随着服务的不断升级，总会有一些意想不到的事情发生，比如缓存写错导致内存溢出，故障是不可避免的，每次一个核心服务宕机，都会有大面积的波及，而且人们恐慌。如何控制故障的影响？服务的功能可以降级吗？还是资源退化？
