标签：服务 故障 吞吐量 监控 分布式系统 架构 分布式 科普

　　1. 分布式架构解决什么问题

　　主要是两个：

　　大流量的处理通过集群技术将大规模并发请求负载均衡到不同的机器上。关键业务的保护提高后台服务的可用性，把故障隔离起来，阻止多米诺骨牌效应，如果流量过大，需要对业务降级。已保证关键业务的流转。

　　说白了就是干两件事、一是提高整体架构的吞吐量，二是提高系统的稳定性，让系统的可用性更高。

　　2. 如何提高架构性能缓存系统异步调用负载均衡数据分区数据镜像3. 如何提高架构稳定性服务拆分服务冗余限流降级高可用架构高可用运维4. 分布式系统的核心

　　img

　　5. 全栈监控

　　img

　　基础层：监控主机和底层资源。比如：CPU、内存、网络吞吐、硬盘I/O、硬盘使用等。中间层：就是中间件层的监控。比如：Nginx、Reids、ActiveMQ、Kafka、MySQL、Tomcat等。应用层：监控应用层的使用。比如：HTTP访问吞吐量、响应时间、返回码、调用链路分析、性能瓶颈、还包括用户端的监控。6. 服务治理梳理服务之间的依赖关系 （zipkin）服务状态和服务声明周期管理 （服务发现）整体架构版本管理 （类似于Springboot和Spring clound之间的版本对应）资源/服务调度服务状态的维持和拟合（一种不预期的变化会维持服务状态，例如服务挂掉。预期的变化会拟合服务状态、例如服务启动）服务的弹性伸缩和故障迁移 （docker、kubernetes）服务工作流和编排7. 总结7.1 构建分布式系统面临的问题分布式系统的硬件故障发生率高。故障发生是常态，需要尽可能地将运维流程自动化。需要良好的设计服务，避免某服务的单点故障对依赖它的其他服务造成大面积影响。为了容量的可伸缩性，服务的拆分、自治和无状态变得更加重要，可能需要对老的软件逻辑做大的修改。老的服务可能是异构的，此时需要让他们使用标准的协议，以便可以被调度、编排、且互相之间可以通信。服务软件故障的处理也变得复杂，需要优化的流程，以加快故障的恢复。为了管理各个服务的容量，让分布式系统发挥出最佳性能，需要有流量调度技术。分布式存储会让事务处理变得复杂；在事务遇到故障无法被自动恢复的情况下，手动恢复流程也会变得复杂。测试和查错的复杂度增大。系统的吞吐量会变大，但响应时间会变长。7.2 了解一些解决方案需要有完善的监控系统，以便对服务运行状态有全面的了解。设计服务时要分析其依赖链；当非关键服务故障时，其他服务要自动降级功能，避免调用该服务。重构老的软件，使其能被服务化；可以参考 SOA 和微服务的设计方式，目标是微服务化；使用 Docker 和 Kubernetes 来调度服务。为老的服务编写接口逻辑来使用标准协议，或在必要时重构老的服务以使得它们有这些功能。自动构建服务的依赖地图，并引入好的处理流程，让团队能以最快速度定位和恢复故障，详见《故障处理最佳实践：应对故障》一文。使用一个 API Gateway，它具备服务流向控制、流量控制和管理的功能。事务处理建议在存储层实现；根据业务需求，或者降级使用更简单、吞吐量更大的最终一致性方案，或者通过二阶段提交、Paxos、Raft、NWR 等方案之一，使用吞吐量小的强一致性方案。通过更真实地模拟生产环境，乃至在生产环境中做灰度发布，从而增加测试强度；同时做充分的单元测试和集成测试以发现和消除缺陷；最后，在服务故障发生时，相关的多个团队同时上线自查服务状态，以最快地定位故障原因。通过异步调用来减少对短响应时间的依赖；对关键服务提供专属硬件资源，并优化软件逻辑以缩短响应时间。

标签：服务,故障,吞吐量,监控,分布式系统,架构,分布式,科普
来源： https://blog.csdn.net/iqifenxia/article/details/122341135

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。