容器与微服务要“联姻” 你对它们够了解吗?

日期:2016-12-14作者:Tom Nolle

容器   微服务   

【TechTarget中国原创】

在虚拟化和云计算领域,容器大概是发展最快、最广为令人兴奋的技术了,微服务则紧随其后。如果把这两大技术结合起来会碰撞出怎样的火花呢?

云规划人员和应用开发者应该清楚地知道将容器和微服务相结合的好处,然后再把它们结合起来。他们尤其应该注意自己的应用动态,还要为服务联合制订好计划。

容器与微服务关系复杂

容器和微服务之间的关系很复杂,时刻处于变化状态。容器不是微服务部署的必要条件,也不需要用微服务来证明容器使用的必要性。容器是一项运营性工具,可改善部署时间和效率,但是还有其他可与之相较的工具,比如虚拟机(VM)。微服务是增强应用敏捷性和代码重用的一种方式,但是一样也有其他的办法。所以审视自己的软件目标来评估容器能为微服务环境带来哪些好处就非常关键。

我们先从最吸引人的地方开始:运营性技术。大多数IT专业人士都知道,容器是虚拟化的一种,可通过提供一个共享所有组件的公共平台来避免跨机器镜像的操作系统冗余。最常见的容器工具是Docker,它已经是一个非常知名且易用的虚拟化和云组件的部署方式。在虚拟化数据中心和私有云的部署技术方面,容器目前落后于占据统治地位的VM,但是正在迅速发展,有望赶上VM。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

SOA开发>更多

  • 故障注入注定要成为软件专业人士的必备技能

    尽管云改善了企业迅速发布高质量、高能力应用的能力,但专家警告说要小心这些应用会变得太复杂,难以进行人工测试。

  • 容器与微服务要“联姻” 你对它们够了解吗?

    在虚拟化和云计算领域,容器大概是发展最快、最广为令人兴奋的技术了,微服务则紧随其后。如果把这两大技术结合起来会碰撞出怎样的火花呢?

  • 事件驱动框架和SOA在空军的应用

    空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。

  • HTML5促进企业移动化服务走向极致

    在企业困扰于传统移动化方式过于复杂时, HTML5凭借其天然的跨平台特性,乘势而起并逐渐得到企业的关注。可是,由于HMTL5标准建立时间不长,展示性能及稳定性更是需要和浏览器有一个良好的兼容,除此之外企业更是缺乏实际应用经验,所以基于HTML5技术的企业级服务市场还处于一片初创状态。

相关推荐

  • 你的微服务设计支持可重用并避免冗余吗?

    微服务是代码小型的功能捆绑,旨在通过适当的使用来促进可重用并改善QoE以及可用性。如果使用不恰当的话,它们就会成为应用生命周期管理和资源效率的“噩梦”。

  • Red Hat披露更加架构驱动的BPM模型愿景

    Red Hat的一个更加结构化的BPM设计方案有望搭设应用开发界与业务流程管理的桥梁,让企业架构师、开发者和业务侧的人更快速更容易地实时新的业务流程。

  • 中国市场DevOps应用趋势分析

    为了解决开发人员与运维之间的协作问题,从而提升工作效率,DevOps方法论应运而生。几年的发展,DevOps现在国内市场的应用情况如何?如何才能取得DevOps实施的成功?

  • 如何将微服务从AWS撤走

    为了降低成本、改善可伸缩性,大部分组织都搬迁到了AWS上。但通过搬到AWS上,至少有一家公司发现这既能节省成本、改进控制,还能维持一个健壮的服务器基础设施。

技术手册>更多

  • SOA与MDM知识解析

    大多数企业领导人都同意这样的观点:数据是重要的战略资产。因此,有效的信息管理一直是令人难以捉摸的问题。通过正确地使用SOA架构,企业能够利用自己现有的系统,在保持这些系统基本不变的同时为各种单独的应用程序之间有效的信息共享创建一个新的集成解决方案。本技术手册对于SOA与MDM知识进行了简要解析。

  • 解围应用集成困境指南

    集成是个很老的话题,很多时候在谈及新技术的时候,我们会避而不谈,但集成问题却一直贯穿在企业之中。应用集成就是建立一个统一的综合应用,也即将截然不同的、基于各种不同平台、用不同方案建立的应用软件和系统有机地集成到一个无缝的、并列的、易于访问的单一系统中,并使它们就像一个整体一样,进行业务处理和信息共享。要实现这样的效果并不简单,在这本手册中,我们会为您拨开一些迷雾,更好的解决应用集成所面临的问题。

  • 企业OSGi应用开发教程

    在JavaOne 2011上,Peter Kriens关于OSGi做了两个介绍。Kriens的演讲解释了为什么尽管OSGi表现的很难,用OSGi实现模块化对于今天的应用开发者来说是很有价值的。他也解释了如何进入这个领域,同时澄清了一些关于OSGi和模块化应用的错误概念。那么对于模块化应用开发的未来是怎么样的?企业中OSGi应用开发如何实现?在这本教程中我们将为您详细介绍。

  • 移动BPM攻略指导

    随着iPhone,Android等移动设备的兴起,移动设备已经在人们的日常工作中发挥着重要的作用,跨越多个时区的人们经常使用手机进行沟通,重要的是,信息管理要适应移动办公这种新的工作方式,移动应用时代来临了。而对于移动应用来说,业务流程管理(BPM)成为了焦点,使用BPM可以大的提高企业的工作效率。可以这样说,移动BPM开启了企业流程管理的新纪元。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算
【TechTarget中国原创】

在虚拟化和云计算领域,容器大概是发展最快、最令人兴奋的技术了,微服务则紧随其后。如果把这两大技术结合起来会碰撞出怎样的火花呢?

云规划人员和应用开发者应该清楚地知道将容器和微服务相结合的好处,然后再把它们结合起来。他们尤其应该注意自己的应用动态,还要为服务联合制订好计划。

容器与微服务关系复杂

容器和微服务之间的关系很复杂,时刻处于变化状态。容器不是微服务部署的必要条件,也不需要用微服务来证明容器使用的必要性。容器是一项运营性工具,可改善部署时间和效率,但是还有其他可与之相较的工具,比如虚拟机(VM)。微服务是增强应用敏捷性和代码重用的一种方式,但是一样也有其他的办法。所以审视自己的软件目标来评估容器能为微服务环境带来哪些好处就非常关键。

我们先从最吸引人的地方开始:运营性技术。大多数IT专业人士都知道,容器是虚拟化的一种,可通过提供一个共享所有组件的公共平台来避免跨机器镜像的操作系统冗余。最常见的容器工具是Docker,它已经是一个非常知名且易用的虚拟化和云组件的部署方式。在虚拟化数据中心和私有云的部署技术方面,容器目前落后于占据统治地位的VM,但是正在迅速发展,有望赶上VM。

开发方面,微服务是朝着应用组件化以及组件松绑这一长期趋势的一次演进。小的、普遍有用的软件功能都是作为网络连接型服务发布出去的,这样可以跨应用进行重用。通过让每一个应用使用通用功能或特性的一份拷贝,还可以减少软件镜像大小,并且通过创建接近于组件组成或者无代码的新软件模型来增强开发。在与包括SOA在内的其他新应用开发模型的竞争当中,微服务正在赢得优势。

对于因为担心hypervisor以及VM复杂性而尚未考虑采用虚拟化或者采用私有云的用户来说,容器提供了托管微服务的一个非常出色的轻量级解决方案。你可以快速部署容器,快速替换容器,可以移动甚至复制容器。如果遭遇性能问题或者服务器失效的话,毫无疑问,放到容器中的微服务要比传统托管方式更好。

那么,用容器还是虚拟机?

如果容器是传统微服务托管方式的合理替代的话,那么采用容器唯一的问题就是VM这种替代方案是不是更好。一旦要做出与容器与微服务结合的相关决定时,你得比较一下容器和VM是如何为微服务提供支持的。

毫无疑问,容器是高效的微服务托管宿主。微服务模式牵涉到大量独立托管的组件,如果每一个微服务都是托管在有着独立OS的VM上的话,会浪费大量内存。OS的多重性还会导致机器镜像的版本控制维护工作更加繁重,给运营增加更多的压力。

在决定微服务是否可以有效托管到容器中时,需要考虑的主要因素是你的公司出于安全或者合规性的原因对关键应用的隔离严格程度如何。因为容器共享的是同一个OS,所以在维持应用组件租户的独立性方面并没有VM那么可靠。有隔离需求的应用与没有隔离需求的应用共享的微服务也会存在类似的合规性风险。

当应用不需要隔离时,不管是容器还是微服务都可以自由地部署,两者同时使用可以改进开发和运营效率。但如果需要应用隔离的话,容器技术和微服务都必须按照规定要求进行部署。这应该从隔离应用的网络连接性计划开始,通过提供特殊的安全保护以及将其放入受保护子网来满足要求。

通过企业软件定义网络技术很容易就可以实现这一点,甚至是传统的IP网络也可以按照这种方式来进行分区。寻求对此的特殊支持,可以为托管有安全和合规性要求应用的子网提供连接性和访问控制。此外,如果你要在安全和传统应用之间共享微服务的话,要确保没有数据或访问泄露的风险。

现在假设你成功处理好了容器和微服务的合规风险了。那容器是不是就可以帮助微服务部署了呢?是的,几乎在所有情况下答案都是如此,而且结合起来用每部署一次就更有价值。最大的好处是内存节省,因为消除每个镜像内含OS的需要,但你也许还会发现,把微服务放到容器里面,服务器的利用率也要高很多。

好的微服务做法是,一般经常被调用的功能不要做成微服务。这些功能的网络耦合会导致延迟,最终影响到运行时和体验质量。这意味着大部分的微服务都将是轻量的,对资源的使用要最小化。如果你把每个微服务都分配给一个VM的话,你要限制每台服务器托管的微服务数量,还会增加运营成本。

微服务容器化对运营不好的地方是DevOps。DevOps工具对VM的支持往往比对容器的支持更好,而像Docker这样的容器系统对复杂部署编排往往只提供有限的内部支持。微服务部署越复杂,确保手上有合适的DevOps工具就显得越重要。所以,在你致力于容器化之前,要仔细考察好你的DevOps选项。

一些Docker用户已经发现,求助于基于OASIS Topology以及云应用编排规范(TOSCA)的DevOps非常有价值。跟大多数根治传统数据中心部署的DevOps工具不一样,TOSCA采用的是云架构,也有针对大部分容器部署的蓝图。

总之,微服务应该是简单的,而容器可以实现这一点。但是微服务部署的容器使用可能会加剧跨应用边界的安全风险,导致违背企业安全和合规性指南。处理好容器和微服务的关系是非常重要的。