分布式架构设计概要总结

《分布式架构设计概要总结》由会员分享，可在线阅读，更多相关《分布式架构设计概要总结（12页珍藏版）》请在金锄头文库上搜索。

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

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

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

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

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

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

7、步通信，实现服务解耦； 为了加速数据访问速度,我们引入缓存中间件，为应用层与存储层提供一个 缓存的过程，避免所有相同的数据查询操作的流量都落地到数据存储层；同时我们还看到接入层节点抑或是网关服务节点要实现高可用保证，需要 引入负载均衡中间件实现高可用；再或者应用层与实现分片的数据存储层进行数据交互，为简化开发以及查 询匹配等因素引入数据库中间件，从而对于应用层仍然可以透明地实现对数据 存储的CRUD等操作，而无须关系数据匹配以及一致性等问题。5、SOA与微服务架构SOA为面向服务的架构，是属于一种设计方法，每个服务之间都相互独立且通过网络进行服务调用来完成一次复杂的业务请求操作；微服务架构是在

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

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

10、行分析与优化等操作。8、DevOps&自动化运维利用CI/CD等持续集成工具来完成一系列业务服务的发布流程，即代码 review后提交-测试-单元测试-打包-集成测试-UI测试-测试环境发布部署服 务-预生产灰度发布服务-真是发布部署服务等一系列流程可以称为DevOps全流 程，这对于我们做服务化架构能够实现快速迭代开发；有了 DevOps之后，我们就可以针对我们的业务服务进行自动伸缩，故障转 移，配置管理，状态管理等一系列自动化运维工作。四、分布式技术1、架构的高性能加缓存负载均衡async数据镜像数据分区缓存系统网关系统异步系统数据鑛像蝕据分区缓存分区负截均衡消息限列数据同步fiB务路由消

11、息持久读写井甌数据访问愿球存命中服务发现异步車务数据一致性豔踞一致性异步调用这里引入分布式高性能相关的技术，已经很好地诠释了分布式高性能技术 栈，对于高性能方面，自己也基于上述的基础上做一些补充:集群与负载均衡：通过水平扩展业务处理能力来提升系统的并发处理能 力。缓存设计：在我们的上述服务进行水平抑或是垂直扩展的时候，这个时候 我们的业务吞吐量也会增加，这个时候会把所有的流量压力打到数据存储系统 上，为了缓解数据存储系统的压力，这个时候我们会考虑将数据进行冷热划 分，对于热点数据集中在缓存系统服务以降低我们的数据存储压力。对于缓存的设计存在以下三种模式:其一是Cache Aside更新模式，即

12、失效-命中-更新策略；其二是Read/Write Through更新模式，即缓存更新对应用程序透明，对于 应用程序而言只有一个数据存储操作，由cache负载更新数据操作；其三是Write Back模型，类似于Linux下的Page Cache算法，应用程序 直接将数据更新到cache中，有cache异步批量更新到数据库中。垂直拆分业务（服务化设计）：当我们的一个服务节点承担复杂繁多的业务 服务的时候，必然会影响到我们业务处理的能力，为了提升我们的并发处理能 力，为了提升我们的系统并发能力，可以考虑将我们的业务进行垂直拆分，于 是就有了一个请求的处理需要多个服务之间进行协作完成。数据镜像与分区（

13、读写分离/分库分表）：尽管使用缓存可以缓解我们的服务 压力，但是仍然无法从根源上缓解流量对数据存储的压力，于是我们一方面会 做读写分离，做主从集群，主节点负责处理事务的数据写入，从节点数据负责 数据的读取；另一方面为了提升单库单表的并发能力，这个时候我们也是借助 分而治之的设计思想，采取分库分表的思路来缓解我们单库单表的流量压力。借助MQ中间件实现异步处理：可以通过中间件技术实现异步处理，对流量 进行削峰缓冲，进一步提高了程序的并发处理能力以及系统的稳定性。数据异构设计：将同一个业务数据按照业务需求的用途划分为不同的数据 仓库存储以适用相应的业务需求场景，比如对于爬虫的聚合资讯数据来源存在 很

14、多不确定的因素，我们可以通过MQ的方式接收数据变更并将数据持久化存储 到ES存储的引擎中；抑或是查询一个用户的订单信息，如果按照订单表的订单 ID进行拆分，则需要聚合多张表才能返回相应的聚合数据，这个时候可以采取 按照用户维度来进行异构一个与用户相关的订单数据仓库的策略（存在数据冗 余,但是提升读取性能）。2、高可用设计同样地,这里也是引入分布式高可用相关的技术，在此基础自己也做以下的 一些补充:服务冗余与负载均衡技术：从集群角度上思考，我们需要考虑集群是流量 如何分担到集群服务的节点，集群服务节点出现异常或者不可用的时候流量如 何切换，这个时候我们就需要考虑到负载均衡技术来帮助我们实现流量分

15、发的 调度，对服务节点采取心跳检测以及当服务节点异常采取重试与流量切换重新 调度分配可用服务节点来避免单点故障问题，简而言之服务的高可用可以是服 务冗余与负载均衡技术来避免单点故障，实现故障自动的恢复。隔离技术：为了防止故障蔓延到其他服务节点，我们通常会采取隔离技术 来隔离拆分的业务服务，每个业务服务分别各自独立部署，在分布式系统设计 中，一般会服务的种类或者是用户来进行隔离。降级与限流技术：当系统承担的并发流量服务压力十分庞大的时候，这个 时候我们需要采取保护措施，通过降级或者限流的技术来停用部分业务服务或 者是拒绝部分用户的请求操作以确保整个系统不会被流量冲垮导致整体不可 用。超时重试与熔断：在服务化架构设计中，为了防止服务产生雪崩，需要在 调用服务加入超时重试以及熔断机制，避免将错误蔓延到其他服务导致整个系 统服务不可用。从而缩小部分服务。高可用架构设计：利用服务冗余来避免单点故障，比如多租户隔离，灾备 多活抑或是数据副本保证一致性，高可用不仅是的服务集群的高可用，还有就 是中间件实现高可用设计。高可用的运维：实现devops的CI或者CD的持续集成计划任务，能够构建 执行自动化测试，实现灰度发布部署以及线上系统的自动化控制。缓存的高可用：对于缓存系统也需要采用集群高可用的方式来避免单点故 障以及实现故障恢复，同时对于缓存系统要实现高可用，需要