从Cloud到Docker-容器技术能如何帮助我们改进交易系统

2019-06-14 本文已影响0人 ce2a5fc7b1e4

一、什么是容器？

容器（container）这个词，当我们第一眼看它或许脑子里是这东西：瓶瓶罐罐、盒子箱子、装水、装其他东西的玩意。

总的来说，容器给人第一印象就是——“能装东西”。

那今天我们要说的容器技术是怎么一个概念呢？其实，IT里的容器技术是英文单词Linux

Container的直译。container这个单词有集装箱、容器的含义（主要偏集装箱意思）。不过，在中文环境下，我们要交流这些技术，如果直接翻译成“集装箱技术”

不仅拗口也不贴切，所以结合中国人的用词习惯和文化背景，技术人员更喜欢用“容器”这个词。

不过，如果要形象的理解Linux

Container技术的话，我们还是可以拿“集装箱”打一些比方。我们知道，海边码头里的集装箱是运载货物用的，它是一种按规格标准化的钢制箱子。集装箱的特色，在于其格式划一，并可以层层重叠，所以可以大量放置在特别设计的远洋轮船中（早期航运是没有集装箱概念的，那时候货物杂乱无章的放，很影响出货和运输效率）。有了集装箱，那么这就更加快捷方便的为贸易者提供价廉物美的运输服务。

因此，IT世界里借鉴了这一理念。早期，大家都认为硬件抽象层基于hypervisor的虚拟化方式可以最大程度上提供虚拟化管理的灵活性。各种不同操作系统的虚拟机都能通过hypervisor（KVM、XEN等）来衍生、运行、销毁。然而，随着时间推移，用户发现hypervisor这种方式麻烦越来越多。为什么？因为对于hypervisor环境来说，每个虚拟机都需要运行一个完整的操作系统以及其中安装好的大量应用程序。但实际生产开发环境里，我们更关注的是自己部署的应用程序，如果每次部署发布我都得搞一个完整操作系统和附带的依赖环境，那么这让任务变得很繁重而性能还容易很低下。

基于上述情况，开发者就在想，有没有其他什么方式能让人更加的关注应用程序本身，底层多余的操作系统和环境我们可以共享和复用？换句话来说，那就是我们部署一个服务（比如一个量化交易系统）运行好后，我再想移植到另外一个地方，我可以不用再安装一套操作系统和依赖环境。这就像集装箱运载一样，我把货物一辆兰博基尼跑车（比如我们的量化交易程序），打包放到一容器集装箱里，它通过货轮可以轻而易举的从上海码头（CentOS7.2环境）运送到纽约码头（Ubuntu14.04环境）。而且运输期间，我的兰博基尼（量化交易程序）没有受到任何的损坏（文件、数据没有丢失），在另外一个码头卸货后，依然可以风驰电掣（进行正常的交易）。

Linux

Container容器技术的诞生（2008年）就解决了IT世界里“集装箱运输”的问题。Linux

Container（简称LXC）它是一种内核轻量级的操作系统层虚拟化技术。Linux

Container主要由Namespace和Cgroup两大机制来保证实现。那么Namespace和Cgroup是什么呢？刚才我们上面提到了集装箱，集装箱的作用当然是可以对货物进行打包隔离了，不让A公司的货跟B公司的货混在一起，不然卸货就分不清楚了。那么Namespace也是一样的作用，起隔离的作用。光有隔离还没用，我们还需要对货物进行资源的管理。同样的，航运码头也有这样的管理机制：货物用什么样规格大小的集装箱，货物用多少个集装箱，货物哪些优先运走，遇到极端天气怎么暂停运输服务怎么改航道等等...

通用的，与此对应的Cgroup就负责资源管理控制作用，比如进程组使用CPU/MEM的限制，进程组的优先级控制，进程组的挂起和恢复等等。

二、容器技术的特点

容器的特点其实我们拿跟它跟硬件抽象层虚拟化hypervisor技术对比就清楚了，我们之前也提到过，传统的虚拟化（虚拟机）技术，创建环境和部署应用都很麻烦，而且应用的移植性也很繁琐，比如你要把vmware里的虚拟机迁移到KVM里就很繁琐（需要做镜像格式的转换）。那么有了容器技术就简单了，总结下容器技术主要有三个特点：

1. 极其轻量：只打包了必要的Bin/Lib；

2. 秒级部署：根据镜像的不同，容器的部署大概在毫秒与秒之间（比虚拟机强很多）；

3. 易于移植：一次构建，随处部署；

4. 弹性伸缩：Kubernetes、Swam、Mesos这类开源、方便、好使的容器管理平台有着非常强大的弹性管理能力。

三、容器的标准化

当前，docker几乎是容器的代名词，很多人以为docker就是容器。其实，这是错误的认识，比如除了docker

还有coreos。所以，容器世界里并不是只有docker一家。既然不是一家就很容易出现分歧。任何技术出现都需要一个标准来规范它，不然各搞各的很容易导致技术实现的碎片化，出现大量的冲突和冗余。因此，在2015年，由Google，Docker、CoreOS、IBM、微软、红帽等厂商联合发起的OCI（Open

Container

Initiative）组织成立了，并于2016年4月推出了第一个开放容器标准。标准主要包括runtime运行时标准和image镜像标准。标准的推出，有助于替成长中市场带来稳定性，让企业能放心采用容器技术，用户在打包、部署应用程序后，可以自由选择不同的容器Runtime；同时，镜像打包、建立、认证、部署、命名也都能按照统一的规范来做。

两种标准主要包含以下内容：

1. 容器运行时标准（runtime spec）

a). creating：使用 create 命令创建容器，这个过程称为“创建中” 。

b). created：容器创建出来，但是还没有运行，表示镜像和配置没有错误，容器能够运行在当前平台。

c). running：容器的运行状态，里面的进程处于 up 状态，正在执行用户设定的任务。

d). stopped：容器运行完成，或者运行出错，或者 stop 命令之后，容器处于暂停状态。这个状态，容器还有很多信息保存在平台中，并没有完全被删除。

2. 容器镜像标准（image spec）

a). 文件系统：以 layer 保存的文件系统，每个 layer 保存了和上层之间变化的部分，layer 应该保存哪些文件，怎么表示增加、修改和删除的文件等。

b).

config 文件：保存了文件系统的层级信息（每个层级的 hash

值，以及历史信息），以及容器运行时需要的一些信息（比如环境变量、工作目录、命令参数、mount

列表），指定了镜像在某个特定平台和系统的配置。比较接近我们使用 docker inspect <image_id> 看到的内容;

c). manifest 文件：镜像的 config 文件索引，有哪些 layer，额外的 annotation 信息，manifest 文件中保存了很多和当前平台有关的信息。

d). index 文件：可选的文件，指向不同平台的 manifest 文件，这个文件能保证一个镜像可以跨平台使用，每个平台拥有不同的 manifest 文件，使用 index 作为索引。

四、容器的主要应用场景

容器技术的诞生其实主要解决了PAAS的层的技术实现。像OpenStack、Cloudstack这样的技术是解决IAAS层的问题。IAAS层和PAAS层大家估计也听得很多了，关于他们的区别和特性我这里不在描述。那么容器技术主要应用在哪些场景呢？目前主流的有以下几种：

1. 容器化传统应用容器不仅能提高现有应用的安全性和可移植性，还能节约成本。

每个企业的环境中都有一套较旧的应用来服务于客户或自动执行业务流程。即使是大规模的单体应用，通过容器隔离的增强安全性、以及可移植性特点，也能从 Docker 中获益，从而降低成本。一旦容器化之后，这些应用可以扩展额外的服务或者转变到微服务架构之上。

例如，在2016年高盛就宣布要在一年内将其90%的IT算力资源容器化。

2. 持续集成和持续部署 (CI/CD)通过 Docker 加速应用管道自动化和应用部署，交付速度提高至少 13 倍。

现代化开发流程快速、持续且具备自动执行能力，最终目标是开发出更加可靠的软件。通过持续集成

(CI) 和持续部署 (CD)，每次开发人员签入代码并顺利测试之后，IT 团队都能够集成新代码。作为开发运维方法的基础，CI/CD

创造了一种实时反馈回路机制，持续地传输小型迭代更改，从而加速更改，提高质量。CI 环境通常是完全自动化的，通过 git

推送命令触发测试，测试成功时自动构建新镜像，然后推送到 Docker

镜像库。通过后续的自动化和脚本，可以将新镜像的容器部署到预演环境，从而进行进一步测试。

3. 微服务加速应用架构现代化进程。

应用架构正在从采用瀑布模型开发法的单体代码库转变为独立开发和部署的松耦合服务。成千上万个这样的服务相互连接就形成了应用。Docker

允许开发人员选择最适合于每种服务的工具或技术栈，隔离服务以消除任何潜在的冲突，从而避免“地狱式的矩阵依赖”。这些容器可以独立于应用的其他服务组件，轻松地共享、部署、更新和瞬间扩展。Docker

的端到端安全功能让团队能够构建和运行最低权限的微服务模型，服务所需的资源（其他应用、涉密信息、计算资源等）会适时被创建并被访问。

4. IT 基础设施优化充分利用基础设施，节省资金。

Docker

和容器有助于优化 IT

基础设施的利用率和成本。优化不仅仅是指削减成本，还能确保在适当的时间有效地使用适当的资源。容器是一种轻量级的打包和隔离应用工作负载的方法，所以

Docker

允许在同一物理或虚拟服务器上毫不冲突地运行多项工作负载。企业可以整合数据中心，将并购而来的IT资源进行整合，从而获得向云端的可迁移性，同时减少操作系统和服务器的维护工作。

五，容器技术对交易系统的帮助

容器技术有助于构建一个灵活且强韧的交易系统。

容器技术的到来，让许多量化投资机构可以实现“弯道超车”：

从容器化入手，中小量化投资机构忽然间就获得了一定的“计算资源集合使用”的能力 – 此前只有技术实力较强的科技企业能做Grid Computing。

在软件安装、发布方面，我们还需要去学习、模仿Oracle、IBM们研发什么工具吗？不需要了 – 采用容器、容器编排技术、容器镜像管理技术、容器目录（catalog），我们轻易的“一键发布”应用，而且谁都可以执行。

在打补丁方面，我们还要去参考Redhat开发个升级工具吗？没必要了，因为我们可以不打补丁，已经发布的容器里内容永远不会改变（Immutable），需要修复缺陷或者升级版本，我们就发布新容器

–

发布组件乃至整个全新交易系统，成本都是很低的（并且必须永远维持那么低）。因此，我们也不一定需要什么中心化的、统一的、集中的可视化配置管理工具。

灰度发布、在线升级、多版本生产环境、回滚现在都是容器化系统天然自带的——因为整个系统的发布、部署是低成本的和快速高效的，只要有硬件资源就再发布一套，不行就切换回旧的那套 – 技术界已经在不断总结最佳实践，总有一款套路适合我们。

基于容器的微服务，天然支持多服务版本并存；对于回滚，数据库可能是个问题，但首先一切以数据库为中心就是个很有可能是错误的观念（当然，视应用场景而定），在分布式架构里，关系型数据库有可能不在系统关键路径上、事务有好些办法可以规避、通过很好的面向对象设计解耦内存与持久层的耦合…

实际上，经验告诉我们，关系型数据库被滥用是企业应用软件的通病。

而比解决交易系统运维问题更有趣的，还有这几方面：

Infrastructure

As Code（“基础设施即代码”） –

现在总算不是口号了，对着容器、容器编排技术进行编码，让“无人值守”、“智能运维”真正成为可能。虽然Puppet、Chef、Ansible这些技术早就存在，但是它们基本上仅限于操作基础设施的物理、虚拟资源，与一个专业应用系统通过API深度结合然后基于业务场景、系统业务指标来自我维护，是非常困难的。而容器，基本上只是一个进程，通过其API可以轻易深度整合到交易系统里。