Kubernetes之服务发现Service

目录

  • Kubernetes之服务发现Service

    • 理解
    • Service的实现模型
      • userspace代理模式
      • iptables代理模式
      • ipvs代理模式
    • Service定义
      • Service配置清单重要字段
      • 创建ClusterIP类型Service
      • 创建NodePort类型Service
      • Pod的会话保持
    • Headless无头Service

Kubernetes之服务发现Service

理解

Service是对一组提供相同功能的Pods的抽象，并为它们提供一个统一的入口。借助Service，应用可以方便的实现服务发现与负载均衡，并实现应用的零宕机升级。Service通过标签来选取服务后端，一般配合Replication Controller或者Deployment来保证后端容器的正常运行。这些匹配标签的Pod IP和端口列表组成endpoints，由kubeproxy负责将服务IP负载均衡到这些endpoints上。
Service有四种类型：

  • ClusterIP：默认类型，自动分配一个仅cluster内部可以访问的虚拟IP
  • NodePort：在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过 :NodePort 来访问该服务
  • LoadBalancer：在NodePort的基础上，借助cloud provider创建一个外部的负载均衡器，并将请求转发到 :NodePort
  • ExternalName：将服务通过DNS CNAME记录方式转发到指定的域名（通过 spec.externlName 设定） 。需要kube-dns版本在1.7以上。

另外，也可以将已有的服务以Service的形式加入到Kubernetes集群中来，只需要在创建
Service的时候不指定Label selector，而是在Service创建好后手动为其添加endpoint。

Service的实现模型

在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。kube-proxy 负责为 Service 实现了一种 VIP（虚拟 IP）的形式，而不是 ExternalName 的形式。 在 Kubernetes v1.0 版本，代理完全在 userspace。在 Kubernetes v1.1 版本，新增了 iptables 代理，但并不是默认的运行模式。 从 Kubernetes v1.2 起，默认就是 iptables 代理。在Kubernetes v1.8.0-beta.0中，添加了ipvs代理。在 Kubernetes v1.0 版本，Service 是 “4层”（TCP/UDP over IP）概念。 在 Kubernetes v1.1 版本，新增了 Ingress API（beta 版），用来表示 “7层”（HTTP）服务。
kube-proxy 这个组件始终监视着apiserver中有关service的变动信息，获取任何一个与service资源相关的变动状态，通过watch监视，一旦有service资源相关的变动和创建，kube-proxy都要转换为当前节点上的能够实现资源调度规则（例如：iptables、ipvs）。

userspace代理模式

当客户端Pod请求内核空间的service iptables后，把请求转到给用户空间监听的kube-proxy 的端口，由kube-proxy来处理后，再由kube-proxy将请求转给内核空间的 service ip，再由service iptalbes根据请求转给各节点中的的service pod。
这个模式有很大的问题，由客户端请求先进入内核空间的，又进去用户空间访问kube-proxy，由kube-proxy封装完成后再进去内核空间的iptables，再根据iptables的规则分发给各节点的用户空间的pod。这样流量从用户空间进出内核带来的性能损耗是不可接受的。在Kubernetes 1.1版本之前，userspace是默认的代理模型。

iptables代理模式

客户端IP请求时，直接请求本地内核service ip，根据iptables的规则直接将请求转发到到各pod上，因为使用iptable NAT来完成转发，也存在不可忽视的性能损耗。另外，如果集群中存在上万的Service/Endpoint，那么Node上的iptables rules将会非常庞大，性能还会再打折扣。iptables代理模式由Kubernetes 1.1版本引入，自1.2版本开始成为默认类型。

ipvs代理模式

Kubernetes自1.9-alpha版本引入了ipvs代理模式，自1.11版本开始成为默认设置。客户端IP请求时到达内核空间时，根据ipvs的规则直接分发到各pod上。kube-proxy会监视Kubernetes Service对象和Endpoints，调用netlink接口以相应地创建ipvs规则并定期与Kubernetes Service对象和Endpoints对象同步ipvs规则，以确保ipvs状态与期望一致。访问服务时，流量将被重定向到其中一个后端Pod。

与iptables类似，ipvs基于netfilter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着ipvs可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs为负载均衡算法提供了更多选项，如，rr轮询，lc最小连接数，dh目标哈希，sh源哈希，sed最短期望延迟，nq不排队调度。
注意： ipvs模式假定在运行kube-proxy之前在节点上都已经安装了IPVS内核模块。当kube-proxy以ipvs代理模式启动时，kube-proxy将验证节点上是否安装了IPVS模块，如果未安装，则kube-proxy将回退到iptables代理模式。

当某个服务后端pod发生变化，标签选择器适应的pod有多一个，适应的信息会立即反映到apiserver上,而kube-proxy一定可以watch到etc中的信息变化，而将它立即转为ipvs或者iptables中的规则，这一切都是动态和实时的，删除一个pod也是同样的原理。

Service定义

Service配置清单重要字段

apiVersion:
kind:
metadata:
spec:
　　clusterIP: 可以自定义，也可以动态分配
　　ports:（与后端容器端口关联）
　　selector:（关联到哪些pod资源上）
　　type：服务类型

Service的服务类型
对一些应用（如 Frontend）的某些部分，可能希望通过外部（Kubernetes 集群外部）IP 地址暴露 Service。
Kubernetes ServiceTypes 允许指定一个需要的类型的 Service，默认是 ClusterIP 类型。
Type 的取值以及行为如下：

  • ClusterIP：通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的 ServiceType。
  • NodePort：通过每个 Node 上的 IP 和静态端口（NodePort）暴露服务。NodePort 服务会路由到 ClusterIP 服务，这个 ClusterIP 服务会自动创建。通过请求 :，可以从集群的外部访问一个 NodePort 服务。
  • LoadBalancer：使用云提供商的负载均衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务。
  • ExternalName：通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容（例如， foo.bar.example.com）。 没有任何类型代理被创建，这只有 Kubernetes 1.7 或更高版本的 kube-dns 才支持。

创建ClusterIP类型Service

[[email protected] manifests]# vim redis-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: redis
  namespace: default
spec:
  selector:
    app: redis
    role: logstore
  clusterIP: 10.97.97.97
  type: ClusterIP
  ports:
  - port: 6379    #容器端口
    targetPort: 6379   #Pod端口

创建并查看svc:

[[email protected] manifests]# kubectl apply -f redis-svc.yaml
service/redis created
[[email protected] manifests]# kubectl get svc
NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   10.96.0.1     <none>        443/TCP    4d22h
redis        ClusterIP   10.97.97.97   <none>        6379/TCP   4s

查看redis服务详细信息

[[email protected] manifests]# kubectl describe svc redis
Name:              redis
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"redis","namespace":"default"},"spec":{"clusterIP":"10.97.97.97","...
Selector:          app=redis,role=logstore
Type:              ClusterIP
IP:                10.97.97.97  　#service ip
Port:              <unset>  6379/TCP
TargetPort:        6379/TCP
Endpoints:         10.244.2.43:6379   #此处的ip+端口就是pod的ip+端口
Session Affinity:  None
Events:            <none>

[[email protected] manifests]# kubectl get pods  -o wide
NAME                     READY   STATUS    RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
filebeat-ds-h8rwk        1/1     Running   0          8m36s   10.244.1.39   node01   <none>           <none>
filebeat-ds-kzhxw        1/1     Running   0          8m36s   10.244.2.44   node02   <none>           <none>
readiness-httpget-pod    1/1     Running   0          2d21h   10.244.2.18   node02   <none>           <none>
redis-76c85b5744-94djm   1/1     Running   0          8m36s   10.244.2.43   node02   <none>           <none>

总结：

  • service不会直接到pod，service是直接到endpoint资源，就是地址加端口，再由endpoint再关联到pod。
  • service只要创建完，就会在dns中添加一个资源记录进行解析，添加完成即可进行解析。资源记录的格式为：SVC_NAME.NS_NAME.DOMAIN.LTD.
  • 默认的集群service 的A记录：svc.cluster.local.
  • redis服务创建的A记录：redis.default.svc.cluster.local.

创建NodePort类型Service

将myapp-deploy发布出去，并可以通过集群外部进行访问

[[email protected] manifests]# kubectl get pods --show-labels
NAME                            READY   STATUS    RESTARTS   AGE     LABELS
filebeat-ds-h8rwk               1/1     Running   0          12m     app=filebeat,controller-revision-hash=7f59445876,pod-template-generation=1,release=stable
filebeat-ds-kzhxw               1/1     Running   0          12m     app=filebeat,controller-revision-hash=7f59445876,pod-template-generation=1,release=stable
myapp-deploy-65df64765c-257gl   1/1     Running   0          26s     app=myapp,pod-template-hash=65df64765c,release=canary
myapp-deploy-65df64765c-czwkg   1/1     Running   0          26s     app=myapp,pod-template-hash=65df64765c,release=canary
myapp-deploy-65df64765c-hqmkd   1/1     Running   0          26s     app=myapp,pod-template-hash=65df64765c,release=canary
myapp-deploy-65df64765c-kvj92   1/1     Running   0          26s     app=myapp,pod-template-hash=65df64765c,release=canary
readiness-httpget-pod           1/1     Running   0          2d22h   <none>
redis-76c85b5744-94djm          1/1     Running   0          12m     app=redis,pod-template-hash=76c85b5744,role=logstore

#编辑yaml文件
[[email protected] manifests]# vim myapp-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  selector:
    app: myapp
    release: canary
  clusterIP: 10.99.99.99
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    nodePort: 31111    #节点端口设置非常用端口

创建并查看svc

[[email protected] manifests]# kubectl apply -f myapp-svc.yaml
service/myapp created
[[email protected] manifests]# kubectl get svc
NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1     <none>        443/TCP        4d22h
myapp        NodePort    10.99.99.99   <none>        80:31111/TCP   8s
redis        ClusterIP   10.97.97.97   <none>        6379/TCP       10m

此时可以在集群外使用31111端口进行访问

[[email protected] ~]# while true;do curl http://10.0.0.11:31111/hostname.html;sleep 1;done
myapp-deploy-65df64765c-czwkg
myapp-deploy-65df64765c-czwkg
myapp-deploy-65df64765c-hqmkd
myapp-deploy-65df64765c-czwkg
myapp-deploy-65df64765c-czwkg
myapp-deploy-65df64765c-czwkg
myapp-deploy-65df64765c-257gl
myapp-deploy-65df64765c-czwkg
myapp-deploy-65df64765c-257gl
myapp-deploy-65df64765c-czwkg
myapp-deploy-65df64765c-czwkg
myapp-deploy-65df64765c-czwkg
myapp-deploy-65df64765c-kvj92

总结：从以上例子，可以看到通过NodePort方式已经实现了从集群外部端口进行访问，访问链接如下：http://10.0.0.10:31111 。实践中并不鼓励用户自定义使用节点的端口，因为容易和其他现存的Service冲突，建议留给系统自动配置。

Pod的会话保持

ervice资源还支持Session affinity（粘性会话）机制，可以将来自同一个客户端的请求始终转发至同一个后端的Pod对象，这意味着它会影响调度算法的流量分发功用，进而降低其负载均衡的效果。因此，当客户端访问Pod中的应用程序时，如果有基于客户端身份保存某些私有信息，并基于这些私有信息追踪用户的活动等一类的需求时，那么应该启用session affinity机制。

　　Service affinity的效果仅仅在一段时间内生效，默认值为10800秒，超出时长，客户端再次访问会重新调度。该机制仅能基于客户端IP地址识别客户端身份，它会将经由同一个NAT服务器进行原地址转换的所有客户端识别为同一个客户端，由此可知，其调度的效果并不理想。Service 资源 通过. spec. sessionAffinity 和. spec. sessionAffinityConfig 两个字段配置粘性会话。 spec. sessionAffinity 字段用于定义要使用的粘性会话的类型，它仅支持使用“ None” 和“ ClientIP” 两种属性值。如下：

[[email protected] ~]# kubectl explain svc.spec.sessionAffinity.
KIND:     Service
VERSION:  v1

FIELD:    sessionAffinity <string>

DESCRIPTION:
     Supports "ClientIP" and "None". Used to maintain session affinity. Enable
     client IP based session affinity. Must be ClientIP or None. Defaults to
     None. More info:
     https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

sessionAffinity支持ClientIP和None 两种方式，默认是None（随机调度） ClientIP是来自于同一个客户端的请求调度到同一个pod中:

[[email protected] manifests]# vim myapp-svc-clientip.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  selector:
    app: myapp
    release: canary
  sessionAffinity: ClientIP
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    nodePort: 31111

[[email protected] manifests]# kubectl apply -f myapp-svc-clientip.yaml
service/myapp created

[[email protected] manifests]# kubectl describe svc myapp
Name:                     myapp
Namespace:                default
Labels:                   <none>
Annotations:              kubectl.kubernetes.io/last-applied-configuration:
                            {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"myapp","namespace":"default"},"spec":{"ports":[{"nodePort":31111,...
Selector:                 app=myapp,release=canary
Type:                     NodePort
IP:                       10.106.188.204
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  31111/TCP
Endpoints:                10.244.1.40:80,10.244.1.41:80,10.244.2.45:80 + 1 more...
Session Affinity:         ClientIP
External Traffic Policy:  Cluster
Events:                   <none>

[[email protected] ~]# while true;do curl http://10.0.0.11:31111/hostname.html;sleep 1;done
myapp-deploy-65df64765c-257gl
myapp-deploy-65df64765c-257gl
myapp-deploy-65df64765c-257gl
myapp-deploy-65df64765c-257gl
myapp-deploy-65df64765c-257gl
myapp-deploy-65df64765c-257gl
myapp-deploy-65df64765c-257gl
myapp-deploy-65df64765c-257gl
myapp-deploy-65df64765c-257gl
myapp-deploy-65df64765c-257gl

也可以使用kubectl patch来动态修改

kubectl patch svc myapp -p '{"spec":{"sessionAffinity":"ClusterIP"}}'  #session保持，同一ip访问同一个pod
kubectl patch svc myapp -p '{"spec":{"sessionAffinity":"None"}}'    #取消session

Headless无头Service

有时不需要或不想要负载均衡，以及单独的Service IP。 遇到这种情况，可以通过指定 Cluster IP（spec.clusterIP）的值为 "None" 来创建 Headless Service。

这个选项允许开发人员自由寻找他们自己的方式，从而降低与 Kubernetes 系统的耦合性。 应用仍然可以使用一种自注册的模式和适配器，对其它需要发现机制的系统能够很容易地基于这个 API 来构建。

对这类 Service 并不会分配 Cluster IP，kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由。 DNS 如何实现自动配置，依赖于 Service 是否定义了 selector

[[email protected] manifests]# vim myapp-svc-headless.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp-headless
  namespace: default
spec:
  selector:
    app: myapp
    release: canary
  clusterIP: "None"
  ports:
  - port: 80
    targetPort: 80

部署并查看

[[email protected] manifests]#  kubectl apply -f myapp-svc-headless.yaml
service/myapp-headless created
[[email protected] manifests]# kubectl get svc
NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes       ClusterIP   10.96.0.1        <none>        443/TCP        4d23h
myapp            NodePort    10.106.188.204   <none>        80:31111/TCP   10m
myapp-headless   ClusterIP   None             <none>        80/TCP         2s
redis            ClusterIP   10.97.97.97      <none>        6379/TCP       68m

使用coredns进行解析验证

[[email protected] manifests]# dig -t A myapp-svc.default.svc.cluster.local. @10.96.0.10

; <<>> DiG 9.9.4-RedHat-9.9.4-73.el7_6 <<>> -t A myapp-svc.default.svc.cluster.local. @10.96.0.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35237
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;myapp-svc.default.svc.cluster.local. IN        A

;; AUTHORITY SECTION:
cluster.local.          30      IN      SOA     ns.dns.cluster.local. hostmaster.cluster.local. 1554105626 7200 1800 86400 30

;; Query time: 2 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: 一 4月 01 16:03:40 CST 2019
;; MSG SIZE  rcvd: 157

#10.96.0.10是coredns服务的svc地址
[[email protected] manifests]# kubectl get svc -n kube-system
NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE
kube-dns   ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP   5d

解析普通的svc 来对比查看区别

[[email protected] manifests]# dig -t A myapp.default.svc.cluster.local. @10.96.0.10

; <<>> DiG 9.9.4-RedHat-9.9.4-73.el7_6 <<>> -t A myapp.default.svc.cluster.local. @10.96.0.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26217
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;myapp.default.svc.cluster.local. IN    A

;; ANSWER SECTION:
myapp.default.svc.cluster.local. 5 IN   A       10.99.99.99

;; Query time: 0 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: 一 4月 01 16:09:34 CST 2019
;; MSG SIZE  rcvd: 96

从以上的演示可以看到对比普通的service和headless service，headless service做dns解析是直接解析到pod的，而servcie是解析到ClusterIP的。
headless无头服务主要用在statefulset中。

参考资料

https://www.cnblogs.com/linuxk
马永亮. Kubernetes进阶实战 (云计算与虚拟化技术丛书)
Kubernetes-handbook-jimmysong-20181218

原文地址：https://www.cnblogs.com/wlbl/p/10652899.html

时间： 2024-10-12 16:24:23

Kubernetes之服务发现Service的相关文章

Kubernetes之服务发现及负载Services

Service 概述 kubernetes 中的pod是有生生灭灭的,时刻都有可能被新的pod所代替,而不可复活(pod的生命周期).一旦一个pod生命终止,通过ReplicaSets动态创建和销毁pod(Pod的动态扩缩容,滚动升级 等). 每个pod都有自己的IP,这IP随着pod的生生灭灭而变化,不能被依赖.这样导致一个问题,如果这个POD作为后端(backend)提供一些功能供给一些前端POD(frontend),在kubernete集群中是如何实现让这些前台能够持续的追踪到这些后台的?

Istio技术与实践01： 源码解析之Pilot多云平台服务发现机制

服务模型 首先,Istio作为一个(微)服务治理的平台,和其他的微服务模型一样也提供了Service,ServiceInstance这样抽象服务模型.如Service的定义中所表达的,一个服务有一个全域名,可以有一个或多个侦听端口. type Service struct { // Hostname of the service, e.g. "catalog.mystore.com" Hostname Hostname `json:"hostname"` Addre

Kubernetes如何使用kube-dns实现服务发现

大纲: ?       Kubernetes中如何发现服务 ?       如何发现Pod提供的服务 ?       如何使用Service发现服务 ?       如何使用kube-dns发现服务 ?       kube-dns原理 ?       组成 ?       域名格式 ?       配置 注:本次分享内容基于Kubernetes 1.2版本! 下面从一个简单的例子开始讲解. 1.Kubernetes中如何发现服务 ◆   发现Pod提供的服务 首先使用nginx-deploym

Docker Kubernetes 服务发现原理详解

Docker Kubernetes  服务发现原理详解 服务发现支持Service环境变量和DNS两种模式: 一.环境变量 (默认) 当一个Pod运行到Node,kubelet会为每个容器添加一组环境变量,Pod容器中程序就可以使用这些环境变量发现Service. 环境变量名格式如下: {SVCNAME}_SERVICE_HOST {SVCNAME}_SERVICE_PORT 注:其中服务名和端口名转为大写,连字符转换为下划线. 限制: 1)Pod和Service的创建顺序是有要求的,Servi

kubernetes云平台管理实战： 服务发现和负载均衡（五）

一.rc控制器常用命令 1.rc控制器信息查看 [root@k8s-master ~]# kubectl get replicationcontroller NAME DESIRED CURRENT READY AGE myweb 3 3 3 3m [root@k8s-master ~]# kubectl get rc NAME DESIRED CURRENT READY AGE myweb 3 3 3 5m 2.删除rc [root@k8s-master ~]# kubectl delete

服务发现系统etcd介绍

一.概述 etcd是一个高可用的键值存储系统,主要用于共享配置和服务发现.etcd是由CoreOS开发并维护的,灵感来自于 ZooKeeper 和 Doozer,它使用Go语言编写,并通过Raft一致性算法处理日志复制以保证强一致性.Raft是一个新的一致性算法,适用于分布式系统的日志复制,Raft通过选举的方式来实现一致性,在Raft中,任何一个节点都可能成为Leader.Google的容器集群管理系统Kubernetes.开源PaaS平台Cloud Foundry和CoreOS的Fleet都

K8s基于DNS的服务发现（转）

原文地址:https://www.oschina.net/question/2657833_2201246 1.Kubernetes中如何发现服务 ◆   发现Pod提供的服务 首先使用nginx-deployment.yaml文件创建一个Nginx Deployment,文件内容如图所示: 首先创建两个运行Nginx服务的Pod: 使用kubectl create -f nginx-deployment.yaml指令创建,这样便可以得到两个运行nginx服务的Pod.待Pod运行之后查看一下它

Kubernetes集群中Service的滚动更新

Kubernetes集群中Service的滚动更新 二月 9, 2017 0 条评论 在移动互联网时代,消费者的消费行为已经"全天候化",为此,商家的业务系统也要保持7×24小时不间断地提供服务以满足消费者的需求.很难想像如今还会有以"中断业务"为前提的服务系统更新升级.如果微信官方发布公告说:每周六晚23:00~次日凌晨2:00进行例行系统升级,不能提供服务,作为用户的你会怎么想.怎么做呢?因此,各个平台在最初设计时就要考虑到服务的更新升级问题,部署在Kubern

微服务化之服务拆分与服务发现

本文章为<互联网高并发微服务化架构实践>系列课程的第六篇 前五篇为: 微服务化的基石--持续集成 微服务的接入层设计与动静资源隔离 微服务化的数据库设计与读写分离 微服务化之无状态化与容器化 微服务化之缓存的设计 一.服务拆分的前提 说到微服务,服务拆分是绕不过去的话题,但是微服务不是说拆就能拆的,有很多的前提条件,需要完成前面几节所论述的部分. 首先要有一个持续集成的平台,使得服务在拆分的过程中,功能的一致性,这种一致性不能通过人的经验来,而需要经过大量的回归测试集,并且持续的拆分,持续的演