day4-----k8s交付dubbo服务的消费者（3）

交付dubbo服务的消费者（dubbo-demo-consumer）

通过jenkins进行一次cli

打开Jenkins页面，使用admin登录，准备构建dubbo-demo项目

以为dubbo-demo这个流水线已经构建完成了，它是既可以交付dubbo服务的提供者，有可以交付dubbo服务的消费者的
点构建后进行相关的填写工作
注意第三项：git_repo就不能走http了因为他是一个私有仓库，需要走ssh了
克隆的时候需要走ssh通道

第7项为什么用./dubbo-client/target这个目录，因为写代码的人起点名称就叫这个
第8项那个-e -q若是不加上了也没事，就会输出的多一点，加上输出的少一点

点console output能看到输出的过程

我们可以通过容器里面看缓存


你看所有的包都给你拉到这里了
构建完成了可以看蓝海流水线

准备资源配置清单

在200上

[root@hdss7-200 k8s-yaml]# pwd
/data/k8s-yaml
[root@hdss7-200 k8s-yaml]# mkdir dubbo-consumer
[root@hdss7-200 k8s-yaml]# cd dubbo-consumer/
[root@hdss7-200 dubbo-consumer]# vi dp.yaml
[root@hdss7-200 dubbo-consumer]# vi svc.yaml
[root@hdss7-200 dubbo-consumer]# vi ingress.yaml
[root@hdss7-200 dubbo-consumer]# cat dp.yaml 
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: dubbo-demo-consumer
  namespace: app
  labels: 
    name: dubbo-demo-consumer
spec:
  replicas: 1
  selector:
    matchLabels: 
      name: dubbo-demo-consumer
  template:
    metadata:
      labels: 
        app: dubbo-demo-consumer
        name: dubbo-demo-consumer
    spec:
      containers:
      - name: dubbo-demo-consumer
        image: harbor.od.com/app/dubbo-demo-consumer:master_191201_1600
        ports:
        - containerPort: 8080
          protocol: TCP
        - containerPort: 20880
          protocol: TCP
        env:
        - name: JAR_BALL
          value: dubbo-client.jar
        imagePullPolicy: IfNotPresent
      imagePullSecrets:
      - name: harbor
      restartPolicy: Always
      terminationGracePeriodSeconds: 30
      securityContext: 
        runAsUser: 0
      schedulerName: default-scheduler
  strategy:
    type: RollingUpdate
    rollingUpdate: 
      maxUnavailable: 1
      maxSurge: 1
  revisionHistoryLimit: 7
  progressDeadlineSeconds: 600
[root@hdss7-200 dubbo-consumer]# cat svc.yaml 
kind: Service
apiVersion: v1
metadata: 
  name: dubbo-demo-consumer
  namespace: app
spec:
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8080
  selector: 
    app: dubbo-demo-consumer
[root@hdss7-200 dubbo-consumer]# cat ingress.yaml 
kind: Ingress
apiVersion: extensions/v1beta1
metadata: 
  name: dubbo-demo-consumer
  namespace: app
spec:
  rules:
  - host: demo.od.com
    http:
      paths:
      - path: /
        backend: 
          serviceName: dubbo-demo-consumer
          servicePort: 8080
[root@hdss7-200 dubbo-consumer]# 

应用资源配置清单

[root@hdss7-21 ~]# kubectl apply -f http://k8s-yaml.od.com/dubbo-consumer/dp.yaml
deployment.extensions/dubbo-demo-consumer created
[root@hdss7-21 ~]# kubectl apply -f http://k8s-yaml.od.com/dubbo-consumer/svc.yaml
service/dubbo-demo-consumer created
[root@hdss7-21 ~]# kubectl apply -f http://k8s-yaml.od.com/dubbo-consumer/ingress.yaml
ingress.extensions/dubbo-demo-consumer created
[root@hdss7-21 ~]# 
[root@hdss7-21 ~]# kubectl get po -napp

这时候去监控端查看是否有新的接口产生

这个时候应该就可以看出消费者信息已经产生了
hello?需要写，后面的的name=的内容随便写就行不需要必须是wangdao

为什么会出现这个结果呢，因为这是开发在gitee早就定义的

这就是dubbo的神奇之处，调用hello这个方法的时候就像是调用本地方法一样，节约省了本地的资源
有什么好处呢，如果有大的流量过来，我们可以消费者不动，就扩容提供者的pod,这也是无状态的服务

这个时候去看监控的时候会发现接口变多了

但是在前台显示的时候是不变的，因为它会自动给你负载均衡到不同的接口,不过并发就已经大的多了

consumer也是可以自动扩容的，扩容消费者后可以看下traefik已经发生了变化