Get best of the week

微服务：什么，为什么？以及何时需要实施它们

我想写一篇关于微服务体系结构的文章很长时间了，但是一直有两点停顿-我越深入该主题，在我看来，我所知道的很明显，而我不知道，我仍然必须继续学习。另一方面，我相信在广泛的受众中已经有一些可以推测的东西。因此，欢迎提出其他意见。

《 Conway法》以及企业，组织和信息系统之间的关系


我再次允许自己引用：
“任何设计系统的组织（广义上来说）都会收到其结构复制该组织中团队结构的设计。”
-梅尔文·康威，1967年
我认为，该法律更可能与组织业务的权宜之计有关，而不是直接与信息系统有关。我将举例说明。假设我们有一个足够稳定的商业机会，其生命周期的持续时间足以组织一个企业（这不是一个错字，但我真的很喜欢我刚离开的术语）。自然，该企业的支持系统将是与该企业一致的组织和流程。

商业导向信息系统




我将举例说明。假设有一个组织比萨业务的商机。在V1版本中（我们称其为信息前），该公司是一家比萨店，收银台，送货服务。该版本在周围世界变化少的情况下是长期存在的。然后是版本2，该版本更高级，能够使用信息系统作为具有整体架构的业务的基础。在我看来，关于整体架构，这简直是可怕的不公正行为- 据说整体架构与领域业务模型不符。是的，如果是这样，那么该系统将根本无法运行，这与康威法则和常识相抵触。不，在业务发展的这一阶段，整体架构与业务模型完全一致-当然，我的意思是系统已经创建并投入运行的阶段。绝对值得注意的事实是，无论采用哪种架构方法，版本3的面向服务的体系结构和版本N的微服务体系结构都将同样出色地工作。有什么收获？

一切都会流动，一切都会改变还是微服务是应对复杂性的一种方式？


在继续之前，我们将考虑一些关于微服务架构的误解。

支持微服务方法的人经常说，将整体拆分为微服务可以通过减少单个服务的代码库来简化开发方法。我认为，这种说法完全是胡说八道。认真地讲，整体和同类代码中的明显交互似乎复杂吗？如果这是真的，那么所有项目最初都将构建为微服务，而实践表明，从整体迁移到微服务更为普遍。复杂性不会在任何地方消失，而只是从单个模块转移到接口（数据总线，RPC，API和其他协议）和编排系统。而且很难！

使用异构堆栈的优势也令人怀疑。我不会说这也是可能的，但是在现实中很少发生（展望未来-这应该是应该去的地方-而是结果而不是优势）。

产品生命周期和服务生命周期


再看看上面的图表。并非偶然，我注意到一个业务的单独版本的生命周期不断缩短-在现代条件下，加速业务在各个版本之间的过渡对于其成功至关重要。产品的成功取决于测试其中业务假设的速度。在我看来，微服务架构的关键优势就在这里。但是，让我们按顺序进行。

让我们继续进行信息系统发展的下一步-面向服务的SOA体系结构。因此，在某个特定时刻，我们在产品中强调了长期服务-从某种意义上说是长寿的，在产品版本之间进行过渡期间，服务生命周期可能会比下一个产品版本的生命周期更长。完全不更改它们是合乎逻辑的- 过渡到下一个版本的速度对我们很重要。但是，a，我们被迫对服务进行不断的更改-在这里一切都适合我们，并且DevOps的实践，容器化等等-所有想到的东西。但是这些仍然不是微服务！

微服务作为对抗复杂性的工具...配置管理


在这里，我们最终可以继续讨论微服务的定义角色-这是一种简化产品配置管理的方法。更具体地说，每个微服务的功能都根据域模型准确地描述了产品内部的业务功能-这些功能并非存在于短暂的版本中，而是存在于长期的业务机会中。从根本上讲，过渡到产品的下一个版本是难以察觉的-您更改/添加了一个微服务，也许只是它们的交互方案，并在将来突然发现自己，留下了哭泣的竞争对手，他们继续在各个版本之间切换。现在想象一下，存在大量具有预定义接口和商机的微服务。然后，您可以通过现成的微服务来构建产品的结构-仅通过绘制图表即可。恭喜-您有了平台-现在您可以经营自己的生意。梦梦。

发现


  • 系统的体系结构应由其组成组件的生命周期决定。如果组件存在于产品版本中，那么使用微服务方法就不会增加系统的复杂性。
  • 微服务架构应基于域模型-因为商机是寿命最长的领域
  • 交付实践（DevOps实践）和编排对于微服务架构具有最重要的价值之一-因为增加组件的更改率对交付速度和质量提出了更高的要求

More articles:


All Articles