分布式架构

架构师的学习可从如下几个方面着手：

第一、基础方面：包括数据结构、操作系统、算法应用、设计模式等一切拥有优秀编程能力
所应该熟知的软件基础知识；
第二、技术方面：如何使用优秀的技术产品去构建自己的系统，这些技术产品各自的特点是
什么，有什么优缺点、具体原理是怎样的？都要有深刻掌握和理解。对大型互联网系统而言，
主要包括缓存、异步、分布式存储、微服务等；
第三、架构方面：考虑点主要包括高可用、高性能、高扩展这三部分。
总之，作为一名技术人，我们既然选择了这个职业，就一定要有上进的决心，不能只顾写代
码，一定要提升架构设计能力。因为即使代码写得再好，做的也是执行层面的事儿，就会有
收入的天花板，想要突破它，就要突破你做事儿的边界，让自己成为一个架构师或技术负责
人。

分布式

什么是分布式架构？

当系统的并发处理能力，存储能力等不足时，我们可能会创建多个 Web 服务 ( 多个 tomcat
服务器 ), 多个数据库服务 ( 主动架构等 ) ，这些服务器通过网络进行连接，然后协同处理客
户端的并发请求，这样的系统我们称之为分布式系统。（这里要说明的一点是微服务架构是
分布式架构，但分布式架构不一定是微服务架构）例如：

为什么需要分布式架构？

当一个系统的业务 量 越来越大时，我们需要垂直或是水平拆分业务系统，同时为了避免所有
业务都部署在一台机器上时，一旦机器出现故障从而导致整体不可用，就需要将这些业务部
署在多台计算机上，来构建一个分布式架构。
分布式架构可以更好的提高系统的容量、可靠性（避免单点故障）、性能 。同时因为模块化，
系统的可重用性以及并行开发的效率也会提高。

分布式架构有哪些优势？

1. 可以实现更大数据量的存储。（字节跳动每天几十个 PB 的数据）
2. 可以更好提高系统的高可用性。（业务冗余、业务拆分、限流、降级 …. ）
3. 可以更好提高系统的可重用性。 ( 公共模块 - 例如订单系统、支付系统，日志收集系统，
监控系统，。。。 )
4. 可以更好提高系统的性能。（并行处理能力）

分布式架构有什么劣势？

分布式系统架构虽然解决 了 “单点”、“性能”和”容 量 “的问题，但却新增 了 一些新的问题。
①会增加架构设计的难度。
②部署和维护的成本也会加大。
很多技术方案都是“按下葫芦浮起瓢”，都是有得有失，分布式架构也是如此，理性面对即
可。

分布式架构有哪些关键技术？

服务治 理 。
服务治 理 的最大意义是需要把服务间的依赖关系、服务调用链，以及关键的服务给梳 理 出来，
并对这些服务进 行 性能和可用性方面的管 理 。
架构管 理 。
基于服务所形成的架构需要有架构版本管 理 、整体架构的生命周期管 理 ，以及对服务的编排、
聚合、事务处 理 等服务调度功能。
DevOps 。
分布式系统可以 更 为快速地 更 新服务，但是对于服务的测试和部署都会是挑战。所以，还需
要 DevOps 的全流程，其中包括环境构建、持续集成、持续部署等。自动化运维。有 了 DevOps
后，我们就可以对服务进 行 自动伸缩、故障迁移、配置管 理 、状态管 理 等 一系 列 的自动化
运维技术 了 。
资源调度管 理 。
应用层的自动化运维需要基础层的调度支持，也就是云计算 IaaS 层的计算、存储、网络等
资源调度、隔离和管 理 。
整体架构监控。
如果没有一个好的监控系统，那么自动化运维和资源调度管 理 只可能成为一个泡影， 因为
监控系统是你的眼睛。没有眼睛，没有数据，就无法进 行 高效的运维。所以说，监控是非常
重要 的部分。这 里 的监控需要对三层系统（应用层、中间件层、基础层）进 行 监控。
流 量 控制。
我们的流 量 控制，负载均衡、服务 路 由、熔断、降级、限流等和流 量 相关的调度都 会在这
里 ，包括灰度发布之类的功能也在这 里 。

基于分布式架构如何提高其高性能？

一般面对这样的问题，从整体维度去思考时，通常要分析问题，例如影响系统性能的因素有
哪些？
1) 请求数据传输时间
2) 请求数据的处理时间
3) 响应数据的传输时间
4) 响应数据的渲染时间 （ json->html/css/js ）
解决方案如下：
1) 减少数据传输时间？ ( 加带宽，减少数据传输量，减少传输距离，数据压缩 )
2) 提高请求数据的处理速度？ ( 分布式架构，缓存，算法， sql 调优，索引的设计，异步，
硬件 )
3) 提高数据在客户端的渲染时间？ ( 局部更新，减少不必要的元素等 )
具体从架构层面进行设计的话可以从如下几个维度进行思考：
应用缓存。
为系统添加缓存，可以有效地提高系统的访问能 力 。从前端的浏览 器 ，到网络，再到后端的
服务，底层的数据库、文件系统、硬盘和 CPU ，全都有缓存，这是提高快速访问能 力 最有效
的手段。
负载均衡。
负载均衡是做水平扩展的关键技术，我们可以使用多台机 器 来共同分担一部分流 量 请求。
异步调用。
异步系统主要通过消息队 列 来对请求做排队处 理 ，这样可以把前端的请求的峰值给“削平”
了 ，而后端通过自己能够处 理 的速度来处 理 请求。
数据分区和数据镜像
数据分区是把数据按一定的方式分成多个区（比如通过地 理 位置）， 不 同的数据区来分担 不
同区的流 量

如何基于架构提高系统的稳定性？

服务拆分。
服务拆分可以更好的实现故障隔离，同时也可以重用服务模块。
服务冗余。
服务冗余是为了去除单点故障，支持服务的弹性伸缩，以及故障迁移。
限流降级。
当系统扛 不 住压 力 时，只能通过限流或者功能降级的方式来停掉一部
分服务，或是拒绝一部分用户，以确保整个架构 不 会挂掉。
高可用架构。
高可用就是从冗余架构的角度来保障可用性。比如多租户隔离，灾备
多活等。总之，就是为 了不 出单点故障。
高可用运维。
指的是 DevOps 中的 CI（持续集成）/CD（持续部署）。一个良
好的运维应做 了 足够的自动化测试，做了相应的灰度发布，以及对线
上系统的自动化控制。这样，可以做到“计划内”或是“非计划内”的宕机
事件的时长最短。

分布式架构有什么难点？

异构系统存在很多不标准问题。
构建软件时使用的编程语言、通讯协议、数据格式、运维标准可能不同，进而导致架构设计
的复杂度越来越高。
系统架构中的服务依赖问题。
传统的单体应用，一台机器挂了，整个软件就挂掉了，分布式架构下也可能会出现这样的问
题，因为一个服务可能会依赖于另一个服务，某个服务挂掉了，会导致调用链上的服务都出
现故障（这就是多米诺骨牌效应）
故障发生的概率更大。
分布式系统中，服务和机器都会比较多，故障发生的频率会更大，只是影响面没有单体应用
的影响面大，分布式系统中故障可以被隔离。还有就是分布式架构管理相对于单体架构也更
加复杂，没有优秀的架构管理人员，故障的频率还是会非常高。
多层架构的运维复杂度更大。
分布式架构中，我们可以将系统分为四层 ( 基础层、平台层、应用层、接入层 ) 。
1) 基础层 : 包括机器、网络和存储设备。
2) 平台层 : 就是中间件层包括 tomcat 、 MySQL 、 Redis 、 Kafka 类似的软件。
3) 应用层 : 就是我们的业务软件，包括各种业务服务。
4) 接入层 : 就是接入用户请求的网关、负载均衡、 CDN 、 DNS 等。