标签：测试 事件 释放 service 阿里巴巴 动作 方法 ret 情况
作者 | 郝树伟(花名：流生)??阿里云高级研发工程师本文整理自架构师成长系列 2 月17 日直播课程。
关注“阿里巴巴云原生”公众号，回复?“217”，即可获取对应直播回放链接及 PPT 下载链接。
导读：DevOps 是一种软件开发人员和 IT人员之间的合作过程，目标是高效地自动执行软件交付和基础架构更改流程。在云原生时代，企业又如何借助 DevOps 实现产品快速、稳定、高效和安全地迭代，释放业务价值呢？
为了解决传统应用升级缓慢、架构臃肿、不能快速迭代、故障不能快速定位、问题无法快速解决等问题，云原生这一概念横空出世。
Pivotal 是云原生应用的提出者，并推出了 Pivotal Cloud Foundry 云原生应用平台和 Spring 开源 Java 开发框架，成为云原生应用架构中先驱者和探路者。
早在 2015 年 Pivotal 公司的 Matt Stine 就写了一本叫做迁移到云原生应用架构的小册子，其中探讨了云原生应用架构的几个主要特征：
后来 Pivotal 对云原生的定义做过几次更新， 最新的 Pivotal 官网上对云原生应用的最新介绍是关注以下四点：
DevOps 是软件开发人员和 IT 运营之间的合作，目标是自动执行软件交付和基础架构更改流程。它创造了一种文化和环境，可在其中快速、频繁且更可靠地构建、测试和发布软件；
持续交付使得单个应用更改在准备就绪后即可发布，而不必等待与其它更改捆绑发布或等待维护窗口期等事件。持续交付让发布行为变得平淡可靠，因此企业可以以更低的风险频繁交付，并更快地获得最终用户的反馈，直到部署成为业务流程和企业竞争力必不可少的组成部分；
微服务是将应用作为小型服务集合进行开发的架构方法，其中每个服务都可实施业务功能，在自己的流程中运行并通过 HTTP API 进行通信。每个微服务都可以独立于应用中的其他服务进行部署、升级、扩展和重新启动，通常作为自动化系统的一部分运行，可以在不影响最终客户的情况下频繁更新正在使用中的应用；
Google 主导成立了云原生计算基金会（CNCF），对云原生的定义为：
“云原生（Cloud Native）技技术帮助企业和机构在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、 服务网格、微服务、不可变基础设施和声明式 API；这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术可以使开发者轻松地对系统进行频 繁并可预测的重大变更 。”
目前云原生背后最大的推手就是 CNCF，关键技术包括容器、微服务、服务网格、devops，声明式的 API 等等。
云原生应用与传统应用的对比，云原生应用可以充分利用云的优势，灵活地在各个云厂商分发应用，释放企业生产力，聚焦到业务创新上，而不是花费更多的时间在适配和扩展不同的基础设施平台上。
首先我们要清楚地知道， 站在企业的角度来看，在这样一个快捷商业的时代，企业最需要什么？
DevOps 最初的出现打破了开发人员和运维人员之间历来存在的壁垒和沟鸿，加强了开发、运营和质量保证人员之间的沟通、协作与整合。在后 DevOps 时代，我们可以借助容器技术更快地对应用进行迭代上线。
下面是应用发布的一般过程，开发者 push 代码，触发构建，构建过程是拉取源码，应用打包，容器镜像推送，部署。
这个模型其实已经有很多地方充分利用了云原生的优势，比如容器技术、Kubernetes、动态分配 slave pod 等。但还有一些挑战。
首先我们要充分利用云原生技术的优势，云原生可以改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策。在容器领域内，Kubernetes 已经成为了容器编排和管理的社区标准。它通过把应用服务抽象成多种资源类型，比如 Deployment、Service 等，提供了一个云原生应用通用的可移植模型。
在这样的背景下，我们如何在云原生的环境下实践更高效的 DevOps 来达到更有生产力的表现就成为了一个新的课题和诉求。
下面是一个企业应用平台的建设目标：
在此 PaaS 平台的基础上，我们设计了 GitOps 安全发布模型来解决前面我们提到的一些挑战。
在设计 GitOps 发布模型的时候是有以下这些核心诉求的：
GitOps 发布模型有以下特性：
下面是使用 GitOps 管理应用发布到不同 Kubernetes 集群的架构图。
首先是应用源码与构建源码分离，我们可以看到橙色框起来的这两个源码项目，一个是我们的应用源码项目 application-java-demo， 左侧的这个源码项目是用来存放构建源码的，比如 preview pipeline 的 Jenkinsfile， staging pipeline 的 Jenkinsfile，production pipeline 的 Jenkinsfile， 除了 Jenkinsfile 之外，可能还有一些关于动态创建测试环境、连接预发环境或者生产环境的敏感信息，这些敏感信息也可以存放在数据库里，然后这里保存数据库的连接信息。
这个普通应用 application-java-demo 在 Git 仓库里是有不同的分支的，每个分支跟 Kubernetes 集群环境都有一定的对应关系，比如我们这里的设定，master 分支对应的是生产环境，latest 分支对应的是预发环境，其他开发分支对应的是测试环境，测试环境的动态创建和销毁、应用再测试环境的部署发布是开发测试人员自助的服务，但应用想要部署到预发环境和生产环境中的话是需要经过管理员安全审批的。
普通开发者的权限只有创建新代码分支和创建合并请求的权限，除此之外，剩下其他的部分都是管理员才有权限做的，绿色区域是 Jenkins 的流水线任务，当然你也可以是使用其他 cicd 引擎来做这个流水线任务的构建。普通开发者没有 Jenkins 环境的创建 Job 和构建 Job 的权限，也没有更改配置的权限，他有的只是构建 Job 的日志查看权限。
最后是一个时序图，演示一个应用从开发测试到业务上线迭代的一个完整流程：
GitOps 是一套方法论，所以其实是有多种实践的方式的，会有多种多样的好用的工具，比如使用 draft 可以帮助完成应用编排模板的自动化生成，skaffold 用来简化应用构建部署流程，kaniko 可以实现不依赖 docker daemon 的镜像构建和推送，helm 用作应用的包管理工具，还有其他 cicd 引擎像 jenkins，tekton，argo 以及为云原生而生的 jenkinsx 等等。
后面，我们会单独实战演示 GitOps 安全发布模型的工作过程。
参考文献：https://pivotal.io/cn/cloud-native
“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术圈。”
标签：测试 事件 释放 service 阿里巴巴 动作 方法 ret 情况
原文地址：https://blog.51cto.com/13778063/2473929
