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

日期: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实施的成功?

技术手册>更多

  • API开发与管理大作战

    2014将会是API管理方法新旧PK的一年,据Delyn Simons说,她领导了Mashery开发者的外展团队。应用编程接口(API)的主流化和私有化在新的一年也将掀起波澜,她在波士顿“Future Insights Ultimate Developer Event 2013”大会上预测说。

  • 大型机数据迁移和遗留SOA集成向导

    大型机应用现代化对于保持原有系统至关重要,而且大型机在大型企业高性能企业计算仍旧处于核心地位。这也是SOA成功案例中,目前正在进行的革新中最为显著的内容。以前,遗留大型机应用抵制重建,开发团队通过为意大利面式的代码排序,试图改写系统并非易事。遗留系统是一个已经运行了很长时间的,对机构来说是很重要的系统,但是往往不知道如何处理的大的软件系统。它与平台相关,但不能在网络环境中直接访问。另外,遗留系统不能直接访问存储在各种数据库管理系统中的数据,但由于遗留系统所完成的是关键业务,所以不能简单丢弃。在这本向导手册中我们将着重为您介绍遗留SOA集成问题以及大型机的数据迁移问题。

  • SOA建模指导手册

    SOA的跨组织的特性决定了其建模必须采取一个从企业级考虑,系统思考问题的方法。企业架构提供了一个企业整体的视图,是在对企业业务战略和核心业务流程理解的基础上,进行信息化顶层设计,形成的相对稳定的结构。本手册简单介绍了SOA建模的一些小技巧,帮助企业SOA架构师从本企业需求和SOA特点出发建立服务架构模型。

  • 业务流程执行语言BPEL(升级版)

    BPEL即业务流程执行语言,是一种使用XML编写的编程语言。用于自动化业务流程,也曾经被称作WSBPEL和BPEL4WS。广泛使用于Web服务相关的项目开发中,优点为具有可移植性和有效保护了投资。

    BPEL是一门用于自动化业务流程的形式规约语言。用XML文档写入BPEL中的流程能在Web服务之间以标准化的交互方式得到精心组织。这些流程能够在任何一个符合BPEL规范的平台或产品上执行。 所以,通过允许顾客们在各种各样的创作工具和执行平台之间移动这些流程,BPEL使得他们保护了他们在流程自动化上的投资。

TechTarget

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

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

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

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

微服务应该是什么样的?

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

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

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

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

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

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

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

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

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

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

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

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