一种基于eBPF的流量治理方法和系统与流程

一种基于ebpf的流量治理方法和系统
技术领域
1.本发明涉及通讯技术领域，具体涉及一种基于ebpf的流量治理方法和系统。


背景技术：

2.服务网格是用于微服务应用的可配置基础架构层，把微服务的各个服务(service)节点，用一张网格(mesh)连接起来，使每个服务实例之间的通信流畅、可靠和迅速。随着微服务数量的不断增加，微服务之的调用关系复杂化。
3.每个服务配置全量调用关系的配置，将使数据面的内存开销加大；因此需要一种管理服务间调用关系的同时减少cpu、内存消耗，以及网络带宽的流量治理方法。
4.现有的一种解决方法为：构建两个组件，global proxy和lazyxds controller。global proxy用于接收容器组(pod)的第一次调用请求；lazyxds controller用于根据第一次调用请求，更新服务调用拓扑图后，将配置信息下发给调用的请求方。但随着服务实例的增加，调用关系的复杂化，lazyxds controller的cpu开销也大大增加；而该组件的稳定性，影响了整个微服务集群的运行状态。


技术实现要素：

5.针对现有技术中存在的上述技术问题，本发明提供一种基于ebpf的流量治理方法和系统，基于ebpf获取服务的调用地址，并根据调用地址的类型，进行配置信息的下发，在内核下监听系统调用，有效降低性能开销。
6.本发明公开了一种基于ebpf的流量治理方法，所述方法包括：基于ebpf获取第一服务的调用地址；判断所述调用地址是否包括第二服务的服务地址；若是，向第二服务的调用方下发第二服务的配置信息。
7.优选的，所述第二服务的调用方包括第一服务的第一容器组，所述第一容器组部署有第一代理；
8.将所述第二服务的配置信息下发给第一代理；
9.第一代理用于第一容器组的流量转发，所述配置信息包括第二服务的端点列表。
10.优选的，建立依赖关系的方法：
11.根据第一容器组的配置信息中，建立服务与地址的第一映射；
12.判断所述调用地址是否与第一映射相匹配；
13.若否，根据第一服务的调用地址，建立第一服务和第二服务的依赖关系，所述依赖关系包括第一服务的端点地址、以及第二服务的地址；根据所述依赖关系，向所述调用方下发配置信息。
14.优选的，所述流量治理方法包括：
15.监听服务添加的添加事件；
16.根据所添加的服务及其服务地址的第二映射；
17.判断所述调用地址是否与第二映射相匹配；
18.若是，根据第一服务的调用地址，建立第一服务和第二服务的依赖关系，所述依赖关系包括第一服务的地址、以及第二服务的地址；
19.根据所述依赖关系，向所述调用方下发配置信息。
20.优选的，第二服务配置信息的更新方法包括：
21.若所述配置信息更新或变更，根据依赖关系向调用方推送第二服务的配置信息。
22.优选的，建立第三映射的方法包括：
23.根据第二服务的配置信息，建立第三映射，所述第三映射包括第二服务及其端点地址的映射、第一服务及其端点的映射；
24.根据第三映射和调用地址，获得服务及其端点地址，以及调用地址的类型。
25.优选的，所述流量治理方法包括：
26.基于内核态的ebpf探针拦截第一容器组的流量，获取第一服务的调用地址；
27.根据第二映射中服务地址与服务的映射关系，获取所述调用地址的类型；
28.若所述类型为服务地址，将第一服务和第二服务的依赖关系，保存到第四映射中；
29.在用户态监听所述第四映射；
30.若所述第四映射的依赖关系变化，向网格控制面发送所述变化；
31.所述网格控制面根据所述变化，向第一容器组的第一代理下发第二服务的配置信息；
32.第一代理根据所述配置信息进行流量转发。
33.作为一种变型，基于ebpf的流量治理方法包括：基于ebpf获取第一服务的调用地址；判断所述调用地址是否包括端点地址；若否，向第二服务的调用方下发第二服务的配置信息。
34.本发明还提供一种用于实现上述流量治理方法的系统，其特征在于，包括拦截模块、调用地址分析模块和网格控制面；
35.所述拦截模块用于基于ebpf获取第一服务的调用地址；
36.所述调用地址分析模块用于分析所述调用地址是否包括第二服务的服务地址；若是，通过网格控制面向第二服务的调用方下发第二服务的配置信息。
37.优选的，所述系统还包括控制模块，
38.所述调用地址分析模块用于根据第二映射或第一映射，获得调用地址的类型；若所述类型为服务地址，建立第四映射，所述第四映射包括第一服务和第二服务的依赖关系；
39.所述控制模块用于监听所述第四映射，若发现新的依赖关系，向网格控制面发送报告；
40.所述网格控制面根据所述报告的依赖关系，向第二服务的调用方下发第二服务的配置信息；
41.其中，所述控制模块用于维护第一映射、第二映射或者第三映射；
42.所述调用地址分析模块用于维护第四映射。
43.与现有技术相比，本发明的有益效果为：基于内核态的ebpf获取服务的调用地址，通过对调用地址类型的分析，进行配置信息的下发，有效降低调用关系管理造成的性能开销。
附图说明
44.图1是本发明的基于ebpf流量治理方法流程图；
45.图2是实施例2的方法流程图；
46.图3是实施例3的方法流程图；
47.图4是实施例4的系统逻辑框图。
具体实施方式
48.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
49.下面结合附图对本发明做进一步的详细描述：
50.一种基于ebpf的流量治理方法，如图1所示，所述方法包括：
51.步骤101：基于ebpf获取第一服务的调用地址，执行步骤102或105。
52.步骤102：判断所述调用地址是否包括第二服务的服务地址(service ip)。
53.若是，执行步骤103：向第二服务的调用方下发第二服务的配置信息。
54.其中，所述第二服务的调用方包括第一服务的第一容器组，所述第一容器组部署有第一代理(sidecar)，第一服务运行在第一容器组中；将所述第二服务的配置信息下发给第一代理；第一代理用于第一容器组的流量转发，例如转发到第二服务的具体实例，而每个实例具有不同的端点地址，所述配置信息包括第二服务的端点列表。
55.若否，所述调用地址包括第二服务的端点地址(endpoint)，说明调用方具有第二服务的配置信息，无需更新配置信息。
56.步骤105：判断所述调用地址是否包括端点地址。
57.若否，执行步骤103。
58.若是，说明调用方具有第二服务的配置信息，无需更新配置信息。
59.基于内核态的ebpf获取服务的调用地址，通过对调用地址类型的分析，进行配置信息的下发，有效降低调用关系管理造成的性能开销。
60.本发明的流量治理方法，还可以根据调用地址的类型建立依赖关系。
61.实施例1
62.步骤201：根据第一容器组的配置信息中，建立服务与地址的第一映射。第一映射用于反映已有配置中的服务与地址的关系。
63.步骤202：判断所述调用地址是否与第一映射相匹配。
64.若是，则本地的配置信息中具有相应的调用关系，无需进行配置信息下发操作。
65.若否，执行步骤203：根据第一服务的调用地址，建立第一服务和第二服务的依赖关系，所述依赖关系包括第一服务的地址/端点地址、以及第二服务的地址。
66.步骤204：根据所述依赖关系，向所述调用方下发配置信息。
67.实施例2
68.如图2所示，包括以下步骤：
69.步骤301：监听服务添加的添加事件。可以通过监听服务注册中心，监听添加事件。
70.步骤302：根据所添加的服务及其服务地址的第二映射，例如service map。用于记录服务地址到服务本身的映射，key为服务ip，value为服务id，类型为bpf_map_type_hash。
71.步骤303：判断所述调用地址(目的地址)是否与第二映射相匹配。其中调用地址，可以通过ebpf探针监听代理(sidecar)的发送报文获得。
72.若是，执行步骤304：根据第一服务的调用地址，建立第一服务和第二服务的依赖关系，即第四映射，所述依赖关系包括第一服务的地址、以及第二服务的地址。
73.步骤304：根据所述依赖关系，向所述调用方下发配置信息，执行步骤305或306。
74.第二映射反应了新添加服务及其服务地址的关系，调用地址与第二映射相匹配，说明本地配置中没有该服务的配置信息。
75.步骤305：第二服务配置信息的更新：若所述第二服务的配置信息更新或变更，根据依赖关系向调用方推送第二服务的配置信息。即向调用方推送变更的第二服务配置信息。
76.步骤306：建立第三映射：
77.根据第二服务的配置信息，建立第三映射，例如endpoint map，所述第三映射包括第二服务及其端点地址的映射、第一服务及其端点的映射；
78.根据第三映射和调用地址，可以获得服务及其端点地址，以及调用地址的类型。
79.例如调用地址与第三映射成功匹配，则说明该调用地址的类型为端点地址，本地配置信息中包含该调用地址目的服务的配置信息。
80.实施例3
81.如图3，所述流量治理方法包括：
82.步骤401：基于内核态的ebpf探针拦截第一容器组的流量，获取第一服务的调用地址或目的地址。
83.在初始状态下，第一容器组向网格控制面报告最小依赖关系，即第一代理没有任何其他服务的配置信息，仅需要部分必要信息，如控制面服务的配置信息等。例如，有服务a、b、c，初始状态下服务a的代理配置不包括服务b、c的任何配置信息，服务b和c同样没有其它服务的配置信息。
84.其中，ebpf探针拦截服务(service)调用的connect函数，可以得到调用地址。
85.步骤402：根据第二映射中服务地址与服务的映射关系，获取所述调用地址的类型。第二映射为新添加服务与服务地址的关系；若调用地址与第二映射相匹配，表示该调用地址的类型为服务地址。
86.步骤403：若所述类型为服务地址，将第一服务和第二服务的依赖关系，保存到第四映射中，例如dependency map。用于记录服务间的依赖关系，key为源服务(调用方)ip，value为目的服务(被调用方)ip，类型为perf_event_array。第一映射-第四映射可以部署在ebpf map中。
87.步骤404：在用户态监听所述第四映射。
88.步骤405：若所述第四映射的依赖关系变化，向网格控制面发送所述变化。
89.步骤406：所述网格控制面根据所述变化，向第一容器组的第一代理下发第二服务的配置信息。
90.步骤407：第一代理根据所述配置信息进行流量转发。
91.在一个具体实施例中，在ebpf程序中发现连接的源ip为100.103.244.73，目的ip为10.100.100.5，在第二映射(service map)中找到了调用地址或目的ip，则该调用地址为服务b的地址，则将依赖关系《100.103.244.73，10.100.100.5》添加至第四映射(dependency map)中。在用户态监听到该变化的依赖关系后，向网格控制面报告该变化，从网格控制面报告接收下发的配置信息，实现调用关系的管理。
92.如果在ebpf程序中发现调用地址或目的地址并不在第二映射(service map)中，说明此时连接的目的地址是目标服务的某个端点地址，这代表代理中已经有了目标服务的配置信息。例如，在ebpf程序中发现连接的目的地址为100.103.244.73，在service map中无法匹配到该地址，则说明此配置已下发，无需再做任何动作，直接放行。
93.实施例4
94.本实施例提供一种用于实现上述流量治理方法的系统，如图4，包括拦截模块11、调用地址分析模块12和网格控制面3；
95.拦截模块11用于基于ebpf获取第一服务的调用地址；
96.调用地址分析模块12用于判断所述调用地址是否包括第二服务的服务地址；
97.若是，通过网格控制面3向第二服务的调用方下发第二服务的配置信息。
98.本实施例的系统还包括可以控制模块13，
99.调用地址分析模块12用于根据第二映射或第一映射，获得调用地址的类型，所述类型包括服务地址或端点地址；若所述类型为服务地址，建立第四映射，所述第四映射包括第一服务和第二服务的依赖关系；
100.控制模块13用于监听所述第四映射，若发现新的依赖关系，向网格控制面3发送报告；
101.网格控制面3根据所述报告的依赖关系，向第二服务的调用方下发第二服务的配置信息；
102.其中，控制模块13用于维护第一映射、第二映射或者第三映射，以及监听第四映射；
103.调用地址分析模块12用于维护第四映射。
104.例如，第一容器组、第二容器组和第三容器组分别部署有有服务a、b和c，初始时服务a代理的配置不包括服务b、c的任何配置信息，服务b、c同理。
105.用户态的控制模块(controller)会监听服务a、b、c的添加事件，将服务信息同步至第二映射(service map)，将配置信息中服务对应的端点地址(endpoints)信息同步至第三映射(endpoint map)。还可以根据配置信息中服务地址，删除第二映射中相应的服务地址，实现第二映射的轻量化。
106.当服务a第一次调用服务b时，通过拦截模块11捕捉到调用地址；调用地址分析模块12对调用地址进行分析：若其连接目的地址(服务b的service ip)在第二映射service map中具有相应的匹配，则说明服务a此时没有服务b的配置信息，则将依赖关系a-》b记录到第四映射中(dependency map)中。
107.控制模块13会发现第四映射(dependency map)中添加了一条新的依赖关系(a-》b)，就会向网格控制面3报告相应的依赖关系，之后网格控制面3会按最新的依赖关系(a-》b)，下发配置服务b的配置信息，此时服务a的代理(sidecar)将收到服务b的相关配置。
108.在服务a第二次调用服务b时，由于此时服务a的代理(sidecar)已经有了服务b的配置，其连接的目的地址将不再是服务b的服务地址，而是服务b的某个具体的端点地址(endpoint ip)；调用地址分析模块12无法在第二映射中得到匹配；而在第三映射中可以得到匹配，即判定出调用地址的类型为端点地址。因此无需请求更新配置，直接放行该请求。此过程在内核态完成，几乎没有性能消耗。
109.本发明的流量治理方法和系统，能够根据服务的实际调用关系，实现精准的配置下发，极大地减少网格控制面cpu和内存的消耗，很大程度上缓解了数据面和控制面之间的网络带宽压力，数据面上存储配置的内存开销大幅减小。理想状态下，每个服务只存储它调用的服务的相关配置信息。当服务发生变化时，减少了配置信息(xds配置)推送的范围和次数。ebpf随着linux内核升级而具备新特性，可以很好地兼容原有的服务网格治理功能。避免在微服务网格中部署额外的组件，更新请求由每个分布式容器组执行，尤其在大规则或复杂调用关系的情况下，能够减少调用关系管理的性能开销。
110.以上仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。