1.本发明涉及微服务
技术领域：
：，尤其是涉及一种服务网格中边车部署的方法、装置、电子设备和存储介质。
背景技术：
：：2.微服务是近年来新兴的一种软件开发技术。这种技术将传统业务分成很多细粒度的、松散耦合且可独立部署的微服务。在原有的单体软件架构已经无法满足当前互联网产品的技术需求的情况下，微服务技术得到了蓬勃发展。3.在微服务技术发展的同时，服务网格（servicemesh）应运而生。服务网格是用于处理微服务间通信的基础设施层，它负责为构架复杂的云原生应用传递可靠的网络请求。在微服务系统引入服务网格后，微服务之间的网络通信被服务网格代理，经由服务网格实现彼此之间的通信。服务网格对微服务之间的网络通信进行代理，是通过为每个微服务创建一个边车并与之建立关联关系实现的。4.然而，由于多数微服务系统中微服务数量巨大，因而边车的数量也很大。大量边车组成的服务网格占用了网络中过多的资源。技术实现要素：5.本发明实施方式的目的在于提供一种服务网格中边车部署的方法、装置、电子设备和存储介质，用以减少服务网格的资源消耗，且保证微服务之间的正常通信。6.为了解决上述问题，本发明的实施方式提供了一种服务网格中边车部署的方法，包括：根据微服务的资源需求和可靠性需求，确定为所述微服务配置的边车类型；其中，所述边车类型包括独占边车和共享边车；根据所述边车类型为所述微服务部署边车，并为所述微服务分配发布端口；其中，在为所述微服务配置的边车类型为共享边车的情况下，为所述微服务分配的发布端口不同于共享所述边车的其他微服务的发布端口。7.本发明的实施方式还提供了一种服务网格中边车部署装置，包括：确定模块，用于根据微服务的资源需求和可靠性需求，确定为所述微服务配置的边车类型；其中，所述边车类型包括独占边车和共享边车；部署模块，用于根据所述边车类型为所述微服务部署边车，并为所述微服务分配发布端口；其中，在为所述微服务配置的边车类型为共享边车的情况下，为所述微服务分配的发布端口不同于共享所述边车的其他微服务的发布端口。8.本发明的实施方式还提供了一种电子设备，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行上述的服务网格中边车部署的方法。9.本发明的实施方式还提供了一种存储有计算机程序的计算机可读存储介质，计算protocol/internetprotocol，简称“tcp/ip”）。15.服务网格包括数据面和控制面两部分，服务网格的结构示意图如图1所示。数据面的组件通常以轻量级网络代理阵列的形式实现，这些代理与微服务部署在一起，负责微服务之间所有的网络通信。由于代理伴随微服务部署，所以又被称为边车。控制面则负责管理数据面的边车，具体可以包括边车下发服务地址信息、配置服务路由、分发安全证书等等事项。16.为了实现使得服务网格能够代理微服务系统的所有网络通信，边车需要拦截和自己关联的微服务的网络请求，存在以下几种拦截方式。17.一、流量劫持。18.通过为微服务所在的主机配置iptables规则，将出入微服务的流量都转发到其关联的边车上，再由边车转发出去。流量经过边车时，边车可以对通信过程进行控制。启用流量劫持前后，所访问的微服务的地址不变。图2是引入服务网格后的微服务通信传输路径示意图。以微服务a和微服务b为例，引入服务网格后，为微服务a配置边车a，为微服务b配置边车b。微服务a向微服务b发出的调用请求，被边车a拦截并转发至边车b，再由边车b发送至其所关联的微服务b。19.二、流量接管。20.引入服务网格以后，微服务注册被边车所接管，访问微服务的地址被替换为边车的地址。引入服务网格后的微服务通信过程示意图如图3所示。以微服务a和服务地址为1.1.1.1:8001的微服务b为例，引入服务网格后，为微服务a配置边车a，为微服务b配置边车b。微服务b作为被调用方，自己的服务地址被发送给边车b，边车b上为此微服务分配一个端口，然后将边车b的地址（2.1.1.1:8002）作为此微服务b的地址，注册到服务中心。注册后，服务中心增加一条服务记录：微服务b地址2.1.1.1:8002。微服务a作为微服务b的调用方，在使用前，需要在边车a上配置微服务b的访问地址，此时访问地址为2.1.1.2:8003。当微服务a访问微服务b时，微服务a发送请求给边车a的地址，边车a从服务中心可以得知微服务b的地址，因此会将请求发送给边车b的地址，最后边车b将请求发送给微服务b的实际地址。启用流量接管后，所访问的微服务的地址实际上变成边车的地址了，但是微服务仍然感知不到服务网格的存在，因为以上这些和边车相关的配置，可以由服务网格的组件来自动完成，微服务会以为边车的地址就是微服务实际的地址。21.服务网格常用的拦截微服务的网络请求的方式是流量劫持，因为这种方式不会改变微服务的地址，对应用整体的影响较小。然而，以上各种拦截网络请求的方式虽然不同，但都有相同的特征：边车和微服务是一对一的。这种设计会导致边车占用较多的资源。22.在微服务系统中业务会被分成很多细粒度的微服务，这使得系统中微服务数量很多，而每一个微服务，都要对应一个边车，因此边车的数量往往也很多。边车只要启动以后，就会占用基础资源，在新的微服务注册，转发请求的时候，还会进一步增加动态资源消耗。即使每一个边车的资源消耗不多，所有边车的总消耗还是很大。这导致引入服务网格后，占用的资源会增加不少比例。23.边车占用的资源，不管是绝对值，还是相对的比例，都是非常可观的。在一些资源非常有限的特殊场景，例如边缘云等，尽量减少边车资源的占用就显得尤为必要。24.然而传统服务网格资源进行节约的方式，均是针对单个边车的优化，虽有一定节约资源的效果，但只要边车数量过多，由于下述原因，总是会消耗大量的资源：（1）边车进程一启动，即使没有注册微服务，也会消耗基础资源；（2）只要微服务进行注册，边车就会同步数据，即使不发请求，也会消耗资源，例如为每个微服务启动监听、准备处理线程、保存性能数据等；（3）微服务发送请求时，边车会进一步消耗资源。25.本发明的一实施方式涉及一种服务网格中边车部署的方法，具体流程如图4所示。26.在本实施方式中，根据微服务的资源需求和可靠性需求，确定为所述微服务配置的边车类型；其中，所述边车类型包括独占边车和共享边车；根据所述边车类型为所述微服务部署边车，并为所述微服务分配发布端口；其中，在为所述微服务配置的边车类型为共享边车的情况下，为所述微服务分配的发布端口不同于共享所述边车的其他微服务的发布端口。27.下面对本实施例中的服务网格中边车部署的方法的实现细节进行具体的说明，以下内容仅为方便理解本方案的实现细节，并非实施本方案的必须。具体流程如图4所示，可包括如下步骤：步骤401，根据微服务的资源需求和可靠性需求，确定为微服务配置的边车类型；其中，边车类型包括独占边车和共享边车。28.在本步骤中，服务网格中边车的部署装置根据微服务的资源需求和可靠性需求，确定为微服务配置的边车类型。例如：对于发送接收请求多或对网络性能要求高的微服务，可以为其配置独占边车；对于对网络性能要求不高的微服务，可以为其配置共享边车。既可以为微服务配置独占边车，也可以为微服务配置共享边车，既能够使得配置的边车满足微服务的需求，在配置共享边车的情况下还能够减少服务网格中的边车数量，实现资源节约。29.在一个例子中，在所述确定为所述微服务配置的边车类型之后，在所述根据所述边车类型为所述微服务部署边车之前，还可以包括：为所述微服务配置边车的参数；其中，所述参数包括以下之一或其任意组合：边车的id、边车的名称、边车的资源配额、边车的个数。在本例中，除了为微服务配置边车类型之外，还可为微服务配置其他边车相关的参数。30.为配置的边车类型为共享边车的微服务，配置边车的id可以使得将微服务与某一已存在的边车关联。例如可以将一个功能模块的多个子微服务关联同一类型为共享边车的边车，或为对资源与可靠性没有需求的微服务关联至一预先设置的全局共享边车。31.值得注意的是，微服务和边车的关联关系可以是任意组合，不再只限于一对一，还可以是一对多、多对一、多对多的关系。例如，如果希望能够避免边车出现单点故障，还可以为单个微服务关联多个边车，可以通过为微服务配置边车的个数的方式实现。32.若微服务和边车的关联关系是多对多，即一组微服务可以对应一组边车，这种情况下的微服务通信传输路径示意图如图5所示。微服务分组1中的微服务要访问微服务分组2中的微服务时，微服务分组1的微服务发出的请求，会经过边车分组1中的任一边车，转发给边车分组2中的任一边车，最终转发到微服务分组2的微服务。33.在实际实施时，由于边车可以共享，边车不再跟随微服务部署，而是部署在微服务之外。对于传统的将边车跟随微服务部署时，升级边车可能需要重启整个微服务才能更新边车版本，这会导致业务中断较长时间。而将边车部署在微服务之外，为边车的部署带来了更大的灵活性，可以实现独立升级边车而不重启微服务。部署新版本的边车，并逐步将流量接管过去后，再删除旧版本的边车，在此期间，微服务本身不需要重启。34.步骤402，根据边车类型为微服务部署边车，并为微服务分配发布端口；其中，在为所述微服务配置的边车类型为共享边车的情况下，为所述微服务分配的发布端口不同于共享所述边车的其他微服务的发布端口。35.具体地说，服务网格中边车的部署装置根据边车类型的不同，以不同的方法为微服务部署边车。且对于配置的边车类型为共享边车的微服务，由于多个微服务可能共享同一个边车，而不同微服务的端口号有可能重复，所以边车不能再用微服务的原始端口。为微服务分配一个不同于共享所述边车的其他微服务的发布端口，以便边车能根据目的端口来区分不同微服务的请求，避免车转发混乱，确保微服务之间通信的正常进行。36.在为微服务部署边车，并为微服务分配发布端口之后，为了实现边车对微服务请求的及时处理，边车需要对微服务的发布端口进行监听。37.在一个例子中，一边车的边车类型为共享边车，该边车转发微服务请求的流程图如图6所示。38.步骤601，根据目的发布端口号确定目标微服务。边车在监听到关联的微服务发出服务请求后，首先根据目的发布端口号能够准确的确定目标微服务。39.步骤602，在服务网格中查找该目标微服务关联的边车。40.步骤603，根据查找结果判断目标微服务关联的边车是否为此边车。若是，即查找结果表征该目标微服务关联的边车即为此边车，进行步骤604。否则，进行步骤605。41.步骤604，将服务请求直接转发至目标微服务。若目标微服务关联的边车即为此边车，则只需将服务请求转发至目标为服务即可。42.步骤605，将服务请求转发至该目标微服务关联的边车。若目标微服务关联的边车非此边车而是服务网格中的其他边车，则将服务请求转发至该目标微服务关联的边车，再由该关联的边车将服务请求转发给目标微服务。43.应当注意的是，本实施方式中涉及的边车和微服务可以在同一主机中，也可以在不同主机中。微服务和边车的部署形态，可以是进程、docker容器、k8s的pod等。边车实现对关联的微服务发出的请求进行拦截的方式可以是配置iptables、ipvs规则以及进行硬件配置等方式。为微服务配置边车相关的参数，可以通过k8s对象的annotaion、配置文件、配置数据库等方式。44.本实施方式根据微服务的资源需求和可靠性需求，为微服务确定配置的边车类型。其中边车类型包括共享边车，共享边车可以关联网络中的多个微服务，相比于传统的服务网格中为每一个微服务配置各自对应的不同边车的技术，能够大大减少资源消耗。进而本发明的实施方式根据边车类型为微服务部署边车，并为所述微服务分配发布端口。且在微服务配置的边车类型为共享边车的情况下，为微服务分配的发布端口不同于共享该边车的其他微服务的发布端口。不同的发布端口能够避免关联多个微服务的边车转发混乱，使得边车能够根据发布端口将访问请求发送至正确的目标微服务，确保微服务之间通信的正常进行。45.本发明的另一实施方式涉及一种服务网格中边车部署的方法，在本实施方式中，边车的参数包括边车的id，根据所述边车类型为所述微服务部署边车，具体流程如图7所示。46.在步骤701前还包括步骤401和步骤402。47.其中，步骤401为根据微服务的资源需求和可靠性需求，确定为微服务配置的边车类型；其中，边车类型包括独占边车和共享边车。步骤402为根据边车类型为微服务部署边车，并为微服务分配发布端口；其中，在为所述微服务配置的边车类型为共享边车的情况下，为所述微服务分配的发布端口不同于共享所述边车的其他微服务的发布端口。48.步骤401和步骤402在上一实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。49.步骤701，判断为微服务配置的边车类型是否是共享边车。50.具体地说，为微服务部署边车是根据为微服务配置的边车类型，因此，在本步骤中，服务网格中边车部署的装置首先对微服务配置的边车类型进行判断。在为所述微服务配置的边车类型为共享边车的情况下，进行步骤702。在为所述微服务配置的边车类型为独占边车的情况下，进行步骤705。51.步骤702，根据所述边车的id确定服务网格中相同id的边车的存在状态。52.在为所述微服务配置的边车类型为共享边车的情况下，根据所述边车的id确定服务网格中相同id的边车的存在状态。进而根据存在状态，为所述微服务部署边车。53.步骤703，判断存在状态是否为存在。54.在存在状态为存在的情况下，说明服务网格中已经存在部署装置需要为微服务进行部署的边车，进行步骤704。否则，说明服务网格中不存在部署装置需要为微服务进行部署的边车，进行步骤705。55.步骤704，将相同id的边车与微服务关联。56.在所述存在状态为存在的情况下，说明服务网格中已经存在部署装置需要为微服务进行部署的边车，只需将所述相同id的边车与所述微服务关联，能够减少服务网格中边车的数量，有效节省网络资源。57.步骤705，创建边车并将边车与微服务关联。58.具体地说，在为所述微服务配置的边车类型为共享边车且存在状态为不存在的情况下，创建边车并将所述边车与所述微服务关联。在为所述微服务配置的边车类型为独占边车的情况下，创建边车并将所述边车与所述微服务关联。59.在一示例性实施方式中，微服务a1配置的边车的id为x,则在为微服务a1部署边车时，需创建id为x的边车。而对于同样配置的边车的id为x的微服务a2，在为其部署边车时，无需创建边车，只需建立微服务a2与边车x的关联即可。60.为微服务部署边车类型为共享边车的边车后，微服务之间的通信过程如图8所示。首先，微服务b在服务中心进行注册。随后，服务网格的控制面从服务中心获取新注册的微服务b，进而为微服务b分配发布端口并配置微服务的iptables规则。与微服务b关联的边车y对微服务b的发布端口进行监听。61.微服务a通过服务中心发现微服务b的存在，进而对微服务b发出调用请求。该调用请求被iptables规则导向与微服务a关联的边车x上的微服务b的发布端口。进一步地，边车x将该调用请求转发给边车y，最终由边车y将请求发送给微服务b。62.本实施方式为配置的边车类型为独占边车的微服务，以及服务网格中不存在与其配置的边车id相同id的边车的微服务，创建边车并能够使得上述边车与微服务建立关联关系。对于为微服务配置的边车类型为共享边车且服务网格中存在相同id的边车的情况，为这种微服务与该相同id的边车进行关联，能够减少服务网格中边车的数量，有效节约服务网格占用的资源。63.本发明的另一实施方式涉及一种服务网格中边车部署的方法，具体流程如图9所示。64.步骤901，根据微服务的资源需求和可靠性需求，确定为微服务配置的边车类型；其中，边车类型包括独占边车和共享边车。65.步骤902，根据边车类型为微服务部署边车，并为微服务分配发布端口；其中，在为所述微服务配置的边车类型为共享边车的情况下，为所述微服务分配的发布端口不同于共享所述边车的其他微服务的发布端口。66.不难看出，本实施方式中的步骤901与步骤902与前述实施方式中的步骤401与步骤402相同，上一实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。67.步骤903，在微服务需要卸载的情况下，为边车解除与微服务的关联。68.在本步骤中，对微服务进行卸载，为了充分释放占用的资源，还需将边车与该微服务解除关联关系。69.步骤904，在微服务关联的边车的边车类型为共享边车的情况下，根据边车的微服务关联数，确定是否删除边车。70.在一个例子中，根据所述边车的微服务关联数，确定是否删除所属边车，可以包括：在所述边车的微服务关联数大于0的情况下，保留所述边车；在所述边车的微服务关联数不大于0的情况下，删除所述边车。在卸载的微服务的关联边车已无剩余关联边车的情况下，对该边车进行删除能够使得占用资源得到释放。71.本实施方式在对微服务进行卸载后，能够解除边车与该微服务的关联关系。且在微服务关联的边车的边车类型为共享边车的情况下，能够根据边车的微服务关联数，确定是否删除所述边车。能够实现在尽可能的释放占用资源的同时，避免对处于关联关系之中的边车造成错误删除。72.本发明的一实施方式涉及一种服务网格中边车部署装置，如图10所示，包括：确定模块1001，用于根据微服务的资源需求和可靠性需求，确定为所述微服务配置的边车类型；其中，所述边车类型包括独占边车和共享边车；部署模块1002，用于根据所述边车类型为所述微服务部署边车，并为所述微服务分配发布端口；其中，在为所述微服务配置的边车类型为共享边车的情况下，为所述微服务分配的发布端口不同于共享所述边车的其他微服务的发布端口。73.在一个例子中，服务网格中边车部署装置还可以包括：配置模块（图中未示出），用于在所述确定为所述微服务配置的边车类型之后，在所述根据所述边车类型为所述微服务部署边车之前，为所述微服务配置边车的参数；其中，所述参数包括以下之一或其任意组合：边车的id、边车的名称、边车的资源配额、边车的个数。74.在一个例子中，部署模块1002，还可以用于在为所述微服务配置的边车类型为共享边车的情况下，根据所述边车的id确定服务网格中相同id的边车的存在状态；根据所述存在状态，为所述微服务部署边车。75.在一个例子中，部署模块1002，还可以用于在所述存在状态为存在的情况下，将所述相同id的边车与所述微服务关联；在所述存在状态为不存在的情况下，创建边车并将所述边车与所述微服务关联。76.在一个例子中，服务网格中边车部署装置还可以包括：卸载模块（图中未示出），在所述为所述微服务分配发布端口之后，卸载所述微服务，并为所述边车解除与所述微服务的关联；在所述微服务关联的边车的边车类型为共享边车的情况下，根据所述边车的微服务关联数，确定是否删除所属边车。77.在一个例子中，卸载模块还可以用于在所述边车的微服务关联数大于0的情况下，保留所述边车；在所述边车的微服务关联数不大于0的情况下，删除所述边车。78.在一个例子中，部署模块1002，还可以用于在为所述微服务配置的边车类型为独占边车的情况下，创建边车并将所述边车与所述微服务关联。79.本实施方式提供的服务网格中边车部署装置能够根据微服务的资源需求和可靠性需求，为微服务确定配置的边车类型。其中边车类型包括共享边车，共享边车可能关联网络中的多个微服务，相比于传统的服务网格中为每一个微服务配置各自对应的不同边车的技术，能够大大减少资源消耗。进而本发明的实施方式根据边车类型为微服务部署边车，并为所述微服务分配发布端口。且在微服务配置的边车类型为共享边车的情况下，为微服务分配的发布端口不同于共享该边车的其他微服务的发布端口。不同的发布端口能够避免关联多个微服务的边车转发混乱，使得边车能够根据发布端口将访问请求发送至正确的目标微服务，确保微服务之间通信的正常进行。80.值得一提的是，本发明上述实施方式中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，本实施方式中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明本实施方式中不存在其它的单元。81.本发明的实施例还提供一种电子设备，如图11所示，包括至少一个处理器1101；以及，与所述至少一个处理器1101通信连接的存储器1102；其中，存储器1102存储有可被至少一个处理器1101执行的指令，指令被至少一个处理器1101执行，以使至少一个处理器1101能够执行上述服务网格中边车部署的方法。82.其中，存储器1102和处理器1101采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器1101和存储器1102的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器1101处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器1101。83.处理器1101负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器1102可以被用于存储处理器1101在执行操作时所使用的数据。84.上述产品可执行本技术实施例所提供的服务网格中边车部署的方法，具备执行方法相应的功能模块和有益效果，未在本实施例中详尽描述的技术细节，可参见本技术实施例所提供的方法。85.本技术的实施例还提供一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述服务网格中边车部署的方法。86.本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备（可以是单片机，芯片等）或处理器（processor）执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器（rom，read‑onlymemory）、随机存取存储器（ram，randomaccessmemory）、磁碟或者光盘等各种可以存储程序代码的介质。87.上述实施例是提供给本领域普通技术人员来实现和使用本发明的，本领域普通技术人员可以在不脱离本技术的发明思想的情况下，对上述实施例做出种种修改或变化，因而本发明的保护范围并不被上述实施例所限，而应该符合权利要求书所提到的创新性特征的最大范围。当前第1页12当前第1页12