一文读懂分布式架构知识制度（内含超全核心知识大图）(2)

过去软件平台随着客户量降低需要提高机器资源的话，传统的方法就是找运维申请机器，然后推进好工具服务接入集群，整个过程依赖的是运维人员的人肉经验，效率低下甚至容易错误。微服务分布式则无需人肉增加物理机器，在容器化技术的支撑下，我们只应该申请云资源，然后执行容器脚本即可。

有了计算资源后，另外更重要的就是网络资源了。在现有的云化背景下，我们几乎不会直接接触到物理的带宽资源，而是直接由云系统统一管理带宽资源。我们必须的是对网络资源的最大化应用跟有效的管控。

在系统故障的之后我们第一要务是系统修复，同时保留案发现场也是相当重要的，资源调度系统则必须有统一的模式保存好故障现场。

在我们建设好分布式平台后，最先受到考量的关口就是网关了，进而我们必须关注平台流量的状况，也就是如何对流量的管控，我们追求的是在平台可容纳的流量上限内，把资源留给更优质的流量使用、把违法恶意的流量挡在门外，这样节省费用的同时保证系统不会被冲击崩溃。

负载均衡是我们对服务如何消化流量的通用设计，通常分为物理层的底层协议分流的硬负载均衡和工具层的软负载。负载均衡解决方案已经是业界成熟的方案，我们一般会对于特定业务在不同环境进行改进，常用有如下的负载均衡解决方案

负载均衡首当其冲的就是网关，因为中心化集群流量最先打到的地方就是网关了，如果网关扛不住压力的话，那么整个平台将不可用。

剩下的真实流量我们引入不同的算法来分流请求。

流量限制在流量增长的之后，通常我们必须有限流措施来避免系统发生雪崩，那么就必须预测系统的流量上限，然后设置好上限数，但流量下降至一定阈值后，多起来的流量则不会进入平台，通过牺牲部分流量来保全系统的可用性。

所谓打铁还需自身硬，流量做好了调度管理后，剩下的就是服务自身的健壮性了。分布式平台服务发生故障是常有的事情，甚至我们必须把故障本身只是是分布式服务的一部分。

我们网络管理一节中介绍了网关，网关是流量的集散地，而注册中心则是服务的根据地。

服务编排的定义是：通过消息的交互序列来控制各个个别资源的交互。参与交互的资源都是对等的，没有集中的控制。微服务环境下服务很多我们必须有一个总的协调器来协议服务之间的依赖，调用关系，K8s 则是我们的不二选择。

前面我们解决了网络的健壮性和强度问题，这节介绍的是怎样让我们的服务非常健壮。

降级：当用户下降的之后，我们首先是在流量端做手脚，也就是限流。当我们看到限流后平台响应变慢了，有也许造成更多的弊端时，我们也必须对服务原本做一些操作。服务降级就是把当前不是很核心的功能关闭掉，或者不是很要紧的准确性放宽范围，事后再做一些人工补救。

熔断：当我们都做了以上的操作后，还是认为不安心，那么就必须再进一步操心。熔断是对过热的一种自身保护，犹如我们开关跳闸一样。比如当我们服务不断对进行查询的之后，如果业务弊端导致查询问题，这是本身必须熔断来确保不会被应用拖垮，并且访问友好的信息，告诉服务不要再过度调用了。

幂等：我们明白，一个幂等操作的特征是其任意多次执行所造成的妨碍均与一次执行的妨碍相同。那么就必须对单次操作赋予一个全局的 id 来做标识，这样多次请求后我们可以判定来源于同个客户端，避免发生脏数据。

数据存储最大的挑战就是数据冗余的管控，冗余多了强度变低并且占用资源，副本少了起不到灾备的作用，我们一般的做法是把有转态的请求，通过转态分离，转化为无状态请求。

分离状况到全局存储，请求转化为无状态流量，比如我们一般会将登录信息缓存到全局 redis 中间件，而不需要在多个应用中去冗余用户的登录数据。

数据横向扩展。

多副本冗余。

我们从资源申请管理的之后就介绍到 devops 的趋势，真正做到开发运维一体化则必须不同的中间件来配合完成。

全局配置中心按环境来区别，统一管理，减少了多处配置的混乱态势。

微服务分布式部署是家常便饭，如何使我们的服务更好地支撑业务发展，稳健的推进思路是我们首先必须考量的，如下的推进思路适合不同业务和不同的阶段。

任务调度是平台必不可少的一个环节，传统的方法是在 Linux 机器上配置 crond 定时任务以及直接在业务代码上面完成调度业务，现在则是成熟的中间件来替代。

运维工作中巨大一部分时间应该对应用进行重启，上下线操作，还有日志清理。

既然我们明白分布式系统故障是家常便饭，那么应对故障的方案也有不可或缺的环节。通常我们有主动跟被动的方法来处理：

重试设计的关键在于设计好重试的时间跟次数，如果达到重试次数，或是一段时间，那么重试就没有意义了。开源的项目 spring-retry 可以很好地推动我们重试的计划。

事务补偿符合我们最后一致性的观念。补偿事务不必定会将平台中的数据返回至原始操作开始时其所处的状况。 相反，它补偿操作失败前由未顺利完成的流程所执行的工作。补偿事务中方法的次序不一定与原始操作中方法的次序完全相反。 例如，一个数据存储可能比另一个数据存储对不一致性更加脆弱，因而补偿事务中撤销对此存储的修改的方法需要会首先出现。对完成操作所需的每个资源运用短期的基于超时的锁并预先获得很多资源，这样有助于增加总体活动顺利的可能性。 仅在获得所有资源后才要执行工作。 锁过期之前必须完成所有操作。

由于分布式系统是由很多机器共同协同的平台，而且网络也能够确保完全只用，所以我们必须建设一套对各个环节都可监控的平台，这样我们能够从底层到业务各个层面进行监控分布式存储架构，出现意外的之后可以迅速恢复故障，避免更多的难题发生。

基础层面是对容器资源的检测，包含各个软件指标的负载状况

分布式平台接入了大量的中间件平台，中间件本身的健康状况也必须监控。

当故障终于出现后，我们第一个要做的就是马上清除故障，确保平台服务正常可用，这个之后一般做回滚操作。

应用回滚之前需要保存好故障现场，以便排查原因。

应用服务回滚后，代码基线也必须 revert 到前一版本。

整体回滚需要服务编排，通过大版本号对集群进行回滚。

性能改进是分布式平台的大专题，涉及的面比较广，这块简直可以单独拿出来做一个系列来讲，本节就先不展开。本身我们做服务治理的过程也有在性能的改进过程。<br />参考《高并发编程知识体系》

缓存是解决性能问题的一大利器，理想状况下，每个请求不需要额外计算就立即可获得至结果时更快。小至 CPU 的三级缓存，大到分布式缓存，缓存无处不在，分布式缓存需要解决的就是数据的一致性，这个之后我们采用了分布式锁的概念，如何处理分布式锁的难题将决定我们获得缓存数据的效率。

多线程编程范式提升了平台的吞吐量，但也同时带给了业务的复杂度。

事件驱动的异步编程是一种新的编程范式，摒弃了多线程的复杂业务处理难题，同时还能提高平台的响应效率。

最后总结一下，如果有也许的话，请尝试使用单节点方法而不是分布式平台。分布式系统伴随着一些失败的操作，为了处理灾难性故障，我们使用备份；为了提升可靠性，我们采用了冗余。

分布式平台本质就是一堆机器的协同，而我们要做的就是搞出各种方式来然机器的运行超过预期。这么复杂的平台，需要知道各个环节、各个中间件的接入，是一个非常大的工程。庆幸的是，在微服务背景下，多数基础性的工作尚未有人帮我们推动了。前文所叙述的分布式架构，在项目推动了是必须用到分布式三件套 (Docker+K8S+Srping Cloud) 基本就可以形成起来了。

分布式架构核心技术分布图如下：

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-135772-2.html