运行容器组的节点，容器组的管理系统和方法与流程

1.本技术涉及云计算领域，且特别涉及一种运行容器组的节点，容器组的管理系统和方法。


背景技术：

2.服务网格(service mesh)技术将微服务架构(microservice architecture)的分布式应用中非功能性的针对流量的服务治理逻辑从业务进程中剥离到边车(sidecar)容器中，以无侵入的方式提供服务间的连接、安全、流控、灰度发布、观测能力，实现业务轻量化和服务治理基础设施化。另外，由于服务网格技术是基于传统互联网协议(internet protocol， ip)网络之上的应用网络技术。因此，在服务网格技术中，服务之间的发现与路由不再直接基于ip地址，而是基于服务的元数据信息(包括但不限于服务名称、版本等)。
3.随着用户需求的发展，微服务的规模和调用复杂度快速增长。如何在持续运行阶段高效的治理微服务、降低运维成本，是服务网格技术演进的一个重要问题。


技术实现要素：

4.本技术实施例提供了一种运行容器组的节点，容器组的管理系统和方法，可以为业务容器组选择边车，以对业务容器组进行更优的流量管理。
5.第一方面，本技术实施例提供了一种运行容器组的节点，该节点运行有连接控制模块、边车集群、和第一业务容器组，边车集群包括至少两个边车，其中，连接控制模块，用于接收与该节点相连的控制台发送的边车分配策略，根据边车分配策略在边车集群中选择第一边车，并将第一业务容器组发出的数据包转发至第一边车；第一边车，用于对第一业务容器组发出的数据包进行流量管理。
6.在该方案中，连接控制模块可以按照控制台发送的边车分配策略，从至少两个边车中为第一业务容器选择边车，并使用选择出的边车对第一业务容器组发出的数据包进行流量管理，从而可以实现对第一业务容器组的灵活管理，可以为对第一业务容器组进行更优的流量管理，保障第一业务容器组业务的高可用能力。
7.在一种可能的实现方式中，该节点还包括第二业务容器组；连接控制模块，还用于根据边车分配策略在边车集群中选择第二边车，并将第二业务容器组发出的数据包转发至第二边车；第二边车，用于对第二业务容器组发出的数据包进行流量管理。其中，第二边车和第一边车可以为同一边车冗余，也可以为不同的边车。
8.也就是说，连接控制模块可以按照边车分配策略，从至少两个边车中为第二业务容器选择边车，并使用选择出的边车对第二业务容器组发出的数据包进行流量管理，从而可以实现对第二业务容器组的灵活管理，可以为对第二业务容器组进行更优的流量管理，保障第二业务容器组的业务的高可用能力。
9.在一种可能的实现方式中，第一边车分配的硬件资源规格高于第二边车分配的硬件资源，边车分配策略包括第一策略，第一策略用于指示第一业务容器组优先使用第一边
车；连接控制模块，具体用于根据第一策略在边车集群中选择第一边车。
10.也就是说，在该实现方式中，可以设置硬件资源规格高低不同的硬件资源，并在边车分配策略指示第一业务容器组优先使用高硬件资源规格的边车的情况下，使用高硬件资源规格的边车对第一业务容器组发出的数据包进行流量管理，保障了第一业务容器组业务的服务质量。
11.在一种可能的实现方式中，该节点还包括第二业务容器组，边车分配策略还包括第二策略，第二策略用于指示第一边车的服务对象数量不超过上限值；连接控制模块，还用于确定第一边车的服务对象的数量，在第一边车的服务对象的数量不超过上限值的情况下将第二业务容器组发出的数据包转发至第一边车；第一边车，还用于对第一业务容器组发出的数据包和第二业务容器组发出的数据包同时进行流量管理。
12.也就是说，在该实现方式中，可以设置边车的服务对象数量的上限值，并在该边车当前的服务对象的数量不超过上限值的情况下，继续为该边车分配数据包，使得该边车对该数据包进行流量管理，从而在避免边车过载的同时，提高了边车的资源利用率。
13.在一种可能的实现方式中，连接控制模块，用于在第一边车失效后，从边车集群中选择第三边车或通知控制台在所述节点创建第三边车，将第一业务容器组发送的另一数据包转发至第三边车；第三边车，用于对第一业务容器组发出的另一数据包进行流量管理。
14.也就是说，在该实现方式中，第一边车失效后，可以重新为第一业务容器组选择第三边车，第三边车可以继续对第一业务容器组发出的数据包进行流量管理，从而保障了第一业务容器组业务的高可用能力。
15.在一种可能的实现方式中，第三边车是基于第一边车进行功能升级的新版本，或者第三边车是第一边车的复制版本。
16.也就是说，在该实现方式中，在第一边车失效后，可以为第一业务容器组选择与第一边车的功能相同的边车，或者选择比第一边车更高级的边车，以继续对第一业务容器组发出的数据包进行流量管理，从而保障了第一业务容器组业务的高可用能力。
17.在一种可能的实现方式中，第一边车，用于在对第一业务容器组发出的数据包进行流量管理之后，将数据包发送至后端容器组。
18.也就是说，在该实现方式中，第一边车可以将经过流量管理后的数据包发送至后端容器组，以调用后端容器组的服务或为后端容器组提供服务。
19.在一种可能的实现方式中，第一边车，还用于产生会话标识并发送会话标识至第一业务容器组和连接控制模块；连接控制模块，用于记录会话标识与后端容器组的对应关系；第三边车，用于从第一业务容器组获取会话标识并根据会话标识在连接控制模块记录的对应关系中确定后端容器组，在对第一业务容器组发出的另一数据包进行流量管理之后，将另一数据包发送至后端容器组。
20.也就是说，在该实现方式中，连接控制模块可以记录第一边车产生的会话标识和后端容器组的对应关系，第三边车可以根据该对应关系，将第一容器组发出的其他数据包进行流量管理后发送至该后端容器组，从而避免了同一容器组发出的不同数据包被不同边车发送至不同后端容器组的问题。
21.在一种可能的实现方式中，边车分配策略包括第三策略，第三策略用于指示边车集群中的边车的服务对象数量为0时被优先使用；连接控制模块，还用于确定第一边车的服
务对象的数量，在第一边车的服务对象的数量为0的情况下将第一业务容器组发出的数据包转发至第一边车。
22.在一种可能的实现方式中，连接控制模块，还用于监控边车集群中每个边车的工作状态，在发现存在下线的边车时，发送下线的边车的信息至控制台。
23.也就是说，在该实现方式中，可以向控制台反馈下行的边车，以便控制台更新正在运行的边车，并据此制定边车分配策略，实现对容器组的有效管理。
24.在一种可能的实现方式中，流量管理包括：流量控制、流量安全以及流量观测。
25.在一种可能的实现方式中，节点为虚拟机、计算机或裸金属服务器。
26.第二方面，本技术实施例提供了一种容器组的管理系统，包括控制台和第一方面所提供的节点。
27.第三方面，本技术实施例提供了一种节点中的容器组的管理方法，节点运行有连接控制模块、边车集群、和第一业务容器组，边车集群包括至少两个边车，该方法包括：连接控制模块接收与节点相连的控制台发送的边车分配策略，根据边车分配策略在边车集群中选择第一边车，并将第一业务容器组发出的数据包转发至第一边车；第一边车对第一业务容器组发出的数据包进行流量管理。
28.在一种可能的实现方式中，节点还运行有第二业务容器组，该方法还包括：连接控制模块根据边车分配策略在边车集群中选择第二边车，并将第二业务容器组发出的数据包转发至第二边车；第二边车对所述第二业务容器组发出的数据包进行流量管理。
29.在一种可能的实现方式中，第一边车分配的硬件资源规格高于第二边车分配的硬件资源，边车分配策略包括第一策略，第一策略用于指示第一业务容器组优先使用第一边车；根据边车分配策略在边车集群中选择第一边车包括：根据第一策略在边车集群中选择第一边车。
30.在一种可能的实现方式中，节点还运行有第二业务容器组，边车分配策略还包括第二策略，第二策略用于指示第一边车的服务对象数量不超过上限值；方法还包括：连接控制模块确定第一边车的服务对象的数量，在数量不超过上限值的情况下将第二业务容器组发出的数据包转发至第一边车；第一边车对第一业务容器组发出的数据包和第二业务容器组发出的数据包同时进行流量管理。
31.在一种可能的实现方式中，该方法还包括：连接控制模块，在第一边车失效后，从边车集群中选择第三边车或通知控制台在节点创建第三边车，将第一业务容器组发送的另一数据包转发至第三边车；第三边车对第一业务容器组发出的另一数据包进行流量管理。
32.在一种可能的实现方式中，第三边车是基于第一边车进行功能升级的新版本，或者第三边车是第一边车的复制版本。
33.在一种可能的实现方式中，该方法还包括：第一边车在对第一业务容器组发出的数据包进行流量管理之后，将数据包发送至后端容器组。
34.在一种可能的实现方式中，该方法还包括：第一边车产生会话标识并发送会话标识至第一业务容器组和连接控制模块；连接控制模块记录会话标识与后端容器组的对应关系；第三边车从第一业务容器组获取会话标识并根据会话标识在连接控制模块记录的对应关系中确定后端容器组，在对第一业务容器组发出的另一数据包进行流量管理之后，将另一数据包发送至后端容器组。
35.在一种可能的实现方式中，边车分配策略包括第三策略，第三策略用于指示边车集群中的边车的服务对象数量为0时被优先使用；根据边车分配策略在边车集群中选择第一边车，并将第一业务容器组发出的数据包转发至第一边车包括：连接控制模块确定第一边车的服务对象的数量，在第一边车的服务对象的数量为0的情况下将所述第一业务容器组发出的数据包转发至所述第一边车。
36.在一种可能的实现方式中，该方法还包括：连接控制模块监控边车集群中每个边车的工作状态，在发现存在下线的边车时，发送下线的边车的信息至控制台。
37.在一种可能的实现方式中，流量管理包括：流量控制、流量安全以及流量观测。
38.第四方面，本技术实施例提供了一种运行容器组的节点，包括处理器和存储器，处理器用于执行存储器中存储的指令，以执行第二方面所提供的方法。
39.第五方面，本技术实施例提供了一种计算机可读存储介质，包括计算机程序指令，当计算机程序指令由计算设备集群执行时，计算设备集群执行如第一方面所提供的方法。
40.第六方面，本技术实施例提供了一种包含指令的计算机程序产品，当指令被计算机设备集群运行时，使得计算机设备集群执行如第一方面所提供的方法。
41.本技术实施例提供的运行容器组的节点，容器组的管理系统和方法，可以按照控制台发送的边车分配策略，从至少两个边车中为业务容器选择边车，并使用选择出的边车对该业务容器组发出的数据包进行流量管理，从而可以实现对该业务容器组的灵活管理，可以为对该业务容器组进行更优的流量管理，保障该业务容器组业务的高可用能力。
附图说明
42.图1为本技术实施例提供的一种容器组的管理系统的结构示意图；
43.图2为本技术实施例提供的一种运行容器组的节点的结构示意图；
44.图3a为本技术实施例提供的一种容器组管理框架示意图；
45.图3b为本技术实施例提供的一种容器组管理方法流程图；
46.图4a为本技术实施例提供的一种容器组管理框架示意图；
47.图4b为本技术实施例提供的一种容器组管理方法流程图；
48.图5a为本技术实施例提供的一种容器组管理框架示意图；
49.图5b为本技术实施例提供的一种容器组管理框架示意图；
50.图5c为本技术实施例提供的一种容器组管理方法流程图；
51.图6a为本技术实施例提供的一种容器组管理框架示意图；
52.图6b为本技术实施例提供的一种容器组管理框架示意图；
53.图6c为本技术实施例提供的一种容器组管理方法流程图；
54.图7为本技术实施例提供的一种容器组管理方法流程图；
55.图8为本技术实施例提供的一种节点的示意性框图。
具体实施方式
56.下面将结合附图，对本发明实施例中的技术方案进行描述。显然，所描述的实施例仅是本说明书一部分实施例，而不是全部的实施例。
57.在本说明书的描述中“一个实施例”或“一些实施例”等意味着在本说明书的一个
或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。
58.其中，在本说明书的描述中，除非另有说明，“/”表示或的意思，例如，a/b可以表示a 或b；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，在本说明书实施例的描述中，“多个”是指两个或多于两个。
59.在本说明书的描述中，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
60.微服务架构为一种面向服务的架构(service oriented architecture，soa)，其将复杂系统切分为多个小服务或者说应用。可以将该小服务或者说应用称为微服务。每个微服务负责实现一个独立的业务逻辑。微服务是围绕业务功能进行构建的，可以独立部署。微服务之间通过相互依赖，从而可以提供一系列的功能。微服务易于被理解和修改，带来了语言和框架选择灵活性。微服务可以运行在容器(container)中。其中，多个相互之间依赖性较高的容器可以构成一个容器组。例如，在k8s(kubernetes)系统中，多个容器可以封装到一个 pod中，即容器组为pod。
61.在本技术实施例中，运行微服务的容器可称为业务容器。边车可通过容器或进程实现，在边车通过容器实现时，边车又可称为边车容器。
62.在微服务架构中，服务治理也称soa治理(service oriented architecture governance， soa governance)，是用来管理微服务架构的采用和实现的过程。在基于微服务架构的服务网格中，服务治理可由边车执行。其中，在k8s(kubernetes)系统中，边车是设置有边车功能的容器，边车为业务容器提供流量服务治理功能。
63.在一个方案中，部署pod级别的边车。即，每个pod对应一个边车，该边车用于对该pod 进行服务治理。在该方案中，不同的边车对应不同的pod。一个边车的故障，仅影响该边车对应的pod，而不影响其他pod。可以说，该方案有助于保障业务的高可用能力。但在该方案中，若部署的pod的数量较多，部署的边车也较多，使得边车所占用的计算资源是不可忽略的，可能会导致链路时延大等问题。
64.在另一个方案中，部署节点级别的边车。即一个节点部署一个边车，用于对该节点上的多个pod进行服务治理。在该方案中，边车的故障，会影响节点上的多个pod，从而对业务的高可用能力造成较大影响。
65.针对以上技术问题，本技术实施例提供了一种容器组的管理系统，如图1所示，该管理系统可以包括节点100、节点200等多个节点，还可以包括与该多个节点相连的控制台300。控制台300可以管理该多个节点，例如可以向多个节点中的任一节点发送边车分配策略，使得该节点可以根据边车分配策略为该节点中的业务容器组分配边车，以便对该业务容器组发出的数据包进行更优的流量管理，实现业务的高可用能力。
66.在一些实施例中，分配策略可以是节点所在数据中心的管理人员或租户在控制台
300配置的，由此，可以实现对容器组的灵活管理。
67.接下来，以节点100为例，对本技术实施例涉及的图1所示管理系统中的节点进行示例介绍。
68.在一些实施例中，节点100可以为虚拟机(virtual machine，vm)。
69.在一些实施例中，节点100可以具有多种硬件组件，例如一个或多个处理器(例如中央处理单元(central processing unit，cpu))、一个或多个存储器等。节点100所具有的硬件组件可以赋予节点100数据计算以及数据存储能力。在一个例子中，节点100可以为计算机。在另一个例子中，节点100可以为裸金属服务器。
70.参阅图2，节点100可以运行有连接控制模块110、边车集群120以及业务容器组集群 130。其中，边车集群120可以包括边车121、边车122、边车123等至少两个边车。示例性的，边车又称为sidecar。业务容器组集群130可以包括业务容器组131。业务容器组131可以包括一个或多个容器，其中每个容器可以运行有应用或者微服务。连接控制模块110可以接收控制台200发送的边车分配策略a。在业务容器组131具有流量管理需求时，连接控制模块110可以根据该分配策略a在边车集群120中为业务容器组131选择边车，例如可以选择边车121。之后，连接控制模块110可以将业务容器组131发出的数据包转发至边车121。边车121可以对该数据包进行流量管理。
71.在一个例子中，流量管理具体可以为流量控制。其中，流量控制可以包括流量通过、流量拒绝、流量复制以及流量染色中的任一项或任意多项的组合。在一个例子中，流量管理具体可以为流量安全。其中，流量安全可以包括对数据包进行加密或解密等。在一个例子中，流量管理具体可以为流量观测。其中，流量观测可以包括在控制台300中绘制调用链等。
72.在一些实施例中，连接控制模块可以配置有边车列表。数据面代理列表可以包括处于运行状态的边车的信息。边车的信息可以包括边车的标识(例如，进程身份标识(identity， id))、边车的监听端口。其中，边车的监听端口也可以称为边车的入方向端口。通过边车121 的监听端口，业务容器组131发出的数据包可以被发送到边车121，从而使得边车121可以对该数据包进行流量治理。
73.在一些实施例中，边车121分配的硬件资源规格高于边车122分配的硬件资源，边车分配策略a包括策略a1，策略a1用于指示业务容器组131优先使用边车121；由此，连接控制模块110可以根据策略a1在边车集群120中选择边车121，使得边车121对容器组131发出的数据包进行服务治理(即流量管理)。该实施例具体实现过程将在下文实施例2中进行具体介绍，在此不再赘述。
74.在一些实施例中，继续参阅图2，业务容器组集群130还可以包括业务容器组132。在业务容器组132具有流量管理需求时，连接控制模块110还可以根据分配策略a，在边车集群 120中选择边车122，并将业务容器组132发出的数据包转发至边车122。之后，边车122可以对该数据包进行流量管理。
75.在一些实施例中，边车集群120中的同一个边车可以同时对多个业务容器组发出的数据包进行流量管理。例如，可以设定业务容器组集群130还可以包括业务容器组132。边车分配策略a还包括策略a2，策略a2可以用于指示边车的服务对象数量不超过上限值。边车的服务对象是指接受业务容器组的流量管理服务的业务容器组。也就是说，若边车对业务
容器组发出的数据包进行流量管理，那么该业务容器组是该边车的服务对象。边车的上限值是指边车在同一时刻，能够进行流量管理的业务容器组的最大数量。其中，连接控制模块可以确定边车121的服务对象的数量，并在边车121的服务对象的数量不超过边车121上限值的情况下，将业务容器组132发出的数据包转发至边车121。之后，边车121可以对业务容器组 131发出的数据包和业务容器组132发出的数据包同时进行流量管理。
76.在一些实施例中，在边车失效后，例如边车发生崩溃(crash)或重启后，可以为该边车的服务对象重新选择边车，以便新选择的边车继续对失效的边车的服务对象继续进行流量管理。仍以边车121为例，如上所述，边车121失效前可以对业务容器组131发出的数据包进行流量管理。当边车121失效后，连接控制模块110可以为业务容器组131重新确定边车。重新确定的边车可以对业务容器组131发出数据包进行流量管理。示例性的，为业务容器组 131重新确定边车，具体可以为连接控制模块110从边车集群120中重新选择为业务容器组 131的数据包进行流量管理的边车。例如，可以设定边车集群120包括边车123，连接控制模块110从边车集群120中选择边车123，使边车123对业务容器组131发出的数据包进行流量管理。具体而言，可以将业务容器组131发出的数据包发送至边车123，使得边车123对该数据包进行流量管理。示例性的，为业务容器组131重新确定边车，具体可以为连接控制模块通过控制台300在节点100中创建边车123，然后，将业务容器组1131发出的数据包发送至边车123，使得边车123可以对该数据包进行流量管理。其中，在节点100中创建边车 123的具体过程将在下文的实施例1中进行具体介绍，在此不再赘述。
77.在一些实施例中，边车123可以在边车121的基础上进行功能升级的新版本边车。其中，边车的版本升级过程将在下文进行具体介绍，在此不再赘述。
78.在一些实施例中，边车123是边车121的复制版本。也就是说，控制台300可以再次在节点100中创建功能与边车121相同的边车。
79.在一些实施例中，边车121在对业务容器组131发出的数据包进行流量管理之后，将数据包发送至后端容器组。在一个例子中，后端容器组可以是其他节点，例如节点200，上的业务容器组。在一个例子中，后端容器组可以是节点100上的除业务容器组131之外的其他业务容器组。
80.在这些实施例的一个示例中，边车121还可以产生会话标识，并将该会话标识发送至业务容器组131和连接控制模块110。该会话标识可以是指业务容器组131和后端容器组之间的会话标识。连接控制模块110可以记录会话标识与后端容器组的对应关系。边车123在对业务容器组131发出的数据包进行流量管理时，可以从业务容器组131获取该会话标识，然后可以根据会话标识与后端容器组的对应关系以及从业务容器组131获取的会话标识，确定后端容器组，从而在边车123对业务容器组131发送的新的数据包进行流量管理之后，将新的数据包发送至后端容器组。其中，新的数据包可以是指在边车123根据会话标识与后端容器组的对应关系以及从业务容器组131获取的会话标识，确定后端容器组之后，业务容器组 131发送的数据包。具体将在下文实施例4中进行具体介绍，在此不再赘述。
81.在一些实施例中，边车分配策略a可以包括策略a3，策略a3用于指示边车集群120中的边车的服务对象数量为0时被优先使用。连接控制模块110可以确定边车121的服务对象的数量，并且在边车121的服务对象的数量为0的情况下将业务容器组131发出的数据包转发至边车121。其中，服务对象是指边车所服务的业务容器组，具体可以参考下文对实施
例2介绍的内容实现，在此不再赘述。
82.在一些实施例中，连接控制模块110还用于监控边车集群120中每个边车的工作状态，在发现存在下线的边车时，发送下线的边车的信息至控制台300。具体将在下文实施例1中进行具体介绍，在此不再赘述。
83.本技术实施例提供的节点可以运行多个边车，并根据分配策略，在多个边车中为业务容器组选择边车，然后，利用选择出的边车对业务容器组发出的数据包进行流量管理，从而可以对业务容器组的数据包进行更优的流量管理，可实现业务的高可用能力。
84.接下来，在具体实施例中，对本技术实施例提供的节点以及容器组管理方案进行具体说明。
85.实施例1
86.参阅图3a，本实施例提供了一种节点100，其可以运行有业务容器组集群130，包括业务容器组131、业务容器组132等多个业务容器组。节点100还运行有sidecar集群120，包括sidecar121、sidecar122、sidecar123等多个sidecar。示例性的，该多个sidecar中每个sidecar可以绑定不同的硬件资源，例如可以绑定一个或多个中央处理器(centralprocessingunit，cpu)，还可以绑定其他计算模块(例如专门用于加密解密的硬件、图形处理器(graphicsprocessingunit，gpu)等)。节点100还运行有连接管理模块110。示例性的，连接管理模块110可以包括协议栈111和sidecar启动管理器112。
87.微服务节点100可以接入网络，该网络可以包括后端容器组210、后端容器组220等多个后端容器组。在一个示例中，后端容器组可以运行于指该网络中除节点100之外的其他节点。在另一个示例中，后端容器组可以运行于节点100。节点100中的业务容器组所发出的数据包在经过sidecar的流量管理后，可以发送到后端容器组，以调用后端容器组的服务或者为后端容器组提供服务。
88.其中，该网络还可以包括控制台300。其中，控制台300可以接收管理人员或者说运维人员的操作，并响应该操作对网络中的节点100以及其他节点进行控制。例如，控制台300可以向sidecar发送服务列表，以进行服务列表同步，使得sidecar可以根据服务列表进行流量管理。再例如，控制台300可以向连接管理模块110发送边车分配策略a，以便连接管理模块110根据边车分配策略a，在sidecar集群中为业务容器组选择sidecar。选择出的sidecar对业务容器组发出的数据包进行流量管理。
89.连接管理模块110可以采用多活方式管理节点100中的多个sidecar。即该多个sidecar可以同时处于运行状态或者说工作状态。
90.示例性的，同一sidecar可以为同时为多个业务容器组的链路提供流量管理。在一个例子中，如图3a所示，sidecar121可以同时为链路1311、链路1312以及链路1321提供流量管理。其中，链路1311和链路1312是源自业务容器组131的链路，链路1321是源自业务容器组132的链路。
91.示例性的，不同sidecar可以同时为同一业务容器组的不同链路提供流量管理。在一个例子中，如图3a所示，sidecar121可以为源自业务容器组132的链路1321提供流量管理。sidecar123可以为源自业务容器组132的链路1322提供流量管理。
92.其中，在本实施例中，为业务容器组的链路提供流量管理具体可以是指为业务容器组通过该链路发送的数据包提供流量管理。例如，对该数据包进流量控制、流量安全、流
sidecar列表中任一sidecar的当前连接业务容器组。可以根据sidecar列表中各sidecar 的当前连接数，确定当前连接数最少的sidecar。可以设定sidecar列表中的sidecarb2的当前连接数最少。可以将sidecarb2分配给连接请求p1。sidecarb2在接收到连接请求p1时，根据基于连接请求p1，在sidecarb2和业务容器组p之间再建立一条链路。业务容器组p可以通过该链路向sidecarb2发送数据包。sidecarb2接收到该数据包后，可以对该数据包进行流量管理。
103.在一个说明性示例中，协议栈111在接收到连接请求p1时，可以判断sidecar列表中是否存在新版本的sidecar。具体而言，可以判断sidecar列表中的所有sidecar的版本是否相同。若sidecar列表中一个或多个sidecar的版本高于其他sidecar的版本，那么可以确定该一个或多个sidecar为新版本的sidecar。若sidecar列表中所有sidecar的版本均相同，那么可以确定sidecar列表中不存在新版本的sidecar。
104.当sidecar列表中存在新版本的sidecar时，可以将新版本的sidecar分配给连接请求 p1。新版本的sidecar在接收到连接请求p1时，根据基于连接请求p1，在新版本的sidecar 和业务容器组p之间再建立一条链路。业务容器组p可以通过该链路向新版本的sidecar发送数据包。新版本的sidecar接收到该数据包后，可以对该数据包进行流量管理。
105.在一个说明性示例中，可以对节点100中的sidecar进行热升级。即可以在用户不感知的情况下，完成sidecar的升级。
106.接下来，结合图3b，对实施例1提供的sidecar分配方案以及sidecar升级方案，进行更具体地说明。
107.运维人员可以在控制台300配置sidecar创建信息，用于在节点100中创建新的sidecar。其中，sidecar创建信息可以包括版本信息、硬件资源信息。
108.sidecar创建信息还可以包括被替换sidecar的信息，用于指示新创建的sidecar用于替换节点100中的哪些sidecar。其中，被替换sidecar可以是节点100中已处于运行状态的sidecar。被替换sidecar的信息可以包括被替换sidecar的标识以及被替换sidecar的剩余运行时长等。示例性的，当被替换sidecar有多个时，可以为不同的被替换sidecar设置不同的剩余运行时长，以防止或缓解多个被替换sidecar同时下线而导致的连接请求突增的问题。另外，当sidecar创建信息包括被替换sidecar的信息时，该sidecar创建信息也可以称为sidecar升级信息，即该sidecar创建信息可用于升级sidecar。
109.经过上述配置后，控制台300可以执行步骤401，向sidecar启动管理器111321发送 sidecar创建信息。
110.sidecar启动管理器112可以基于sidecar创建信息，创建新的sidecar。当sidecar创建信息包括版本信息时，sidecar启动管理器112创建符合版本信息的sidecar。即创建的新的sidecar的版本符合该版本信息。在创建sidecar的过程中，sidecar启动管理器112还可以执行步骤402，为新的sidecar分配监听端口。示例性的，sidecar启动管理器112可以根据节点100中监听端口的占用情况，为新的sidecar分配监听端口。在分配监听端口时，可以将监听端口号分配给新的sidecar，以完成监听端口的分配。sidecar启动管理器112可以执行步骤403，启动新的sidecar。如此，在sidecar侧创建了新的sidecar。
111.新的sidecar可以执行步骤404，新的sidecar可以进行初始化，进入运行状态。
112.在新的sidecar执行了步骤404之后，sidecar启动管理器112可以执行步骤407，更
新 sidecar列表，并将更新后的sidecar列表发送至协议栈111。其中，更新sidecar列表包括：将新的sidecar的信息(例如监听端口、版本信息、当前连接数、当前连接业务容器组的标识、硬件资源信息等信息)添加到sidecar列表中。示例性的，sidecar启动管理器112可以更新后的sidecar列表可以携带在ebpf(extendedbpf)map中，然后，向协议栈111发送ebpf map，从而将更新后的sidecar列表发送至协议栈111。
113.在一些实施例中，在新的sidecar执行了步骤404之后，sidecar启动管理器112可以执行步骤406，监听sidecar的运行状态。在一些实施例中，sidecar启动管理器112可以建立其和sidecar之间的域套接字(domain socket)长连接，并通过域套接字长连接监听sidecar 的运行状态。并根据监听到的结果，执行步骤407以及执行步骤408。其中，在步骤408，sidecar 启动管理器112可以向控制台300发送sidecar更新信息，其中包括新的sidecar的运行状态以及标识信息等。
114.另外，当sidecar创建信息包括被替换sidecar的信息时，在步骤404，新的sidecar 在步骤404中，还可以启动域套接字(domain socket)监听。并且，新的sidecar还可以执行步骤405，新的sidecar通过域套接字连接被替换sidecar。新的sidecar可以通过其和被替换sidecar之间的域套接字，监听被替换sidecar的运行状态，并向被替换sidecar发送下线指令，以指示被替换sidecar下线。其中，当被替换sidecar的信息包括被替换sidecar 的剩余运行时长时，新的sidecar在完成初始化后开始计时，当计时达到剩余运行时长时，新的sidecar可以执行步骤409，将被替换sidecar下线。具体而言，新的sidecar可以通过其和被替换sidecar之间的域套接字，向被替换sidecar发送下线指令。被替换sidecar 可以响应该指令而下线。
115.另外，可以理解，节点100中的一个或多个sidecar可能会执行步骤410，发生崩溃(crash) 或重启。其中，为方便描述，可以将sidecar的崩溃或重启，统称下线。
116.sidecar的下线可以导致sidecar和业务容器组之间的链路断开，以及导致sidecar和 sidecar启动管理器112之间的域套接字断开。即在步骤411中，下线的sidecar和业务容器组之间的链路断开。在步骤412中，下线的sidecar和启动管理器112之间的域套接字断开。当下线的sidecar和数据面启动管理器112之间的域套接字断开时，sidecar启动管理器112可以确认sidecar下线，进而执行步骤413，向控制台300发送sidecar更新信息，其中包括下线的sidecar的标识信息等。
117.sidecar启动管理器112在确认sidecar下线时，还可以执行步骤414，更新sidecar列表，并将更新后的sidecar列表发送至协议栈111。其中，更新sidecar列表可以包括将下线的sidecar从sidecar列表中删除或者列为不运行状态。在一些实施例中，协议栈111可以执行步骤415，清理下线sidecar的连接信息。该连接信息可以包括下线sidecar历史连接的业务容器组等信息。
118.当业务容器组和sidecar之间的链路断开(例如，因sidecar的下线而断开)时，业务容器组可以产生连接请求，以再次请求连接sidecar。具体而言，业务容器组可以在步骤416 中，向协议栈111发送连接请求。为方便描述，可以将发出连接请求的业务容器组称为待连接业务容器组。协议栈111在接收到连接请求之后，可以执行步骤417，为待连接业务容器组选择sidecar。
119.在一些实施例中，可以通过如下规则，选择sidecar。
120.首先，判断sidecar列表中是否有存在新版本的sidecar。具体而言，可以判断sidecar 列表中的所有sidecar的版本是否相同。若sidecar列表中一个或多个sidecar的版本高于其他sidecar的版本，那么可以确定该一个或多个sidecar为新版本的sidecar。当sidecar 列表中存在新版本的sidecar时，可以将新版本的sidecar作为选择的sidecar。
121.当sidecar列表中不存在新版本的sidecar时，可以判断待连接业务容器组和sidecar 列表中的sidecar之间是否已经存在了一条或多条链路。若待连接业务容器组和sidecar列表中的sidecarb1之间已经存在了一条或多条链路。那么可以将sidecarb1作为选择的 sidecar。
122.若待连接业务容器组和sidecar列表中的sidecar之间不存在链路，那么可以从sidecar 列表中确定当前连接数最少的sidecar。并将当前连接数最少的sidecar作为选择的sidecar。
123.通过上述规则，在选择出sidecar之后，协议栈111可以执行步骤418，将连接请求发送给选择的sidecar，以便在该sidecar和待连接业务容器组之间创建链路，使得该sidecar 可以对业务容器组通过该链路发送的数据包进行流量管理。
124.在另一些实施例中，可以通过图2所示实施例所提供的规则，选择sidecar。
125.实施例1提供的节点可以支持sidecar的多实例运行，并可通过连接数对每个可用 sidecar实例进行负载均衡。该节点还可以支持动态扩充sidecar实例及对已有实例热升级，新连接优先使用热升级后的sidecar，并控制被替换sidecar的下线时间窗口，降低瞬间连接切换导致的连接队列堆积问题。并且，在该节点中，协议栈与sidecar启动管理器可以自动管理每个sidecar的监听端口，当sidecar因本身问题导致的宕机时，该sidecar连接的业务容器组将被重新定位到其他可用sidecar上，无需人工干预，提升系统整体可用性。
126.实施例2
127.本技术实施例提供了一种节点100，其运行有sidecar集群120，可以包括多种类型的 sidecar，其中，不同类型的sidecar的性能高低不同。可以设定sidecar集群120包括 sidecar121和sidecar122，其中，sidecar121为高性能sidecar，sidecar122为低性能 sidecar。
128.高性能sidecar的性能高于普通sidecar的性能。具体而言，相对于普通sidecar，高性能sidecar配置了更多的硬件资源，例如可以配置有更多数量的cpu，也可以配置有加速硬件，等等。也就是说，高性能sidecar分配的硬件资源高于普通性能sidecar。由此，高性能sidecar比普通sidecar具有更强大的数据处理能力。当高性能sidecar为业务容器组的链路提供流量管理时，可以保障该业务容器组的服务质量(quality of service，qos)。因此，对于具有服务质量要求的业务容器组，可以在其和高性能sidecar之间创建链路，使得高性能sidecar可以为该链路提供流量管理，以保障该业务容器组的服务质量。
129.运维人员可以通过控制台300配置优先级列表，优先级列表可以包括多种类型的连接请求。其中，不同类型的连接请求对应不同类型的sidecar。例如，节点100设置有高性能sidecar 和普通sidecar。优先级列表可以包括第一类型的连接请求和第二类型的连接请求。其中，第一类型的连接请求对应高性能sidecar，第二类型的连接请求对应普通性能sidecar。
130.在一个例子中，每一类型的连接请求可以对应至少一种业务容器组标签(label)。
不同类型的连接请求对应不同的业务容器组标签。也就是说，每一类型的连接请求可以通过业务容器组标签来表征。业务容器组标签用于表示一种类型的业务容器组。其中，当业务容器组为pod时，业务容器组标签为pod label。优先级列表记录了连接请求对应的业务容器组标签和sidecar类型的对应关系。例如，一类型的连接请求对应业务容器组标签q1和业务容器组标签q2，并且该类型的连接请求对应高性能sidecar。那么，优先级记录列表可以记录业务容器组标签q1和高性能sidecar的对应关系，也记录了业务容器组标签q2和高性能 sidecar的对应关系。
131.在一个例子中，每一类型的连接请求可以对应至少一种服务类型。不同类型的连接请求对应不同的服务类型。也就是说，每一类型的连接请求可以通过服务类型来表征。优先级列表记录了连接请求对应的服务类型和sidecar类型的对应关系。例如，一类型的连接请求对应服务类型s，并且该类型的连接请求对应高性能sidecar。那么，优先级记录列表可以记录服务类型s和高性能sidecar的对应关系。
132.参阅图4a，节点100还运行有连接控制模块110。连接控制模块110可以包括协议栈111 和控制面代理113。
133.参阅图4a，控制台300可以将配置的优先级列表发送至控制面代理113。控制面代理113 可以保存该优先级列表，以及将优先级列表发送至协议栈111。示例性的，控制面代理可以通过ebpf map将优先级列表发送至协议栈111。
134.协议栈111还配置有sidecar列表，该sidecar列表记录有节点100的sidecar的类型、 sidecar监听端口等信息。其中，sidecar列表的获取以及更新方式可以参考上文对实施例1 的介绍。其中，与实施例1不同的是，在实施例2中可以预先配置sidecar标识和sidecar 类型的对应关系。由此，协议栈111可以根据sidecar标识和sidecar类型的对应关系，将 sidecar的类型记录到sidecar列表中。
135.协议栈111还可以配置有业务容器组标签和业务容器组标识的对应关系。在一个例子中，业务容器组标识可以为cgroup.ns(control group namespace)。其中，业务容器组标识用于表示一个业务容器组，业务容器组标签用于表示一种类型的业务容器组。也就是说，多个业务容器组具有多个业务容器组标识，其中，多个业务容器组和多个业务容器组标识一一对应。当该多个业务容器组为同一类型的业务容器组时，该多个业务容器组的业务容器组标签相同。其中，业务容器组标签与业务容器组标识的对应关系的确定方式将在下文对图4b所示实施例的介绍，在此不再赘述。
136.在一个说明性示例中，优先级列表记录了业务容器组标签和sidecar类型的对应关系。当协议栈111接收到业务容器组，例如业务容器组131，发送的连接请求时，协议栈111可以根据该连接请求的源地址(例如源ip地址)，确定业务容器组131的业务容器组标识。然后，可以根据业务容器组131的业务容器组标识，以及业务容器组标签和业务容器组标识的对应关系，确定业务容器组131的业务容器组标签。在确定业务容器组131的业务容器组标签后，可以根据优先级列表，确定业务容器组131的业务容器组标签对应的sidecar类型。然后，协议栈111将该连接请求发送至确定出的sidecar类型的数据代理。例如，可以设定业务容器组131的业务容器组标签对应的sidecar类型为高性能sidecar，则协议栈111可以将来自业务容器组131的连接请求发送至高性能sidecar。使得高性能sidecar为来自业务容器组131的数据包提供流量管理。
137.在一个说明性示例中，优先级列表记录了服务类型和sidecar类型的对应关系。当协议栈111接收到业务容器组，例如业务容器组132，发送的连接请求时，协议栈111可以确定该连接请求的目标服务。然后，可以根据该目标服务的服务类型以及优先级列表，确定该目标服务对应的sidecar类型。然后，协议栈111可以将该连接请求发送至确定出的sidecar 类型的数据代理。例如，可以设定业务容器组132发送的连接请求的目标服务对应的sidecar 类型为普通能sidecar，则协议栈111可以将来自业务容器组132的连接请求发送至普通性能sidecar。使得普通性能sidecar为来自业务容器组132的数据包提供流量管理。
138.接下来，结合图4b，对实施例2提供的方案进行更具体地说明。
139.参阅图4b，节点100中的业务容器组监听模块(例如，pod监听模块(monitor))可以通过步骤501对业务容器组创建模块进行监听，以监听业务容器组创建。示例性的，业务容器组创建模块具体可以为kubelet。业务容器组创建模块在步骤502中，可以创建业务容器组。如此，业务容器组监听模块通过步骤503，可以检测到业务容器组创建事件。通过业务容器组创建事件，业务容器组监听模块可以获取创建的业务容器组的业务容器组标识和业务容器组标签。之后，业务容器组监听模块可以执行步骤504，建立业务容器组标签和业务容器组标识的对应关系。业务容器组监听模块可以通过步骤505，将业务容器组标签和业务容器组标识的对应关系发送至协议栈111。示例性的，业务容器组监控模块可以通过ebpf map 将业务容器组标签和业务容器组标识的对应关系发送至协议栈111。
140.运维人员可以在控制台300配置优先级列表。优先级列表具体可以参考上文所述，在此不再赘述。控制台300可以通过步骤507，向控制面代理113发送优先级列表。控制面代理 113可以通过步骤508，向协议栈111发送优先级列表。协议栈111可以通过步骤509，保存优先级列表。
141.协议栈111可以通过步骤510，接收业务容器组发送的连接请求。为方便表述，可以将发送连接请求的业务容器组称为待连接业务容器组。协议栈111可以解析连接请求的源地址，并在步骤511中根据连接请求的源地址，确定业务容器组标识。接着，协议栈111可以在步骤512中，根据确定的业务容器组标识，确定业务容器组标签。进而，协议栈111可以在步骤513中，根据优先级列表，确定业务容器组标签对应的sidecar类型，从而可以确定待连接业务容器组对应的sidecar类型。
142.协议栈111可以在步骤514中，为待连接业务容器组选择sidecar。
143.若优先级列表为空，即没有配置连接请求和sidecar类型的对应关系。则从sidecar列表中，选择当前连接数最少的sidecar。
144.若高性能sidecar的当前连接数为零，且待连接业务容器组不对应高性能sidecar，则从sidecar列表中，选择当前连接数最少的sidecar。也就是说，在高性能sidecar没有连接业务容器组的情况系，即使待连接业务容器组对不对应高性能sidecar，也可以允许高性能sidecar为待连接业务容器组提供流量管理，从而可以在高性能sidecar空闲时，提升 sidecar整体资源利用率。
145.若待业务容器组对应高性能sidecar，则选择高性能sidecar。
146.之后，协议栈111可以执行步骤515，将连接请求发送至选择的sidecar。以便在该sidecar 和待连接业务容器组之间创建链路，使得该sidecar可以对业务容器组通过该链路发送的数据包进行流量管理。
147.实施例2提供的方案在实施例1支持多活高可用的情况下，支持使用不同性能的sidecar 对不同类型的业务容器组或目标服务，进行流量管理，从而保证某些对服务质量要求较高的连接请求使用独立或较多硬件资源，并可以在高性能sidecar空闲时，提升sidecar的整体资源利用率。
148.实施例3
149.在服务网格系统中，sidecar需要感知系统中的服务变更，并获取因服务变更而发生更新的服务列表。其中，服务变更可以包括服务上线、服务下线等。
150.在一种方案中，参阅图5a，服务网格系统中的节点m、节点n等各节点的sidecar和服务网格系统中的控制面之间建立套接字(socket)长连接。在后端容器组发生服务变更时，控制面可以产生服务变更消息。该服务变更消息可用于描述后端容器组发生的服务变更，或者服务变更消息包括因后端容器组发生的服务变更而发生更新的服务列表。控制面通过其和各个sidecar之间的长连接，将服务变更消息发送至各sidecar。其中，后端容器组可以是指能够响应节点m或节点n的服务调用而提供相应服务的容器组。
151.在该方案中，若服务网格系统中节点数量的增加，控制面的连接数将大大增加。服务网格系统中的每个服务的下线或下线均可引起服务变更，进而使得控制面产生服务变更消息。其中，控制面需要轮询其连接的所有sidecar，并进行服务变更消息的发送。当控制面的连接数非常大时，轮询sidecar以及发送服务变更消息将消耗控制面大量的计算资源并对网络形成较大压力。另外，控制面是按照sidecar的启动顺序或某个随机顺序，进行轮询和服务变更消息发送的。这可能导致同一节点内不同sidecar接收服务变更消息的时间相差较大。进而导致同一节点内sidecar感知到的服务实例不一致的时间窗口变大，如此，可能引发业务异常。
152.并且控制面的套接字文件描述符数量也有限。
153.因此，在该方案中，上述限制导致了服务网格系统难以扩大规模。
154.本实施例提供了一种方案，参阅图5b，控制台300可与各节点的控制面代理建立连接(例如套接字长连接)。如此，控制台300可以将服务变更消息发送至各节点的控制面代理。例如，控制面将服务变更消息发送至节点100的控制面代理113和节点200的控制面代理213。然后，控制面代理113可以将服务变更消息发送至节点100中的sidecar121、sidecar122等各个sidecar。控制面代理213可以将服务变更消息发送至节点200中的sidecar221、 sidecar222等各个sidecar。
155.如此，控制面的连接数将大大减少。并且当服务网格中发生服务变更时，控制面在节点层级上进行轮询和服务变更消息的发送，降低了控制面计算资源的消耗以及对网络的压力。并且，节点的控制面代理接收到服务变更消息后，通过节点内部通信机制，将服务变更消息发送至该节点中各sidecar，如此，大大降低了同一节点内sidecar所感知到的服务实例不一致的时间窗口。
156.另外，在本实施例中，当控制面和控制代理之间的网络发生故障时，控制面代理可以作为离线服务中心，为所在节点内的sidecar提供的读取功能，实现sidecar和控制侧的通信。其中，控制侧包括控制面代理和控制面。
157.接下来，结合图5c，对实施例3提供的方案进行更具体地说明。
158.参阅图5c，控制台300可以通过步骤601，对后端容器组进行服务变更监听。并且在
步骤602中，建立控制台300和节点100内的控制面代理113之间的连接。该连接可以为套接字长连接。在步骤603中，控制面代理113可以和其所在节点内的sidecar建立连接。
159.当控制台300在感知到后端容器组发生服务变更时，可以在步骤604中产生服务变更消息，并通过步骤605，将服务变更消息发送至控制面代理。
160.控制面代理在接收到服务变更消息后，可以通过步骤606，向sidecar发送服务变更消息。sidecar在步骤607中，可以根据服务变更消息更新路由信息。
161.实施例4
162.客户端第一次向服务端请求会话(session)时，服务端会为客户端创建一个会话，并通过特殊算法算出的一个会话标识(session identity，sessionid)，用于标识该会话。服务端可以向客户端返回该会话标识。客户端可以将会话标识保存在本地cookie中。当客户端再次访问对服务端时，可将会话标识发送至服务端。服务端会再次使用该会话标识对应的会话为客户端提供相应服务。
163.其中，在服务网格系统中，客户端为可调用服务的业务容器组。服务端也可以称为后端容器组，其可以为业务容器组提供的服务。服务端可以包括多个服务实例，并使用其中的一个或多个服务实例为客户端提供服务。
164.参考图6a，基于实施例1提供的方案，业务容器组c可以通过链路c1和sidecar m1连接，通过链路c2和sidecar m2连接。业务容器组c可以通过链路c1发送对后端容器组的连接请求，该连接请求可以携带会话标识e。sidecar m1接收到该连接请求后，可以提取其中的会话标识e，然后根据会话标识e，使用哈希(hash)算法，确定路由策略，以便按照该路由策略，将连接请求发送至服务实例。例如，可以设定该路由策略将该连接请求发送至后端容器组中的服务实例d1。
165.同理，业务容器组c也可以通过链路c2发送对后端容器组的连接请求，该连接请求可以携带会话标识e。sidecar m2接收到该连接请求后，可以提取其中的会话标识e，然后根据会话标识e，使用哈希(hash)算法，确定路由策略，以便按照该路由策略，将连接请求发送至服务实例。例如，可以设定该路由策略将该连接请求发送至后端容器组中的服务实例d2。
166.可以理解，在后端容器组发送服务变更时，不同sidecar接收服务变更消息的时间不一致，可能导致不同sidecar在进行哈希计算时，采用的哈希环大小不一致。例如，sidecar m1 在接收到服务变更消息之前，进行哈希计算；sidecar m2在接收到服务变更消息之后，进行哈希计算；那么sidecar m1和sidecar m2分别进行哈希计算时，所采用的哈希环大小不一致，从而产生不同的路由策略。也就是说，业务容器组c1发起的不同连接请求，可能会被发送至不同的服务实例，进而可能引发业务异常。
167.实施例4提供了一种方案，在不同sidecar为同一业务容器组的不同链路提供流量管理的情况下，可以将该业务容器组通过不同链路发生的连接请求，发送至同一服务实例。接下来，结合图6b和图6c，对该方案进行示例说明。
168.该方案可以应用于图6b所示的容器组管理系统，包括节点100、后端容器组210。其中，节点100可以包括sidecar121和sidecar122。示例性的，节点100还可以包括连接控制模块110。业务容器组131可以通过链路1311和sidecar121连接，通过链路1313和sidecar122 连接。后端容器组可以配置有服务实例g1、服务实例g2等多个服务实例。
169.参阅图6b，节点100可以配置有会话标识f和服务实例的映射关系。其中，当一
sidecar，例如sidecar121，根据会话标识f，进行哈希计算，得到的路由策略所对应的服务实例时， sidecar121可以建立会话标识f和该服务实例的映射关系。sidecar121可以向sidecar122 分享该映射关系。示例性的，sidecar121可向连接控制模块110发送该映射关系。sidecar122 可以读取连接控制模块110中的会话标识f和服务实例的映射关系，也可以将该映射关系保存在本地缓存中。
170.当sidecar121接收到业务容器组131通过链路1311发送的包含会话标识f的连接请求时，可以按照会话标识f和服务实例的对应关系，确定服务实例。进而将该连接请求路由到该服务实例。当sidecar122接收到业务容器组131通过链路1313发送的包含会话标识f的连接请求时，可以按照会话标识f和服务实例的对应关系，确定服务实例。进而将该连接请求路由到该服务实例。如此，在不同sidecar为同一业务容器组的不同链路提供流量管理的情况下，可以将该业务容器组通过不同链路发生的连接请求，发送至同一服务实例。
171.接下来，结合图6c，对实施例4提供的方案进行更具体地说明。
172.如图6c所示，业务容器组131可以通过步骤701向后端容器组210发送会话请求。后端容器组210可以在步骤702中，响应该会话请求为业务容器组131分配会话标识f，并通过步骤703，将会话标识f发送至业务容器组131。业务容器组131在步骤704中，可以保存会话标识f。
173.业务容器组131可以通过步骤705，向sidecar121发送包含会话标识f的连接请求。
174.在一个说明性示例中，sidecar121在接收到包含会话标识f的连接请求时，可以通过步骤706a，在连接控制模块110中查询会话标识f对应的服务实例。
175.在一个说明性示例中，sidecar121在接收到包含会话标识f的连接请求时，可以通过步骤706b，在sidecar121的本地缓存中查询会话标识f对应的服务实例。也就是说，在该示例中，会话标识f和服务实例的对应关系可以被保存在sidecar121的本地缓存中。
176.业务容器组131可以通过步骤707，向sidecar122发送包含会话标识f的连接请求。
177.在一个说明性示例中，sidecar122在接收到包含会话标识f的连接请求时，可以通过步骤708a，在连接控制模块110中查询会话标识f对应的服务实例。
178.在一个说明性示例中，sidecar122在接收到包含会话标识f的连接请求时，可以通过步骤708b，在sidecar122的本地缓存中查询会话标识f对应的服务实例。也就是说，在该示例中，会话标识f和服务实例的对应关系可以被保存在sidecar122的本地缓存中。
179.继续参阅图6c，sidecar121可以执行步骤709，若未查询到服务实例，则根据会话标识 f进行哈希运算，得到对应于会话标识f的服务实例。也就是说，通过上述步骤706a和步骤 706b，均未查询到对应于会话标识f的服务实例。这说明在sidecar122执行步骤706a时，连接控制模块110中没有保存会话标识f和服务实例的对应关系；以及sidecar121在执行步骤706b时，sidecar121本地缓存中没有保存会话标识f和服务实例的对应关系。如此， sidecar121根据会话标识进行哈希运算，以得到对应于会话标识f的服务实例。
180.接着，sidecar121可以执行步骤710，创建会话标识f和服务实例的映射关系，并向连接控制模块110发送会话标识f和服务实例的映射关系。连接控制模块110在步骤711中，可以保存会话标识f和服务实例的映射关系。示例性的，sidecar121可以执行步骤712，更新本地缓存，以将会话标识f和服务实例的映射关系保存在本地缓存中。
181.并且，sidecar121可以执行步骤713，根据服务实例，创建连接。即将连接请求发送
至对应于会话标识f的服务实例，以建立业务容器组131和该服务实例之间的连接。
182.继续参阅图6c，sidecar122可以执行步骤714，若未查询到服务实例，则根据会话标识 f进行哈希运算，得到对应于会话标识f的服务实例。也就是说，通过上述步骤708a和步骤 708b，均未查询到对应于会话标识f的服务实例。这说明在sidecar122执行步骤708a时，连接控制模块110中没有保存会话标识e和服务实例的对应关系；以及sidecar122在执行步骤708b时，sidecar122本地缓存中没有保存会话标识f和服务实例的对应关系。如此， sidecar122根据会话标识进行哈希运算，以得到对应于会话标识f的服务实例。
183.接着，sidecar122可以执行步骤715，创建会话标识f和服务实例的映射关系，并向连接控制模块110发送会话标识f和服务实例的映射关系。
184.连接控制模块110可以执行步骤716，确定连接控制模块110中已存在会话标识f和服务实例的映射关系(在上述步骤711中保存了会话标识f和服务实例的映射关系)，不再根据 sidecar122发送的会话标识e和服务实例的映射关系进行更新。连接控制模块110还可以执行步骤717，将在步骤711中保存的会话标识f和服务实例的映射关系发送至sidecar122。 sidecar122可以执行步骤718，更新本地缓存，以将从连接控制模块110接收的会话标识f 和服务实例的映射关系保存在本地缓存中。
185.sidecar122可以根据从连接控制模块110接收的会话标识f和服务实例的映射关系，确定对应于会话标识f的服务实例。然后，sidecar122可以执行步骤719，根据服务实例，创建连接。即将连接请求发送至对应于会话标识f的服务实例，以建立业务容器组131和该服务实例之间的连接。
186.另外，在一个说明性示例中，可以配置会话标识的生命周期。连接控制模块110可以在会话标识的生命周期结束时，确定该会话标识过期，并且执行步骤720，清理过期的会话标识。其中，在步骤720中，具体清理过期的会话标识和服务实例的映射关系。连接控制模块 110可以执行步骤721a，向sidecar121发送会话标识清理命令。sidecar121可以响应于会话标识清理命令，执行步骤722a，清理缓存，以将过期的会话标识和服务实例的映射关系从本地缓存中清理掉。连接控制模块110可以执行步骤721b，向sidecar122发送会话标识清理命令。sidecar122可以响应于会话标识清理命令，执行步骤722b，清理缓存，以将过期的会话标识和服务实例的映射关系从本地缓存中清理掉。
187.由此，通过实施例4提供的方案，在不同s idecar为同一业务容器组的不同链路提供流量管理的情况下，可以将该业务容器组通过不同链路发生的连接请求，发送至同一服务实例，进而使得该服务实例可以通过不同的链路为该业务容器组提供服务。
188.接下来，基于上文所描述的容器组管理方案，对本技术实施例提供的一种节点中的容器组的管理方法进行介绍。可以理解的是，该方法是上文所描述的容器组管理方案的另一种表达方式，两者是相结合的。该方法是基于上文所描述的容器组管理方案提出，该方法中的部分或全部内容可以参见上文对容器组管理的描述。
189.该节点运行有连接控制模块、边车集群、和第一业务容器组，边车集群包括至少两个边车。参阅图7，该方法包括如下步骤。
190.步骤7001，连接控制模块接收与节点相连的控制台发送的边车分配策略，根据边车分配策略在边车集群中选择第一边车，并将第一业务容器组发出的数据包转发至第一边车。
191.步骤7002，第一边车对第一业务容器组发出的数据包进行流量管理。
192.在一些实施例中，该节点还运行有第二业务容器组，该方法还包括：连接控制模块根据所述边车分配策略在所述边车集群中选择第二边车，并将所述第二业务容器组发出的数据包转发至所述第二边车；所述第二边车对所述第二业务容器组发出的数据包进行流量管理。
193.在这些实施例的一个示例中，所述第一边车分配的硬件资源规格高于所述第二边车分配的硬件资源，所述边车分配策略包括第一策略，所述第一策略用于指示所述第一业务容器组优先使用所述第一边车；所述根据所述边车分配策略在边车集群中选择所述第一边车包括：根据所述第一策略在边车集群中选择所述第一边车。
194.在一些实施例中，所述节点还运行有第二业务容器组，所述边车分配策略还包括第二策略，所述第二策略用于指示所述第一边车的服务对象数量不超过上限值；所述方法还包括：所述连接控制模块确定所述第一边车的服务对象的数量，在所述数量不超过所述上限值的情况下将所述第二业务容器组发出的数据包转发至所述第一边车；所述第一边车对所述第一业务容器组发出的数据包和所述第二业务容器组发出的数据包同时进行流量管理。
195.在一些实施例中，所述方法还包括：所述连接控制模块，在所述第一边车失效后，从所述边车集群中选择第三边车或通知所述控制台在所述节点创建所述第三边车，将所述第一业务容器组发送的另一数据包转发至所述第三边车；所述第三边车对所述第一业务容器组发出的另一数据包进行流量管理。
196.在这些实施例的一个示例中，所述第三边车是基于所述第一边车进行功能升级的新版本，或者所述第三边车是所述第一边车的复制版本。
197.在这些实施例的另一个示例中，所述方法还包括：所述第一边车在对所述第一业务容器组发出的数据包进行流量管理之后，将所述数据包发送至后端容器组。
198.在该示例的一个例子中，所述方法还包括：所述第一边车产生会话标识并发送所述会话标识至所述第一业务容器组和所述连接控制模块；所述连接控制模块记录所述会话标识与所述后端容器组的对应关系；所述第三边车从所述第一业务容器组获取所述会话标识并根据所述会话标识在所述连接控制模块记录的所述对应关系中确定所述后端容器组，在对所述第一业务容器组发出的另一数据包进行流量管理之后，将所述另一数据包发送至后端容器组。
199.在一些实施例中，所述边车分配策略包括第三策略，所述第三策略用于指示所述边车集群中的边车的服务对象数量为0时被优先使用；所述根据所述边车分配策略在边车集群中选择所述第一边车，并将所述第一业务容器组发出的数据包转发至所述第一边车包括：所述连接控制模块确定所述第一边车的服务对象的数量，在所述第一边车的服务对象的数量为0的情况下将所述第一业务容器组发出的数据包转发至所述第一边车。
200.在一些实施例中，所述方法还包括：所述连接控制模块监控所述边车集群中每个边车的工作状态，在发现存在下线的边车时，发送下线的所述边车的信息至所述控制台。
201.在一些实施例中，所述流量管理包括：流量控制、流量安全以及流量观测。
202.本技术实施例提供的容器组管理方法，可以按照控制台发送的边车分配策略，从至少两个边车中为业务容器选择边车，并使用选择出的边车对该业务容器组发出的数据包
进行流量管理，从而可以实现对该业务容器组的灵活管理，可以为对该业务容器组进行更优的流量管理，保障该业务容器组业务的高可用能力。
203.值得注意的是，在本技术实施例中，边车也可以对从节点外或节点内其他业务容器组发送至与边车绑定的业务容器组的数据包进行流量处理，流量处理的策略也可以参照以上方式进行设置，本技术实施例对此不作限定。
204.参阅图8，本技术实施例还提供了一种节点800，包括处理器810和存储器820，处理器810用于执行存储器820中存储的指令，使得节点800可以执行如图7所示的方法。
205.本技术实施例还提供了一种计算机可读存储介质，包括计算机程序指令，当所述计算机程序指令由计算设备集群执行时，所述计算设备集群执行如图7所示的方法。
206.本技术实施例还提供了一种包含指令的计算机程序产品，当所述指令被计算机设备集群运行时，使得所述计算机设备集群执行如图7所示的方法。
207.可以理解的是，本技术的实施例中的处理器可以是中央处理单元(centralprocessingunit，cpu)，还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(fieldprogrammablegatearray，fpga)或者其他可编程逻辑器件、晶体管逻辑器件，硬件部件或者其任意组合。通用处理器可以是微处理器，也可以是任何常规的处理器。可以理解的是，在本技术的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本技术的实施例的范围。