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

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

微服务   ALM   

【TechTarget中国原创】

微服务如果管理不当的话,可能会给工作带来一点麻烦。Tom Nolle解释了恰当的微服务设计意味着什么。

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

要想解决这一问题,你不仅仅需要把目录和注册结合起来,更要把你的微服务作为一个虚拟应用来看待,聚焦于可重用来进行微服务设计,微服务的分类要能够确保新服务和实例能够适配,以及最后让应用架构师和ALM团队来判断创建了不必要服务的情况。

微服务应该是什么样的?

微服务本来是要促进可重用的,但是往往创建出来之后并没有达到那个目的。微服务应该是一项公司资源,应该是能保证在尽可能广泛的范围内加以重用的。对此的推论应该是任何项目创建微服务之前都应该进行审查,确定是否已经存在相同或者类似服务,以及对那些决定要新建的服务的所有应用前景进行评估。

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

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

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

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

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

作者>更多

Tom Nolle
Tom Nolle

关于作者:Tom Nolle是CIMI公司的总裁,这家公司成立于1982年,是致力于电信和数据通信的战略顾问公司。Tom Nolle是IEEE、ACM、Telemanagement Forum和IPsphere Forum的一员,著作有关于Netwatcher方面的书籍。

SOA基础>更多

相关推荐

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

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

  • 对于orchestration而言 ALM和DevOps至关重要

    为了确保开发和运营能够持续同步演进,开发者需要理解DevOps与orchestration之间的差异,对自己的开发和运营策略进行重新思考,并且对重要的新兴趋势保持警觉。

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

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

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

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

技术手册>更多

  • SOA与REST混合使用指南

    大多数应用架构师都意识到,如果应用合适,开发实践反映了双方的目标和好处的话,在某些情况下,将表述性状态转移(REST)与SOA结合起来是有可能且有优势的。最大的问题是目标是否要开发一个自始至终的RESTful接口,同时满足大部分SOA目标,或者混合使用REST和SOA。

  • 云集成实践基础教程

    随着面向服务和基于云的架构脱颖而出,IT部门越来越重视良好的集成设计。为了避免过快的云应用集成的潜在危险,需要精心策划架构。随着应用集成需要更多的灵活性和普遍的可适用性,优化设计比以往便得更加重要。在即将到来的云计算应用集成中,以集成为中心的云计算,像iPaaS,显示了云应用者数量的快速增长,未来也将面临着更加复杂的集成和实际挑战。在这本技术手册中,我们将重点关注云集成实践。

  • 复杂事件处理CEP手册

    在金融服务和其他行业中,如何使那些重要且具有战略意义的业务信息以高速数据流的方式到达企业变得尤其重要,而复杂事件处理(CEP)就是这一过程的代名词。在复杂事件处理中,数据是不断变化的,而“操作”是“静态”的。复杂事件处理具备了分析高速数据流并鉴别重要事件的能力,虽然对这些事件的鉴别过程是复杂的,但结果却是无价的。复杂事件处理能够帮助企业及时全面地洞察市场变化,降低风险和提高决策效率。下面我们就来介绍一下复杂事件处理。

  • 开源框架Ruby on Rails

    Ruby on Rails, 也称RoR或简称Rails, 是一个使用Ruby语言写的开源网络应用框架,它是严格按照MVC结构开发的。它努力使自身保持简单,来使实际的应用开发时的代码更少,使用最少的配置。

TechTarget

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

微服务如果管理不当的话,可能会给工作带来一点麻烦。Tom Nolle解释了恰当的微服务设计意味着什么。

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

要想解决这一问题,你不仅仅需要把目录和注册结合起来,更要把你的微服务作为一个虚拟应用来看待,聚焦于可重用来进行微服务设计,微服务的分类要能够确保新服务和实例能够适配,以及最后让应用架构师和ALM团队来判断创建了不必要服务的情况。

微服务应该是什么样的?

微服务本来是要促进可重用的,但是往往创建出来之后并没有达到那个目的。微服务应该是一项公司资源,应该是能保证在尽可能广泛的范围内加以重用的。对此的推论应该是任何项目创建微服务之前都应该进行审查,确定是否已经存在相同或者类似服务,以及对那些决定要新建的服务的所有应用前景进行评估。

最简单方式是把微服务当作一项广泛应用来考虑,这项应用的持续变化是由新的微服务、变更的微服务的结合来推动的,这样才能适应更广泛的使用或者撤销微服务。这个虚拟应用应该服从常规开发审查,与其他开发团队进行协调,从而确保微服务实际上得到使用并且使用得当,同时与ALM活动进行协调以确保微服务变化不会中断已有应用。

除非应用架构师习惯于在应用设计中寻找微服务的机会,并且在需要新建时创建尽可能通用的微服务,否则微服务策略就不可能取得成功。这意味着微服务使用最有效的控制过程要以专门的负责微服务审查的应用架构师小组为基础。然后由这支团队来进行这一微服务虚拟应用的协调。

在应用设计的早期阶段,其目标应该是用微服务来实现应用功能并且满足应用性能和安全需求。在开发的应用架构点做这件事可确保微服务设计针对的是可重用。

如果微服务不能胜任怎么办?

如果用当前微服务不能满足一项需求的话,那么可选的做法可以用嵌入式的传统逻辑,或者增强当前微服务来适应需求,或者开发新的微服务等。嵌入式逻辑这个选项被认为是不存在广泛价值的功能,或者工作流需要外部微服务支持,会影响到体验质量(QoE)。增强当前微服务是最好的方案,对现有微服务进行最小的改造和逻辑扩展就可以满足需求(避免尴尬的功能结合)。如果这两种方案都不可行的话,那就得考虑新的微服务了。

审查每一项新的微服务以确保广泛可重用非常重要。一般而言,这是从使用一项简单的RESTful接口并且实现该服务的无状态操作开始的。这些简化了对服务的多并发使用,还可以在负载变化的情况下对服务进行水平伸缩。在此之后,尝试设计服务让它在任何应用背景下支持其功能。

解决这一问题的办法之一是审查当前应用什么地方可以或者应该使用新的的微服务。这是防止微服务在不知不觉间重复了嵌入逻辑的重要一步。发生了这样的事,只会引起性能或者安全/合规性的问题,把共同代码放入到嵌入逻辑和微服务的步骤应该要考虑避免给后面的开发者造成混淆。

下一步就是考虑以哪种方式来发现微服务。常见的办法是利用某种形式的注册,但是准确的机制应该取决于所使用的编程语言以及对微服务动态的预期。如果微服务调用是在开发时显式引入到应用代码里面的话,那么可以考虑把注册作为开发者工具,这几乎就像是一个类库一样。如果微服务调用的动态性预期更强的话,则需要运行时发现流程,这更像是SOA应用的目录。

不管是哪种情况,最佳实践都要求微服务要在欠载的情况下伸缩,这意味着注册/发现机制必须在微服务的实例数发生变化的情况下更新,必须把请求引导到一个实例来实现负载平衡。用来进行负载均衡和实例管理的机制必须包括在注册之内,不管微服务是以静态还是动态方式调用均是如此。

微服务管理的最后一步是“去重”。尽管有了控制微服务部署以及消除重叠或者完全重复的努力,一些问题还是有可能忽视的。一些问题可以在常规软件架构师的审查中发现,但另一个抓住“漏网之鱼”的机会是在ALM。

如果你接受把整个微服务当作虚拟应用来看待的建议,那么你就会有ALM的步骤来专门验证微服务的变化。这些步骤可暴露任何现有微服务存在的问题。在“正常”应用层级的ALM也会要求对每一个应用相关的微服务进行测试,这个步骤会把任何审查流程漏掉的新的微服务暴露出来。一旦发生了这样的事,要对这些“行为不合常规”的微服务进行审查,要么通过合并来撤除,要么把它们添加到正规的注册表和虚拟应用流程内。