本文主要是介绍【成为架构师3-5】服务化：必须搞定负载均衡，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
系列文章是博主对沈剑的《架构师训练营》分享内容的个人笔记总结，原内容公众号“成为架构师”。
目录
- 负载均衡方法论
- 同构环境下的负载均衡
- 静态权重
- 动态权重
- 过载保护
本篇是对微服务架构中实现负载均衡的一个通用思路的阐述
负载均衡方法论
- 同构环境下，重点在于 “均匀”
- 异构环境下，重点在于 “负载与能力匹配”
同构环境下的负载均衡
在同构环境下，负载均衡的实现基本上不需要额外的支持，在实现高并发、高可用的基础设施中：客户端到反向代理由dns轮询完成；反向代理到站点由nginx来完成；站点到服务由连接池完成；服务到数据层也是由数据层框架的客户端提供的连接池来完成。
因为是同构的，所以均衡策略是简单，轮询，随机的方式都可以实现。
本篇的重点是异构环境下的负载均衡。
静态权重
静态权重和同构环境下的“均衡方式”几乎是一样的，若按照 1：1：1配置下游的权重，那么就是均衡，可以说均衡是静态权重的一个特殊例子
静态权重一个最大的问题它是静态的，它是无法实时变化的，过载保护等也无法进行实施，但它是最快的也是成本最低的。
动态权重
动态权重有两个要点：
- 如何标识服务的处理能力
- 如何设计动态权重
服务的处理能力由调用方说了算，如果服务能够正常返回那么说明能力可以，如果超时了说明服务不能承受当前的流量压力
设计动态权重的原则就是：成功加小分，失败减大分
举个例子，先规定分值区间为【0，100】假设三个集群的下游服务service-1、service-2、service-3，三个服务的初始分值都是60，也就是说，在最初负载是均匀的。
随着时间的推移：
- 处理能力强的服务处理成功的请求越来越多
- 处理能力相对弱的服务偶尔有超时
最后动态权重的增减，变化为：service1-100分，service2-60分，service3-40分
那么这三个service负载比就是：5：3：2，service1会处理一半的请求，符合按照能力进行负载均衡。
过载保护
什么是过载保护：当服务过载的时候很有可能造成我们说的“雪崩”，服务的流量到达处理能力的峰值，随之再增加流量，处理成功的请求直线下降，服务进入不可用的状态。
过载保护也有两种方式，一种是静态的，一种是动态的。
静态的过载就是设定一个流量阈值，超过这个阈值就不会再有多的请求了。
动态的过载保护和动态的负载均衡策略是相似的：
- 连接代表服务，分值代表服务（连接）的处理能力
- 处理成功加小分，处理失败减大分
- 临界边界喘口小气（减少流量、短时）
- 死亡状态喘口大气（没有流量、可能时间较长）
过载保护的核心是为了不掉底，过载保护是实施在集群中的某一个节点的，本来应该由该节点处理的流量转由其它节点处理。
如果整个集群达到过载状态，那么只能依靠丢弃请求来实现自我保护，集群的过载保护策略和某一节点的策略是不同的。
下一篇会讲讲微服务中的连接池组件，它是微服务架构中重要的基础设施之一
上一篇回顾：【成为架构师3-4】服务化：必须支持高并发
下一篇更精彩：【成为架构师3-6】服务化：连接池，微服务的基础组件
这篇关于【成为架构师3-5】服务化：必须搞定负载均衡的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
