一种流量分流的方法、装置、终端和计算机存储介质与流程

1.本发明涉及kubernetes云平台中ingress的流量分流技术，尤其涉及一种流量分流的方法、装置、终端和计算机存储介质。


背景技术：

2.为了满足web应用的快速部署，自动维护和自动扩容的需求，从而产生了kubernetes平台。但随之而来的问题是如何实现kubernetes平台上的灰度发布功能。
3.现有kubernetes平台上ingress的灰度方案，利用原生ingress中的annotation：nginx.ingress.kubernetes.io/canary来实现，现有的方案通过创建两个ingress配置，每个ingress对应一个后端服务service，并在ingress配置中填写对应的后端服务以做区分，具体地，ingress控制器可以采取以下3种方式对接收到的用户流量进行分流以实现灰度发布：
4.基于header：nginx.ingress.kubernetes.io/canary-by-header
5.基于cookie：nginx.ingress.kubernetes.io/canary-by-cookie
6.基于weight：nginx.ingress.kubernetes.io/canary-weight
7.然而，针对上述灰度发布来说，用户流量仅仅能够分流到两个ingress配置分别对应的后端服务上，这样使得流量分流受到限制，并不利于灰度发布；由此可以看出，现有的kubernetes云平台中ingress在实现流量分流时存在局限性。


技术实现要素：

8.有鉴于此，本发明实施例提供一种流量分流的方法、装置、终端和计算机存储介质，以解决现有技术中存在的kubernetes云平台中ingress在实现流量分流时具有局限性的技术问题。
9.本发明的技术方案是这样实现的：
10.第一方面，本发明实施例提供了一种流量分流的方法，所述方法应用于kubernetes的ingress组件中，所述kubernetes的数据库中存储有一组配置信息，所述配置信息是针对至少两个后端服务的配置信息，包括：
11.接收用户请求；
12.根据预设的分流参数，采用所述分流参数对应的分流规则，对所述用户请求进行处理，从所述kubernetes的数据库中确定所述用户请求的后端服务；
13.将所述用户请求的流量分流至所述用户请求的后端服务中。
14.在上述方法中，所述ingress组件包括ingress控制器和负载均衡器，相应地，
15.所述ingress控制器接收用户请求；
16.所述负载均衡器根据预设的分流参数，采用所述分流参数对应的分流规则，对所述用户请求进行处理，从所述kubernetes的数据库中确定所述用户请求的后端服务；
17.所述负载均衡器将所述用户请求的流量分流至所述用户请求的后端服务中。
18.在上述方法中，所述负载均衡器根据预设的分流参数，采用所述分流参数对应的分流规则，对所述用户请求进行处理，从所述kubernetes的数据库中确定所述用户请求的后端服务，包括：
19.所述负载均衡器根据所述分流参数，对所述用户请求进行解析，得到所述用户请求的分流参数的值；
20.所述负载均衡器根据所述分流参数的值，采用所述分流规则，从所述kubernetes的数据库中确定所述用户请求的后端服务。
21.在上述方法中，在所述ingress控制器接收用户请求之前，所述方法还包括：
22.所述ingress控制器监听并从所述kubernetes的数据库中获取所述配置信息；
23.所述ingress控制器根据所述配置信息动态渲染出所述ingress组件的配置文件；
24.所述负载均衡器动态加载所述配置文件，并从所述配置文件中读取所述预设的分流参数和所述分流规则。
25.在上述方法中，所述分流参数的种类包括以下任意一项：
26.header，cookie，weight和ip地址。
27.在上述方法中，当所述分流参数为ip地址时，所述均衡负载器根据所述分流参数，对所述用户请求进行解析，得到所述用户请求的分流参数的值，包括：
28.所述负载均衡器对所述用户请求进行解析，得到所述用户请求的客户端的ip地址；
29.所述负载均衡器根据所述分流参数的值，采用所述分流规则，从所述kubernetes的数据库中确定所述用户请求的后端服务，包括：
30.所述负载均衡器确定所述用户请求的客户端的ip地址所属的预设网段；
31.所述负载均衡器从所述kubernetes的数据库中确定所述预设网段对应的后端服务；
32.所述负载均衡器将所述预设网段对应的后端服务，确定为所述用户请求的后端服务。
33.在上述方法中，所述将所述用户请求的流量分流至所述用户请求的后端服务中，包括：
34.将所述用户请求的流量分流至所述用户请求的后端服务的pod中；
35.其中，所述后端服务中的pod是通过annotation字段进行标记的。
36.第二方面，本发明实施例提供了一种流量分流的装置，所述装置设置于kubernetes的ingress组件中，所述kubernetes的数据库中存储有一组配置信息，所述配置信息是针对至少两个后端服务的配置信息，包括：
37.接收模块，用于接收用户请求；
38.确定模块，用于根据预设的分流参数，采用所述分流参数对应的分流规则，对所述用户请求进行处理，从所述kubernetes的数据库中确定所述用户请求的后端服务；
39.分流模块，用于将所述用户请求的流量分流至所述用户请求的后端服务中。
40.在上述装置中，所述ingress组件包括ingress控制器和负载均衡器，相应地，
41.所述ingress控制器的接收模块，用于接收用户请求；
42.所述负载均衡器的确定模块，用于的根据预设的分流参数，采用所述分流参数对
应的分流规则，对所述用户请求进行处理，从所述kubernetes的数据库中确定所述用户请求的后端服务；
43.所述负载均衡器的分流模块，用于将所述用户请求的流量分流至所述用户请求的后端服务中。
44.在上述装置中，确定模块根据预设的分流参数，采用所述分流参数的分流规则，对所述用户请求进行处理，从所述kubernetes的数据库中确定所述用户请求的后端服务中，包括：
45.根据所述分流参数，对所述用户请求进行解析，得到所述用户请求的分流参数的值；
46.根据所述分流参数的值，采用所述分流规则，从所述kubernetes的数据库中确定所述用户请求的后端服务。
47.在上述装置中，所述ingress控制器还用于：
48.在所述ingress控制器接收用户请求之前，监听并从所述kubernetes的数据库中获取所述配置信息；
49.根据所述配置信息动态渲染出所述ingress组件的配置文件；
50.所述负载均衡器还用于：
51.加载所述配置文件，并从所述配置文件中读取所述预设的分流参数和所述分流规则。
52.在上述装置中，所述分流参数的种类包括以下任意一项：
53.header，cookie，weight和ip地址。
54.在上述装置中，当所述分流参数为ip地址时，确定模块根据所述分流参数，对所述用户请求进行解析，得到所述用户请求的分流参数的值中，包括：
55.对所述用户请求进行解析，得到所述用户请求的客户端的ip地址；
56.确定模块根据所述分流参数的值，采用所述分流规则，从所述kubernetes的数据库中确定所述用户请求的后端服务中，包括：
57.确定所述用户请求的客户端的ip地址所属的预设网段；
58.从所述kubernetes的数据库中确定所述预设网段对应的后端服务；
59.将所述预设网段对应的后端服务，确定为所述用户请求的后端服务。
60.在上述装置中，分流模块，具体用于：
61.将所述用户请求的流量分流至所述用户请求的后端服务的pod中；
62.其中，所述后端服务中的pod是通过annotation字段进行标记的。
63.第三方面，本发明实施例还提供了一种终端，所述终端包括：处理器以及存储有所述处理器可执行指令的存储介质，所述存储介质通过通信总线依赖所述处理器执行操作，当所述指令被所述处理器执行时，执行上述一个或多个实施例所述流量分流的方法。
64.本发明实施例提供了一种计算机存储介质，存储有可执行指令，当所述可执行指令被一个或多个处理器执行的时候，所述处理器执行上述一个或多个实施例所述流量分流的方法。
65.本发明实施例所提供的一种流量分流的方法、装置、终端和计算机存储介质，该方法应用于一kubernetes的ingress组件中，该kubernetes的数据库中存储有一组配置信息，
该配置信息是针对至少两个后端服务的配置信息，包括：接收用户请求，根据预设的分流参数，采用分流参数对应的分流规则，对用户请求进行处理，从kubernetes的数据库中确定用户请求的后端服务，将用户请求的流量分流至用户请求的后端服务中；也就是说，在本发明实施例中，通过预先在kubernetes的数据库中存储有一个ingress配置对应的至少两个后端服务，使得ingress组件可以根据分流参数，并采用分流规则，将用户请求的流量可以分流至至少两个后端服务，并且，所有的后端服务只与一个ingress配置相对应，这样，在进行流量分流时，简化了流量分流时所采用的架构，通过监听一个ingress配置就可以实现流量分流，降低了复杂度，提高了稳定性。
附图说明
66.图1为本发明实施例中的一种可选的流量分流的方法的流程示意图；
67.图2为ingress组件进行灰度发布的流程示意图；
68.图3为本发明实施例提供的一种可选的流量分流的方法的实例的流程示意图；
69.图4为本发明实施例中的一种可选的流量分流的装置的结构示意图；
70.图5为本发明实施例提供的一种可选的终端的结构示意图。
具体实施方式
71.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。
72.实施例一
73.本发明实施例提供一种流量分流的方法，该方法应用于kubernetes的ingress组件中，该kubernetes的数据库中存储有一组配置信息，该配置信息是针对至少两个后端服务器的配置信息，图1为本发明实施例中的一种可选的流量分流的方法的流程示意图，如图1所示，该方法可以包括：
74.s101：接收用户请求；
75.目前，kubernetes平台的ingress灰度发布方案通常采用基于header，或者cookie，或者weight的方式进行发布，并且，kubernetes的数据库中存储有多组配置信息，每组配置信息为一个后端服务器的配置信息，图2为ingress组件进行灰度发布的流程示意图，如图2所示，首先，在kubernetes的数据库中设置有两组配置信息，分别为ingress配置-01和ingress配置-02，其中，ingress配置-01对应服务(service01)deployment01，deployment01包括pod-v1，ingress配置-02对应服务(service02)deployment02，deployment02包括pod-v2，然后，ingress控制器监听ingress配置并渲染出配置文件nginx.conf，其中，配置文件nginx.conf中包含有lua脚本，ingress控制器接收到用户请求(相当于用于流量)，lua脚本根据预设的分流参数，例如cookie，对用户请求进行解析，得到该用户请求的cookie的值，负载均衡器nginx根据解析出的cookie的值采用分流规则，例如，cookie的值所落入的预设区间，将所落入的预设区间对应的后端确定为用户请求的后端服务，并将用户请求的流量分流至用户请求的后端服务中，例如pod-v1中。
76.由此可以看出，现有ingress灰度发布方案，大多通过lua脚本编写逻辑判断，调试运维成本高，且后期支持不完善；其中，提供灰度发布的维度不够完善，只提供基于三种维
度，支持的维度较少，另外，根据kubernetes平台判别后端服务需创建两组配置信息，浪费资源，lua脚本与原生nginx配置相比，存在性能瓶颈，稳定性方面未能保证。
77.为了简化架构提高稳定性，本发明实施例提供一种流量分流的方法，先接收到用户请求，其中，该用户请求可以为多个，通过该方法可以实现对用户请求的流量进行分流，分流至不同的后端服务中。
78.s102：根据预设的分流参数，采用分流参数对应的分流规则，对用户请求进行处理，从kubernetes的数据库中确定用户请求的后端服务；
79.s103：将用户请求的流量分流至用户请求的后端服务中。
80.具体来说，在接收到用户请求之后，先确定出预设的分流参数，其中，分流参数的种类包括以下任意一项：header，cookie，weight和ip地址；也就是说，预设的分流参数可以为以上任何一种，例如为header或者cookie时，先确定出用户请求header的值或者cookie的值，然后可以根据该值所落入的区间对应的后端服务器确定用户请求的后端服务，最后将用户请求分流至确定出的后端服务中，针对weight，假设后端服务为5个，将20％的用户请求分流至后端服务01，20％的用户请求分流至后端服务02，20％的用户请求分流至后端服务03，20％的用户请求分流至后端服务04，20％的用户请求分流至后端服务05；针对ip地址，需要去解析出用户请求的ip地址，在采用ip地址对应的分流规则确定用户请求的后端服务，将用户请求分流至确定出的后端服务中。
81.为了简化流量分流的架构，在一种可选的实施例中，该ingress组件包括ingress控制器和负载均衡器，相应地，
82.ingress控制器接收用户请求；
83.负载均衡器根据预设的分流参数，采用分流参数对应的分流规则，对用户请求进行处理，从kubernetes的数据库中确定用户请求的后端服务；
84.负载均衡器将用户请求的流量分流至用户请求的后端服务中。
85.具体来说，在本发明实施例中，ingress控制器接收用户请求，然后，负载均衡器确定用户请求的后端服务，并将用户请求的流量分流至用户请求的后端服务中。
86.进一步地，为了确定出用户请求的后端服务，在一种可选的实施例中，负载均衡器根据预设的分流参数，采用分流参数的分流规则，对用户请求进行处理，从kubernetes的数据库中确定用户请求的后端服务，包括：
87.负载均衡器根据分流参数，对用户请求进行解析，得到用户请求的分流参数的值；
88.负载均衡器根据分流参数的值，采用分流规则，从kubernetes的数据库中确定用户请求的后端服务。
89.其中，在ingress组合件中预先存储有分流参数，负载均衡器根据分流参数对用户请求进行解析，例如，分流参数为header，对用户请求进行解析，解析得到用户请求的header的值，负载均衡根据header的值，确定出该值对应的后端服务，并将该值对应的后端服务确定为用户请求的后端服务。
90.为了确定出分流参数和分流规则，在一种可选的实施例中，在ingress控制器接收用户请求之前，上述方法还包括：
91.ingress控制器监听并从kubernetes的数据库中获取配置信息；
92.ingress控制器根据配置信息动态渲染出ingress组件的配置文件；
93.负载均衡器动态加载配置文件，并从配置文件中读取预设的分流参数和分流规则。
94.具体来说，在ingress控制器接收用户请求之前，ingress控制器监听并从kubernetes的数据库中获取配置信息，然后根据配置信息动态渲染出ingress组件的配置文件，这里，动态渲染除了现有的渲染功能之外，还可以主动查询kubernetes信息，例如主动查询pod的信息，然后渲染出配置文件，使得负载均衡器动态加载配置文件，负载均衡器能够从配置文件中读取分流参数和分流规则，这样，负载均衡器在分流的过程中，可以获取分流参数，并对用户请求进行解析，并确定出用户请求的后端服务，与现有的lua脚本解析用户请求相比，避免引入第三方脚本，使用负载均衡器解析用户请求，降低了流量分流的复杂度。
95.为了实现采用ip地址这一维度进行用户请求的分流，在一种可选的实施例中，当分流参数为ip地址时，均衡负载器根据分流参数，对用户请求进行解析，得到用户请求的分流参数的值，包括：
96.负载均衡器对用户请求进行解析，得到用户请求的客户端的ip地址；
97.负载均衡器根据分流参数的值，采用分流规则，从kubernetes的数据库中确定用户请求的后端服务，包括：
98.负载均衡器确定用户请求的客户端的ip地址所属的预设网段；
99.负载均衡器从kubernetes的数据库中确定预设网段对应的后端服务；
100.负载均衡器将预设网段对应的后端服务，确定为用户请求的后端服务。
101.这里，负载均衡器对接收到的用户请求进行解析，这样，可以得到发出用户请求的客户端的ip地址；然后负载均衡器中存储有多个预设网段，负载均衡器确定所得到的用户请求的ip地址所属的预设网段，在负载均衡器中还设置有每个预设网络对应的后端服务，所以，在确定出ip地址所属网段之后，就可以确定出所属网段对应的后端服务，并将对应的后端服务确定为用户请求的后端服务。
102.为了实现用户请求的分流，在一种可选的实施例中，将用户请求的流量分流至用户请求的后端服务中，包括：
103.将用户请求的流量分流至用户请求的后端服务的pod中；
104.具体来说，在后端服务中，采用在pod上打标签来区分后端服务，其中，后端服务中的pod是通过annotation字段进行标记的；也就是说，不再需要依赖不同的ingress的配置信息来判别后端服务，而是通过在多个后端服务的pod上打标签来进行区分，操作更简单，并且节省了kubernetes的资源。
105.下面举实例来对上述一个或多个实施例中的流量分流的方法进行说明。
106.图3为本发明实施例提供的一种可选的流量分流的方法的实例的流程示意图，如图3所示，上述流量分流的方法可以包括：
107.在kubernetes的数据库中设置有一组配置信息，即为图3中的ingress配置，其中，ingress配置对应服务(service)deployment01，deployment02和deployment03，deployment01包括pod-v1，deployment02包括pod-v2，deployment03包括pod-v3；在本实例中，针对不同的后端服务，修改其对应的kubernetes平台中deployment资源yaml配置中的annotation字段，进而影响到pod的annotation字段，起到打标签的作用。例如打上版本信
息的标签v1，v2，v3。
108.修改ingress控制器的源码使其监听kubernetes中自定义的ingress配置资源，该配置中定义了自定义的一些规则，用于描述根据哪些特征进行流量分流；例如：header，cookie，weight和ip等维度，同时根据ingress配置中用户配置的pod版本信息，获取各版本pod的ip。
109.ingress控制器监听ingress配置，根据其中的配置动态渲染出对应规则的配置文件(nginx.conf)；例如：用户配置了根据ip分流到不同版本的规则，ingress控制器就会渲染出静态的nginx.conf支持该规则，该nginx.conf规则会先后解析x-forward-for，x-real-ip，$remote_addr等字段判断客户端ip，并将源ip为指定ip的流量转到特定后端。
110.与现有lua脚本解析用户请求的方案则不同，其只有一套nginx.conf，嵌套的lua脚本对所有情况进行判断分流，其目前不支持基于ip的分流方案。此外，现有方案只能通过2不同的配置信息进行2个版本后端服务的区分，而本实例是通过annotation打标签进行区分，支持多个不同版本的后端服务。
111.具体来说，ingress控制器接收用户请求(例如http请求)的流量，负载均衡器nginx动态加载nginx.conf，并生效；ingress组件中的负载均衡器nginx根据之前配置好的规则，对流量进行分流，可以根据http请求中特定(或自定义)header的值，cookie的值或者客户端的ip地址或者直接根据权重weight去做流量分流，转发到特定的后端服务上。
112.通过上述实例，不需要对ingress组件中包含的nginx进行改造升级，利用kubernetes平台资源监听的先天优势，以及nginx的固有语法规则，简化流量分流的具体实现，降低复杂度，提高了稳定性。
113.本发明实施例所提供的一种流量分流的方法，该方法应用于一kubernetes的ingress组件中，该kubernetes的数据库中存储有一组配置信息，该配置信息是针对至少两个后端服务的配置信息，包括：接收用户请求，根据预设的分流参数，采用分流参数对应的分流规则，对用户请求进行处理，从kubernetes的数据库中确定用户请求的后端服务，将用户请求的流量分流至用户请求的后端服务中；也就是说，在本发明实施例中，通过预先在kubernetes的数据库中存储有一个ingress配置对应的至少两个后端服务，使得ingress组件可以根据分流参数，并采用分流规则，将用户请求的流量可以分流至至少两个后端服务，并且，所有的后端服务只与一个ingress配置相对应，这样，在进行流量分流时，简化了流量分流时所采用的架构，通过监听一个ingress配置就可以实现流量分流，降低了复杂度，提高了稳定性。
114.实施例二
115.基于同一发明构思，本发明实施例提供一种流量分流的装置，图4为本发明实施例中的一种可选的流量分流的装置的结构示意图，如图4所示，该流量分流的装置，包括：
116.接收模块41，用于接收用户请求；
117.确定模块42，用于根据预设的分流参数，采用分流参数对应的分流规则，对用户请求进行处理，从kubernetes的数据库中确定用户请求的后端服务；
118.分流模块43，用于将用户请求的流量分流至用户请求的后端服务中。
119.在一种可选的实施例中，ingress组件包括ingress控制器和负载均衡器，相应地，
120.ingress控制器的接收模块41，用于接收用户请求；
121.负载均衡器的确定模块42，用于根据预设的分流参数，采用分流参数对应的分流规则，对用户请求进行处理，从kubernetes的数据库中确定用户请求的后端服务；
122.负载均衡器的分流模块43，用于将用户请求的流量分流至用户请求的后端服务中。
123.在一种可选的实施例中，确定模块42，具体用于：
124.根据分流参数，对用户请求进行解析，得到用户请求的分流参数的值；
125.根据分流参数的值，采用分流规则，从kubernetes的数据库中确定用户请求的后端服务。
126.在一种可选的实施例中，ingress控制器还用于：
127.在ingress控制器的确定模块42接收用户请求之前，监听并从kubernetes的数据库中获取配置信息；
128.根据配置信息动态渲染出ingress组件的配置文件；
129.负载均衡器还用于：动态加载配置文件，并从配置文件中读取预设的分流参数和分流规则。
130.在一种可选的实施例中，分流参数的种类包括以下任意一项：
131.header，cookie，weight和ip地址。
132.在一种可选的实施例中，当分流参数为ip地址时，确定模块42根据分流参数，对用户请求进行解析，得到用户请求的分流参数的值中，包括：
133.对用户请求进行解析，得到用户请求的客户端的ip地址；
134.确定模块42根据分流参数的值，采用分流规则，从kubernetes的数据库中确定用户请求的后端服务中，包括：
135.确定用户请求的客户端的ip地址所属的预设网段；
136.从kubernetes的数据库中确定预设网段对应的后端服务；
137.将预设网段对应的后端服务，确定为用户请求的后端服务。
138.在一种可选的实施例中，分流模块43具体用于：
139.将用户请求的流量分流至用户请求的后端服务的pod中；
140.其中，后端服务中的pod是通过annotation字段进行标记的。
141.在实际应用中，上述接收模块41，确定模块42和分流模块43可由位于终端上的处理器实现，具体为中央处理器(cpu，central processing unit)、微处理器(mpu，microprocessor unit)、数字信号处理器(dsp，digital signal processing)或现场可编程门阵列(fpga，field programmable gate array)等实现。
142.图5为本发明实施例提供的一种可选的终端的结构示意图，如图5所示，本发明实施例提供了一种终端500，包括：
143.处理器51以及存储有所述处理器51可执行指令的存储介质52，所述存储介质52通过通信总线53依赖所述处理器51执行操作，当所述指令被所述处理器51执行时，执行上述实施例一所述的流量分流的方法。
144.需要说明的是，实际应用时，终端中的各个组件通过通信总线53耦合在一起。可理解，通信总线53用于实现这些组件之间的连接通信。通信总线53除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图5中将各种总线都标
为通信总线53。
145.本发明实施例提供了一种计算机存储介质，存储有可执行指令，当所述可执行指令被一个或多个处理器执行的时候，所述处理器执行实施例一所述的流量分流的方法。
146.其中，计算机可读存储介质可以是磁性随机存取存储器(ferromagnetic random access memory，fram)、只读存储器(read only memory，rom)、可编程只读存储器(programmable read-only memory，prom)、可擦除可编程只读存储器(erasable programmable read-only memory，eprom)、电可擦除可编程只读存储器(electrically erasable programmable read-only memory，eeprom)、快闪存储器(flash memory)、磁表面存储器、光盘、或只读光盘(compact disc read-only memory，cd-rom)等存储器。
147.本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
148.本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
149.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
150.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
151.以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。