事件驱动架构中的持续集成与持续部署

作者:禅与计算机程序设计艺术

1.简介

事件驱动架构(Event-driven architecture EDA) 是一个软件设计模式,其特点是通过异步通信机制来解耦并行处理过程,从而实现高度灵活、可伸缩、可扩展、容错性强、响应快、弹性高的系统。在事件驱动架构中,一个重要的构件是事件总线或事件驱动器,它作为消息传递的中枢,负责向订阅者发送事件通知,帮助发布者触发事件并进行相应的业务处理。

相对于面向服务架构(Service-Oriented Architecture SOA),事件驱动架构更加关注应用如何响应外部事件,因此它的架构风格比较偏向函数式编程和分布式计算,具有更高的抽象程度和实时性要求。

企业级应用开发都离不开持续集成CI/CD(Continuous Integration and Continuous Delivery)策略,这种策略旨在自动化构建、测试、部署应用,降低部署风险,提升效率。但是在事件驱动架构中,由于事件本身的非确定性和动态性,使得CI/CD变得复杂起来。

为了能够让持续集成和部署顺利进行,事件驱动架构需要一种新的持续集成和持续部署工具链。那么,什么是持续集成?什么又是持续部署呢?CI/CD又是如何工作的呢?

持续集成就是指频繁地将代码提交到版本控制服务器上,包括自动编译、运行测试等,目的是使产品可以快速迭代、交付更新。持续部署则是在整个过程中保证应用始终处于可用状态,并随时准备接受用户请求,这样才能确保产品质量。

CI/CD流程的核心是源代码管理工具、构建、测试、部署工具的结合。一般来说,这些工具包括Jenkins、GitLab CI、TeamCity、Bamboo、Travis CI、GoCD、CircleCI等。当有新代码提交时,源代码管理工具就会触发构建,自动执行编译和单元测试,生成测试报告;如果测试通过,则继续部署到目标环境。

通常,持续集成和持续部署是通过自动化脚本来实现的,但是由于事件驱动架构的特性,实现持续集成与持续部署就变得复杂了。这里面的关键问题就是如何在异步架构下有效的实现自动化流程。

为了解决这个问题,下面介绍一下基于事件驱动架构的持续集成与持续部署方案。

2.基本概念术语说明

2.1 DevOps

DevOps(Development and Operations together),即开发运维一体化。DevOps是一种文化、方法论和工具的集合,是对IT(信息技术)组织的一种全面转型,试图通过一系列的流程、规范和工具来促进敏捷开发、持续集成和部署,帮助组织实现“Build、Measure、Learn”的目标,从而释放创造力、加速交付价值。

2.2 Continuous Integration(CI)

持续集成(Continuous integration,简称CI)是一种软件开发实践,是一种强调开发人员频繁将代码集成到主干的方法。在持续集成过程中,开发人员会经常集成最新版的产品代码到共享仓库,并进行自动构建和自动测试。如果发现错误,项目经理会及时修复,以尽早发现错误。持续集成也有助于减少合并冲突、节省时间、提升效率。

2.3 Continuous Deployment (CD)

持续部署(Continuous deployment,简称CD)是指通过自动化测试、构建、部署的方式,不间断地将软件的更新、改动,部署到生产环境、集成测试环境或任何其他类型的环境中进行验证。它是持续集成的一种,目的在于减少手动的重复部署,让部署变成自动化的过程。比如说,在自动化测试之后,部署会将应用程序的最新版本推送到生产环境,客户就可以立刻得到最新的应用功能。

2.4 Pipeline

管道(Pipeline)是指流水线,用于将一组连续的操作任务组合起来,形成一个管道。在持续集成/持续部署中,一般用管道来定义一些任务,并按照顺序来执行这些任务。每个阶段都是可重复的,意味着前面已经成功完成的阶段可以直接用来进行后面的操作。

例如,在持续集成中,一般有一个构建任务,会把本地的代码编译为可部署的安装包,另一个测试任务会启动一套完整的自动化测试用例,第三个部署任务会把编译好的安装包部署到测试环境中进行测试。如果所有任务都执行成功,那么接下来就会开始进行第二个循环——持续部署,即把最后的构建成功的安装包推送到生产环境中。

2.5 Job

任务(Job)是管道的一个阶段,在持续集成/持续部署中,通常是执行构建任务、运行测试任务、部署任务之类的。不同的任务之间通常存在依赖关系,即前一个任务的输出作为当前任务的输入。

2.6 Event-driven architecture(EDA)

事件驱动架构(Event-driven architecture,简称EDA)是一种异步通信架构,由事件总线或事件驱动器作为消息传递的中枢,向订阅者发送事件通知,帮助发布者触发事件并进行相应的业务处理。EDA的核心思想是通过异步通信实现松耦合、解耦并行处理,从而实现高度灵活、可伸缩、可扩展、容错性强、响应快、弹性高的系统。

2.7 Messaging service

消息服务(Messaging Service)是EDA架构中消息的载体,负责接收、存储和转发消息。主要分为两类:中间件和平台服务。中间件是指采用独立的软件框架来实现消息传递,如Apache ActiveMQ、RabbitMQ、Kafka等。平台服务则是指由云服务提供商提供的基于云平台的消息服务,如AWS SQS、Azure Queue Storage等。

2.8 Message queue

消息队列(Message Queue)是存放消息的容器,它是通过消息服务提供方提供的消息存储和传递功能实现的。它可以根据实际的需要进行配置和优化,能够支持不同类型的消息,如文本、图像、音频、视频、对象等。

2.9 Source control system

源码管理系统(Source Control System)是EDA架构中的一种特殊的消息服务,它负责存储和管理源代码文件,并且允许多人协作编辑,以便实施持续集成和部署。目前,常用的源码管理系统有Git、GitHub、Bitbucket等。

2.10 Build server

构建服务器(Build Server)也是EDA架构中的一种特殊的消息服务,它负责编译项目源码,并运行自动化测试,产生测试报告。常用的构建服务器有Jenkins、TeamCity、Bamboo等。

2.11 Artifact repository

构件仓库(Artifact Repository)用于存放构建出来的可执行文件或包,供部署服务器下载。构件仓库可以是私有仓库,也可以是共有的仓库,如Maven Central或Nexus Repository。

2.12 Test environment

测试环境(Test Environment)是EDA架构中用于部署测试用的虚拟机或者云主机。它与生产环境隔离,通过消息队列同步消息,可以实现快速的测试和回滚。

2.13 Production environment

生产环境(Production Environment)是EDA架构中用于正式部署的虚拟机或云主机。部署之后,应用程序的流量就会被导流到该环境,即进入生产模式。

2.14 Trigger

触发器(Trigger)是EDA架构中用于引起特定操作的事件或条件。比如,当某些消息到达消息队列时,就可以触发构建任务;当有新的代码提交到源码管理系统时,就可以触发持续集成任务。

2.15 Status report

状态报告(Status Report)是EDA架构中用于监控和报告应用状态的一项服务。它将各种指标收集到一起,汇总展示给用户,让用户能够方便地看到应用的运行情况。

2.16 Change management process

变更管理过程(Change Management Process)是EDA架构中的一项服务,用于管理应用的发布过程,包括需求分析、设计、开发、测试、发布等环节,并能根据反馈结果调整计划。

3.核心算法原理和具体操作步骤以及数学公式讲解

3.1 持续集成工具选择

常见的持续集成工具有Jenkins、TeamCity、Bamboo、Travis CI等,其中Jenkins是一个开源的基于Java的持续集成工具,它提供了超过万种插件,支持多种语言,适用于构建、测试、发布周期的自动化。

3.2 源码管理工具选择

常用的源码管理工具有Git、SVN等。由于团队成员的分布性,推荐使用分布式版本控制系统,如Git。它支持多种操作,包括版本回退、冲突解决、团队协作等。

3.3 创建仓库并添加远程连接

首先登录GitHub网站创建账号,然后创建一个仓库,并记录URL地址,如:https://github.com/username/projectname。然后将远程仓库克隆到本地目录:

git clone https://github.com/username/projectname.git

3.4 配置Jenkins

打开Jenkins首页,点击“新建项”,填写相关参数,如“名称”、“描述”、“类型”。然后点击“确定”创建新的任务。

3.4.1 添加构建步骤

在“构建”页面,选择“添加构建步骤”,并选择“执行shell”
在“命令”输入框内输入以下命令:

mvn clean package

3.4.2 添加触发器

在“触发器”页面,勾选“GitHub hook trigger for GITScm polling”

3.4.3 设置参数化构建

在“构建”页面,勾选“This project is parameterized”并设置参数,如SCM_BRANCH=origin/master

3.4.4 设置凭据

在“凭据”页面,选择“添加”按钮,添加GitHub账号的用户名密码凭据

3.4.5 提交并启动构建

保存所有的设置后,点击“立即构建”按钮,等待构建结束

3.5 测试环境部署

为了让测试环境的部署尽可能的自动化,可以将测试环境的部署操作也纳入到持续集成/持续部署流程中。

3.5.1 安装Vagrant

下载并安装最新版的Vagrant软件。安装后,可以在命令提示符窗口下运行如下命令检查是否安装成功:

vagrant version

3.5.2 创建测试VM

在当前目录打开一个文本编辑器,新建一个名为Vagrantfile的文件,写入以下内容:

Vagrant.configure("2") do |config|
  config.vm.box = "bento/ubuntu-16.04"

  config.vm.provider "virtualbox" do |vb|
    vb.memory = "512"
  end
  
  # setup networking
  config.vm.network "private_network", type: "dhcp"
  config.vm.provision "shell", inline: <<-SHELL
    apt update && 
    apt install -y nginx curl git
  SHELL
  
end

然后运行以下命令:

vagrant up

这条命令会启动一个Ubuntu 16.04系统的虚拟机,并进行简单的网络配置。

3.5.3 配置测试环境

打开浏览器,访问http://localhost:8080,验证测试环境是否安装成功。

3.5.4 编写配置文件

在项目根目录下,新建一个名为deploy.yaml的文件,写入以下内容:

---
- hosts: testserver
  become: yes
  tasks:
    - name: Deploy application
      synchronize:
        src: /var/lib/jenkins/jobs/{{ job_name }}/workspace/target/
        dest: /var/www/html
        owner: www-data
        group: www-data
        recursive: yes

    - name: Restart Nginx
      systemd:
        state: restarted
        name: nginx.service

3.5.5 使用Ansible进行配置部署

安装Ansible:

sudo pip install ansible

在项目根目录下,新建一个名为ansible.cfg的文件,写入以下内容:

[defaults]
inventory           =./hosts
remote_user         = root
host_key_checking   = false
retry_files_enabled = False

创建测试环境的主机列表文件:

[testserver]
testserver

执行以下命令进行部署:

ansible-playbook deploy.yaml --extra-vars="job_name={{ jenkins_job_name }}"

3.6 持续部署工具选择

常见的持续部署工具有CodeDeploy、DockerHub、AWS CodePipeline等。由于产品较为简单,选择AWS CodePipeline。它在亚马逊云(AWS)、微软Azure、谷歌GCE等多个云平台上提供了跨云端部署的能力。

3.7 配置CodePipeline

登录AWS控制台,依次选择“Developer Tools”、“CodePipeline”、“Create pipeline”

3.7.1 连接GitHub仓库

选择“Connect to source provider”选项卡,选择“GitHub”
填入GitHub账户的身份认证信息,选择之前创建的项目仓库

3.7.2 连接AWS CodeBuild

选择“Add stage”按钮,选择“Build”阶段

选择“AWS CodeBuild”
选择一个现有的CodeBuild项目,或创建一个新的CodeBuild项目

选择“CodeBuild buildspec file”:
选择刚才创建的deploy.yaml文件:

3.7.3 部署环节

选择“Deploy”阶段,选择“AWS Elastic Beanstalk”:

选择现有的Elastic Beanstalk应用或创建一个新的应用:
选择“CodeDeploy IAM Role”:

选择“Create new role”:

配置权限策略:
选择“Next”:

配置部署组名称和部署配置:

选择“Next”:

选择要部署到的环境:

选择“Next”:

配置自定义设置:

选择“Save”:

3.7.4 配置管道

选择“Actions”按钮,开始管道的配置
选择“Start Pipeline Execution”
选择要启动的管道
确认并启动管道

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>