Activiti7 探索系列一部署和运行业务流程(一)

本文为翻译文章，如有不合理处请查看原文：https://community.alfresco.com/community/bpm/blog/2018/12/10/getting-started-with-activiti-7-beta

介绍

Activiti 7是Alfresco经过实战考验的Activiti工作流引擎的演变，完全被采用在云环境中运行。 它是根据Cloud Native应用程序概念构建的，与之前的Activiti版本在架构方面有所不同。 还有一个新的Activiti Modeler，我们将在另一篇文章中介绍。

Activiti 7引擎的核心仍然与以前的版本非常相似。但是，它已经变得更加严格地专注于完成一项工作，并且另它出乎意料好的完成，这就是运行BPMN业务流程。Activiti运行时中内置的辅助功能，包括为引擎生成并存储在引擎数据库中的查询和审计数据的API运行时请求提供服务，已从引擎中移出并作为Spring Boot 2微服务运行，每个微服务都在各自的高度可扩展容器中运行。

Activiti引擎的核心库也已经为版本7重新构建，我们将在另一篇文章中介绍它们

Activiti 7 Deep Dive文章系列

本文是详细介绍Activiti 7的系列文章的一部分，应按列出的顺序阅读。

1. 部署和运行业务流程-本文
2. 使用Modeler设计业务流程
3. 构建、部署和运行自定义业务流程
4. 使用核心库

前提条件

你已经安装了Docker

基础概念与技术

以下是在部署和使用Activiti 7产品时您将接触到的概念（术语）和技术列表

虚拟机监视器（hypervisor）

Hypervisor用于在本地主机上运行其他OS实例。 通常，它用于在你的计算机上运行不同的操作系统，例如Mac上的Windows。 当你在主机上运行另一个操作系统时，它称为客户操作系统，它在所谓的虚拟机（VM）中运行。

镜像

镜像是许多可用于实例化容器的软件层。 它是一个轻量级，独立，可执行的软件包，包含运行应用程序所需的一切：代码，运行时，系统工具，系统库和设置。 例如，这可以是Java + Apache Tomcat。 您可以在名为Docker Hub的公共存储库中找到各种Docker镜像。 还有私有镜像存储库（用于商业企业镜像之类的东西），例如Alfresco使用的名为Quay的存储库

容器

镜像的实例称为容器。 你有一个一组层结构描述的镜像。 如果你要启动此镜像，你可以再一个运行的容器中运行该镜像。你可以在不同的容器中运行相同的镜像。

Docker

Docker是最受欢迎的容器平台之一。 Docker提供了基于镜像在容器中部署和运行应用程序的功能。

Docker Compose

当有许多容器构成解决方案时，例如使用Activiti 7，并且需要配置每个容器以便它们可以很好地协同工作，那么就需要一个工具来实现这一点

Docker Compose是一个用于定义和运行多容器Docker应用程序的工具。 使用Compose，可以使用YAML文件来配置应用程序的服务。 并且使用一个简单的命令，就可以从配置中创建并启动所有服务

Dockerfile

Dockerfile是一个脚本，包含一系列连续的指令，指示和命令，这些指令，指令和命令将被执行以形成新的Docker镜像。 执行的每个命令都为镜像产生新的层结构，形成最终新镜像产品。 它们取代了手动和重复执行所有操作的过程。 当Dockerfile完成执行时，最终构建了一个新镜像，然后可以使用它来启动新的Docker容器。

容器和虚拟机之间的区别

了解使用容器和使用VM之间的区别非常重要。 这是一张图片说明：

主要区别在于，当运行容器时，并未启动全新的OS实例。这使得容器更轻便，更快速启动。容器在硬盘上占用的空间也少得多，因为它不需要运送整个操作系统，更多信息请参考What is a Container | Docker.

集群

集群形成由服务器（具有一个或多个容器的节点）组成的共享计算环境，其中资源已集群在一起以支持集群中运行的工作负载和进程：

 

Kubernetes

Docker非常适合在一台主机上运行容器，并为此提供所有必需的功能。 但在当今的分布式服务环境中，真正的挑战是跨服务器和复杂的基础架构管理资源和工作负载。

今天最常用和支持的工具是Kubernetes（希腊语中的“舵手”或“飞行员”），它最初由谷歌创建，然后是开源的。 正如单词所暗示的那样，Kubernetes利用许多有用的功能承担了在许多节点上编排容器的繁琐任务。 Kubernetes是一个开源平台，可用于在集群中运行，扩展和操作应用程序容器。

Kubernetes由几个架构组件组成：

Kubernetes Node-运行一个或多个容器的集群节点

• Kube Proxy - Kubernetes网络代理抽象服务访问点，可以路由到其他节点。
• Kubelet - kubelet是主节点代理。 根据pod模板中的规范确保容器正常运行。
• Pods -这是可以部署的Kubernetes对象模型中的最小单元（参见下一节）。 它表示集群中正在运行的进程。 pod封装了一个应用程序容器，Docker是最常用的容器运行时。
• Labels-附加到Kubernetes对象的元数据，包括pod。

Kubernetes Master

• API Server-前端到群集的共享状态。 提供所有组件使用的ReST API。
• Replication controllers-调节集群的状态。 从pod模板创建新的pod“副本”，以确保正在运行可配置数量的pod
• Scheduler-调度程序通过观察未创建节点的新创建的pod来管理工作负载，并选择一个节点供它们运行

Kubectl-为了从命令行控制和管理kubernetes集群，我们将使用一个名为kubectl的工具。它与kubernetes主服务器中的api服务器通信，后者反过来与各个kubernetes节点通信。

Service 提供了一种低开销的方法，使用标签驱动的选择器将请求路由到集群中的一组逻辑pod后端

下图说明：

 

您可能也听说过Docker Swarm，它类似于Kubernetes

Kubernetes Objects

在Kubernetes工作过程中的创建，部署，管理和销毁不同类型的东西。 我们可以称这些东西为对象。 Kubernetes对象模型中有许多不同类型的对象，可以很好地了解。 下图说明了您可能遇到的一些对象：

 

 

其中一些对象已经很熟悉了，这里有一个列表解释其余的：

1. Container-我们的应用程序所部署的Docker容器
2. Volume-我们的应用程序可以通过指向物理存储的卷存储数据
3. Pod-包含一个或多个容器，它是短暂的，不能保证长久存在
4. Replica Set-管理一组复制的Pod,确保始终运行正确数量的副本
5. Deployment-使用部署来调度pod，这些部署提供副本管理，扩展，滚动更新，回滚，清理等
6. Service-定义一组提供微服务的pod。为群集中的短暂（短期）pod提供稳定的虚拟端点
7. Ingress-一个或多个服务的公共访问点。 Ingress是用于HTTP流量的内置Kubernetes负载平衡框架。使用Ingress，您可以控制外部流量的路由
8. Secret-包含访问令牌并提供对私人镜像的访问
9. Config Map-应用程序的名称和值对属性配置
10. Namespace-一个命名空间中的所有对象名称都不能与另一个命名空间中的对象名称冲突。 Namespace的使用提供了完全隔离，非常适合满足多租户要求

Minikube

Minikube是一种工具，可以在本地轻松运行Kubernetes。 Minikube在笔记本电脑的VM中运行单节点Kubernetes集群。 它主要面向希望尝试Kubernetes或用作开发环境的用户。

Helm

当我们启动并运行了Kubernetes集群，现在可以进行容器部署了。我们可能有很多容器用于诸如数据库层，应用程序层，Web层，搜索层等等。并且它们应该具有不同的可伸缩性和故障转移配置。我们如何有效地处理这个问题？听起来很复杂。

然而，有一种名为Helm的工具可以提供帮助。 它是Kubernetes集群的包管理器。 有了它，我们可以确切地指定数据库层部署应该是什么样子，3个带MySQL的容器，2个备用故障转移容器，像这样的自动缩放等，Helm包被定义为Helm Chart。 每个Chart都是列出或定义的文件集合

1. 应该被部署的Docker容器镜像（指向它们）。
2. 组件的配置
3. 以及解决方案使用的基础架构配置

其他重要的Helm概念：

1. Release-加载到Kubernetes的chart实例
2. Helm Repository-已发布Charts的存储库。在kubernetes.io有一个公共仓库但是只属于他们自己的仓库者。例如Alfresco有自己的charts仓库
3. Template-使用Go语言模板语言编写的Kubernetes配置文件（添加了Sprig函数）

Helm Charts存储在Helm存储库中，就像JAR存储在例如Maven Central中一样。 所以Helm实际上是由Client位和Server位构成的。 Helm的服务器位称为Tiller，在Kubernetes集群中运行。 Helm架构看起来像这样：

不仅是一个包管理器，它还是一个部署管理器，可以进行以下操作：

1. 做可重复的部署
2. 管理依赖关系：重用和共享
3. 管理多个配置
4. 更新，回滚和测试应用程序部署（称为版本）

Activiti 7解决方案与Helm一起打包，Activiti提供了一个Helm存储库，其中包含与Activiti 7组件相关的charts。

云原生应用程序

为了理解Activiti 7的架构，构建和运行方式，了解一下有关Cloud Native应用程序的信息非常有用。 让我们试着通过一个例子来解释。 大约10年前，Netflix正在考虑未来客户可以点击按钮并在线观看电影。没有大量的DvDs被广泛地发送给人们，你无法在想要的地方看到你想要的东西，你只能通过邮件发送有限的DVD，DVD可能会被损坏等.Netflix以有限的方法有效地向客户推荐新电影。

要实施这种新的在线流媒体服务，Netflix必须创建一种新型的在线服务：

1. Web-scale -一切都是分布式的，包括服务和计算能力。 系统具有自我修复功能，具有故障隔离和分布式恢复功能。 会有API驱动的自动化。 多个应用程序同时运行
2. Global-无论您身在何处，电影服务都必须立即在全球范围内提供
3. Highily-available-当您单击按钮查看电影时，它才起作用，否则客户端将不会采用该服务
4. Consumer-facing-在线服务必须直接面向家中的客户

Netflix真正想要的是大规模的速度和访问。 电影网站需要始终开启，始终可用，几乎没有停机时间。 作为消费者，您不会接受由于技术问题而无法观看电影的情况。 他们还知道，在运行时，他们必须不断更改产品，以根据消费者需求添加新功能。 基本上他们必须越来越好，越来越快。 这是Cloud Native应用程序的关键。

那么什么是Cloud Native，它使您能够提供似乎始终在线并且可以连续添加和交付新功能的应用程序？ 以下是Cloud Native应用程序的一些特征：

1. Modularity(模块化) - 应用程序不再是单块，其中所有功能都被整合到一个大型应用程序中。 每个应用程序功能都需要作为独立服务提供，称为微服务。 在Netflix的情况下，他们将看到从传统开发模型转变为100个工程师生产单片DVD租赁应用程序到微服务架构，许多小团队负责数百个微服务的端到端开发，这些微服务一起工作到 每天为数百万Netflix客户提供数字娱乐服务
2. Observability(可观察性) - 使用所有这些微服务，持续监控它们以检测问题然后立即启动服务的新实例非常重要，因此看起来好像整个应用程序始终在工作
3. Deployablity(可部署性) - 将应用程序作为许多微服务提供，使您能够快速，持续地部署这些小型服务。它还意味着您可以独立升级和维护应用程序的不同部分。这些服务也可以被部署在Docker容器，这意味着操作系统是抽象的
4. Testablility(可测试性) - 在进行持续交付时，所有测试都是自动化的，因此我们可以尽快提供新功能
5. Disposability(可处理性) - 在应用程序中删除功能或功能应该非常容易。 如果所有主要功能都作为微服务独立提供，这很容易
6. Replaceablility(可替换性) - 我们可以轻松地替换构成应用程序的功能。 如果易于处理功能并用新功能替换它们，那么应用程序可以非常灵活地满足客户的新要求。

那么与传统应用程序开发相比有哪些主要区别：

1. OS abstraction(操作系统抽象) - 不同的微服务作为Docker容器提供和部署，这意味着我们不必担心我们需要什么操作系统和其他依赖库，这通常是传统应用程序面对的问题。
2. Predictable(可预测) - 我们可以遵守约定，并对我们提供服务的速度和可靠性具有可预测性。 使用一个巨大的整体，很难预测何时可以使用新功能
3. Right size capability(适当大小功能) - 我们可以根据每个服务的负载来上下调整各个服务。 对于传统应用程序，通常会超大部署以满足“未来”峰值负载的需求。
4. Continuous Delivery(cd) (持续交付） - 我们将能够在准备好后立即进行软件更新，因为我们可以依靠自动化测试来快速发现任何回归。 使用一个巨大的单块，您无法轻松更新一个功能，因为您必须先测试整个应用程序，然后才能提供功能更新。 并且通常自动测试覆盖率非常低。
5. Automated scaling(自动扩展)：我们可以非常有效地扩展整个应用程序，并自动依赖于需求和负载。对于传统应用程序，您经常会看到过度扩展和大多数扩展都必须手动完成。
6. Rapid recovery(快速恢复)——我们从失败中恢复的速度有多快。通过对单个微服务的复杂监控，我们可以轻松检测故障并快速恢复。应用程序对完全停机的抵抗力也会更强，因为如果只有一个或几个微服务暂时停机，通常可以继续为客户提供服务。对于一个整体应用程序，可能需要数小时才能找出问题所在的应用程序的哪个部分，从而导致更长的停机时间

那么，今天任何人都可以构建这样的解决方案并且需要特殊的知识和长期的经验吗？是的，你可以开发Cloud Native应用程序，如果你已经了解了有关Cloud Native应用程序的概念，并且了解了一些支持它的更突出的框架，那么你肯定可以做到。

以下是Cloud Native Applications的一些构建块：

1. 服务注册
2. 分布式配置服务
3. 分布式消息传递（流）
4. 分布式记录和监控
5. 网关
6. 断路器，隔板，后备，假装
7. 协议

Spring Cloud框架中提供了许多这些功能，它提供了许多可用于构建Cloud Native应用程序的工具：

云原生解决方案的典型架构如下所示：

 

 

未完待续  点我继续