典型的分布式网站架构

发布：2018-11-27 16:52:03 浏览：3935

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

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

我们在网站升级中一般会接触到两个概念:一是服务化改造；二是分布式化改造。那么它们是一回事吗?

服务化改造更多是从业务架构的角度出发，目的是将业务做更细粒度的功能拆分，使业务逻辑更加清晰、边界更加清楚且易于维护；服务化的另一个好处是收敛业务逻辑，通过接口标准化提供统一-的访问方式。分布式化更多是从网站制作系统架构层面的角度出发，更多是看请求的访问路径，即一个请求必须先访问什么再访问什么、一次访问要经过哪些步骤才能最终有结果等...因此，这是两个不同层面的工作。