究竟什么是微服务架构?

日期: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与相关技术

    面向服务的体系结构(service-oriented architecture,SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 

    这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。松耦合系统的好处有两点,一点是它的灵活性,另一点是,当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时,它能够继续存在。

  • ActiveMQ实践入门指南

    ActiveMQ是Apache出品,最流行的,能力强劲的开源消息总线。ActiveMQ是一个完全支持JMS1.1和J2EE 1.4规范的JMS Provider实现,尽管JMS规范出台已经是很久的事情了,但是JMS在当今的J2EE应用中间仍然扮演着特殊的地位。下面我们将分四部分来介绍ActiveMQ的相关内容。

  • BPM项目错误规避指南

    业务与技术的交叉点正是BPM关注的焦点,这也是大多数重大IT问题出现的地方,通过为业务分析员和软件开发人员提供通用的工具,BPM有希望使应用集成发生革命性变化。正因为这样,技术不能够单独支撑BPM的全部内容,也不能单独解决业务流程的所有问题。业务是BPM依托的另一方面。但是企业在进行BPM项目时却会遭遇种种问题,而有些问题是可以通过前期工作避免的,本期TT SOA技术手册介绍如何合理规避BPM项目中的错误,同时提供BPM技巧和工具信息。

TechTarget

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