我很早就想写一篇关于微服务架构主题的文章，但有两件事一直阻止着我——我越深入这个主题，我就越觉得我知道的东西是显而易见的，而我不知道的东西不知道需要研究和研究。 另一方面，我认为广大观众已经有了一些可以讨论的东西。 因此欢迎其他意见。
康威定律与业务、组织和信息系统之间的关系
我将再次引用：
“任何设计系统（广义上）的组织都会收到一个其结构复制该组织中团队结构的设计。”
——梅尔文·康威，1967 年
在我看来，这条法则更可能与组织企业的可行性有关，而不是直接与信息系统有关。 让我用一个例子来解释一下。 假设我们有一个相当稳定的商业机会，其生命周期如此之长，以至于组织一个企业是有意义的（这不是错字，但我真的很喜欢我偷来的这个术语）。当然，这个企业的支撑系统将在组织上和流程上对应此业务。
信息系统业务导向
让我用一个例子来解释一下。 假设有一个组织销售披萨业务的商机。 在 V1 版本中（我们称之为预信息），该公司是一家比萨饼店、一家收银机和一家送货服务公司。 该版本在环境变化较小的条件下可以长期存在。 然后版本 2 取代了它 - 更先进，能够使用信息系统作为其核心，通过整体架构进行业务。 在我看来，这里对巨石来说简直是一种可怕的不公正—— 据称单体架构与领域业务模型不对应。 是的，如果真是这样，该系统将根本无法运行——这与康威定律和常识相矛盾。 不，单体架构完全符合业务发展现阶段的业务模型——当然，我指的是系统已经创建并投入运行的阶段。 一个绝对美妙的事实是，无论采用哪种架构方法，面向服务的架构版本 3 和微服务架构版本 N 都将同样运行良好。 有什么问题吗？
一切都在流动，一切都在变化，或者微服务是对抗复杂性的一种手段吗？
在继续之前，让我们先看看关于微服务架构的一些误解。
使用微服务方法的支持者经常认为，将整体分解为微服务可以通过减少单个服务的代码库来简化开发方法。 在我看来，这种说法完全是无稽之谈。 说真的，单体和同构代码中明显的交互看起来很复杂？ 如果情况确实如此，那么所有项目最初都将构建为微服务，而实践表明从整体迁移到微服务更为常见。 复杂性并没有消失；它只是从单个模块转移到接口（数据总线、RPC、API 和其他协议）和编排系统。 而这很难！
使用异构堆栈的优势也值得怀疑。 我不会说这也是可能的，但实际上它很少发生（展望未来 - 这应该发生 - 但作为结果而不是优势）。
产品生命周期和服务生命周期
再看一下上图。 我注意到业务的单独版本的生命周期正在缩短，这并非巧合 - 在现代条件下，加速业务在版本之间的转换对于其成功至关重要。 产品的成功取决于测试其业务假设的速度。 在我看来，这就是微服务架构的关键优势。 但我们还是按顺序来吧。
让我们进入信息系统演进的下一个阶段——面向服务的SOA 架构。 因此，在某些时候我们在产品中强调了 长期服务 - 长期存在，即当在产品版本之间移动时，服务的生命周期有可能比产品的下一版本的生命周期长。 根本不改变它们是合乎逻辑的——我们 重要的是过渡到下一个版本的速度。 但遗憾的是，我们被迫不断地对服务做出改变——这里一切都适合我们，DevOps 实践、容器化等等——所有想到的东西。 但这些仍然不是微服务！
微服务作为应对复杂性的手段......配置管理
在这里，我们终于可以继续讨论微服务的定义角色 - 这是一种简化产品配置管理的方法。 更详细地说，每个微服务的功能根据领域模型准确地描述了产品内部的业务功能 - 这些东西不是存在于短暂的版本中，而是存在于长期的业务机会中。 并且向产品的下一版本的过渡实际上是在不被注意的情况下发生的 - 您更改/添加了一个微服务，也许只是它们的交互方案，然后突然您发现自己处于未来，留下了不断在不同版本之间跳转的哭泣的竞争对手他们的巨石。 现在想象一下，有相当大量的具有预定义接口和业务功能的微服务。 您可以通过现成的微服务构建产品的结构 - 例如，只需绘制图表即可。 恭喜你——你有了一个平台——现在你可以为自己吸引业务了。 梦想梦想。
发现
- 系统的架构应该由其组件的生命周期来确定。 如果组件存在于产品版本中，则通过使用微服务方法来增加系统的复杂性是没有意义的。
- 微服务架构应该基于领域模型——因为业务机会是最长寿的领域
- 交付实践（DevOps 实践）和编排对于微服务架构来说是最重要的之一 - 因为组件变更率的增加对交付的速度和质量提出了更高的要求
来源： habr.com