典型的散布式网站架构

散布式架构与传统的单机架构最大的区分在于散布式架构能解决两个标的目的的扩展问题:一是横向扩展，二是纵向扩展。

横向扩展，主要用来解决应用架构上的容量问题。因为单台服务器能撑持的服务威力始终是有限的，以是咱们在架构上就必需做到可能支持横向服务威力的扩展。最典型的横向扩展是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)服务化和散布式化

咱们在网站降级中普通会接触到两个观点:一是服务化改造；二是散布式化改造。那末它们是一回事吗?

服务化改造更可能是从营业架构的角度动身，目的是将营业做更细粒度的功用拆分，使营业逻辑愈加明晰、鸿沟愈加分明且易于维护；服务化的另外一个益处是收敛营业逻辑，经由过程接口标准化提供同一-的访问体式格局。 散布式化更可能是从网站建设零碎架构层面的角度动身，更可能是看要求的访问途径，即一个要求必需先访问甚么再访问甚么、一次访问要颠末哪些步骤才气终极有后果等...因而，这是两个差别层面的事情。