横向扩展，主要用来解决应用架构上的容量问题。由于单台服务器能支撑的服务能力始终是有限的，所以我们在架构上就必须做到能够支持横向服务能力的扩展。最典型的横向扩展是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)服务化和分布式化
我们在网站升级中一般会接触到两个概念:一是服务化改造；二是分布式化改造。那么它们是一回事吗?
服务化改造更多是从业务架构的角度出发，目的是将业务做更细粒度的功能拆分，使业务逻辑更加清晰、边界更加清楚且易于维护；服务化的另一个好处是收敛业务逻辑，通过接口标准化提供统一-的访问方式。 分布式化更多是从网站制作系统架构层面的角度出发，更多是看请求的访问路径，即一个请求必须先访问什么再访问什么、一次访问要经过哪些步骤才能最终有结果等...因此，这是两个不同层面的工作。
本文地址：//www.gogoparty.cc//article/4456.html
