微服务是与团队管理相关的 - filipnikolovski

21-12-02 banq

我知道微服务的话题已经被反复讨论过,我只是想根据我在这种设计 Web 应用程序的方法方面的经验,将我的经验加进去:

  • 很多人认为微服务架构解决了具有扩展性和性能性质的软件问题。但他们解决的最重要的问题是组织问题。
  • 康威定律一直在起作用。当您考虑构建的软件应该是什么样子时,您需要考虑您的组织结构应该是什么样子。他们总是齐头并进。
  • 如果您是一个团队,那么从这个角度来看,涉及多个移动部件的设计没有多大意义。谁应该拥有每个组件的所有权?这些服务如何才能真正相互独立?纠缠它们是不可避免的,因为这样更方便,最终得到类似于微服务架构的东西,但实际上它更像是一个“分布式单体”。从微服务架构开始是很多人的错误做法。软件的结构最终看起来总是像组织的结构。这是不可避免的。
  • 如果您只有一个团队,切勿从微服务架构开始。
  • 随着组织规模的扩大,团队中加入了更多的人,现在是对当前架构设计提出问题的时候了。
  • 随着团队的成长,管理起来会越来越困难。将这个大团队分解成多个、更小、独立的团队是向前迈出的自然一步。那么我们应该问的问题是:这些团队如何对他们负责的产品部分拥有完全的所有权?如何让团队掌握自己的“命运”?
  • 对于一个真正独立的团队来说,它需要在堆栈的每一层都有完整的决策能力:从 UI/UX、后端将要公开的 API,一直到将为整个事物提供动力的基础设施. 作为单个单体应用程序这样做当然是可行的,但是团队需要在他们的开发过程中同步,尤其是在部署阶段。他们会不断地踩对方的脚趾。因此,需要创建一种能够反映组织架构的架构。微服务解决了这个确切的问题 - 扩展团队。
  • 服务需要是可组合的,并且可以很好地相互配合,就像您在单体应用中创建可组合模块一样。将它分开并简单地在它前面放置一个 Web 服务器不会拯救你。
  • 对于跨越多个域的功能,明确的数据所有权以及清晰一致的 API 是必须的,否则您可能会使所涉及的服务之间的关系复杂化。定义这些边界是开发此功能的团队的责任。服务之间的沟通应该反映团队之间的沟通。

1
猜你喜欢