标签：影响 blog 内容 拆分 返回 api 系统 服务架构 实现
欢迎访问网易云社区，了解更多网易技术产品运营经验。
一个互联网产品在搭建服务时可能经常会遇到以下困境：搭建的单节点 web服务性能和可靠性都无法达到要求，节点挂掉=服务异常；直接使用外网提供服务，经常会担心被人攻破，且公司运维团队水平较低，一不小心就会有打开外网端口的情况。这些场景下如果加入负载均衡服务问题便会迎刃而解。
负载均衡，是现代计算机领域的基础服务之一。其基本原理是通过运行在前面的负载均衡服务，按照指定的负载均衡算法，将流量分配到后端服务集群上，从而为系统提供并行扩展的能力。
负载均衡服务一般都会有内外网隔离、健康检查等功能，从而提高系统的安全性和可用性。
下图就是一个标准的负载均衡服务应用场景：
这个是负载均衡服务的核心功能，作为统一的流量入口，负载均衡服务会把流量分发到后端的多个节点上，从而实现集群的横向扩展。当需要扩容时，只需要在负载均衡服务后面加入新的节点就可以了，而不用改变入口。对于有状态的服务来说，还需要启用会话保持来保证把流量分发到固定的节点上去。
基于应用层内容的流量分发。七层服务还存在着更为复杂的应用场景：外网的 web服务默认使用 80端口，但经常也会有多个不同域名的网站需要使用同样一个出口 IP的情况。这时候就需要通过应用层解析，根据用户的访问域名把同一个端口的流量分发到不同的后端服务中去。而随着结构的进一步拆分，还存在着同一个域名的服务根据 url分流到不同后端集群的情况，这种情况就需要进一步的分流和拆分。
通过加入后端多个节点，可以显著地提高服务的可用性。而且负载均衡服务一般会集成健康检查功能，在后端节点出现异常时会把请求转发到健康的节点上去，从而实现异常的自动处理。
很多负载均衡服务还会提供多 AZ支持，支持跨 AZ的高可用和后端部署。在单个机房宕机时仍然可以做到服务可用。
负载均衡服务本身一般都会采用专门的冗余设备，和专门的故障保证策略，保证自身的可用性。在云计算环境下，负载均衡服务一般都可以提供四个九级别的可靠性保证（99.99%），而通过加入多 AZ（机房级别）甚至多 Region（地区级别），还可以进一步提高服务的可用性。（蜂巢的多 AZ方案也会在几个月后跟大家见面，敬请期待）
当负载均衡服务与云计算结合之后，可以简单地实现资源的扩容/缩容，并且可以做到在线服务的弹性伸缩。
以扩容为例，当需要扩容时，可以预先初始化好需要扩容的节点，然后通过负载均衡接入，实现在线业务的并行扩容。
如果通过服务方提供的 open api，结合监控等其他信息，还可以实现自定义的弹性伸缩策略，实现高峰期预先扩容，低峰缩容。
有状态服务和无状态服务，原本是各有优势，并没有明显的优劣之分，但是在大集群、服务化的场景下，无状态服务则更有优势。
因为有状态服务在服务架构较为简单时虽然有易开发，高并发等优势，但随着业务规模的扩大，也会造成异常恢复困难、难以并行扩展等问题。而在这种场景下，无状态服务在服务管理、并行扩展方面有着先天的优势。
一般来讲，使用负载均衡，大多是服务规模较大，业务负载的场景，因此更推荐使用无状态化的服务。
健康检查是负载均衡服务的重要功能之一，也是服务判断后端节点是否存活的重要标准（很多场景下甚至是唯一标准）。不仅仅会影响到显示的状态，还会影响到用户的服务质量，甚至造成整个服务异常。下面举两个例子：
示例1：健康检查判断异常参数过于敏感，在系统压力较大时错误判断而移除正常的节点，导致剩下节点压力增大，从而继续发出移除操作，直到全部节点移除，系统雪崩。
应对之策：在线上压力较大，偶现超时的场景下，建议采用快速拉起，缓慢宕机的策略。通过适当拉长节点异常宕机时周期，减少错误判断的概率，而在服务正常时快速接入服务，缓解负载。
示例2：健康检查宕机参数设置时间过长，结果在节点宕机时无法快速拉起，在异常时影响到了用户访问。
应对之策：在线上压力较小、健康检查接口响应正常的情况下，可以考虑缩短宕机时间，这样在异常时可以快速移除异常节点，减少对用户的影响。
因此，健康检查参数并没有一个固定的原则，关键还是要看业务本身的特点，以及对业务来说，最重要的是什么：是业务稳定，还是用户体验？
有一个常见误区就是认为服务接入负载均衡就算高可用了。而事实上实际服务的高可用性是需要通盘考虑的事情，比如全链路移除单点，服务本身对于异常的处理等。
因此说，接入负载均衡仅仅是保证了接入点的高可用（如果挂单点那接入都不是高可用的），真正要实现高可用还需要全局保证，负载均衡只是构筑服务高可用的一个工具，而不是全部。
负载均衡是一个高性能的转发服务，但是对于单次请求来说，无法做到性能加速。
如果你本来的请求要 100ms返回，使用负载均衡之后也不会把你的请求缩短到 10ms。
而且从理论上说，无论任何形式的负载均衡，都只会增长调用链而不是缩短（一些软负载均衡，如 DNS，Service的 Iptables不会增加调用链本身，但是也会加入额外操作）。因此，对于单个请求，结果往往是变慢而不是加速（一般负载均衡服务增加的成本是微乎其微的 ms以内，应用完全感知不到）。
负载均衡对性能的提升，是通过分担负载带来的并行扩展能力从而提升服务的稳定性。而由于业务并行扩展，造成单台压力变小，从而提升服务的整体性能。
另外，由于负载均衡服务往往有更可靠的接入端（BGP网络），更高效的转发设施（专用转发设备和链路），更好的优化，一般性能还是远远优于自己搭建的转发服务。因此很多场景是会有更好的性能表现。
在这里，主要介绍了负载均衡服务的基本内容和负载均衡服务的主要功能及特征。下一节会进入实战篇，介绍如何在蜂巢中使用负载均衡服务，敬请期待。
网易云为您提供负载均衡服务，欢迎点击免费试用。
相关文章：
【推荐】 论用户体验测试：牛逼的功能千篇一律,好的用户体验万里挑一
【推荐】 MongoDB安全事件的防范与反思
【推荐】 适配的那些事
标签：影响 blog 内容 拆分 返回 api 系统 服务架构 实现
原文地址：https://www.cnblogs.com/zyfd/p/10025861.html
