散布式架构与传统的单机架构最年夜的差别在于散布式架构能解决两个偏向的扩大问题:一是横向扩大，二是纵向扩大。

横向扩大，重要用来解决运用架构上的容量问题。因为单台办事器能支持的办事才能始终是有限的，所以我们在架构上就必需做到可以或许支撑横向办事才能的扩大。最典范的横向扩大是Web/API接人层，它在支撑1亿PV和10亿PV时所须要的办事器数目必定是完整纷歧样的，是以要斟酌当办事器不敷用时，它也能支持PV的无穷增加。是以这两层~般都属 于无状况的办事。

纵向扩大，重要解决营业的扩大问题。当营业赓续扩大时，营业逻辑的庞杂度也会赓续上升，所以在架构上要能依据功效的划分进行纵向条理的划分。例如，Web/API层只做页面逻辑或者展现数据的封装，办事层做营业逻辑的封装等。营业逻辑层还可以划分成更多的条理，以支撑更细的营业的组合。

一个典范的散布式网站架构。它将用户的要求经由过程负载平衡随机分派给一台Web机械，Web机械再经由过程长途挪用要求办事层。然则数据层一般都是有状况的，而数据要做到散布式化，就必需包管数据的一致性。要包管数据的一一致性，一般都须要对最细粒度的数据做单写掌握，是以要记载数据的状况、做好数据的拜访掌握等。

一个有状况的散布式架构。散布式集群中-一般都有一个Master负责治理集群中所有机械的状况和数据拜访的规制等，为了包管高可用Master也有备份，Master平日会把拜访的路由规矩推给现实的要求提议端，如许Client就可以直接和现实要拜访的节点通讯了，避免中央再经由一层署理。

还有一种散布式架构长短Master-Slave模式而是Leader 选举机制，即散布式集群中没有零丁的Master脚色，每个节点功效都是一样的，然则在集群的初始化时会拔取一个Leader承担Master的功效。一旦该Leader掉效，集群会从新选择一个Leader。这种方法的利益是不消零丁斟酌Master的节点的可用性，然则也会增长集群保护的庞杂度。

(1)须要散布式中央件

早年面典范的散布式架构上可以看出，要搭建一个散布式运用体系必需要有支撑散布式架构的框架。例如起首要有一个同一的负载平衡体系( LB/LVS )赞助平均分派外部要求的流量，将这些流量分派到后端的多台机械上，这类装备一般都是工作在第四层，只做链路选择而不做运用层解析；运用层的负载平衡可以经由过程HA来实现，例如可以依据要求的URL或者用户的Cookie精准地调剂流量。

要求达到办事层，就须要解决办事之间的体系挪用了。这时，须要在办事层构建一个典范的散布式体系，包含同步骤度的散布式RPC框架、异步骤度的散布式新闻框架息争决静态设置装备摆设信息的散布式设置装备摆设框架。这三个散布式框架就像人体的骨骼和经络，把全部办事层衔接起来。我们会在后面具体介绍这三个典范的散布式框架(散布式框架的开源产物有许多，例如Dubbo、RocketMQ等)。

要求达到数据层。数据层须要解决以下问题:第一，屏障分歧数据库的差别性，使底层数据库的切换不影响前次运用代码；第二，屏障运用层代码对数据散布的感知，使对数据的分区或者分片不会影响运用代码的编写。因为般来说数据层都是有状况的，所以用数据层解决散布式问题会更庞杂、难度也更年夜。开源的DRDS等都是用于解决这类问题的。

(2)办事化和散布式化

我们在网站进级中一般会接触到两个概念:一是办事化改革；二是散布式化改革。那么它们是一回事吗?

办事化改革更多是从营业架构的角度动身，目标是将营业做更细粒度的功效拆分，使营业逻辑加倍清楚、界限加倍清晰且易于保护；办事化的另一个利益是收敛营业逻辑，经由过程接口尺度化供给同一-的拜访方法。 散布式化更多是从网站制造体系架构层面的角度动身，更多是看要求的拜访路径，即一个要求必需先拜访什么再拜访什么、一次拜访要经由哪些步调能力最终有成果等…是以，这是两个分歧层面的工作。