介绍
架构风格的选择是构建信息系统的基本技术解决方案之一。在本系列文章中，我建议分析建筑应用程序中最流行的建筑风格，并回答何时是最喜欢的建筑风格的问题。在此过程中，我将尝试画出一条逻辑链，该逻辑链解释从整体式到微服务式的建筑风格的发展。
上次我们讨论了不同种类的整体，以及如何使用组件来构建它们，包括组装组件和部署组件。我们已经处理了面向服务的体系结构。
现在，我们将最终定义微服务架构的主要特征。
架构关系
应该理解，基于先前定义文章中的数据，任何服务都是组件，但并非每个服务都是微服务。
微服务架构的特征
微服务架构的主要特征是：
- 围绕业务能力进行组织
- 产品不是项目
- 智能端点和哑管道
- 分散治理
- 分散数据管理
- 基础设施自动化
- 失败设计
- 进化设计
第一点来自面向服务的体系结构，因为微服务是服务的特例。其他几点值得单独考虑。
围绕业务能力进行组织
现在有必要回顾一下康韦定律：创建系统的组织会组织其体系结构，复制这些组织内部的交互结构。例如，考虑创建编译器的情况：一个由7人组成的小组开发了一个7遍编译器，一个由5人组成的小组开发了一个5遍编译器。
如果我们谈论的是整体和微服务，那么如果开发是由职能部门（后端，前端，数据库管理员）组织的，那么我们将获得经典的整体。
要获得微服务，需要按业务机会组织团队（订单，装运，目录团队）。该组织允许团队专注于创建应用程序的特定部分。
产品不是项目
在微服务架构的情况下，团队将开发的功能转移给其他团队的项目方法是完全不合适的。团队必须在整个生命周期中为系统提供支持。亚马逊是采用微服务的旗舰之一，它表示：“您构建，运行它”。产品方法使团队能够感觉到业务需求。
智能端点和哑管道
SOA体系结构已经非常关注通信渠道，特别是企业服务总线（企业服务总线）。这通常会导致错误的意大利面条盒，也就是说，整体的复杂性变成了服务之间连接的复杂性。微服务架构仅使用简单的通信方法。
分散治理
微服务的关键决策必须由实际开发微服务的人员做出。在这里，关键决策意味着选择
编程语言，部署方法，公共接口合同等。
分散数据管理
应用程序依赖于单个数据库的标准方法无法考虑每个特定服务的细节。MSA假定采用各种技术之前的分散数据管理。
基础设施自动化
MSA支持连续的部署和交付过程。这只能通过自动化过程来完成。同时，大量服务的部署看起来不再令人恐惧。部署过程应该很无聊。第二方面涉及产品环境中的服务管理。没有自动化，就无法管理在不同操作环境中运行的流程。
失败设计
许多MSA服务都容易出现故障。同时，分布式系统中的错误处理也不是一件容易的事。应用程序体系结构必须能够应对此类故障。丽贝卡·帕森斯（Rebecca Parsons）认为，非常重要的是，我们甚至不再使用服务之间的进程内通信，而是使用HTTP进行通信，这几乎不那么可靠。
进化设计
MSA系统的体系结构必须不断发展。希望将所需的更改限制到一项服务的边界。还必须考虑对其他服务的影响。传统方法是尝试通过版本控制来解决此问题，但是MSA建议将版本控制作为
最后的手段。
结论
经过以上所有，我们可以制定出什么是微服务。微服务架构是一种将单个应用程序开发为一组小服务的方法，每个小服务都在自己的进程中运行并通过轻量级机制（通常是HTTP资源API）进行交互。这些服务建立在业务功能之上，可以使用
全自动部署引擎独立部署。这些服务的最低级别的集中管理可以用不同的编程语言编写并使用不同的存储技术。阅读第二部分
