1、什么是负载均衡（代理）？
Load balancing，即负载均衡，是一种计算机技术，用来在多个计算机（计算机集群）、网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到最优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。
2、为什么需要负载均衡
我们在日常生活中经常免不了要去一些比较拥挤的地方，比如地铁站、火车站、电影院、银行等。无论是买票，还是排队入场，这些场所一般都会设置多个服务点或者入口的。如果没有人引导的话，大多数情况下，最近的入口会挤满人。而哪些距离较远的服务点或者入口就宽松很多。
这种情况下，就会大大浪费资源，因为如果可以把这些排队的人很好的分散到各个入口的话会大大缩短排队时间。其实，网站的建设也是一样的。为了提升网站的服务能力，很多网站采用集群部署，就像话剧院有多个入口一样。这时候，就需要一个协调者，来均衡的分配这些用户的请求，可以让用户的可以均匀的分派到不同的服务器上。
即即负载均衡（Load Balance），意思是将负载（工作任务，访问请求）进行平衡、分摊到多个操作单元（服务器，组件）上进行执行。是解决高性能，单点故障（高可用），扩展性（水平伸缩）的终极解决方案。
3、负载有哪些？
先看下 OSI 七层模型
OSI 是一个开放性的通信系统互连参考模型，他是一个定义得非常好的协议规范。
OSI 模型有 7 层结构，每层都可以有几个子层。 OSI 的 7 层从上到下分别是 7、应用层；6、表示层；5、会话层；4、传输层；3、网络层；2、数据链路层；1、物理层；
其中高层（即 7、6、5、4 层）定义了应用程序的功能，下面 3 层（即 3、2、1 层）主要面向通过网络的端到端的数据流。
在这七层模型种，高层次都是依赖于低层次的。层次越高，使用起来越方便。
计算机网络有关的概念：
TELNET、HTTP、FTP、NFS、SMTP、DNS 等属于第七层应用层的概念。
TCP、UDP、SPX 等属于第四层传输层的概念。
IP、IPX 等属于第三层网络层的概念。
ATM、FDDI 等属于第二层数据链路层的概念。
了解了网络协议的七层模型以后，再来看看负载均衡。我们可以很明确的一点是，负载均衡是要在网络传输中做文章的。而要在网络传输过程搞事情，那么这七层模型就势必躲不开。
所以，根据负载均衡技术实现在 OSI 七层模型的不同层次，是可以给负载均衡分类的。
常见的实现方式中，主要可以在应用层、传输层、网络层和数据传输层做文章。所以，工作在应用层的负载均衡，我们通常称之为七层负载均衡、工作在传输层的我们称之为四层负载均衡。
大致可以分为以下几种，其中最常用的是四层和七层负载均衡：
二层负载均衡
负载均衡服务器对外依然提供一个 VIP（虚 IP），集群中不同的机器采用相同 IP 地址，但是机器的 MAC 地址不一样。当负载均衡服务器接受到请求之后，通过改写报文的目标 MAC 地址的方式将请求转发到目标机器实现负载均衡。
三层负载均衡
和二层负载均衡类似，负载均衡服务器对外依然提供一个 VIP（虚 IP），但是集群中不同的机器采用不同的 IP 地址。当负载均衡服务器接受到请求之后，根据不同的负载均衡算法，通过 IP 将请求转发至不同的真实服务器。
四层负载均衡
四层负载均衡工作在 OSI 模型的传输层，由于在传输层，只有 TCP/UDP 协议，这两种协议中除了包含源 IP、目标 IP 以外，还包含源端口号及目的端口号。四层负载均衡服务器在接受到客户端请求后，以后通过修改数据包的地址信息（IP + 端口号）将流量转发到应用服务器。
七层负载均衡
七层负载均衡工作在 OSI 模型的应用层，应用层协议较多，常用 http、radius、dns 等。七层负载就可以基于这些协议来负载。这些应用层协议中会包含很多有意义的内容。比如同一个 Web 服务器的负载均衡，除了根据 IP 加端口进行负载外，还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。
4、负载均衡工具有哪些？
市面上有很多开源的负载均衡的工具或软件，基本都是基于前面提到的方案实现的，大多数是工作在第七层和第四层的。Nginx/LVS/HAProxy 是目前使用最广泛的三种负载均衡软件。
LVS ：LVS 主要用来做四层负载均衡
LVS（Linux Virtual Server），也就是 Linux 虚拟服务器, 是一个由章文嵩博士发起的自由软件项目。使用 LVS 技术要达到的目标是：通过 LVS 提供的负载均衡技术和 Linux 操作系统实现一个高性能、高可用的服务器群集，它具有良好可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的服务性能。
Nginx ：Nginx 主要用来做七层负载均衡
Nginx（发音同 engine x）是一个网页服务器，它能反向代理 HTTP, HTTPS, SMTP, POP3, IMAP 的协议链接，以及一个负载均衡器和一个 HTTP 缓存。。
HAProxy ：HAProxy 主要用来做七层负载均衡
HAProxy 是一个使用 C 语言编写的自由及开放源代码软件，其提供高可用性、负载均衡，以及基于 TCP 和 HTTP 的应用程序代理。
5、负载均衡如何工作
负载均衡服务器在决定将请求转发到具体哪台真实服务器的时候，是通过负载均衡算法来实现的。负载均衡算法，是一个负载均衡服务器的核心。
就像电影院门口的引导员一样，他根据什么把排队人员分配到具体的入口呢？是哪个入口人少吗？还是哪个入口速度最快？还是哪个入口最近呢？
负载均衡算法可以分为两类：静态负载均衡算法和动态负载均衡算法。
1）. 静态负载均衡算法包括：轮询，比率，优先权
- 轮询（Round Robin）： 顺序循环将请求一次顺序循环地连接每个服务器。当其中某个服务器发生第二到第 7 层的故障，BIG-IP 就把其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。
- 比率（Ratio）： 给每个服务器分配一个加权值为比例，根椐这个比例，把用户的请求分配到每个服务器。当其中某个服务器发生第二到第 7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配, 直到其恢复正常。
- 优先权（Priority）： 给所有服务器分组, 给每个组定义优先权，BIG-IP 用户的请求，分配给优先级最高的服务器组（在同一组内，采用轮询或比率算法，分配用户的请求）；当最高优先级中所有服务器出现故障，BIG-IP 才将请求送给次优先级的服务器组。这种方式，实际为用户提供一种热备份的方式。
2). 动态负载均衡算法包括: 最少连接数, 最快响应速度，观察方法，预测法，动态性能分配，动态服务器补充，服务质量，服务类型，规则模式。
- 最少的连接方式（Least Connection）： 传递新的连接给那些进行最少连接处理的服务器。当其中某个服务器发生第二到第 7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配, 直到其恢复正常。
- 最快模式（Fastest）： 传递连接给那些响应最快的服务器。当其中某个服务器发生第二到第 7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
- 观察模式（Observed）： 连接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。当其中某个服务器发生第二到第 7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
- 预测模式（Predictive）： BIG-IP 利用收集到的服务器当前的性能指标，进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器相应用户的请求。(被 BIG-IP 进行检测)
- 动态性能分配 (Dynamic Ratio-APM)： BIG-IP 收集到的应用程序和应用服务器的各项性能参数，动态调整流量分配。
- 动态服务器补充 (Dynamic Server Act.)： 当主服务器群中因故障导致数量减少时，动态地将备份服务器补充至主服务器群。
- 服务质量 (QoS）： 按不同的优先级对数据流进行分配。
- 服务类型 (ToS)： 按不同的服务类型（在 Type of Field 中标识）负载均衡对数据流进行分配。
- 规则模式： 针对不同的数据流设置导向规则，用户可自行。
以上，就是目前实现负载均衡的主流算法。不同的负载均衡服务器会选择不同的算法。就像电影院和火车站可能会选用不同的引导策略一样。火车站可能会把行李少的旅客分配到一个专门的入口，可能给即将发车的旅客分派到特快入口，手持可扫描车票的用户单独分配到特殊入口等。
PS：
现代网络负载均衡与代理（上）
现代网络负载均衡与代理（下）
https://www.infoq.cn/article/modern-network-load-balancing-and-proxying-2
1、云工作负载安全漏洞和补丁修复趋势
2019 年，大量操作系统、虚拟化平台、容器等各种云工作负载的安全漏洞被披露，相关问题应该引起重视。
主流虚拟化平台（VMWare、Xen、VirtualBox、Hyper-V、QEMU）漏洞 166 个，容器（ Docker）漏洞 13 个。
2、入侵威胁趋势
· 暴破攻击事件数量居高不下
· 挖矿与勒索病毒热度不减
·Webshell 威胁形势依旧严峻
· 工作负载间的横向渗透攻击手段层出不穷
· 工作负载越权控制访问威胁种类繁多
3、容器安全
容器是当前云计算的主流技术之一。Docker 是当下容器技术的主流选择（2019 年的市场占比达 79%）。它与 DevOps 理念不谋而合，受到了企业推崇。然而，在 “Docker 容器的全生命周期” 中存在诸多安全问题，下面对其中的重要管控点及相应的管控方法进行介绍。
4、微服务安全
随着互联网飞速发展，传统的 “单体架构” 在面对持续改进、快速部署等需求时显得力不从心，而 “微服务架构” 作为一种系统解决思路应运而生。
单体架构与微服务架构的部分区别如下表所示。可推知，后者在解决一些复杂问题时放大了攻击面，引入了一些安全隐患。
为规避这些安全隐患，须从 “安全开发” 和“安全运维”两方面着手。
微服务架构伴随着软件架构的需求应运而生。这类 Web 应用所面对的安全问题也与传统单体应用有着异同点，对甲方的安全开发和安全运维以及乙方的安全产品研发和落地提出了新的要求和挑战。
CWPP 的定义是基于主机安全的解决方案。云工作保护平台（Cloud Workload Protection Platform）简称 CWPP。在现代混合的数据中心架构中，主要的保护目标是服务器的工作负载。这种架构是由本地服务器、虚拟服务器以及不同公有云环境组成。CWPP 与普通终端管理平台（EPP）的分野就此开始。CWPP 主要解决的问题在于数据中心维度，跟 EPP 解决问题的 PC 维度是不一样的。CWPP 强调了混合数据中心架构需要统一的管理、Linux 系统的重点支持、杀毒软件的无效、定价灵活性以及跟云平台的对接和 API 与 DevSecOps 的结合等等。从技术角度来看，最核心的是跟云平台原生的对接，利用 AWS 或者 Azure 提供的接口来进行相关安全措施的处理。
云计算工作负载对安全有着不同的要求，混合私有云和公有云的云计算模型使这些不同之处更加复杂化，CISO 们应该为保护混合云计算负载部署专门的安全产品。Gartner 推荐公司使用以风险为基础的分层安全策略。
下图展示了用于服务器负载保护的安全控制优先级，塔基包括了关键的基本能力，越往上功能越不重要。我们需要注意的是，其中一些功能可能会由 OS 供应商、云 IaaS 供应商提供，或者通过 IT 运营工具来实现。另外，服务器托管的虚拟桌面架构是一种不同的用例，要使用更加传统的用户终端保护策略。
上图底部方框里列出了一些基本的运维能力，真正实现服务器安全一定要以良好的运维规范为开端，如：
（1）限制访问服务器，服务器工作负载要限制物理或虚拟访问。
（2）限制在服务器运行任意代码的能力，移除或禁用本地浏览器和 email 客户端。
（3）严格控制管理员访问服务器工作负载。多元认证或者其他形式的强认证要取代简单的用户名 / 密码机制；管理认证应该使用 PAM 系统。
（4）变更管理。通过与 PAM 结合，服务器镜像变化应遵守一个明确的、与工单系统相连的变更管理控制流程。
（5）日志管理。把服务器工作负载 OS 和应用日志集中在一个日志管理系统或 SIEM 系统中，同时管理 PAM 日志。在虚拟化和云端环境，还要管理管理员行为日志。
在此基础上，列出了CWPP**服务器保护策略的五个核心能力：**
1**、配置和漏洞管理。** 移除非必要的组件，如 Telnet，FTP 和其他服务。我们要在初期就根据行业标准指南加固镜像，可以由 IT 运营部门管理这一层面，但信息安全要根据公司标准方针确保加固、配置系统。再根据公司的补丁政策，完成系统补丁，定期持续更新系统。一些服务器保护解决方案可以彻底评估系统配置和漏洞，由各自的 agent 提供可视性。利用脚本和模板的自动化云工作负载提出了新的打补丁方式，但线上系统不能打补丁。
2**、工作负载分割和网络流量可视化。** 严格的工作负载安全的基础是隔离和分化与外部资源沟通的能力。一些工作负载的保护方案自身具备防火墙能力，而其他保护方案会管理 windows 和 linux 系统内置的防火墙。解决方案应该支持数据中心东西流量的微型分割需求。另外，一些解决方案提供可视化和监控通信流量，可视化工具让运维和安全管理员可以了解流量类型、设置策略、监控偏差。最后，一些厂商提供工作负载之间的网络流量加密选择来保护动态数据，并在工作负载之间提供加密隔离。
3**、系统完整性监控和管理。** 这项功能包括两个领域：第一个是在 BIOS，管理程序和虚拟机系统镜像加载前进行评估，一般会通过物理系统中硬件层面的可信任措施实现评估。第二个是在工作负载自启后，实时的监控核心系统文件完整性。高级解决方案还会监控 windows 注册表、启动目录、驱动和引导加载程序，文件完整性监控是高级 EDR 方案的前身。
4**、应用程序控制（白名单）。** 之前讨论过，虚拟机和公有云 IaaS 中大多数工作负载只能运行一个应用。使用白名单以控制在服务器运行什么文件，这是一个强大的安全保护策略，默认阻止所有显示为文件的恶意软件。许多 CWPP 解决方案或专门的单点解决方案会提供内置的应用控制功能。还有一种方案，使用内置的 OS 应用控制功能，如 Windows, SELinux 系统的软件限制策略和应用程序控制策略（Applocker）或 Linux 系统的 AppArmor。
5**、渗透阻止和内存保护。** 应用控制解决方案不会一直可靠，应该跟预防漏洞利用和内存保护功能相结合，这些功能可以是 OS，应用控制方案或第三方的保护措施，预防这些情况：白名单应用被攻击而产生漏洞，输入的代码在内存中直接运行，且本身不是单独的执行（或可控）文件。另外，保护和内存保护方案不用传统的、基于签名的杀毒方案就能防御攻击，在没有补丁的情况下，还能减少管控。
除此之外无论是自己研发还是和第三方云安全厂商合作，企业在评估各种解决方案时，需要重点考虑架构的几点要求：
1、支持混合云环境，这是最重要的一点，大量云服务厂商提出的安全方案都可以运行在混合云环境中。对那些仍然使用物理服务器的公司，要求他们提供支持混合云环境的服务。
2、支持服务器操作系统，大多数厂商都支持 windows 和 Linux 系统，如果厂商支持 Linux 系统，为你的企业布局寻求特定支持及 32/64 位支持，判断产品是否同时具备 windows 功能。如果厂商支持 Windows 系统，要弄清支持哪个版本，还是 32/64 位都支持；很少有供应商支持 HP-UX,IBM AIX 或 Oracle Solaris 系统；有一些供应商专门支持那些不再受支持的服务器系统，如 Windows2000 和 2003 服务器。
3、支持容器，基于主机的 agent 要分辨单独的 Linux 容器，包括网络分段，再根据实际情况实施相应策略。这对那些使用容器支持微服务架构和快速发展 DevSecOps 工作流的公司来说，这个新要求非常重要。
4、全面支持 **API**，安全保护要越来越能自动适应 DevSecOps 工作流的工作负载，通过 API，利用高自动化开发环境中的脚本、方法和模板，使控制台自动配置安全策略，不再像以前那样通过” 人为介入 “执行昂贵的、缓慢的手动配置。
5、对系统空间和性能的影响，CWPP 的整套功能可能会对系统空间和功能产生较大影响，例如，以数据包深度检测为基础的 HIPS 可能会占用大量资源，如果可以的话，数据加密应该使用硬件加速能力，如因特尔的 AES-NI。以签名为基础的反恶意软件扫描在爬取、扫描文件系统时，也会对安全系统的性能产生影响。
6、“**无 agent”保护 **，在虚拟系统环境中，很多供应商都会连接其 vSphere 管理程序 API，进行无 agent 反恶意软件扫描。作为无 agent 集成管理程序的另一种模式，Bracket Computing 使用的是创新性的” 外包装 “方式，可以在无 agent 的情况下，保护每个工作负载。
7、虚拟化和云服务提供商的原生集成和支持，在云基础环境中，为了实现有效保护，CWPP 应该充分理解并能整合平台的原生附加能力，这样才能在这些标记的基础上执行安全策略。在创建新的工作负载时，集成云厂商的 API 可能无需设置安全保护，就可以联络控制台。最后，充分理解本地云供应商的不同分类有助于我们界定细分策略。
8、控制台管理能力，在所有服务器工作负载中，要强制实施对不同职责管理员的全面访问控制，一些供应商会提供” 云控制台 “，因此无需本地管理服务器。
9、合规性报告，对于有明确法规要求的企业来说，当审计人员要求出示合规证据时，提供详细的合规报告能力就可以减少工作量（比如要求提供 PCI 和 HIPAA 合规报告）。
10、安全自启能力，内置安全 agent 的系统配置速度很快，但可能无法在运行时执行安全策略。Agent 应该准备使用模板和 upon boot，这样才能根据工作负载的环境（例如工作负载的位置或者在标记的基础上），安全地获取、下载和应用合适的策略。
11、灵活的价格模型，理想的解决方案可以让企业混合几种授权模型，以发挥最大的作用。大多数厂商是根据每年每台虚拟机的订阅模式来收费，还有一些根据每台中央处理器插槽收费，对于高度灵活的工作负载来说，定价模式有一个更好的选择，那就是根据虚拟机的实际使用时长或其他基于使用情况的标准来制定。
12、审计和日志记录，要记录控制台上所有管理行为和事件，并将这些日志传输到主要的 SIEM 系统中。
13、威胁情报 **/** 社区情报，厂商的研究实验室要提供全面的威胁情报，将攻击模型和趋势的变化告知安全运营官，理想情况下，厂商要直接提供保护方案。厂商的客户群体要允许参与人分享这种可视性和情报信息，以更好地防御威胁。
https://www.yuque.com/lnadmin/qs3tf4/nyhd69
若有收获，就点个赞吧
0 人点赞
