容器服务正在改变应用程序的部署方式和管理方式。但容器服务究竟是什么?它与其他传送平台方式有何不同?
Gartner研究总监Gary Olliffe发表了一篇深刻见解的文章,标题为“微服务:用外部内容建设服务”,文章阐释了微服务架构模式如何处理系统复杂性。在他的文章中,Gary描述了在一个微服务式的应用程序中,怎样把每个服务的设计都尽可能简单化,从而最大限度地提高开发人员的工作效率。但是,复杂性必须去某个地方;通过微服务方法,复杂性被推送到单个的微服务外部的公共服务层。
加里把微服务的(简单化)执行称为“内部体系结构”,把复杂性所被推送到的阶层称为“外部体系结构”。这种分类为我们提供了一个很好的定义容器服务的模式。
所以,如果复杂性被推送到应用程序的外部,谁来处理呢?显然,需要一些处理公共服务的层,即微服务所需的“管道”。
如何传送给新的服务平台方面有两个新兴的趋势:
在2015年年中,几家容器领域的供应商在Linux基础下推出了OCI(开放容器倡议)。该协议的目标是解决供应商业务流程堆栈和构造的不同,以及以容器基元中构造OS特定结构的不同。
应用容器既是描述应用程序组件内部的图像打包机制,又是指定如何启动和执行应用程序组件的应用程式执行。这并不奇怪,因为OCI处理两个规范:处理应用程序运行时的OCI运行规范,以及最近公布的涵盖了应用程序的定义和打包的OCI图像格式规范。
OCI标准目前让我们能把容器作为运行和管理的标准单位,并且在容器周围立共同的应用服务。
容器服务基于开放的容器标准构建,在容器外提供通用的应用程序服务。
有一些容器服务可以提供帮助的例子:
并非所有这些都与微服务直接相关。其他的类似服务发现和版本识别的请求路由,是构建微服务式应用程序所必需的。实际上,在云原生的过程中,最好的做法是将应用程序与底层基础架构分离开。这样的话,即使在容器中部署的传统应用程序也可以从这些服务中获益。
因此,回到Gary关于推送复杂性到微服务之外的观点 - 我们现在有两种方法来考虑:
虽然两种方法中没有正确或错误的方法,但了解两种方法之间的区别很重要。容器编排工具,管理工具,以及应用程序框架,将为平台服务提供不同程度的支持。事实上,在许多情况下,最终可能会混合使用应用程序框架和容器服务,从而在生产环境中能够覆盖部署和运行微服务式应用程序所需的一切。
应用程序框架 | 容器服务 |
---|---|
编译时与应用程序耦合 | 运行时与应用程序耦合 |
语言特定库 | 语言不可知 |
开发人员可以更容易地通过API进行尝试 | 需要一个容器运行 |
(至少部分)在应用程序中执行 | 在应用程序之外执行 |
可以针对特例进行高度优化(例如NetflixOSS) | 用法更广泛的 - 减少某些用例的优化范围。 |
更少的架构层 | 更多的架构层 |
更难以启用多语言混合的微服务(一旦大量的图书馆建立一种语言) | 更容易启用 多语言混合的微服务 |
“外层”的更改可能需要更改应用程序 | “外层”的更改不需要更改应用程序。 |
“外层”升级可能需要升级应用程序。 | “外层” 升级 不需要升级应用程序。 |
尽管可以设计具有与平台框架和服务的编译时集成的微服务应用程序,但使用容器则提供了其他的一些好处。除了敏捷性和运行时可移植性之外,容器还可以利用标准层的平台服务,这些平台服务可以清楚地解决构建、部署、和运行云本机应用程序时遇到的一些挑战。更好的地方是,其中一些容器服务本身可以进行部署和编排,从而更加便于管理和真正的多云应用程序传送和管理。容器服务可以帮助减少维护和升级所需要的应用程序代码。然而应谨慎向应用程序添加依赖关系。在少数情况下,编译公共服务和管理依赖关系,版本控制和升级等方式是有意义的。但总体来说,我建议尽可能地向应用程序容器之外、应用程序之外的“外部”体系结构层推送!
如果您有兴趣了解Nirmata如何在开放容器上构建自适应云本地应用程序管理,请访问我们的 nirmata.com 网站,还可以在Nirmata进行15天免费试用。