究竟什么是微服务架构?

日期:2015-3-16作者:Todd Biske翻译:邹雅玲 来源:TechTarget中国 英文

微服务架构   SOA   微服务   

【TechTarget中国原创】无论您将微服务架构的关注放在侧重点的改变还是方式的改变,其工作原理都对提升系统存在潜在的影响。

我们之所以能够知道“微服务”这个词,要感谢2014年3月Martin Fowler所写的一篇文章。文章中他提到:“该微服务的架构特点是要开发一种独立的应用作为一套微小服务。各自运行在自己独立的进程中,并与其它轻量级装置进行沟通,通常是HTTP型API。这些服务都是建立在业务能力的基础上,并以全自动化开发设备作为保障独立运行。”

起初,此时的微服务与几年前SOA专家所提倡的服务并无多大差异。上述陈述的确属实,2000年代中期SOA所呈现的效益也是事实,但是遗憾的是,未能按照Thomas Erl的定向服务原则或者微服务架构支持原则进行设计。这些曾经的努力和付出换来的更多的是新型的技术(例如SOAP集成接口或者企业服务总线)而非服务。Fowler在定义时试图全面地描述出SOA成功的案例,例如Amazon Web Services和Netflix。因此,我们不妨分开来看看。

首先,我们先单独谈谈微服务。它可以在“自己的程序”中运行,并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中,许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能,那么就必须缩小进程范围。在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程。

微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称,微服务是需要与业务能力相匹配,这种说法完全正确。不幸的是,仍然意味着,如果能力模型粒度的设计是错误的,那么,我们就必须付出很多代价。如果你阅读了Fowler的整篇文章,你会发现,其中的指导建议是非常实用的。在决定将所有组件组合到一起时,开发人员需要非常确信这些组件都会有所改变,并且规模也会发生变化。服务粒度越粗,就越难以符合规定原则。服务粒度越细,就越能够灵活地降低变化和负载所带来的影响。然而,利弊之间的权衡过程是非常复杂的,我们要在配置和资金模型的基础上考虑到基础设施的成本问题。

在许多企业中,其成本单位仍然是以CPU核心为基础,至少要有2-3个高可用性方案。一天能够收到100个请求的服务必须具备同等数量的基础设施,从而能够应付得了每天100,000个服务请求。较为难处理的是,要想获得细粒度的服务就意味着要添加更多的移动组件。这就是为什么定义中会提到“部署全自动化开发设备”的一大原因。如果不能实现全自动化,那么,后期增加的移动部件就会削弱人工流程。

关于上述定义,我想说的最后一点就是所使用的“开发方法”。该方法不仅仅是在所谓的“服务”中简简单单地创建Visio图标就可以了。成功的案例必须与决策、开发、部署以及服务的整个生命周期紧密相连。你必须将这些服务视为非常重要的产品而不是简单的项目。很多,但并非全部IT部门仅仅成为执行项目的发动机,对“产品”生命周期并没有任何概念。

站在产品的角度来思考,你会更长远的看。你会想出更有效的服务设计方法,那就是良方法,从而避免对现有消费者造成影响。此外,这种基于产品的设计方法也会改变其所有权。Fowler指出,过去,开发方式所有权是归技术或者传统方所有(例如,UI团队、服务团队以及数据团队)。如今,以产品为基础的设计思想与业务能力紧密相关,强调自上向下的所有关系,这就意味着,在需要的时候,你可以使用各种不同的技术。

在文章的结尾部分Fowler提到,只有时间可以证明微服务是否能继续下去。但是有了这种进化的设计精神,微服务就会成为SOA演化的一部分。无论你认为微服务是在侧重点上有所变化还是在方法上所有变化,其所呈现出来的设计原则都会对系统改善有所影响。

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

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

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

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

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

SOA开发>更多

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

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

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

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

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

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

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

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

相关推荐

技术手册>更多

  • SOA实现与交付指南

    随着SOA渐成IT潮流, 越来越多的SOA项目启动了。有些项目彻底失败了,有些项目则勉强成功了。为什么有些项目成功了,有些去失败了,最大的问题出在哪里?如何吸取这些失败项目的教训,并形成自己规划SOA路线图所需的远见与策略。同样的,我们又要如何判断SOA项目是否已经成功实现?这些将是未来SOA项目成功实现的关键。下面让我们来看看个中因由。

  • SOA与Web服务管理

    不管是服务的质量或是可靠性或是可获得性,所有这些能力服务都必须具有,他们必须以适当的方式工作。可能一个供应商提出了一个SOA管理技术,而且是如此地优于其他的技术以致于其实际上成为了事实上的标准。但是更可能的是相同的竞争压力驱使供应商试图合并,而唯一的SOA管理产品最终迫使市场在内部协作性上妥协,如果不能获得一个实际上的基于标准的方法。

  • BPEL 2.0服务契约手册

    本技术手册旨在探讨如何为封装WS-BPEL流程逻辑所需的Web服务设计WSDL定义。因为SOA提倡用“契约优先”的方式来设计服务,所以理解由WS-BPEL引发的这种独特服务契约设计理念,是成功构建有效流程和服务的关键因素。

  • 复杂事件处理CEP教程

    在金融服务和其他行业中,如何使那些重要且具有战略意义的业务信息以高速数据流的方式到达企业变得尤其重要,而复杂事件处理(CEP)就是这一过程的代名词。复杂事件处理具备了分析高速数据流并鉴别重要事件的能力,虽然对这些事件的鉴别过程是复杂的,但结果却是无价的。下面我们就来介绍一下复杂事件处理。

TechTarget

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