精华内容
下载资源
问答
  • 苦于本人英语水平poor..., 对这两个产品的服务组装,服务编排和业务流程编排方面的信息没有得到任何的了解.但这两个方面又是我们项目进行SOA升级的关键所在. 请坛子里的大牛们帮忙介绍介绍,让某人有所明白. ...
  • 服务编排

    2019-03-03 18:38:37
    物理机部署 传统发布流程(以Java spring boot为例) 编译jar包 分发到服务器A,B,C 服务启动,监听到指定端口 配置负载均衡到已启动服务端口 ... 启动服务,通过健康检查QA之后,将服务器...

    物理机部署

    传统发布流程(以Java spring boot为例)

    • 编译jar包
    • 分发到服务器A,B,C
    • 服务启动,监听到指定端口
    • 配置负载均衡到已启动服务端口
    • 服务发布成功

    关于服务更新,为了实现滚动更新,可以让LB绑定的服务逐渐更新

    传统更新流程

    • 编译jar包
    • 分发到服务器A,B,C
    • 将服务器A从LB上解绑,更新服务器A上的服务
    • 启动服务,通过健康检查和QA之后,将服务器A绑定到LB上
    • 继续更新服务器B和C
    • 服务完全更新成功

    拓容流程

    • 新增机器节点
    • 启动jar包
    • 将新节点注册到LB上

    特点

    • 单机端口有限,同一个服务如果在同一个服务器更新,需要不同的端口
    • 动态更新LB
    • 拓容成本高

    服务化部署(这里以kubernetes为例)

    k8s发布流程

    • 构建docker镜像
    • 创建deployment和service,可以限制服务的CPU、Memory等资源,k8s寻找空闲节点启动服务
    • 更新iptables将物理机上指定端口路由到VIP(虚拟服务IP)
    • 绑定物理机端口到LB

    k8s更新流程

    • 构建docker镜像
    • 更新deployment和service,k8s更新某个pod
    • 轮流更新pod,直到所有pod更新完成

    k8s拓容

    • 寻找空闲节点启动服务,直到达到指定数量

    特点

    • 几乎无物理端口限制(k8s需要物理端口作为转发,默认为30000+,数量有限)
    • 服务间通信,可以使用serviceName或者服务的VIP进行访问,内网访问更方便
    • 虚拟化物理机资源,隔离物理资源的细节,资源控制如拓容、服务资源限制方便

    Kubernetes vs Docker swarm

    • 稳定性上,k8s上基于iptables的网络路由比docker swarm的网络更加稳定
    • 配置性上,k8s比docker swarm要复杂,swarm采用manager-worker架构,由manager调度worker,docker 1.12以上对于swarm原生支持,方便启动集群,不过k8s在新版本之后也越来越易于配置
    • 管理系统上,swarm比k8s的UI界面更友好,操作性更强

    微服务架构下的应用

    • 外部访问可以暴露gateway到LB上,外部通过访问LB进行访问
    • 使用k8s或者swarm,服务间通信可以使用serviceName进行访问,也可以利用容器的IP,使用服务注册进行服务查询
    • 自动拓容,当检测到服务的CPU和内存利用率升高,通过水平拓展,增加服务节点;服务压力减少后,逐渐减少服务节点数量
    展开全文
  • 面向服务架构(service oriented architecture,SOA)适用于分布式企业信息系统的跨域集成方案,但其现行的实现方法很难同时较好地实现系统的高度安全性和服务流程编排的松耦合性。为此提出了一种服务访问代理方法,...
  • 高度灵活的库,用于管理和编排JWT工作流程 | | 去做 添加更多示例 提高覆盖率 特征 管理协调JWT以进行用户登录,注销续订 选项1:DynamicVault(使用动态调度,但所需的样板代码少得多) 选项2:DefaultVault...
  • 它是业务流程引擎,使用用户创建的方案插件将不同的系统连接在一起。 建造 依存关系: 2.18+ (可选) (节点10或更高版本) git clone ... cd concord ./mvnw clean install -DskipTests Docker映像 您可以使用...
  • 本文是对Conductor微服务编排工具的使用说明,对初学者有很好的启蒙作用。Conductor是使用广泛的无微服务编排工具,具有良好的微服务编排功能轻量化流程管理控制能力,在微服务架构中使用广泛。
  • 图像识别处理后端演示了如何使用通过 , , 和来编排无服务器处理工作流程。 此工作流程处理上传到Amazon S3的照片,并从图像中提取元数据,例如地理位置,大小/格式,时间等。然后,它使用图像识别来标记照片中的...
  • 文章目录第八课 Kubernetes生产级实践-k8s服务调度编排和Pod深入讲解第一节 健康检查1.1 健康检查-通过Command方式1.2 健康检查-通过HTTP方式1.3 健康检查-通过TCP方式第二节 POD的调度策略2.1 调度流程2.2 S

    第八课 Kubernetes生产级实践-k8s服务调度编排和Pod深入讲解

    tags:

    • k8s
    • 慕课网

    categories:

    • 健康检查
    • 调度器
    • 污点容忍
    • 部署策略
    • Pod深入
    • 投射数据卷
    • Secret
    • ConfigMap
    • DownwardAPI

    第一节 健康检查

    1.1 健康检查-通过Command方式

    1. 在没有健康检查时默认:入口程序不退出那么k8s就认为是正常的。容器中pid为1的程序或者
      ENTRYPOINT指定的程序就是入口程序。显然这种健康方式过于简单。
    2. 例子, 健康检查时容器级别的:
      • initialDelaySeconds: 等待容器启动10秒之后再执行健康检查的命令
      • periodSeconds: 每隔10秒检查一次
      • failureThreshold: 失败的门槛,失败2次我认为它失败了 进行容器重启
      • successThreshold: 从错误到正确只需要通过1次
      • timeoutSeconds: 每次执行健康检查命令时 最长等待时间5秒
        spec:
          containers:
          - name: web-demo
            image: 192.168.242.130/k8s/web:v1
            ports:
            - containerPort: 8080
            livenessProbe:
              exec:
                command:
                - /bin/sh
                - -c
                - ps -ef|grep java|grep -v grep
              initialDelaySeconds: 10
              periodSeconds: 10
              failureThreshold: 2
              successThreshold: 1
              timeoutSeconds: 5
    
    1. 测试一下。
    kubectl apply -f web-dev-cmd.yaml
    kubectl get pods -n dev
    kubectl exec -it  -n dev bash
    kubectl exec -it web-demo-79cf5b99c8-gx2s7  -n dev bash
    # 查看进程 手动健康检查命令
    ps -ef
    ps -ef|grep java|grep -v grep
    # 查看命令结果
    echo $?
    # 容器内强制杀掉进程tail -f /usr/local/tomcat/logs/catalina.out
    kill -9 13
    # 发现容器重启了一次
    kubectl get pods -n dev
    

    1.2 健康检查-通过HTTP方式

    1. path: 应用要访问的路径
    2. port: 容器本身的真实端口
    3. 返回200正常,其他返回失败
       spec:
          containers:
          - name: web-demo
            image: 192.168.242.130/k8s/web:v1
            ports:
            - containerPort: 8080
            livenessProbe:
              httpGet:
                path: /examples/index.html
                port: 8080
                scheme: HTTP
              initialDelaySeconds: 5
              periodSeconds: 5
              failureThreshold: 1
              successThreshold: 1
              timeoutSeconds: 5
    
    1. 测试一下
    kubectl get pods -n dev
    # 发现pod在不断的重启 重启原因是http检测超时
    kubectl describe pod web-demo-577b5d88f6-x5fts -n dev
    # 上面initialDelaySeconds:10 时间设置长一点呀 要不容器没启动你就检查 能检查到吗
    # failureThreshold也要多给两次机会
    

    1.3 健康检查-通过TCP方式

    1. 补充就绪探针, 例子:
        spec:
          containers:
          - name: web-demo
            image: 192.168.242.130/web:v1
            ports:
            - containerPort: 8080
            livenessProbe:
              tcpSocket:
                port: 8080
              initialDelaySeconds: 20
              periodSeconds: 10
              failureThreshold: 2
              successThreshold: 1
              timeoutSeconds: 5
            readinessProbe:
              tcpSocket:
                port: 8080
              initialDelaySeconds: 20
              periodSeconds: 10
              failureThreshold: 2
              successThreshold: 1
              timeoutSeconds: 5
    
    1. 测试一下。
    kubectl create -f web-dev-tcp.yaml
    kubectl get pods -n dev -o wide
    # readinessProbe 决定下面的available字段 可以提供服务
    kubectl get deploy -n dev -o wide
    
    1. 这里有一些工作中的策略。
      • 如果restart频率比较低,几天几十天一次。不让它重启,保留上下文去解决问题。
      • 如果是稳定复现的问题。去掉livenessProbe,让它一直成功。进入环境当成沙箱环境,先排查问题。

    第二节 POD的调度策略

    2.1 调度流程

    在这里插入图片描述

    1. ApiServer向ETCD数据中心交互。优先级队列用于存储等待调度的优先级列表。Informer用来监听ApiServer的变化。
    # nodeName这个字段,在pod刚刚创建时是不存在的只有在调度器调度后,它才会把字段加上去。
    kubectl get pod web-demo-79cd8f9f4-bqp72 -n dev -o yaml
    
    1. 如果每次调度pod就去ApiServer请求信息,性能必然会差。k8s设计了一个Cache, 它从ApiServer取信息保存起来
    2. **预选策略,**初步过滤掉不符合的节点。剩余内存,cpu,端口,volume类型,nodeSeletor必须匹配。
    3. 优选策略,上一步筛选的node进行评分。
    4. 然后pod和Node进行绑定,把绑定信息告诉ApiServer。然后更新pod的那个字段nodeName
    5. 然后指派那个节点的kubelet把服务调度起来

    2.2 Scheduler节点调度的配置

    1. affinity亲和性。nodeAffinity,节点亲和性
    2. requiredDuringSchedulingIgnoredDuringExecution:必须满足下面条件才能调度
    3. nodeSelectorTerms: 节点的选择策略。多个nodeSelectorTerms 是或的关系
    4. matchExpressions:如果有多个,是并且的关系
    5. key: 节点的label名字
    6. preferredDuringSchedulingIgnoredDuringExecution: 最好选择那些节点
    7. weight: 1 最好的权重
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                - matchExpressions:
                  - key: beta.kubernetes.io/arch
                    operator: In
                    values:
                    - amd64
              preferredDuringSchedulingIgnoredDuringExecution:
              - weight: 1
                preference:
                  matchExpressions:
                  - key: disktype
                    operator: NotIn
                    values:
                    - ssd
    
    1. 运行测试
    kubectl apply -f web-dev-node.yaml
    kubectl get pods -n dev -o wide
    # 因为最好不在ssd标签的节点上 所以选择s1
    kubectl get nodes --show-labels
    

    2.3 pod调度的配置

          affinity:
            podAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                  - key: app
                    operator: In
                    values:
                    - web-demo
                topologyKey: kubernetes.io/hostname
              preferredDuringSchedulingIgnoredDuringExecution:
              - weight: 100
                podAffinityTerm:
                  labelSelector:
                    matchExpressions:
                    - key: app
                      operator: In
                      values:
                      - web-demo-node
                  topologyKey: kubernetes.io/hostname
    
    
    1. pod的亲和性。 podAffinity, pod想和那些pod运行在一起,不想和某些pod运行在一起
    2. 上面例子说:要跟app=web-demo的pod运行在一同一节点
    3. topologyKey 对应节点上label的名字
    4. 更好的话:跟app=web-demo-node的pod运行在同一节点
    5. podAntiAffinity 反亲和性调度
    6. 运行测试
    kubectl apply -f web-dev-pod.yaml
    kubectl get pods -n dev -o wide
    

    2.4 污点和污点容忍

    1. 给节点打上一个污点
      • 调度效果:NoSchedule 节点不会把pod调度到这
      • 调度效果:PreferNoSchedule 节点最好不把pod调度到这
      • 调度效果:NoExcute 除了不调度之外 调度了的也给你干掉
    2. 如果没有配置污点容忍,pod不会部署到该节点上的。
    kubectl taint nodes s1 gpu=true:NoSchedule
    # 删除污点
    kubectl taint nodes s1 gpu=true:NoSchedule-
    
    1. 污点容忍例子:
    spec:
          containers:
          - name: web-demo-taint
            image: 192.1687.242.130/k8s/web:v1
            ports:
            - containerPort: 8080
          #第一种表达方式,effect可选值:NoSchedule、NoExecute
          tolerations:
          - key: "gpu"
            operator: "Equal"
            value: "true"
            effect: "NoSchedule"
          #第二种表达方式
          #tolerations:
          #- key: "key"
          #  operator: "Exists"
          #  effect: "NoSchedule"
    
    1. tolerations污点容忍,gpu=true。 effect一定要配置上

    第三节 部署策略实践

    3.1 部署策略

    1. 滚动跟新:Rolling update, 之前修改yaml后重新apply 就是这种方式
    2. 重新创建 : Recreate,先停止旧的服务 在启动新服务
    3. 蓝绿部署: 利用Service的Selector选择不同版本的服务
    4. 金丝雀部署: 通过Ingress,轮询访问不同的服务。之前刷新一下,变一下就是这个
    5. 前面两种是k8s支持的不同的重启策略,后面两种是我们利用了Service的特征结合Deployment完成的部署方式。

    3.2 部署实践-重新创建

    1. Recrete 重新创建
    strategy:
        type: Recreate
    
    1. Recrete测试一下
    # 使用场景不多 更新服务过程中 服务会断掉的 或许在资源不太充足的场景下 每个节点只能有一个实例时使用
    kubectl apply -f web-recreate.yaml
    kubectl delete -f web-recreate.yaml
    

    3.3 部署实践-滚动部署

    1. 滚动部署 Rolling update
      • maxSurge 最大可以超出服务实例数的百分比 比如有四个实例:我们最多可以多启动1个实例
      • maxUnavailable 最大不可用的实例数百分比 有四个实例 必须三个实例可用才行
    spec:
      strategy:
        rollingUpdate:
          maxSurge: 25%
          maxUnavailable: 25%
        type: RollingUpdate
    
    1. 测试下滚动部署
    kubectl apply -f web-rollingupdate.yaml 
    kubectl get pods -n dev
    # 修改镜像从web到spring-web 滚动更新
    kubectl apply -f web-rollingupdate.yaml 
    # 暂停更新
    kubectl rollout pause deploy web-rollingupdate -n dev
    # 开个窗口一直访问服务 可以观察到新版本到旧版本的过程
    while sleep 0.2;do curl "http://web-rollingupdate.mooc.com/hello?name=michael";echo "";done
    # 继续更新
    kubectl rollout resume deploy web-rollingupdate -n dev
    # 发现这个版本不适用 回滚到上一个版本 undo 就可以
    kubectl rollout undo deploy web-rollingupdate -n dev
    

    3.4 部署实践-蓝绿部署

     template:
        metadata:
          labels:
            app: web-bluegreen
            version: v1.0
    
    1. 这里多了个version字段。通过这个字段来控制版本。
    2. 蓝绿部署的过程。
    # 1. 第一步 部署1.0版本的应用
    kubectl apply -f web-bluegreen.yaml
    kubectl apply -f bluegreen-service.yaml
    # 2. 第二部 部署2.0版本的web-bluegreen.yaml
    # 这里修改镜像springboot-web变为web version: v2.0 name: web-bluegreen-v2 这三个地方
    kubectl apply -f web-bluegreen.yaml
    # 3. 第三部 pod都运行起来后 只需修改bluegreen-service.yaml切换流量.把1.0改成2.0
    # 效果没有过渡的痕迹,直接切换流量。使用于新版本线上测试完成后删除旧版本
    kubectl apply -f bluegreen-service.yaml
    while sleep 0.2;do curl "http://web-bluegreen.mooc.com/hello?name=michael";echo "";done
    

    3.5 部署实践-金丝雀部署

    1. 在蓝绿部署的继承上简单修改Selector就变成了金丝雀部署。
    2. 只要把bluegreen-service.yaml中的version字段去掉即可。
    3. 所有的pod都会被轮训交替访问。同时访问两个或者多个版本。
    4. 比如我新开发个功能,但是我不确定是否好用,可以给一些pod让别人尝试。也是人常说的AB测试。

    第四节 Pod的深入学习

    4.1 Pod的设计

    1. Pod是k8s最小的调度单位。
    2. 本质上还是容器的隔离,pod是一个逻辑的概念,物理机上没有一个真实的东西叫pod。pod的本质是共享了network,namespace同一个volume。
    # docker这种指定方式对容器的启动顺序是有要求的 容器间不是一种对等的关系
    docker run --net=xxX --volumes-from=
    
    1. Pause容器。不需要我们显式声明每个pod都会有。

    4.2 Pod的资源学习

    1. volume资源挂载。它的定义是pod层面的。把目录/shared-volume-data挂载到容器的/shared-dubbo和/shared-web中。
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-volume
    spec:
      hostNetwork: true
      hostPID: true
      hostAliases:
        - ip: "192.168.242.130"
          hostnames: 
          - "web.mooc.com"
      containers:
      - name: web
        image: 192.168.242.130/k8s/web:v1
        ports:
        - containerPort: 8080
        volumeMounts:
        - name: shared-volume
          mountPath: /shared-web
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "echo web starting... >> /var/log/message"]
          preStop:
            exec:
              command: ["/bin/sh", "-c", "echo web stoping... >> /var/log/message && sleep 3"]
      - name: dubbo
        env:
        - name: DUBBO_PORT
          value: "20881"
        image: 192.168.242.130/k8s/dubbo:v1
        ports:
        - containerPort: 20881
          hostPort: 20881
          protocol: TCP
        volumeMounts:
        - name: shared-volume
          mountPath: /shared-dubbo
      volumes:
      - name: shared-volume
        hostPath:
          path: /shared-volume-data
    
    1. 测试一下 。POD级别参数
      • hostAliases
      • hostPID
      • hostNetwork
    2. 容器级别参数
      • lifecycle
        • postStart 注意下 容器执行ENTRYPOINT 命令时 同时执行它 并行执行
        • preStop 停止之前做的事 串行执行 它执行完在停止容器。有个超时
    kubectl create -f pod-volume.yaml 
    kubectl get pods -o wide
    # 进入到容器中查看挂载目录 随便创建个文件 touch qnhyn.sh
    docker ps | grep volume
    docker exec -it 65fdf2ef2b36 bash
    # 到挂载目录
    docker exec -it 3b886defe598 bash
    # 这两个容器的hosts文件一样 它是由pod给我们统一管理的
    docker exec -it 65fdf2ef2b36 cat /etc/hosts
    docker exec -it 3b886defe598 cat /etc/hosts
    # 如何自定义自己的hosts文件 通过如下定义hostAliases
    # 是否使用宿主机的网络 hostNetwork: true
    # 是否使用宿主机的进程空间: hostPID: true
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-volume
    spec:
      hostNetwork: true
      hostPID: true
      hostAliases:
        - ip: "192.168.242.130"
          hostnames: 
          - "web.mooc.com"
    
    # pod的字段修改和deployment不一样 很多字段不能直接修改 所以应用时先删除再创建
    kubectl delete  -f pod-volume.yaml
    kubectl create  -f pod-volume.yaml
    # 测试一下
    docker exec -it 4d1995a2f5b0 cat /etc/hosts
    docker exec -it 4d1995a2f5b0 sh
    ps -ef # 发现很多进程 我们使用了宿主机的进程空间 
    netstat -ntlp # 发现很多监听 我们使用了宿主机的network namespace
    tail -f /var/log/message
    
    1. 容器的状态:
      • Pendding 还没有被调度的的状态。如果长时间这个状态可能资源不足,镜像没下载完等
      • containerCreating 被调度了 等待容器创建
      • Running
      • Succeeded && Failed
      • Ready 通过健康检查
      • CrashLoopBackOff 如果没有通过健康检查的话 等待时间过长则一直处于启动失败中
      • UnKnown 未知状态 kubelet和apiserver通讯的问题

    4.3 Pod的投射数据卷ProjectedVolume介绍

    1. 投射数据卷ProjectedVolume: 它是轻量级的volume,通过apiServer投射到pod中的。比如:知道pod需要什么文件,在启动时给你扔过来。
    2. 常用的三种使用方式:
      • Secret
      • ConfigMap
      • DownwardAPI
    kubectl get secret
    # 查看它的具体定义 发现数据都是base64加密的 type: kubernetes.io/service-account-token 
    kubectl get secret default-token-bvh9v -o yaml
    # k8s实际上会把serviceaccount自动加入到每一个pod中 随便一个pod进行查看
    kubectl get pods pod-volume -o yaml
    # 里面有volume.secretName: default-token-bvh9v 挂载到/var/run/secrets/kubernetes.io/serviceaccount 文件夹下 可以到容器中查看
    

    4.4 Secret创建和应用

    1. 创建一个secret Opaque是不透明的意思
    apiVersion: v1
    kind: Secret
    metadata:
      name: dbpass
    type: Opaque
    data:
      username: aW1vb2M=
      passwd:  aW1vb2MxMjM=
    
    # base64加密 aW1vb2M=
    echo -n imooc|base64
    # 把它写到etcd中
    kubectl apply -f secret.yaml
    
    1. Pod使用上面的Secret
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-secret
    spec:
      containers:
      - name: springboot-web
        image: 192.168.242.130/k8s/springboot-web:v1
        ports:
        - containerPort: 8080
        volumeMounts:
        - name: db-secret
          mountPath: /db-secret
          readOnly: true
      volumes:
      - name: db-secret
        projected:
          sources:
          - secret:
              name: dbpass
    
    1. 测试用下。可以动态修改容器中的密码
    kubectl apply -f pod-secret.yaml
    kubectl get pod -o wide
    # 到执行机上
    docker ps | grep secret
    docker exec -it 6ac784681b7a sh
    cd db-secret/
    # 这个用户名密码可以用在数据库
    cat username
    cat passwd
    # 如果这个用户名密码错了 直接修改secret.yaml重新应用即可
    # pod上会延迟自动更新
    

    4.5 ConfigMap创建和应用

    1. 它和secret的应用和部署非常相似,只是它存储的数据不需要加密。比如一些启动参数,参数的配置等等。
    2. 创建ConfigMap
    # 从配置文件game.properties创建ConfigMap
    kubectl create configmap web-game --from-file game.properties
    # ConfigMap简写cm
    kubectl get cm web-game -o yaml
    
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-game
    spec:
      containers:
      - name: web
        image: 192.168.242.130/k8s/springboot-web:v1
        ports:
        - containerPort: 8080
        volumeMounts:
        - name: game
          mountPath: /etc/config/game
          readOnly: true
      volumes:
      - name: game
        configMap:
          name: web-game
    
    1. 测试使用下
    kubectl apply -f pod-game.yaml
    # 节点上
    docker ps | grep game
    docker exec -it 17b6fadf3f4f sh
    cd /etc/config/game/
    cat -n game.properties
    # 试下是否可以直接修改
    kubectl edit cm web-game
    # 每隔5秒看下配置 发现很快就修改完了
    watch -n 5 cat game.properties
    
    1. 另外的方式使用。通过yaml定义配置, 通过环境变量的方式使用
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: configs
    data:
      JAVA_OPTS: -Xms1024m
      LOG_LEVEL: DEBUG
    
    1. 环境变量方式使用。env环境变量
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-env
    spec:
      containers:
      - name: web
        image: 192.168.242.130/k8s/springboot-web:v1
        ports:
        - containerPort: 8080
        env:
          - name: LOG_LEVEL_CONFIG
            valueFrom:
              configMapKeyRef:
                name: configs
                key: LOG_LEVEL
    
    1. 测试使用下
    kubectl apply -f pod-env.yaml 
    # 节点上
    docker ps | grep env
    docker exec -it d0a2c845503f sh
    env | grep LOG
    
    1. 还可以把环境变量应用到我们的启动命令中
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-cmd
    spec:
      containers:
      - name: web
        image: 192.168.242.130/k8s/springboot-web:v1
        command: ["/bin/sh", "-c", "java -jar /springboot-web.jar -DJAVA_OPTS=$(JAVA_OPTS)"]
        ports:
        - containerPort: 8080
        env:
          - name: JAVA_OPTS
            valueFrom:
              configMapKeyRef:
                name: configs
                key: JAVA_OPTS
    

    4.6 DownwardAPI创建和应用

    1. DownwardAPI的作用:是可以让我们在程序中可以取到Pod对象本身的相关信息
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-downwardapi
      labels:
        app: downwardapi
        type: webapp
    spec:
      containers:
      - name: web
        image: 192.168.242.130/k8s/springboot-web:v1
        ports:
        - containerPort: 8080
        volumeMounts:
          - name: podinfo
            mountPath: /etc/podinfo
      volumes:
        - name: podinfo
          projected:
            sources:
            - downwardAPI:
                items:
                  - path: "labels"
                    fieldRef:
                      fieldPath: metadata.labels
                  - path: "name"
                    fieldRef:
                      fieldPath: metadata.name
                  - path: "namespace"
                    fieldRef:
                      fieldPath: metadata.namespace
                  - path: "cpu-request"
                    resourceFieldRef:
                      containerName: web
                      resource: limits.memory
    
    1. 测试使用下
    kubectl apply -f pod-downwardapi.yaml
    docker ps | grep downward
    docker exec -it 6e66ce799088  sh
    cd /etc/podinfo && ls
    cat -n labels
    
    展开全文
  • 在 Camunda Cloud 中使用 Zeebe 轻松构建订单流程,并通过内置的 http worker 编排服务。 了解如何部署您自己的无服务器功能并使用 Zeebe 进行编排。 介绍 所以你听说过并想玩它吗? 或者您只是想建立一个流程并需要...
  • WebSphere Application Server 企业流程编排器(WAS Enterprise Process Choreographer)在 WebSphere Application Server 中支持业务流程。它可以用于编排各种业务流程或流。 在企业中实现的业务流程一般都要求...

    前言

    WebSphere Application Server 企业流程编排器(WAS Enterprise Process Choreographer)在 WebSphere Application Server 中支持业务流程。它可以用于编排各种业务流程或流。

    在企业中实现的业务流程一般都要求人力资源和 IT 资源的结合。业务流程的类型可以多种多样,从 Web 服务导航到对业务事务的支持。业务流程可以是自动的、可恢复的流程,也可以是需要与人交互的流程。使用 WAS 企业流程编排器,您可以将业务流程技术和开放的 J2EE 体系结构提供的任何其他服务结合在一起。

    本文使用一些案例展示了如何通过在当今的商业环境中使用 WAS 企业流程编排器受益。本文解释了 WAS 企业流程编排器使用的一些基本的业务流程概念,并描述了如何开发、使用和管理业务流程。最后,本文还概述了体系结构。





    回页首


    当今商业环境中的业务流程

    今天的公司面临着一个日益严重的问题。业务逻辑和应用程序数据分散在整个组织的多种软件资产中。其中的许多数据都驻留在数据库、打包的应用程序(如企业资源规划(enterprise resource planning(ERP))系统)或后端系统(如 IBM CICS)中。其他的业务逻辑可以在现有的 Java 和 J2EE 应用程序中找到。

    随着开放标准的出现,业务逻辑和应用程序数据不久就可以通过内部和外部可用的 Web 服务获得。公司需要一种方法使他们能够在开发新的基于 J2EE 的应用程序的过程中重用他们现有的软件资产,并且能够利用 Web 服务的力量,而不必在构建每个新应用程序时都另起炉灶。

    WebSphere Application Server 企业版附带的集成 J2EE 工作流功能为应用程序开发提供了一种新的、面向服务的方法,名为 服务编排(Service Choreography)。使用直观的基于业务流程的开发工具,您可以利用现有的软件资产并迅速地定义如何在一个新的 J2EE 应用程序中使用这些资产。例如,您可能想把来自于已打包的 CRM 解决方案的客户信息和来自于现有的面向客户应用程序的 J2EE 组件与新的业务逻辑结合在一起创建一个新的、基于 Web 的订单输入应用程序。然后,通过将该应用程序作为一个 Web 服务向您的业务伙伴公开,您可以扩展它的可用性。

    使用 WebSphere Application Server 企业版,开发者可以用可视的方式编排各种软件资产之间的交互。开发者的工作效率还可以更高,因为他们有一种标准方法用来有效表示任意软件资产、并与之有效交互,因此就不必花时间处理不同的接口和低级 API。拖放(Drag-and-drop)工具使他们能够定义软件资产之间信息的顺序和流。各个软件资产,甚至较大的应用程序工作流都变成了可以在开发其他应用程序的过程中重用的构件。生产率还有可能得到进一步的提高,因为对这些新 J2EE 工作流功能的运行时支持完全集成在应用程序服务器中,从而提供了一个单独的管理和部署环境。

    下面几部分将向您展示如何使用业务流程创建各种类型的应用程序。

    Web 服务的整合 - 基于业务流程的应用程序

    传统上,应用程序包含实现各种业务功能(如“创建订单条目”)的代码以及符合业务要求(如“高价值的订单消息必须被单独批准”)的应用程序的流逻辑代码。只要业务要求发生了变化,代码就必须更改。这些更改通常是针对业务流逻辑的,并且极少影响各个业务功能的实现。

    业务流程的使用改变了应用程序的构建方式。流程引擎允许这样一种应用程序体系结构:它把业务逻辑(流逻辑)的描述与业务功能的实现分开。产生的应用程序结构被称为 基于业务流程的应用程序。控制流由工作流管理系统管理,它负责根据业务逻辑调用各种业务功能。



    基于业务流程的应用程序的结构

    编写一个基于业务流程的应用程序需要完成两个独立的步骤:

    • 编写组件 - 各种业务功能被“照常”实现,即为它们编写代码、购买它们或它们已经存在。业务功能的实际表示可以是,例如:
      • 一个 EJB 方法
      • 一次 JCA 连接器调用,它实现到后端系统(如 CICS)的连接
      • (WSDL)端口类型的一个操作,例如,一个基于 SOAP 的 Web 服务
    • 编写业务流程 - 业务逻辑被描述成一个流程,该流程由流程中需要执行的步骤、这些步骤彼此之间的关系以及它们的排序约束组成。

    业务功能被分配给流程中的每个步骤。一个流程步骤可以是基本步骤,也可以是复合步骤,这就形成了递归的编程模型。

    基于业务流程的应用程序优于传统的应用程序,因为它们拥有许多由负责它们的执行的中间件所保证的特性。这些特性包括:

    • 并发性。如果一个进程包含若干并行的分支,那么中间件可以保证这些分支在并行的线程中(甚至可能在一个群集的不同节点上)并发地执行。
    • 可恢复性。如果系统在执行一个基于进程的应用程序时崩溃,那么该应用程序的执行就从它以前停止的地方继续 - 已执行的步骤就不再重做了。
    • 异构的、分布式的执行。一个业务流程的各种功能的执行(它的步骤)可以分布在一个网络中、分布在异构的操作系统和硬件平台上。
    • 服务的质量范围。流程引擎支持 不可中断的流程(微流)、 可中断的流程(宏流)以及二者的结合。

    涉及的人群

    许多企业正在寻求使其业务流程自动化的方法。无需与人交互的全自动流程的执行成本低,吞吐量高并且响应时间比较短。

    然而,许多现实的流程并不能实现完全自动化。例如,特殊的批准可能必须由被授权的管理人员批示,而不是由机器自动批示。因此,业务流程通常是由自动化的步骤和与人交互的步骤结合在一起组成的。

    下图显示了一个需要与人交互的流程的示例。当一条消息到达该流程的输入队列时,该流程被触发。这种类型的流程也被称为 消息处理流消息流。一般来说,处理这种消息时需要把实现业务流程的步骤和产生一条适当的结果消息的步骤结合起来。然而,当其中任何一个步骤的执行过程中发生异常时,业务流程都需要与人交互来处理异常。



    需要与人交互来处理异常的消息处理流

    只要自动化步骤简短并且不产生异常,那么处理这种类型的流程时吞吐量就会比较高,并且响应时间比较短。虽然与人交互是流程定义的一部分,但如果没有实际执行这些步骤,那么就不会影响流程的执行。业务流程范例轻松地将整个业务流程的描述(包括手工步骤)作为一个单独的流程来支持。流程引擎负责自动流程的高效执行,并负责包含与人的交互来处理异常。

    用补偿撤销复杂的操作

    如今的应用程序一般都要求事务属性,特别是要求保证复杂的请求要么全部执行要么根本不执行。对于传统的事务来说,这是用 ACID 属性原子性、一致性、隔离以及持久性描述的。这是通过事务管理器、资源管理器以及后端系统按照 XA 标准或类似的协议进行合作实现的。这种协作可以确保代表事务执行的操作要么被全部提交要么被全部回滚。

    然而由于许多原因,复杂的请求经常不能被作为一个 ACID 事务来运行:

    • 后端系统或资源管理器可能无法参与 XA 协议。对这些系统的更新被立即执行并且不参与整个事务。如果事务失败,这些更新不会被撤销;复杂请求的处理会产生不一致的状态。
    • 只要事务尚未被提交,那么对它进行的任何更改对于外界来说都是不可见的。隔离属性保证了只有达到事务的最终状态时,这些更改才是可见的。这非常适用于短期运行流程(它们调用同步操作)。
      不过,当一个流程包含异步步骤(例如,由 JMS 消息驱动的后端系统实现的步骤或涉及到与人的交互的步骤)时,必须使流程的中间结果可见。这就意味着 JMS 消息必须被发送出去、有关人们必须执行的步骤(工作项)的信息必须是可用的等等。因此,流程的中间状态必须被提交。
    • 业务流程中有本质上就是非事务性的操作。向客户发送一封信就是一个这样的操作 - 只要信已离开发送方,就无法撤销该操作了。
    • 可中断的流程中的活动可以是事务性的,也可以是非事务性的。事务活动在自己的事务中运行,但一个可中断的流程中并没有一个包含流程中所有活动的事务。因此,没有任何锁来确保整个流程的数据完整性。如果流程失败了,那么可以用补偿来撤销活动已成功进行的更改。

    在所有这些示例中,业务流程的中间结果都是可用的,并且不能仅通过借助事务管理器回滚一个 ACID 事务就撤销它们。相反,必须执行显式恢复原操作的另一个操作:

    • 如果已经调用了一个后端系统来更新数据(例如,增大一个值),就必须再次调用系统(例如,减小该值)。
    • 如果已经将一封信错误地发送给了一个客户,就必须发送另一封信为该错误道歉。

    如果其他操作已经开始使用那些错误提供的结果,那么可能需要一层一层地撤消这些操作。

    为了帮助您定义撤销操作及其自动执行,您可以将一个流程的步骤指定为 补偿对(compensation pairs)。这意味着除标准的“向前”操作之外,还要给活动分配一个“向后”操作,如下图所示。



    使用补偿对向前处理流程

    流程使用向前操作运行。另外,每次调用一个向前操作都要在一个补偿列表中记录它的输入和输出数据。在流程执行期间的任何时候,您都知道已经用哪些数据调用了哪些操作。

    如果流程在其执行过程中发生了故障并且必须被补偿,那么将使用补偿列表驱动流程的向后执行以便重新建立前一个流程状态。对于那些在流程的向前执行过程中已成功执行的操作,将调用与它们相关联的撤销操作并传送原来的数据。例如,撤销操作可能发送一封补偿信告诉客户上一封信发错了,应该被忽略。

    下图显示如何对流程的向前执行过程中执行的活动执行撤销操作。对于那些未定义撤销操作的活动以及在流程的向前执行过程中未被处理的活动,什么都不做。



    使用补偿对向后处理流程

    企业到企业(business-to-business(B2B))流程

    业务流程一般不限于企业中的应用程序和人,它们还涉及到业务伙伴。与这些伙伴的交互可以被轻松地建模为流程的一部分。

    与伙伴的交互有两种类型:

    • 入站(inbound)请求。一个由伙伴发送的请求,请求启动一个业务流程,或者请求将数据作为“对话”的一部分传送给一个正在运行的业务流程。
    • 出站(outbound)请求。一个发送给伙伴的请求,请求启动伙伴处的一个业务流程,或者请求将数据作为“对话”的一部分发送。出站请求的一种特殊情况是业务流程完成并将其结果传递给伙伴。

    对于这两种类型的请求来说,与伙伴的交互都要使用 WebSphere 组件 - Web 服务网关(Web Services Gateway)。该网关负责将入站 Web 服务请求路由到适当的 WebSphere 组件(例如流程引擎)以及将出站 Web 服务请求路由到正确的伙伴。



    一个通过 Web 服务网关与伙伴进行交互的 B2B 案例中的业务流程





    回页首


    业务流程概念

    这一部分解释了 WAS 企业流程编排器所使用的一些基本的业务流程概念。

    业务流程

    元模型(meta model)的顶层构造是流程本身。流程是一个多步骤的操作。流程的图形表示是一张有向图。这张流程图中的主要构造是活动和控制连接器。这些活动描述了要执行的任务,控制连接器则描述了执行这些活动时可能采用的顺序。下图显示了这样一张流程图的示例。



    业务流程的图形表示

    活动用已命名的矩形表示;名称一般描述活动的用途。活动拥有的实现可以包含与人的交互、执行同步或异步调用或者等待传入的事件。提供同步活动实现的服务的示例是基于 SOAP 的 Web 服务、CICS 事务以及 EJB 方法调用。异步调用的一个示例是通过 JMS 发送和接收一条消息。

    控制连接器用箭头表示;箭头的头描述控制流在流程中的流动方向。控制连接器开始处的活动被称作源活动;控制连接器终止处的活动被称为目标活动。

    业务流程有两种类型: 不可中断的流程(微流)和 可中断的流程(宏流)。这两种类型之间的主要差别在于它们的事务行为和资源占用量的大小。

    活动

    有不同类型的活动来执行不同类型的任务。WAS 企业流程编排器支持下列类型的活动:

    • 基本活动
    • 个人活动
    • 接收事件活动
    • 流程活动
    • 空活动

     

    基本活动被用于调用操作或服务。有两种被支持的样式。

    • 调用同步操作(如 EJB 方法、Java 片段、J2EE 连接器或 SOAP 服务)的基本活动。这包括对调用"射后不理(fire and forget)"的基本活动。这种活动的示例是发送一条 JMX 消息而不等待响应,或者是发送一封电子邮件。
    • 调用异步服务(如带有一个 JMS 消息绑定的服务)的基本活动,它稍后要接收响应。

     

    个人活动用于在流程中包含与人的交互。当一个流程进行到一个个人活动时,就为一个人或一组人创建一个工作项。按照流程需求的定义和中心目录中的定义找到适合做此项工作的人被称为 人员分析(staff resolution)。一个人可以检查是否已经为他创建了一个工作项。如果已经为他创建了,那么他可以通过声明该工作项来接受这项工作。当他完成该工作项后,他把产生的数据提供给工作流系统使用。完成这些之后,流程继续进行。

    接收事件活动允许流程等待外部事件。例如,与另一个程序(可能是一个伙伴流程)握手、发出消息、进行一些操作,最后等待外部触发器的触发来继续其操作的流程。通过使用 WAS 企业流程编排器 API,事件被发送给流程。

    流程活动用于对流程进行嵌套。一个流程可以调用本身就调用其他流程的流程,依此类推。这种构造使您能够创建分层流程。这种构造通过将流程分解为子流程还使您能够重用流程逻辑。

    空活动不执行操作。相反,它们充当流程中并行分支的显式同步点,或者允许显式连结或分支节点。

    流程中的活动对数据进行操作;输入数据被传送给一个流程,该流程返回输出或出错数据。在流程内,数据保存在全局变量中。由 Java 片段实现的映射活动可用于转换数据。这些映射活动从一个或多个变量获取输入。结果被写入另一组变量中。为调用一个要求输入消息的活动,各变量被读取。如果该活动产生输出或故障数据,那么这些数据将被映射回同一个变量或另一个变量。

    不可中断的流程(微流)

    不可中断的流程具有以下特征:

    • 它们的运行时间短。
    • 它们运行在一个事务中或者不在事务中运行。
      如果一个流程运行在一个事务中且仅包含事务活动,它就被称为一个 原子球(atomic sphere)[1]。
    • 它们可以包含有事务实现和非事务实现的活动。
    • 它们不能拥有异步活动实现或涉及与人的交互的活动实现。
      异步请求-响应操作要求提交事务以发送请求。然后在一个新事务中处理请求结果。异步通知不期望得到响应。因此,不可中断的流程中支持发送通知。接收事件活动要求有自己的接收事件的事务,因此在不可中断的流程中不被支持。
    • 不可中断的流程中的所有活动都是在一个单独的线程中处理的。因此,所有活动共享同一个线程上下文。

     

    下图显示了一个不可中断的流程及其事务边界。



    不可中断的流程及其事务边界

    WAS 企业流程编排器版本 5.0 仅支持不可中断的事务流程。当一个事务回滚发生时,事务管理器回滚一个不可中断的流程的所有事务活动。其实现不是事务性的活动保持原样。

    不可中断的流程向开发者提供可视化的建模、易于维护以及图形化的调试等优点。只要开发者想开始编写 Java 代码来定义企业 bean 的交互、Java 类、J2C 连接器交互、Web 服务等,就可以使用它们。

    可中断的流程(宏流)

    可中断的流程是现有的工作流系统(如 WebSphere MQ Workflow)中的知名流程类型。例如,可中断的流程可以转到这样一个活动,这个活动需要与人交互或需要来自远程服务的响应,并且数小时、数天、甚至数年地等待,直到期望的事件发生。

    可中断的流程由一组 分层事务(stratified transaction)[3] 组成。这意味在一个包含一组活动的流程中,每一步都是在自己的事务中执行。例如,当一个执行同步服务调用的活动被处理时,将发生下列活动:

    1. 事务开始
    2. 从持久的流程-引擎消息队列中获取携带连接器的布尔值的消息
    3. 如果所有传入的连接器都已触发,就检查开始条件:
      • 如果为 true,则启动活动,也就是调用同步服务
      • 如果为 false,则跳过该活动
    4. 为每个出站控制连接器将一条消息放入持久的流程引擎消息队列中
    5. 将状态更改写入数据库
    6. 提交事务

    如果一个活动是非事务性的(即它的活动实现不参与事务的 2PC 协议),那么发生故障时,可使用 基于补偿的恢复来撤销该活动执行的更改。

    下图显示了一个简单的可中断流程中的各事务边界。

    一个简单的可中断流程中的事务边界

    可中断的流程支持所有的活动类型。事务中执行的活动取决于各种活动类型各自的语义。为了阐明这一点,下图显示了一个几乎使用了所有类型的活动的复杂流程。

    一个复杂的可中断流程中的事务边界

    为了可靠地保存一个流程的导航信息,数据库要存储该流程的持久状态,同时消息传递系统要保存持久的导航状态(即有关流中哪些活动将进入下一个状态的信息)。一个活动实现所使用的数据库、消息传递系统以及事务资源都参与一个两阶段提交(two-phase-commit)协议。因为一个正在运行的流程的完整状态存储在数据库中,所以流程不依赖于特定的应用程序服务器。可中断的流程的资源占用量比不可中断的流程的资源占用量要多得多,因为它们使用持久的存储和事务。

    当一个可中断的流程在一个群集中运行时,每个流程步骤都可以在任何节点上并行执行。负载自动分布在不同的服务器上。

    可中断的流程是完全可向前恢复的。如果正在处理一个可中断流程的应用程序服务器意外终止,任何信息都不会丢失。该流程要么在群集中的另一节点上继续,要么在非群集化的应用程序上等待,一直等到该服务器再次启动。因此,可中断的流程可以被说成是有 涅磐行为(phoenix behavior)[1]。

    流程的生命周期

    当一个可以启动流程的 WAS 企业流程编排器 API 方法被调用时,一个流程的生命开始。所支持的 API 方法是 callinitiate

    • 调用 initiate时,当流程结束时不向调用者返回响应。然而,通过使用个人、同步或接收事件活动,交互可以发生在流程与流程启动者、其他人或其他服务之间。
    • 调用 call时,当流程结束时,流程启动者接收到一个响应。响应机制可以和从一个同步的不可中断流程返回结果一样简单。作为一种替代方法,也可以在流程被调用时提供应答上下文(reply context)。当流程最后返送了响应时,流程引擎使用该上下文。

     

    当流程被启动时,一个现有流程模型的流程实例被创建并被启动。然后流程引擎开始为该业务流程 导航。即,流程引擎确定要激活业务流程的哪些活动以及激活的顺序。一个流程的常规导航继续进行,直到该流程的所有活动都处于终态为止。有效的终态是 finishedfailedexpiredterminated

    当流程进行到它的一个故障终点,或者对流程接收器(sink)的所有传入的控制连接器都求值之后流程就会结束。如果流程是用 call启动的,那么将向流程的调用者返回一个响应。

    请参阅对业务流程引擎的 导航器的描述,以获取关于活动实例的状态过渡的更多信息。





    回页首


    开发、使用和管理业务流程

    开发、使用和管理业务流程需要好几种不同的工具:

    • WebSphere Studio Application Developer - 集成版(WSAD-IE)使您能够创建、部署、安装、测试和调试流程应用程序。WSAD-IE 将一个用于 Java 类、servlet、JSP、EJB 以及静态 HTML 页面的基本开发环境与创建 Java 连接器和 Web 服务的强大企业功能集成在一起。
    • WSAD-IE 通过 WAS 企业流程编排器的流程编排动态构件。
    • WAS 企业流程编排器提供了一个现成可用的 Web 客户机,该客户机使工作流参与者能够访问工作流应用程序及其业务流程。
    • WebSphere Application Server 提供了一个管理控制台来管理业务流程。

     

    用 WSAD-IE 开发流程

    在典型的流程开发案例中,业务分析家和领域专家在抽象级别上定义了业务流程。这包括定义流程、流程的活动及一些条件(这些条件确定按哪条路径执行流程以及何时执行)。

    然后,开发流程的实现。这包括指定哪些服务实现哪些活动。这些服务可以通过 Java 连接器访问后端系统(如 CICS 或 IMS)中的功能,或者使用 Web 服务访问 ERP 系统中的服务。还必须创建涉及到与人的交互的活动。必须定义 GUI 页面和查询为将使用应用程序的人员提供最好的支持。

    您可以在不离开 WSAD-IE 环境的情况下完成所有这些任务。当应用程序准备测试时,您可以在 WSAD-IE 的单元测试环境中部署并安装它。调试和跟踪功能提供了一种非常高效的方法来获取一个准备好用于生产的流程应用程序。

    当在 WSAD-IE 中对流程应用程序进行了充分的测试后,您可以将它部署在生产系统中。除了要额外安装流程压缩文档(process archive(FAR))外,带流程的企业应用程序的安装和任何 J2EE 应用程序的安装都一样。下图显示了如何在 WSAD-IE 中创建企业应用程序以及如何在一个 WebSphere 生产环境中安装它。



    WSAD-IE 中的流程开发

    使用流程、工作项及工作列表

    WAS 企业流程编排器 Web 客户机是基于 servlet 和 JSP 的。您可以按现状使用 Web 客户机,而不必实现任何代码。这使您能够开发和展示以用户为中心的工作流应用程序,而不必对用户界面设计提前进行任何投资。

    然而,工作流用户界面经常需要定制以符合特定的业务流程情景,或者符合现有 Web 站点内公司的外观和感觉。WAS 企业流程编排器提供了一篇教程和一些编码样本来帮助您在保存标准工作流最终用户交互时更改 Web 客户机的外观。

    工作项(也被称为分配)是将“工作的各部分”分配给人们的方式。只有为用户或他所在的小组创建了一个工作项,他才可以使用 Web 客户机与 WAS 企业流程编排器应用程序进行交互。
    为决定是否有工作项在等待,用户要执行一个查询(如 工作项查询)。查询结果就是与查询条件相匹配的工作项。WAS 企业流程编排器既支持特别查询,又支持预定义的查询。预定义的查询被作为工作列表存储。

     


    工作项

    工作项代表一个人或一组人与一个对象之间的关系,通常是一个特定的活动实例。指定对象类型的属性以及将该对象分配给用户的原因进一步描述了这种关系。

    工作项是在下列情况发生时由流程引擎创建的:

    • 一个流程被启动
      然后下列工作项被创建:
      • 供流程启动者处理的工作项
      • 供每个流程读者处理的工作项
      • 供每个流程管理员处理的工作项
      流程启动者就是启动流程的人。流程读者就是拥有读流程及其所有活动的值的权限的人。例如,这包括:如果出现了某些错误条件,就强迫一个流程进入结束状态。
    • 个人活动做好准备。
      然后下列工作项被创建:
      • 供活动的每个可能的所有者处理的工作项
      • 供活动的每个读者处理的工作项
      • 供活动的每个编辑者处理的工作项
      活动的可能的所有者就是可以执行活动所要求的任务的人。活动的读者就是拥有读活动的值这种权限的人。活动的编辑者就是拥有操作一个活动的输出这种权限的人。
    • 个人活动被声明。
      这发生在活动可能的所有者之一声明将对其进行操作的活动时。然后为活动所有者创建一个工作项。
    • 一个个人活动的声明被取消。
      这发生在活动所有者决定异常中止以前声明的一个活动的执行时。然后,声明活动时所创建的工作项被删除。
    • 一个接收事件被激活。
      然后下列工作项被创建:
      • 供活动的每个可能的所有者处理的工作项。可能的所有者被允许发送等候的事件。
    • 一个未经处理的故障在流程的一个活动中发生。
      然后,下列工作项被创建:
      • 供流程的管理员处理的工作项,它允许手工强制重启或强制完成活动。

    当流程结束时,缺省行为就是该流程被删除。为流程创建的工作项也都被删除。

     

    工作列表

    工作列表是持久存储在数据库中的查询。工作列表可被流程应用程序的客户机用来根据预定义的标准过滤工作项。例如,工作列表可以查询某个流程的所有购买请求活动以发现那些要求得到确认的活动。随后,一个流程-应用程序客户机可以使用这张工作列表向角色为“购买请求批准者”的用户展示工作项的结果列表。

    这些查询是使用类似于 SQL 的语法定义的。您可以在查询中包含构造来限制查询结果、对结果进行分类、限制返回对象的数目并指定时区中的差异。只有 WAS 企业流程编排器管理员才可以创建工作列表。

    WAS 企业流程编排器 API 提供了处理工作列表的功能。工作项管理器负责处理工作列表。工作项管理器使您能够进行以下操作:

    • 定义一张工作列表并将其添加到工作列表管理器管理的工作列表集合
    • 从工作项管理器中删除一张工作列表
    • 通过执行各个查询求出工作列表

    管理业务流程

    业务流程管理包括对以下几个方面的管理:

    • 业务流程容器
    • 流程模块
    • 流程模板

     

    本文不讨论其他的管理任务。

     

    业务流程容器

    业务流程容器是为每个安装了 WAS 企业流程编排器的 WebSphere 应用程序服务器配置的。业务流程容器的配置发生在创建新的应用程序服务器时。在配置期间,创建了业务流程容器、它的数据库以及它所要求的不同消息队列之间的关联。完成了最初的配置步骤之后,管理员就可以使用 WebSphere 管理控制台更改业务流程容器的以下设置:

    • 无法处理的流程消息的重试次数
    • 维持队列(retention queue)中消息的最大数目

    如果业务流程容器检测到一个暂时的错误情况(如数据库死锁或连接失败),就把消息存储在维持队列中。一旦错误情况被解决,该消息就从维持队列被送回正常的处理中。

    业务流程容器包含流程模块。

     

    流程模块

    流程模块包含一组流程模板。当把一个企业应用程序安装到应用程序服务器上时,就会在企业应用程序资源库(enterprise application repository(EAR))中为每个流程压缩文档(FAR)创建一个流程模块。随后该流程模块就被添加到应用程序服务器的业务流程容器中。

     

    流程模板

    流程模板是一个部署好的流程模型。流程模板支持下列管理任务:

    • 启动
    • 停止
    • 获取状态

    各个流程模板可以被单独启动和停止。如果一个流程模板被停止了,那么就不能再创建相应流程的新流程实例。这意味着管理员可以禁用一个工作流应用程序的某些功能,例如,出于维护原因。每个流程模板都有一个状态,要么是 started,要么是 stopped





    回页首


    体系结构

    这一部分将概述业务流程引擎的内部结构。这一部分将带领大家看一下各种编程接口,客户机程序可以用这些编程接口来访问业务流程服务。另外,这部分还将更深入地讨论每个组件,描述每个组件的功能以及它在整个系统中的角色。

    编程接口

    WAS 企业流程编排器既提供了一般的编程接口,又提供了特定于流程的编程接口。请参阅 WAS 信息中心以获取关于这些编程接口的更多信息,包括对根据流程引擎编程的介绍、代码示例以及所有外部接口的完整 JavaDoc。

     

    一般的编程接口

    下列流程引擎功能可用作一般的编程接口:

    • 启动流程

      可以通过指定流程模板的名称以及供新实例使用的输入数据来启动一个新的流程实例。另外,您还可以将这个流程实例与一个用户定义的标识关联在一起。稍后,可以用这个标识作为一个辅键来检索这个流程实例。当流程实例完成时,您还可以指定一个由流程引擎调用的回调。

    • 向正在运行的流程发送异步事件

      对于包含 接收事件活动的流程实例,可以使用编程接口来发送相关联的事件。必须传递的参数包括系统生成的或用户定义的目标流程实例标识、事件名称以及事件数据。

    • 分配给个人的查询工作

      该功能可用于检索工作项,方法是使用类似于 SQL 的查询或预定义的 工作列表

    • 处理分配给个人的活动

      这包括一些编程接口,这些接口声明活动(人们就是据此活动接收 工作项)并完成所声明的活动。

    • 执行管理任务

      编程接口可用于查找关于正在运行的流程实例的信息、终止一个正在运行的实例,还可以用于修复已经失败的活动。

    这些一般的编程接口可以通过下面两种形式获得:

    • 一组完整的函数作为业务流程容器提供的无状态会话 EJB 的方法。

      这是首选的从客户机程序(比如提供的 Web 客户机)与流程引擎进行交互的方法。

    • 用于启动新的流程实例并将事件发送给正在运行的流程实例的功能可以通过消息驱动的 bean(message-driven bean(MDB))获得。这个 MDB 接受通过消息的主体传送输入或事件数据的 JMS 消息及其 JMS 属性中的附加信息(如流程模板名称或事件名称)。

      流程引擎接受并认可标准的 JMS 属性(如应答队列的规范)。流程实例一旦完成,就将发送对启动流程消息的应答。

     

     

    特定于流程的编程接口(façade)

    对于每个流程模型,您都可以使用 WSAD-IE 工具来生成一个相关联的 EJB( façade EJB)和一个相关联的 MDB( façade MDB),它们提供用于启动流程实例并将事件发送给正在运行的实例的强类型接口。这些 façade 简化了与某个特定的流程模型进行的交互的编码工作。

    WebSphere 中的业务流程组件

    下图显示了 WebSphere 流程引擎的内部体系结构,又被称为 业务流程容器



    业务流程容器及其组件

     

    导航器(Navigator)

    导航器组件是流程引擎的核心。它管理所有流程实例的状态过渡以及这些流程实例中所有活动的状态过渡。各个流程实例和活动实例的状态表如下面的各图所示。



    流程实例的状态过渡

    一个流程实例的正常寿命从一个启动请求开始。开始时先创建流程实例,并使其进入 running状态中。当该流程实例包含的所有活动都达到结束状态时,该流程实例被标记为 finished。该流程实例隐式停止并退出,或者通过一次显式的 API 调用来停止并退出。

    在异常情况下,流程实例也许会碰到一个没有被作为流程逻辑的一部分处理的故障。在这种情况下,在使流程进入 failed状态之前,它等待活动着的活动完成。如果已经为流程定义了补偿,那么就随后调用补偿。

    流程实例也可以由流程管理员终止。在这种情况下,完成活动着的活动后,流程实例就进入它的 terminated状态。



    活动实例的状态过渡

    创建了一个封闭的流程实例后,流程的各个活动的生命从 inactive状态开始。

    随着流程实例的开始,所有离开其输入节点的控制连接器都被激活。我们可以通过求与它们相关联的过渡条件的值来确定它们的布尔值,这样就会为每个控制连接器产生一个为 true 或 false 的值。然后,向那些作为这些控制连接器的目标的所有活动方向正常继续。

    只要通过控制连接器到达了一个活动,导航器就会检查该活动是否拥有不止一个传入的控制连接器。只有对通向该活动的所有控制连接器都求值后,导航器才尝试激活这个活动。否则,活动的激活将被延期到对所有的连接器都进行求值后,并且该活动仍将处于非活动(inactive)状态。

    当对所有的控制连接器都求值后,开始检查活动的启动条件 - 在 WAS 企业流程编排器中,这个启动条件始终是“至少有一个传入的控制连接器必须为 true”,不能更改。根据对启动条件的求值,将发生下列情况之一:

    • 活动的启动条件值为 false。活动被标记为 skipped。这意味着该活动不被执行,流程将继续进行下去。在不对过渡条件求值的情况下,离开该活动的各个控制连接器的布尔值均被设置为 false。这种处理被称作 死路删除(dead-path elimination)
    • 活动的启动条件值为 true,并且该活动是一个个人活动。在这种情况下,工作项被创建,活动进入 ready状态。在这种状态下,用户可以声明一个活动,当用户对其进行操作时,这种声明将使该活动进入 claimed状态。
    • 活动的启动条件值为 true,并且它是一个由服务实现的元素活动。在这种情况下,活动进入调用期的 running状态。
    • 活动的启动条件值为 true,并且它是一个接收事件活动。在这种情况下,活动进入 waiting状态(图中没有显示),直到接收到一个事件为止。

    当分配给个人活动的个人或基本活动的实现完成活动并产生一个结果时,该活动进入 finished状态。当一个接收事件活动接收到一个等候的事件时,也会进入 finished状态。流程的控制逻辑继续对从该活动开始的控制连接器的过渡条件求值。

    最后,在删除流程时,这个活动作为其中的一部分也被删除。

    有许多用于活动的异常处理的附加状态:

    • 当流程中未处理的活动抛出故障时,该活动就进入 failed状态,并为该活动设置 continue-on-error 标志。
    • 当流程中未处理的活动抛出故障时,该活动就进入 stopped状态,不为该活动设置 continue-on-error 标志。这就有效地产生了缺省的“stop-on-error”语义。
      在 stopped 状态下,活动可以被重试,也可以被完成。这就产生了到 ready、running、finished 或 failed 状态的过渡,过渡到哪种状态取决于请求和活动的类型。
    • 当封闭的流程实例被终止时,如果一个活动是活动的,那么就进入 terminated状态。
    • 最后,如果活动超时,就进入 expired状态。

     

    插件

    导航器将它必须执行的一些任务委托给各个插件。这些插件将导航器与它需要使用的组件分开,使 IBM 将来能够轻松地扩展流程引擎的功能。

    这些插件是为以下操作提供的:

    • 调用活动实现。流程引擎有两个用于此目的的插件,一个插件用于通过 Web 服务调用框架(Web Services Invocation Framework(WSIF))调用(外部)服务,另一个插件用于调用 Java 片段。
    • 在流程中 处理数据,如求条件的值。流程引擎有一个插件可以根据 WSDL 消息理解用 Java 编写的条件。
    • 审计跟踪中记录“有趣”事件。流程引擎有一个插件可以把数据写入到流程引擎的数据库的审计跟踪表中。
    • 根据外部目录 分析员工查询。流程引擎有许多使其能够与外部目录一起工作的插件,如 WAS 用户注册中心或 LDAP 目录。

     

     

    工作项管理(Work Item Management(WIM))

    WIM 组件负责:

    • 在流程引擎的数据库中创建和删除工作项。
    • 根据该数据库分析来自流程参与者的工作项查询。
    • 根据流程引擎中使用的人员目录来分析 员工查询。为了支持不同类型的目录,与目录的交互是通过人员分析插件进行的。
    • 基于实例的授权是以为用户创建的工作项为基础。只有当用户接收到适当的工作项来做时,他们才被授权对一个活动或流程执行操作。例如,只有当流程参与者拥有一个活动的“可能的所有者”工作项时,他们才可以声明该活动。

     

     

    工厂(Factory)

    工厂组件负责管理流程引擎处理的“物理”状态信息。

    它使得数据能够以下列形式之一被存储:

    • 瞬时存储在内存中,不可中断的流程要获得高效率的执行需要这种形式
    • 持久存储在数据库中,可中断的流程要获得持久性需要这种形式

     

    它支持的数据库包括 DB2、Oracle、Sybase 和 Cloudscape。

     

    其他组件

    流程引擎包含一个负责产生诊断信息的 跟踪和记录(tracing and logging)组件。

    façade-session EJBfaçade MDB负责 外部接口的同步生成和异步生成。

    流程引擎使用它的 内部队列将 JMS 消息发送给自己,以便处理 可中断的流程所需的分层事务。这个队列是一个允许消息持久排队的 JMS 队列。

    转载于:https://www.cnblogs.com/hmmcsdd/archive/2006/12/13/IBM-WAS-IDEA.html

    展开全文
  • 话说上次有前辈推荐学习敏捷开发方法,于是我去当当拖了两本书——《敏捷软件开发——原则、模式与实践》《敏捷开发的艺术...版本控制一直在用Google的code服务;客户只能又让自己兼了…… ~~~~以上是胡扯,我...

         话说上次有前辈推荐学习敏捷开发方法,于是我去当当拖了两本书——《敏捷软件开发——原则、模式与实践》和《敏捷开发的艺术》,都是好书,受益匪浅。


         但在这个项目里我是一个人在战斗,怎么办?只能和空气结对~我用Win7的便笺功能作为故事卡片贴桌面上;测试驱动是本来就这么干的;版本控制一直在用Google的code服务;客户只能又让自己兼了……


    ~~~~以上是胡扯,我是分割线~~~~


         在这个发布版里,我重构了之前中期检查时那个版本的对象模型,BPEL元素的对象全部由JAXB来映射;考虑到一些命名空间的细节,我自创的BCP模型也稍作修改;完全重写了从BCP模型到BPEL模型的翻译过程;添加了一个获取方法参数列表的资源服务……


         目前可以实现的流程还是那么多:纯顺序结构、混合顺序结构、与合并和与分叉结构。要体验完整的服务编排和执行,还是得依赖项目组的服务部署服务器和执行引擎(接下来的工作便是模拟一个自己的服务部署服务器和执行引擎)。


          例如下图这个编排方式:


          翻译后的BPEL代码为:(因为没有部署的服务,这段代码只算是一个骨架,没有具体的服务调用数据)

     

    <process name="process" xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable">
      <documentation>This is a test BPEL code.</documentation>
      <partnerLinks/>
      <variables/>
      <sequence>
        <assign name="assign"/>
        <flow>
          <links>
            <link name="link1"/>
            <link name="link2"/>
            <link name="link3"/>
            <link name="link4"/>
            <link name="link5"/>
          </links>
          <receive name="receive0">
            <sources>
              <source linkName="link1"/>
            </sources>
          </receive>
          <assign>
            <targets>
              <target linkName="link1"/>
            </targets>
            <sources>
              <source linkName="link2"/>
            </sources>
          </assign>
          <flow>
            <targets>
              <target linkName="link2"/>
            </targets>
            <invoke name="invoke0">
              <sources>
                <source linkName="link3"/>
              </sources>
            </invoke>
            <invoke name="invoke1">
              <sources>
                <source linkName="link4"/>
              </sources>
            </invoke>
          </flow>
          <assign>
            <targets>
              <joinCondition>$link3 and $link4</joinCondition>
              <target linkName="link3"/>
              <target linkName="link4"/>
            </targets>
            <sources>
              <source linkName="link5"/>
            </sources>
          </assign>
          <reply name="reply0">
            <targets>
              <target linkName="link5"/>
            </targets>
          </reply>
        </flow>
      </sequence>
    </process>
     
         整个部署包我已经上传到了我Google code的项目站点上,扔tomcat里就能跑,有兴趣的可以玩玩:地址

     

    展开全文
  • Greengrass核心组件提供了用于设备侧业务流程编排的功能,以及用于执行Greengrass组件应用程序的生命周期管理的功能。 这包括诸如启动,停止监视组件应用程序的执行,用于组件之间通信的进程间通信服务器,...
  • 这这第三篇ATA中,想分享下平台化中另一个重要方面,平台的服务流程编排 (备注:本文以下提到交易系统,只是举例,可以扩散为业务平台系统) 像本文标题一样,我们想象下,在舞台上,有各种角色...
  • 物理机部署 传统发布流程(以Java spring boot为例) 编译jar包 分发到服务器A,B,C 服务启动,监听到指定端口 配置负载均衡到已启动服务端口 ...启动服务,通过健康检查QA之后,将服务器A绑定到LB上...
  • BPEL 服务编排流程语言。由于基于 OASIS 标准,所以它被工业上广泛接纳。通过WSDL接口进行松偶合集成、富流程构造、稳健的错误处理被清晰定义的可扩展点都是它的突出的特点。 BPEL允许系统集成商得到超出现有更...
  • 为这些流程提供可见性可追溯性。 在暂停,恢复,重启等周围公开控制语义,以获得更好的devops体验。 允许更多地重用现有的微服务,为管理提供更容易的途径。 用户界面可视化流程。 能够在需要时同步处理所有任务。...
  • Web 服务 编制与编排规范

    千次阅读 2015-04-26 17:31:02
    Web 服务正逐渐成为系统架构实现组织内外的业务流程与业务协作的基础,从上面的讨论可以看出,实现的关键是需要一种规范、统一、功能强大的服务与业务流程编排语言,以及与之对应的产品。目前已经存在两种 Web ...
  • ,相对于传统架构,微服务架构下更需要通过各微服务之间的协作来实现一个完整的业务流程,可以说服务编排是微服务架构下的必备技能。但是,编排涉及到RPC、分布式事务等等,编排的质量不能仅仅取决于老师傅的手艺,...
  • 蓝鲸作业流程编排--参数使用

    千次阅读 2020-02-02 14:32:05
    厚诺蓝鲸是腾讯蓝鲸官方授权的技术合作伙伴,可以为客户提供蓝鲸自动化运维解决方案的咨询、服务和实施。基于腾讯蓝鲸智云,厚诺可以为用户提供全面的基础运维服务、多样化的企业级SaaS,以及帮助客户在蓝鲸智云体系...
  • 一.Conductor介绍 ... conductor介绍:主要是帮助我们在Netflix上编制基于微服务的流程。 conductor架构: 4.conductor的安装运行: 从github查看源代码https://github.com/Netflix/conductor git cl...
  • Triggerflow是设计平台中的可扩展,可扩展无服务器的平台,可用于基于事件的无服务器工作流程编排。 触发流遵循事件-条件-动作体系结构,具有状态触发器,该触发器可以以一致且容错的方式聚合,过滤,处理路由...
  • 微服务编排

    万次阅读 2019-03-19 10:35:10
    相对于传统架构,微服务架构下更需要通过各微服务之间的协作来实现一个完整的业务流程,可以说服务编排是微服务架构下的必备技能。但是,编排涉及到RPC、分布式事务等等,编排的质量不能仅仅取决于老师傅的手艺,...
  • 服务协议的多样性带来了消息结构的多样性,而BPEL不支持多样化的服务消息结构,因此在多样化的服务组合方面存在服务交互不匹配的问题...该方法在一定程度上解决了多样化服务编排的问题,对多样化的服务协议类型可扩展。
  • 为什么不进行点对点编排? 基本概念 工作流定义 任务定义 系统任务 工人任务 工作流任务的生命周期 元数据定义 任务定义 重试逻辑 超时政策 工作流定义 工作流程中的任务 连接输入输出 $ {SOURCE.input / ...
  • 这是一个示例,说明如何通过采用一组分布式微服务来建模Saga模式,并使用CamundaBPMN对其进行异步编排。 它涉及3组独立组件。 Camunda平台运行 Camunda Modeler创建的BPMN模型 JavaScript微服务工作者 Camunda ...
  • WSO2 ——(10)ESB功能:服务编排

    千次阅读 2015-02-15 15:32:22
    1 BPS官方文档《Quick Start Guide》(WS_...本章将介绍如何设置启动WSO2 BPS,在WSO2 BPS管理控制台创建、部署测试一个BPEL流程发布包,该流程实现两个数的相加。 1.1 介绍 实现加法运算,不调用外部服务
  • 它是一个完全分布式的,高度可扩展的低代码工作流程编排平台。 它运行在JVM上,并支持Java,KotlinClojure。 (Python也来了!) 您可以在任何地方运行它:本地还是在云中; 在裸机,VM,Docker或K8上。 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 452
精华内容 180
关键字:

服务编排和流程编排