正在颠覆技术栈，一文看懂网易数帆轻舟云原生交付实践

随着云计算技术的发展，云原生技术成为当今时代的主流。云原生（Cloud Native）是一种理念，本质上是一套“以利用云计算技术为用户降本增效”的最佳实践与方法论。

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

在云原生场景下如何做好应用的定义与交付也同样影响着企业的成本投入，也影响着股东的每一份利润。

应用的交付

在进入互联网这个行业以来，很长一段时间我理解的应用交付就是程序的安装部署，把业务方给我的程序安装包运行起来就好了。但是，随着在这个行业中逐渐的摸索，我对交付有了新的理解，我认为交付就是将需求转化成某种介质提供给需求方，以达到提供服务能力并创造价值目的的过程。而应用交付的对象是应用更加具体，更侧重于软件的需求交付，但也不仅局限于程序的安装部署了。

应用的交付可以有多种形态。互联网企业或业务团队成立的初衷是实现一些想法或者目标，比如想要即时通讯 IM工具，想要使用电商平台，想要提供互联网检索功能等等。企业创始人或业务负责人给到业务团队的需求是明确的，就如需求目标就是想要一个即使通讯的工具来支撑整个集团的高效沟通，但是业务团队如何实现并交付这样的需求其实是不固定。当然，可以选择从新开发一个新的通讯IM工具来交付这个需求，更可能的情况确是提供一套解决方案采购其他厂商已有的产品，两种方式都是可以满足最初的需求交付，只是满足需求的方式或者说介质不同了罢了。交付需求的介质可能是打包的程序、代码函数、API接口、公有云产品、解决方案、设计图稿甚至是 Markdown 文档等等，只要能满足的需求方的需求即可，并不局限于固有的意识形态。

随着时代技术的演进，应用交付的载体也在不断的变化以满足不同的交付场景，通过对交付过去、现在和未来的方式进行分析，以便对应用交付有更加深入的理解。

传统应用交付(过去)

传统的应用交付是应用交付的基础方式，比如常用的 RPM 软件包或者直接二进制的方式安装运行，比较适合场景相对固定的基础设施。如果有较多的软件包依赖，一般还会搭建一些 YUM 的软件源来快速安装依赖。这类服务的运行一般也可以通过 systemd 或者 supervisor 的方式来管理。

可执行文件直接交付

基于可执行文件交付的应用一般运行方式比较直接，直接在 shell 中运行程序。比如 /opt/myapp.sh 。如果在终端中运行影响使用，一般还会在命令最后添加 & 符号使其在后台运行，如 java -jar myapp.jar &。

直接使用可执行文件交付没有固定的规范约束，每个研发或运维人员的习惯的不一样，文件放置的位置和启动的命令等都会有差异，就导致在运维管理上有较大的困难，因此规范这些文件成为了一个趋势。将可执行文件和配置按照一定的规范要求封装，就是大家常用的软件安装包。

封装成软件包交付

软件包具有特定的格式，这些格式就是对软件安装的规范过程。由于识别和管理软件包的工具不同，出现了大量的不同类型的软件封装方式，如 CentOS 使用 RPM 包，Debian 使用 DEB 包，Java Web 使用 WAR 包，Windows 使用 exe 包等等。这些不同格式的软件由不同的工具来管理和运行，如 WAR 一般使用 tomcat 运行管理，RPM 和 DEB 包使用 systemd 管理服务等。

虽然软件包能够规范文件的管理，但是由于程序的运行处自身可执行文件和配置外，还会有其他例如系统库文件的依赖才能正常运行，这就是程序的运行环境。由于操作系统的种类不同，版本不同，安装的基础库软件不同都会导致无法满足程序正常运行的需要，管理这些运行环境成为新的痛点。Docker 的出现完美的解决了这个问题。

云原生应用交付(现在)

为了实现企业的降本增效的目的，云原生理念成为当前主流，应用交付方式也逐渐云原生化。

基于 Docker 的应用交付

Docker 的镜像将程序以及依赖的软件或库文件一起打包成 Docker 镜像，在这个镜像中有着程序运行所有的依赖，这样无论这个镜像运行在任何支持 Docker 的操作系统的任何版本，都可以将程序运行起来。由于这种特性确实解决了很多应用交付的痛点问题，因此 Docker 一经出现就立马风靡全球。

Docker 镜像将一个应用的交付难度大大降低，但是在多个应用一起交付和管理时就不那么便捷了，而且程序运行还会有依赖和配置的需求，因此多容器服务的管理 docker-compose 被提出。