互联网域流量编排整理

随着这几年数据安全话题飙升，同时伴随着网络安全法概念的不断提升又将数据安全拉伸到另一个高度；各类的安全产品也不断的涌入市场，像主机检测类型，流量检测类型，应用层防护类型，运营商线路防护类型等等不一一列举，安全规范的界定对于很多互联网域环境结构也存在着冲击。

例如：“三明治”结构

数据报文的业务服务流经过各种业务节点（主要L4-7层节点，如安全，SSL网关，FW，LB等）所有的数据报文按照设定好的业务逻辑经过既定的设备，这种的结构在互联网域的环境下成就了清晰的南北流量结构。

传统的网络结构中引入的安全产品，如何将安全设备（诸如IPS，WAF，DDOS等）部署在数据服务器前端形成清晰的业务流就造成了困扰，同时对于这种“串”结构造成了冲击，由此就引出“流量编排”。

流量编排简单理解，对于途径节点流量进行统一调控，例如，

1. 数据报文的先经过哪个节点，再某某类型的节点等；
2. 节点出现故障时逃生保证业务数据的正常交易；
3. 逃生后如何排查问题，
4. 问题排查后，如何回复正常的业务调度。

在这种环境下又牵扯很多资源协调的问题和边缘化结构的问题；

如：

场景1

某个业务部署硬件负载均衡策略，负载的部署server是nginx，通过硬件负载测试业务出现“session信息错误”的提示，直接访问nginx就无报错信息，就会被甩锅为“硬件负载均衡策略出现问题”。（nginx上调整ecconfig.json）

场景2：

某某业务出现"访问失败，web页面白屏"，网络部门人排查网络，应用部门排查应用，排查结果都没问题造成相互推诿扯皮，问题查清晰之后双方确实都没问题，只是每个部门都稍微调整一下配置，比如：网络部门调整交换机的接口MTU，应用部门调整白名单等等问题就解决了。

以上的两种场景遇到的估计不在少数，流量编排的环境存在同样的状态（有人的地方就有江湖，有江湖就他么有纷争）。安全部门按照安全规范要接入网络环境，网络部门原来的网络结构清晰，按照规范必须要考虑在“串”调整结构接入安全的产品。

需要考虑的问题，这个安全产品可靠么？出现问题怎么办？是不是需要配合查问题（耗费大量时间，这个时间是不是可以喝喝茶，打打两把王者）

以上的这些场景就“一个头两个大”。

在这种“一个头两个大”的环境中诞生的流量编排，将这种因素全部考虑在内，将流量编排描绘成B-29其实也不过分。

（PS:B-29轰炸机，二战时期亚洲战场美国陆军航空队主要的轰炸机，美国波音公司1940年生产战争催生的超级空中堡垒，有五个不同的弹着点，主要用于战略轰炸和远程轰炸，反潜、侦察和空中加油，配有机枪炮塔等，广岛和长崎投掷的蘑菇就是它的杰作）

（一）

ADC的位置可以是想目前市面上提到最多的SSLO的流量编排设备，设定往返的路径所有安全设备统一通过SSLO设备调度流量。

安全设备启用透明模式将网关设定为SSLO保证进出流量统一通过SSLO调度，对应的安全设备之间设置对应的探测策略，规划和配置流量调度需要关注的是有清晰完整的业务报文流程图和对应的逃生通道。

如果安全设备已经启用的代理模式，SSLO的调度流量时除去考虑路由指向，需要考虑在转发过程中目的地址的替换。

（二）

ADC的位置可以是负载均衡设备，通过RS主备的概念，设定安全设备的bypass通道，安全设备需要启用代理模式（反向代理，应用代理叫法很多，视野大的工程师理解原理不纠结名称。）流经两种安全设备之间的数据报文形成无法透明的“黑盒”。如某个安全设备业务节点出现问题前端的ADC有无法感知会造成业务失败。

在安全设备直接相互设定探测，这样当某台安全设备出现故障，探测状态相互传递到最接近ADC设备的一端。

在ADC上设定业务级别的探测方式直接穿透路径上的安全设备直打业务服务器，在这种情况下要针对不同的优先权设备进行分别设置。

两台安全设备直接的流量不透明的问题可以通过在SW上设置不同的span流量进行参考。

（三）

ADC的位置是流量管理设备，在整个网络环境中可以被看作透明，在编辑流量编排的过程中不会对路径节点数据内容进行改变性能高于L4-7层无TCP/IP连接和session表的概念。

安全设备之需要开启检测模式

为保证安全设备直接流量监控可以直接通过流量监控设备将对应的流量输出至探针设备。

流量监控设备用于互联网编排面临的问题是在运维的固有观念里，流量监控设备属于旁路接入业务生产环境需要渡过心理关且考虑冗余性。

流量编排的场景各有利弊，如何选择需要面对实际的场景，同时考虑业务可以承受的风险敞口。