容器服务：来自外部的你好！
容器服务正在改变应用程序的部署和管理方式。但它们究竟是什么呢？它们与其他交付平台的方式相比如何呢？
内部 vs 外部服务
Gartner研究总监Gary Olliffe发表了一篇富有洞察力的文章，题为“微服务：用外部的处理层构建服务 ”，指出微服务架构模式如何处理系统复杂性。在他的文章中，Gary描述了怎样在一个微服务式的应用程序中，每个服务的设计都尽可能简单，以最大限度地提高开发人员的工作效率。但是，复杂性必须存在于某个地方，并且通过微服务方法，这种复杂性被推到个人微服务之外，变成一个通用的服务层。
Gary把（更简单的）微服务的实现称为“内部架构”，将复杂性推到“外部架构”。这种分类为我们提供了一个很好的模型来定义容器服务。
管理应用程序复杂性
所以如果复杂性被推到应用程序之外，谁来处理呢？显然，需要一些处理常用服务的层，即微服务所需的“管道”。
这个新的平台服务如何交付有两个新兴的趋势：
- 应用程序框架：为每种主要语言开发微服务框架。Java有 NetflixOSS， Spring Boot和 Spring Cloud （它抽象了一些NetflixOSS组件）。Go有 Go-kit， Micro等。通常，这些框架是作为一组语言特定的库和运行时服务交付的。
- 容器服务：这些是建立在开放的容器标准之上的，并且是语言或系统无关的。
容器服务
在2015年年中，容器领域的几家供应商在Linux基础下发布了OCI（开放容器倡议）。其目标是将供应商业务流程堆栈和构造以及特定的os构造从容器基元中分离出来。
应用程序容器既是描述应用程序组件中的内容的镜像打包机制，也是指定如何启动和执行应用程序组件的应用程序运行时。毫不疑问，OCI正在处理两个规范：处理应用程序运行时的OCI运行时规范，以及最近公布的涵盖应用程序定义和打包的OCI镜像格式规范。
OCI标准现在让我们利用容器作为运营和管理的标准单元，并围绕容器建立通用的应用服务。
容器服务基于开放的容器标准构建，并在容器外提供通用的应用程序服务。
容器服务可以提供帮助的一些例子是：
- 容器生命周期管理。
- 容器调度和定位。
- 日志。
- 监测。
- 自动恢复
- 自动缩放。
- 注册和发现。
- 负载均衡。
- 请求路由。
- 联网。
- 存储和数据管理。
- 应用安全。
并非所有这些都与微服务直接相关。其他像服务发现和版本感知、请求路由是构建微服务式应用程序所必需的。事实上，在原生云之旅中，最好的做法是将应用程序与底层基础架构分离开来，甚至在容器中部署的传统应用程序也可以从这些服务中获益。
选择一种方法
因此，回到Gary关于推动复杂性到微服务之外的的观点 - 我们现在有几种方法可以考虑：
- 应用程序框架的传统方法，具有编程语言特定的库和运行时组件。
- 基于开放容器计划的容器服务。
虽然没有正确或错误的方法，但了解这两种方法之间的折衷很重要。此外，容器管理工具以及应用程序框架将为平台服务提供不同程度的支持。事实上，在许多情况下，您最终可能会混合使用应用程序框架和容器服务，以涵盖在生产环境中部署和运行微服务式应用程序所需的一切。
应用程序框架 | 容器服务 |
|---|---|
编译时与应用程序耦合 | 运行时与应用程序耦合 |
编程语言特定的库 | 编程语言无关 |
开发人员可以更容易地通过API进行尝试 | 需要一个容器运行时 |
在应用程序中执行（至少是一部分） | 在应用程序之外执行 |
可以针对特定用例进行高度优化（例如NetflixOSS） | 更广泛的用法 - 减少某些用例的优化范围。 |
更少的架构层 | 更多的架构层 |
更难以启用多语言的微服务（大量的库是为一种语言而建立的） | 更容易启用多语言的微服务 |
对“外层”的更改可能需要在应用程序中进行更改 | 对“外层”的更改不需要更改应用程序。 |
升级到“外层”可能需要升级应用程序。 | 升级到“外层”不需要升级应用程序。 |
总结
尽管可以设计平台框架和服务在编译时就集成的微服务应用程序，但使用容器提供了几个好处。除了敏捷性和运行时可移植性之外，容器还可以利用标准层的平台服务，这些平台服务可以清楚地解决构建，部署和运行原生云应用程序时遇到的几个挑战。更妙的是，其中一些容器服务本身作为一组系统容器进行部署和编排，允许额外的管理和真正的多重云应用程序的交付和管理。容器服务帮助您减少维护和升级所需的应用程序代码。向应用程序添加依赖关系应谨慎。在少数情况下，编译公共服务、管理依赖关系、控制版本和升级是有意义的。然而，总的来说，我的建议是尽可能多地向你的应用程序和应用程序容器之外的“外部”架构层推送！
有兴趣了解Nirmata如何在开放容器上构建自适应原生云应用程序管理？请访问我们的网站 nirmata.com 或探索 免费试用15天的Nirmata。