分布式架构设计概要总结.docx

《分布式架构设计概要总结.docx》由会员分享，可在线阅读，更多相关《分布式架构设计概要总结.docx（12页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、分布式架构设计概要总结一、 构建分布式的缘由业务架构的演进分布式系统，顾名思义，数据是分布在不同的节点上，那么数据分布就是首先需要考虑的一点。我们先思考几点：1、数据如何均匀分布到不同的节点上，涉及到负载均衡；2、为了保证数据的牢靠些，需要对数据设置多个副本，那么如何保证副本之间的全都性；3、节点是廉价的 pc 机，假设节点宕机，那么如何自动检测，并迁移数据；4、分布式最根底的两个协议，一个是 paxos 选举协议，一个是两阶段提交协议：l paxos 选举协议：用于在多个节点中选举一个总控节点；l 两阶段提交协议：保证在多个节点中事务操作的原子性，要么完全成功，要么全部失败。在上图简洁以时间

2、线为准，粗略描述了我们系统架构随着业务的需求考量以及业务的进展，系统担当的并发量也将逐步提升，这就要求我们的系统架构需要开头思考如何利用现有的资源来解决。我们目前急需处理并发恳求的效劳. 而思考的方向可以从我们已有的计算机学问体系中找到答案。比方：l 对于并发问题，我们知道处理共享资源可以通过加锁的方式来保证我们的线程安全，那么在有限的资源下又要如何提升我们的并发量，于是我们很简洁想到 hashmap 是如何处理线程安全的，对此我们就会考虑到一个设计思想，那就是分而治之的策略，即是否可以将共享资源拆分成多份来缓解我们的压力,即集群.l 这个时候我们的流量压力通过集群分担到各个应用中，但是此时对

3、数据库的压力反而增加了，于是我们会想到使用缓存策略来缓解我们的压 力，对于缓存架构，我们也可以承受 CPU 高速缓存的策略来对我们现有的效劳进展改进。l 另外,随着业务的增长以及需求不断地调整变化，有时候为了提升我们的查询性能，还需要以不同的维度重构建数据库表构造。比方订单效劳，可以以用户维护进展数据异构产生用户与订单效劳的数据库表构造来提升我们的查询性能。其实对于这种数据异构在编程设计中也是有表达的，比方表单的业务 bean 与数据库存储的业务 bean 多少存在一些冗余但可能是类型或者是状态显示不同，目的固然是简化便于理解。l 随着业务不断扩大，团队人员也在增加，考虑到快速交付产品需求，我

4、们可以划分团队负责不同的业务线，于是便有了效劳的垂直拆分，也就是我们的效劳化架构，在分布式架构设计中引入效劳化架构是我们依据团队以及业务进展拆分的结果，目的是为了更快速交付，同时也是为了更为专注业务开发的落地实现。引入性能技术的优化方案之后，这个时候我们从另外一个视角来看，即一个置身于互联网大环境下的工程系统,我们需要保证分布式系统效劳的高可用。二、构建分布式系统的两个核心因素对此，一个分布式系统效劳需要具备以下两个因素：l 增大系统容量: 我们的业务量越来越大，而要能应对越来越大的业务量，实行分而治之的设计思想，通过进展水平或是垂直拆分业务系统， 让其变成一个分布式的架构。l 保证系统效劳的

5、高可用: 为了增大系统容量，我们将业务进展拆分，彼此独立，但是每一块业务线都有其重要意义。因此我们就需要保证每一块业务线的效劳不能存在单点故障，这样整个系统不会由于单点效劳出故障而导致业务效劳系统不行用，所以需要通过做节点冗余系统以消退单点故障，从而提高系统的可用性。小结我们使用分布式的设计来源于“分而治之“的思想，从整个系统架构上看， 构建分布式架构的缘由就是要扛住互联网海量并发恳求处理以及在此根底上保证我们的系统效劳具备高可用，抑或是允许一小局部效劳不行用。三、分布式术语1、节点可以是操作系统上的一个进程效劳，也可以是分布式系统中一组供给处理规律的程序并能够独立部署运作，在整个分布式系统中

6、与其他效劳协作也可以独立完成业务的恳求处理操作。2、集群在分布式系统中，为了提升效劳的并发处理力气，部署多个节点来供给一样的一组业务效劳操作，这多个供给效劳的节点组成一个集群。3、副本在分布式系统中供给数据抑或是效劳的冗余来保证系统的高可用，数据副本是指在不同的节点上长期化存储一份一样的数据，效劳副本是指在不同的节点上部署一套或一组供给一样业务处理规律的效劳，一般形成主从来保证效劳节点的高可用。4、中间件独立于应用效劳，位于操作系统之上的一套为集群节点效劳解决问题的通用方案的组件，简化开发人员的工作，让开发者更专注于业务上的开发。比方效劳与效劳之间通过消息中间件实现异步通信，实现效劳解耦；为了

7、加速数据访问速度,我们引入缓存中间件，为应用层与存储层供给一个缓存的过程，避开全部一样的数据查询操作的流量都落地到数据存储层；同时我们还看到接入层节点抑或是网关效劳节点要实现高可用保证，需要引入负载均衡中间件实现高可用；再或者应用层与实现分片的数据存储层进展数据交互，为简化开发以及查询匹配等因素引入数据库中间件，从而对于应用层照旧可以透亮地实现对数据存储的 CRUD 等操作，而无须关系数据匹配以及全都性等问题。5、SOA 与微效劳架构SOA 为面对效劳的架构，是属于一种设计方法，每个效劳之间都相互独立且通过网络进展效劳调用来完成一次简洁的业务恳求操作；微效劳架构是在 SOA 的根底上演进而来，

8、强调组件化与效劳化，每个组件供给独立的效劳可以实现可伸缩性的扩展。可以独立开发，设计，部署与优化而不影响微效劳中其他的组件。6、分布式协调其一分布式的多个效劳节点之间的业务处理规律照旧需要保证与单体架构执行的业务规律处理挨次全都，即保证效劳节点处理业务请的规律具备有序 性；其二是对于共享资源的争用，在单体架构中我们通过加锁的方式来保证并发处理共享资源的安全性，同理对于分布式的多效劳节点对共享资源进展事务操作的时候我们也需要协调各个效劳节点的并发把握，保证系统效劳中的共享资源的事务操作具备原子性以及数据全都性。因此，对于分布式协调我们可以理解一个是协调效劳节点来保证业务处理的有序性，一个是协调效

9、劳节点来保证并发操作共享资源的原子性以及数据的全都性。7、效劳治理对于效劳治理的理解，我们需要切换一个维度，此时应当从分布式效劳化的架构设计上来对待问题，那么效劳与效劳之间的通信流程如下：效劳启动并注册到注册中心 - 调用方从注册中心猎取被调用方的效劳列表- 调用方通过负责均衡的方式选择效劳 - 调用选择的效劳,此时通过网络传输的方式传递消息 - 被调用方接收到消息并执行调用返回，这里涉及到业务拆分成独立效劳，效劳注册，效劳觉察，效劳依靠以及效劳调用链等关系，效劳治理就是需要将效劳之间的依靠与调用链全部梳理出来统一存储和治理，这样子我们就能够针对各个效劳进展分析与优化等操作。8、DevOps&

10、自动化运维利用 CI/CD 等持续集成工具来完成一系列业务效劳的公布流程，即代码review 后提交 - 测试-单元测试-打包-集成测试-UI 测试-测试环境公布部署效劳-预生产灰度公布效劳-真是公布部署效劳等一系列流程可以称为 DevOps 全流程，这对于我们做效劳化架构能够实现快速迭代开发；有了 DevOps 之后，我们就可以针对我们的业务效劳进展自动伸缩，故障转移，配置治理，状态治理等一系列自动化运维工作。四、分布式技术1、架构的高性能这里引入分布式高性能相关的技术，已经很好地诠释了分布式高性能技术栈，对于高性能方面，自己也基于上述的根底上做一些补充:集群与负载均衡：通过水平扩展业务处理

11、力气来提升系统的并发处理能力。缓存设计：在我们的上述效劳进展水平抑或是垂直扩展的时候，这个时候我们的业务吞吐量也会增加，这个时候会把全部的流量压力打到数据存储系统上，为了缓解数据存储系统的压力，这个时候我们会考虑将数据进展冷热划 分，对于热点数据集中在缓存系统效劳以降低我们的数据存储压力。对于缓存的设计存在以下三种模式:其一是 Cache Aside 更模式，即失效 - 命中 - 更策略；其二是 Read/Write Through 更模式，即缓存更对应用程序透亮，对于应用程序而言只有一个数据存储操作，由 cache 负载更数据操作；其三是 Write Back 模型，类似于 Linux 下的

12、 Cache 算法，应用程序直接将数据更到 cache 中，有 cache 异步批量更到数据库中。垂直拆分业务(效劳化设计)：当我们的一个效劳节点担当简洁繁多的业务 效劳的时候，必定会影响到我们业务处理的力气，为了提升我们的并发处理力气，为了提升我们的系统并发力气，可以考虑将我们的业务进展垂直拆分，于是就有了一个恳求的处理需要多个效劳之间进展协作完成。数据镜像与分区(读写分别/分库分表)：尽管使用缓存可以缓解我们的效劳 压力，但是照旧无法从根源上缓解流量对数据存储的压力，于是我们一方面会做读写分别，做主从集群，主节点负责处理事务的数据写入，从节点数据负责数据的读取；另一方面为了提升单库单表的并

13、发力气，这个时候我们也是借助分而治之的设计思想，实行分库分表的思路来缓解我们单库单表的流量压力。借助 MQ 中间件实现异步处理：可以通过中间件技术实现异步处理，对流量进展削峰缓冲，进一步提高了程序的并发处理力气以及系统的稳定性。数据异构设计：将同一个业务数据依据业务需求的用途划分为不同的数据仓库存储以适用相应的业务需求场景，比方对于爬虫的聚合资讯数据来源存在很多不确定的因素，我们可以通过 MQ 的方式接收数据变更并将数据长期化存储到 ES 存储的引擎中；抑或是查询一个用户的订单信息，假设依据订单表的订单ID 进展拆分，则需要聚合多张表才能返回相应的聚合数据，这个时候可以实行依据用户维度来进展异

14、构一个与用户相关的订单数据仓库的策略(存在数据冗 余,但是提升读取性能)。2、高可用设计同样地,这里也是引入分布式高可用相关的技术，在此根底自己也做以下的一些补充:效劳冗余与负载均衡技术：从集群角度上思考，我们需要考虑集群是流量 如何分担到集群效劳的节点，集群效劳节点消灭特别或者不行用的时候流量如何切换，这个时候我们就需要考虑到负载均衡技术来帮助我们实现流量分发的调度，对效劳节点实行心跳检测以及当效劳节点特别实行重试与流量切换重调度安排可用效劳节点来避开单点故障问题，简而言之效劳的高可用可以是效劳冗余与负载均衡技术来避开单点故障，实现故障自动的恢复。隔离技术：为了防止故障集中到其他效劳节点，我

15、们通常会实行隔离技术来隔离拆分的业务效劳，每个业务效劳分别各自独立部署，在分布式系统设计中，一般会效劳的种类或者是用户来进展隔离。降级与限流技术：当系统担当的并发流量效劳压力格外浩大的时候，这个时候我们需要实行保护措施，通过降级或者限流的技术来停用局部业务效劳或者是拒绝局部用户的恳求操作以确保整个系统不会被流量冲垮导致整体不行 用。超时重试与熔断：在效劳化架构设计中，为了防止效劳产生雪崩，需要在调用效劳参与超时重试以及熔断机制，避开将错误集中到其他效劳导致整个系统效劳不行用。从而缩小局部效劳。高可用架构设计：利用效劳冗余来避开单点故障，比方多租户隔离，灾备多活抑或是数据副本保证全都性，高可用不

16、仅是的效劳集群的高可用，还有就是中间件实现高可用设计。高可用的运维：实现 devops 的 CI 或者 CD 的持续集成打算任务，能够构建执行自动化测试，实现灰度公布部署以及线上系统的自动化把握。缓存的高可用：对于缓存系统也需要承受集群高可用的方式来避开单点故障以及实现故障恢复，同时对于缓存系统要实现高可用，需要留意以下几个问题:l 缓存穿透：即对于不存在的数据缓存始终都是没有命中会直接将流量打到数据存储层上。l 缓存雪崩：即在某一个时刻，全部的缓存都失效过期，这个时候流量都会打到数据存储层，很简洁引起数据存储层的并发性能问题。l 缓存击穿：即针对某一个热点缓存在某一个时间点存在并发访问量请求

17、并且当前时间点缓存时间已经过期需要刷缓存，这样也会将流量打到数据存层上。因此对于缓存的高可用不仅需要避开单点故障，同时还需要具备容错能 力，比方增加布隆过滤器来把握缓存穿透，依据不同的业务场景可以实行随机时间段的缓存时间来避开同一个时间点缓存失效以及对于具备热点的共享资源缓存操作，需要借助中间件的协调者来治理和把握我们的应用效劳的操作避开缓存击穿的产生。切流量：面临高并发流量的接入时，我们并无法保证全部效劳节点都是可用状态，于是需要在接入层或者效劳网关做故障转移，将流量切换到可用的效劳节点上。可回滚：在分布式的效劳化架构设计，我们需要对效劳实施版本把握与治理，一旦公布的效劳节点产生测试不行预知

18、的测试，为了削减效劳不行用时长抑或是效劳的掩盖面，我们需要对效劳进展回滚到上一个稳定版本以保证线上效劳可用。3、业务设计防重与幂等设计：当我们应用在单位时间内接收到一样并发的事务恳求操作时，这个时候我们需要考虑事务恳求操作处理不管多少次恳求最终只能处理一次，这个时候可以通过设计防重 key 或者是防重表来保证我们只处理一次恳求。比方下单支付操作，由于支付渠道是无法避开重复支付的，因此对于我们系统效劳而言就需要依据业务场景设置防重 key 来保证订单效劳抑或是将支付记录在数据表并通过数据表进展查询验证，假设并发量很大的话，我们可以考虑通过 MQ 来接收支付渠道回调的响应结果并通过鉴权验证之后提交

19、到 MQ，再由 MQ 分发给消费者，这个时候就需要保证幂等，防止重复消息的消费。事务补偿机制：在分布式架构设计中，基于ACID 以及 BASE 理论学问,事务补偿操作可以是保证一系列的业务操作具备原子性而最终到达业务数据全都性的目标，当其中某一个操作消灭特别的时候，我们实行重试让其运行得到我们期望的大事状态，假设重试不成功，则实行人工干预抑或是丢弃回滚大事。比方一个支付场景，用户下单之后并没有马上支付，此时商品扣减库存假设在等待 15min 之后没有收到用户支付的恳求，就需要将商品库存释放，此时就需要对此场景进展事务补偿，保证我们的业务最终全都性；再比方一个主播提现系统，一般会有 N+1 或者

20、 N+7 的支付平台，那么我们进展主播打款的时候有可能由于第三方支付平台网络不稳定导致支付成功但是没有返回响应，此时我们也需要进展事务补偿，针对不稳定的网络因素进展重试与验证处理，保证数据金额的最终全都性.状态机设计：状态机系统包含条件，大事以及大事触发的状态变更操作， 严格依据确定的状态变更规章通过外部大事触发以及条件的推断执行状态变 更。比方设计一个订单状态的状态机，我们需要考虑订单状态的变化以及对应触发状态变更的大事，比方下单-订单被创立，支付-支付成功与失败，接单-已接单状态还是拒单状态，订单签收-订单完成以及后续的退单操作对应的订单退款状态等一系列大事触发的订单状态变更形成一个状态机

21、。后台系统可反响：可以针对一些核心业务功能实行行为记录的日志异步化长期化到数据层上，并通过后台治理系统查看反响以及重要核心业务流程的追踪分析。五、分布式效劳指标监控在分布式架构中，最需要做到的就是能清楚每个效劳节点运作的细节，此时就需要对整个分布式系统进展全栈监控，即不管是应用效劳层(业务效劳 化)，抑或是平台组件效劳还是底层机器的资源监控，我们都需要做到心中有数，才能够针对某一个效劳进展排查与优化。l 根底层:主要监控底层以及资源状况,如 CPU/内存/网络/磁盘 IO/带宽流量等。l 组件层:主要监控我们引入的中间件,比方 Redis/MQ 等,都需要对组件的容量/io/内存/线程/效劳节

22、点安康状态等指标进展监控。l 应用层:一般是我们的业务效劳上的监控,这个时候我们更关注效劳依靠,效劳调用链,日志收集,qps/tps 等因素。六、分布式小结1、分布式设计思考的维度两个目标：提高系统的性能和保证系统效劳的高可用。宏观的架构技术栈：l 全栈系统监控: 单机的根底监控 - 中间件效劳监控 - 应用效劳监控l 效劳/资源调度: 计算机资源调度 - 效劳资源调度 - 架构调度l 流量调度: 流量把握 - 流量治理 - 效劳治理l 状态/数据调度: 数据可用性 - 数据全都性 - 数据分片l DevOps 与自动化运维: 基于上述的根底完成一系列的开发 - 版本提交- 单元测试 - 打包

23、 - 集成测试 - UI 测试 - 公布测试环境 - 预生产环境公布 - 灰度公布 - 正式公布.业务效劳化设计：l 性能设计l 弹力设计(高可用技术)l 业务设计l 全栈系统监控2、分布式面临需要解决的问题技术架构面临的问题：l 效劳节点如何崩溃恢复l 分布式缓存问题l 共识问题l 流量把握降级限流等策略l 整体架构的监控l 自动化运维效劳化架构面临的问题：l 数据全都性与分布式事务l 共享资源与分布式锁l 效劳治理l 效劳持续集成流程(DevOps)l 效劳架构的垂直拆分粒度以及产生的数据全都性问题其实，在这里仅供给一个思考的维度去分析我们的系统效劳，在做分布式架构设计的时候，需要在宏观上搭建好技术根底骨架，进展业务分析并结合引入的效劳化根底去思考我们架构可能存在的问题并验证设计的合理性与适用性。七、分布式理论学问在分布式架构设计中，为了解决上述带来的问题，我们需要借助分布式技术已有的根底理论学问来指导并促进我们问题的解决。其中分布式依靠的根底理论学问主要有以下两方面: 1、分布式理论根底l 拜占庭将军解决共识问题l CAP&BASE 理论l ACID&2PC&3PC2、分布式协议与算法l Paxos 算法l Raft 算法l 全都性 hash 算法l Gossip 协议l Quorum NWP 算法l PBFT 算法l zookeeper 的 ZAB 协议