灵活服务的五大部署技术

日期:2016-6-8作者:Mark Betz翻译:崔婧雯 来源:TechTarget中国 英文

【TechTarget中国原创】

如果是为下一代大型移动应用的前端UI组件工作,那么谈论加快速度和破坏东西看上去还不错。当进入服务器领域时,就没有人希望看到破坏了。业务在飞速发展,但是如果后台基础架构包含手动部署还带有硬编码配置的应用程序的话,要想满足这些变化中的需求就会变成噩梦。本文介绍五大部署技术,使得即使是小团队也能够部署灵活的,响应式技术堆栈。

容器管理系统

Docker容器在过去两年中占领了IT世界,这是有原因的。Unix chroot命令的演化,和内核命名空间以及分层文件系统的组合,容器将应用的完整依赖集合打包在一起,这样可以将代码快速部署到任何运行着兼容内核的服务器上。和硬件虚拟化不同,容器只会造成非常小的额外消耗,启动速度几乎和进程一样快。上千个容器可以运行在一个虚拟机实例里。它们使得不可变基础架构的理念成为现实,将安装和配置状态记录成声明格式,从而可以在任何时间可靠地重做。Ubuntu 16.04 LTS Canonical引入了LXD,一种更为集成的容器管理系统,将很多Docker和硬件虚拟化的优势引入到单个平台上,增强了安全性和性能。现在可以说,容器给云上软件的部署和管理方式带来了革命性的变化。

服务发现框架

容器给用户带来了灵活性,可以几乎在任何地方运行服务,但是用户仍然需要向这些服务发送请求。这意味着系统里的某个地方需要知道实现应用程序的容器在哪里运行,以及如何将流量路由到正确的地址和端口上。在RESTful的设计里,这里的需求包括基于第7层内容来路由请求。强大的开源工具,比如NGINX和 HAProxy,让用户能够快速实现自己的方案,但是手动管理路由配置很容易出错,也会阻碍灵活性。服务发现框架,比如Consul, Apache Zookeeper和mesosphere帮助将面向服务架构的发现和路由的搭建自动化,它们为服务提供了中央化的配置存储,提供了接口来声明其生命周期事件,并且提供pub或者sub模型来将这些事件通知给其他组件。

哪种方案更适用取决于你当前的代码基和所处的开发阶段。和普通代理不同,发现层涉及更多的服务和基础架构之间的合作,因此每种方案如何支持你已经在使用的语言和工具,这是影响决策的重要因素。

容器集群

如果实现了容器化和自动服务发现之后,你就会得到集群。容器集群平台意图使构建整个系统和构建容器一样能够可靠地重复。它们填补了单个容器的运行和让很多不同容器运行起来并且一起工作之间的空白,后者包括这些容器如何在特定数量的宿主机上运行,使用特定的网络规则,自动扩展参数,访问存储等等。领先的平台包括Google的Kubernetes,Amazon Elastic Container service和Docker Compose,它们采用的是略微有所不同的方案,但是目标和理念都很类似。每种方案都有优势和劣势,但是这三种方案都是可以用于生产环境的工具,并且拥有一致的目标:自动化部署技术和整个堆栈层的配置。在其中做选择时,需要重点考虑供应商和服务代码跨平台的移植性。无论使用哪种方案,都需要研究自动化工具,比如Ansible,Chef和可敬又很顽固的GNU Make,来将所有部分组合到一起,但是在这方面的努力一定会物有所值,因为能够帮助获得可持续性和可扩展性。

即时生效的API

好了,集群已经正在运行了,并且集群有可发现的服务。因此,当http请求到达集群的/awesome或者/awesomer/端点时,请求能够分发到正确的地方,并且得到响应。那么,如果终止SSL连接,并且在应用的不同版本或者不同环境间路由呢?需要一个公开的入口点来处理这样的事情,并且可以作为所有部署在其后的不同服务的网关。可以搭建一个使用SSL的负载均衡器,但是通常负载均衡器不需要处理第7层的路由。可以在LB之后搭建一个代理来完成这部分工作,但是这时就需要考虑这个组件的配置,可扩展性和故障转移。如果能够仅仅将整个API配置为云服务,并且一个命令就可以将其部署呢?Amazon的API Gateway就是这么做的,并且非常智能。甚至可以使用Swagger这样的语言描述API,然后只需上传,它就可以工作了。Google这方面还没有提供直接的竞争产品,但是他们显然不会甘于落后,而且该领域已经有Strongloop这样的独立解决方案了。

shake-n-bake网关是否适合于你的项目?在早期阶段,应该更值得投入到速度的提升以及管理上额外消耗的减少上。但是之后,会更加依赖于在你所在的使用层级里需要实际花费多少工作。

无服务器服务

上文提到的技术可以帮助实现复杂系统的完全自动化部署,但是要达到这一目的其实并不需要那么多的后台开发。如果你是个创业公司,仅仅想尽快部署一个 API和服务呢?或者你可能是一家步入正轨的公司,想要实现零基础架构的灵活性,并且基于请求付费。去年涌现了无服务器计算平台,它们对于当今真实的应用程序而言已经足够健壮了。该领域的领导者是Amazon的Lambda,它允许快速部署用python、JavaScript和Java编写的代码。Lambda功能可以是一个脚本或者对其他服务有依赖和I/O的复杂应用程序。它们可以被手动调用或者被其他Amazon服务,比如S3生成的事件触发。 当和APIGateway搭配使用时,可以用来在零基础架构的环境里部署整个微服务的实现。其他主流云平台也已经大步迈入了该领域,比如Microsoft 的Azure Functions和Google的Cloud Functions。

从某种角度看,这些部署技术体现了云计算的绝大多数重要的特性:隐藏了大量底层的复杂性,尽量让应用能够无缝工作,而用户完全无需考虑底层的复杂度。

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

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

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

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

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

SOA开发>更多

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

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

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

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

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

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

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

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

技术手册>更多

  • HTML5现状分析指南

    HTML 5是超文本标记语言(HTML)的下一个修订版 ,超文本标记语言是用来描述网页内容和外观的标准编程语言。HTML5是近十年来Web标准最巨大的飞跃。和以前的版本不同,HTML 5并非仅仅用来表示Web内容,它的使命是将Web带入一个成熟的应用平台,在这个平台上,视频、音频、图象、动画以及同电脑的交互都被标准化。尽管HTML 5的实现还有很长的路要走,但HTML 5正在改变Web。下面我们将分三部分来分析一下HTML5。

  • 企业架构师工具包

    企业架构师如何创建一个有用的工具集呢?目前实践者正在将UML和TOGAF以及其他工具连同使用,从而能够构建出软件模型解决业务构想变成工作系统最重要的一步。但是需要高度熟练的架构师,来创造业务架构参考模型。成功的软件架构师会发现和企业匹配的工作参考模型会成为他们自定制添加“工具”的框架。下面专家的一些建议可以为我们提供一些引导。

  • OSGi模块化技术手册

    最近有一些争论,主要是关于是否完全成熟的OSGi模块化是严格意义上必须的东西,或者Jigsaw是否一种足够好的“更简单”的方法。但是也许关键点在于对于任何既定的组件在哪里适合什么模块化。OSGi是Java领域里无可辩驳的最成熟的模块系统,它与Java几乎是如影相随。在这本技术手册中我们将分三部分来和大家聊聊OSGi模块化以及它和Java千丝万缕的关系。

  • 企业IT消费化指导手册

    IT消费化是个人和商业使用的设备和应用程序的混合体。学习如何保持在前沿技术的最前端,了解工作场所内部或外部的关于IT消费化的挑战与威胁。虽然企业可以掌控在内部建立的安全机制,但是这是关于个人拥有的设备的事情,所以它需要用新方式去思考。本指南解释了IT消费化,帮助企业在IT消费化中生存,并叙述了IT消费化的影响。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算