你好，哈布尔。 今天，我继续出版专门为课程新流的开始而撰写的一系列出版物。 .
介绍
架构风格的选择是构建信息系统时的基本技术决策之一。 在本系列文章中，我建议分析建筑应用中最流行的建筑风格，并回答何时最优选哪种建筑风格的问题。 在演示过程中，我将尝试绘制一条逻辑链来解释架构风格从单体到微服务的发展。
上次我们讨论了不同类型的单体以及使用组件来构建它们，包括构建组件和部署组件。 我们了解面向服务的架构。
现在我们最终将定义微服务架构的主要特征。
架构关系
需要理解的是，根据前面文章给出的定义，任何服务都是组件，但并不是每个服务都是微服务。
微服务架构的特点
微服务架构的主要特点是：
- 围绕业务能力组织
- 产品而非项目
- 智能端点和哑管道
- 去中心化治理
- 分散数据管理
- 基础设施自动化
- 为失败而设计
- 进化发展的架构（进化设计）
第一点来自面向服务的架构，因为微服务是服务的一种特例。 其他要点值得单独考虑。
围绕业务能力组织
现在有必要记住康威定律：创建系统的组织组织其架构，复制这些组织内的交互结构。 作为一个例子，我们可以回忆一下创建编译器的情况：一个七人团队开发了一个七遍编译器，一个五人团队开发了一个五遍编译器。
如果我们谈论单体和微服务，那么如果开发是由职能部门（后端、前端、数据库管理员）组织的，那么我们就会得到一个经典的单体。
为了获得微服务，团队必须按业务能力（订单、发货、目录团队）组织。 该组织将允许团队专注于构建应用程序的特定部分。
产品而非项目
一个团队将开发的功能转移给其他团队的项目方法在微服务架构的情况下是完全不合适的。 团队必须在系统的整个生命周期中支持系统。 微服务实施领域的领导者之一亚马逊表示：“你构建，你运行它。” 产品方法让团队能够感受到业务的需求。
智能端点和哑管道
SOA架构非常注重通信通道，特别是企业服务总线。 这往往会导致错误的意大利面条盒，即单体的复杂性变成了服务之间连接的复杂性。 微服务架构仅使用简单的通信方式。
去中心化治理
有关微服务的关键决策应该由实际开发微服务的人员做出。 在这里，关键决策意味着选择
编程语言、部署方法、公共接口契约等。
分散数据管理
应用程序依赖于单个数据库的标准方法无法考虑每个特定服务的具体情况。 MSA 涉及分散式数据管理，包括使用各种技术。
基础设施自动化
MSA 支持持续部署和交付流程。 这只能通过自动化流程来实现。 同时，部署大量服务看起来不再是一件可怕的事情。 部署过程应该会变得无聊。 第二个方面与产品环境中的服务管理有关。 如果没有自动化，管理在不同操作环境中运行的流程就变得不可能。
为失败而设计
许多 MSA 服务很容易出现故障。 同时，分布式系统中的错误处理并不是一项简单的任务。 应用程序架构必须能够适应此类故障。 Rebecca Parsons 认为，我们甚至不再使用服务之间的进程内通信，这一点非常重要；相反，我们采用 HTTP 进行通信，而这几乎不那么可靠。
进化发展的架构（进化设计）
MSA系统的架构应该不断演进。 建议限制对单个服务边界的必要更改。 还必须考虑对其他服务的影响。 传统的方法是尝试通过版本控制来解决这个问题，但 MSA 建议在
作为最后的手段。
结论
完成上述所有内容后，我们可以明确什么是微服务。 微服务架构是一种将单个应用程序开发为小型服务集合的方法，每个服务都在自己的进程中运行，并通过轻量级机制（通常是 HTTP 资源 API）进行交互。 这些服务建立在业务能力之上，完全可以独立部署
自动化部署机制。 这些服务有最低级别的集中管理，可以用不同的编程语言编写并使用不同的数据存储技术。
来源： habr.com