面向微服务的体系结构现在风靡全球。这是由于更快的部署节奏和更低的成本是面向微服务的体系结构的基本承诺。html
然而,对于大多数试水的公司来讲,开发活动更多的是将现有的单块应用程序转换为面向微服务的体系结构,这多是许多层面上阻碍和冲突的根源。app
虽然Greenfield (未开发的)面向微服务的体系结构实现能够坚持对当前微服务的严格解释-设计原则。但在面向微服务的体系结构中,分解的遗留应用程序存在灰色阴影,若是没有其余缘由,只能知足预算和时间限制。less
在企业管理链的某个地方,有一位业务主管在一个面向微服务的体系结构中查看与这些遗留应用程序相关的分解成本,并将其与遗留代码已经提供的价值进行比较。一旦开发成本超过了预期的收益,业务主管极可能会退出并取消该项目。异步
这种事常常会发生。async
所以,开发经理面临着巨大的压力,要求他们尽快将代码输出。“足够好”地成为转型的理想目标。ide
如今,这不必定是一件坏事。与等待梦想到来相比,输出工做代码的能力老是更好。可是,“灰色的阴影”是很难管理的,问题就在于如何界定“足够好”的界限。微服务
所以,冲突开始了。一方想要输出他们想要的东西,而另外一方则但愿作更多的改进。spa
对你来讲,挑战是不要让这些不一样学派在本质上是信仰支持的观点上制造一场没完没了的争吵。若是您这样作了,它将形成一种状况,即根本不提供任何代码。如今,冲突能够从许多相互竞争的想法中综合出最好的想法。可是,当话语退化为永无止境的冲突时,它多是致命的。设计
我经过集中讨论如下三个问题来处理这类状况,以免这种冲突:code
请容许我详细说明。
当您评估面向微服务的体系结构的设计时,所面临的挑战是将过去的观点转移到理论基础分析上。它的建立主要来自于单个应用程序的分解。任何设计均可能“足够好”,只要你能证实它的好处和价值。
例如,面向微服务的体系结构设计的首选样式之一是采用事件驱动的方法进行服务间通讯。具体来讲,这意味着您使用消息节点以异步方式在微服务之间传递消息。然而,从长远来看,虽然异步通讯更加灵活和可扩展,但消息系统实现比在“面向”微服务的API之间使用同步HTTP调用的设计要复杂得多。所以,当市场时间被关注时,彻底有理由将单块应用程序中的特性重构为以HTTP API方式表示的独立的微服务。
与异步服务相比,同步微服务的实现一般不那么复杂。
从长远来看,同步通讯不必定是最佳选择,但考虑到从单块应用程序中提取独立的微服务所需的全部其余工做,同步对于第一个版原本说是“足够好”的。所以,这是一个合理的理由。
然而,这并非说同步方法没有风险。事实上,风险有不少。当涉及到审查面向微服务的体系结构设计时,仅仅说明理由并非惟一的因素。风险也必须加以阐述。
全部的设计都有内在的风险。在上面描述的同步设计示例中,这种服务间通讯方法可能会致使服务之间类型耦合的风险,因为同步HTTP通讯和其余通讯的性质而增长延迟增长延迟。
重要的是要让人们知道这些风险,这样就能够根据预期设计的合理性来权衡它们。若是风险是巨大的,再多的理由也是不够的。另外一方面,考虑到目前的需求,某些风险多是能够接受的。诀窍是确保风险在审查过程当中获得明确的传达。讨论中已知的风险老是比隐藏的风险更可取,而这种风险可能会在路上形成冲击。此外,若是您之前知道风险,那么随着面向微服务的体系结构的成熟,您能够计划如何在将来的版本中更好地向前迈进。这就是减小风险的缘由。
一个明智的应用程序设计人员的一个标志是可以识别他们的设计风险,一旦肯定下来他会有远见地阐明一种方法,以减轻这些风险。没有适当的缓解技术的风险识别是思惟不完整的标志。
若是面向微服务的体系结构设计有很大的风险和解决这些问题的边际计划,那么设计团队须要认真考虑其可行性。此外,若是缓解计划不切实际-超出项目的专门知识和预算-设计的可行性也须要质疑。这都是平衡的问题。
一个平衡良好的面向微服务的体系结构设计是合理的,由于它想要知足的条件与其固有的设计风险和旨在解决这些风险的缓解计划相权衡。
冲突是创造性进程的重要组成部分。有创造力的人每每对本身的想法坚韧不拔。因此,当你把它们放在一个房间里,让他们为面向微服务的建筑设计一个单一的设计时,紧张关系确定会加重。事情就是这样的。但要振做起来!冲突是好事。
幸运的是,有了一种理性的方法,用我前面描述的三个问题来审查面向微服务的体系结构设计,您就能够促进客观的讨论,从而产生软件以及时知足您的需求。没有任何设计是完美的,特别是那些分解单个应用程序的设计。可是,交付面向微服务的体系结构有一个很大的好处,这个体系结构足够好有效运做在短时间和灵活性足够持续不断改善长期。
原文: https://www.theserverside.com...做者:Bob Reselman
译者:遗失的拂晓