微服务在业界是一个比较新的流行语，每个人似乎都在以这种或那种方式谈论它。让我们了解什么是微服务？通过本教程，我们将了解微服务的定义、概念和原理。微服务的定义在今天，微服务是继SOA（ServiceOrientedArchitecture）之后越来越流行的架构模式之一，如果你关注行业趋势，你会发现如今的企业不再像几年前那样严格有兴趣开发大型应用程序来管理端到端的业务功能。相反，他们选择快速、敏捷的应用程序，这也使他们花费更少的钱。微服务有助于打破大型应用程序的边界，在系统内部构建逻辑上独立的较小系统，例如，借助亚马逊AWS，您可以轻松构建云应用程序。这是微服务的一个很好的例子。如上图所示，每个微服务都有自己的业务层和数据库，改变其中一个微服务不会对其他微服务产生任何影响。总之，微服务使用各种轻量级协议（例如HTTP和REST、TCP）或消息传递协议（例如JMS和AMQP）相互通信。在特定场景下，他们还可以选择更专业的协议。微服务的原则现在让我们看看微服务必须要求的原则。1.单一功能职责单一功能职责是SOLID设计模式之一，意味着一个单元，无论是类、函数还是微服务，都应该有一个且只有一个职责。在任何时候，一个微服务都不应承担多个责任。2.围绕业务功能设计微服务。您应该专注于特定的业务功能，并确保它有助于完成任务。微服务永远不应局限于采用最能解决业务目的的适当技术堆栈或后端数据库存储。当我们设计单个应用程序时，这通常是一个约束条件，我们在其中尝试通过在某些领域进行一些权衡来解决多个业务解决方案。微服务使您能够选择最适合手头问题的解决方案。3.你建造它，你拥有它。此设计的另一个重要方面与开发前后的职责有关。在大型组织中，通常一个团队开发应用程序位置，并在一些知识转移会议之后，将项目移交给维护团队。在微服务中，构建服务的团队拥有它并负责在未来维护它。这让开发人员能够接触到他们软件的日常操作，他们可以更好地了解他们构建的产品在现实世界中是如何被客户使用的。4.基础设施自动化为微服务准备和构建基础设施是另一个非常重要的需求。服务应该是可独立部署的，并且应该捆绑所有依赖项，包括库依赖项，甚至是执行环境，例如抽象物理资源（Web服务器和容器或虚拟机）。微服务和SOA之间的一个关键区别是它们的自治级别。虽然大多数SOA实现提供了服务级别的抽象，但微服务进一步抽象了实现和执行环境。在传统的应用开发中，我们构建一个WAR或EAR，然后将其部署到一个JEE应用服务器中，比如使用JBoss、WebLogic、WebSphere等，我们可以将多个应用部署到同一个JEE容器中。在理想情况下，在微服务方法中，每个微服务都将构建为一个胖Jar，嵌入所有依赖项，并作为独立的Java进程运行。5.容错设计微服务在设计时应考虑到故障场景。如果服务失败或停机一段时间怎么办？这些是必须在实际编码开始之前解决的非常重要的问题——以便清楚地估计服务故障将如何影响用户体验。快速故障是用于构建容错、弹性系统的另一个概念。这种哲学提倡预期会失败的系统，而不是构建永不失败的系统。由于服务随时可能发生故障，因此能够快速检测故障并在可能的情况下自动恢复服务非常重要。微服务应用程序非常重视应用程序的实时监控，检查架构元素（数据库每秒接收多少请求）和业务相关指标（例如每分钟接收多少订单）。语义监控可以提供错误的预警系统，触发开发团队进行跟踪和调查。微服务的优点微服务有很多优点与传统的多层架构（单一的巨大应用程序）相比，微服务的优点如下：1.使用微服务，架构师和开发人员可以为每个微服务选择特定的应用程序。目的的架构和技术（熟悉的语言架构对应多种语言）。这提供了以更具成本效益的方式设计更合适的解决方案的灵活性。2.由于该服务非常简单且规模较小，企业可以尝试新的流程、算法、业务逻辑等。通过提供快速试验和失败的能力，使企业能够进行颠覆性创新。3、微服务可以实现选择性伸缩，即每个服务都可以独立伸缩，伸缩成本低于单体应用。4.微服务是自包含和独立的部署模块。当第二个微服务没有按照我们的需求执行时，我们可以用另一个类似的微服务替换一个微服务。它有助于做出正确的“购买构建”决策，这对许多企业来说通常是一个挑战。5.微服务帮助我们构建本质上是有机的系统（有机系统是通过添加越来越多的功能在一段时间内水平增长的系统）。因为微服务都是关于独立可管理的服务——它允许在需要时添加越来越多的服务，而对现有服务的影响最小。6.技术变革是软件开发的障碍之一。使用微服务，可以单独更改或升级每个服务的技术，而不是升级整个应用程序。7.由于微服务封装了服务运行环境和服务本身，所以允许多个版本的服务在同一个环境中共存。8.最后，微服务还支持更小、更专注的敏捷开发团队。团队将根据微服务边界进行组织。简介：在本文中，我只是尽我所知列出了我在许多组织中看到的微服务的一些好处。由强大的设计和出色的代码支持的单体也可以证明是一个好的决定，并且产品会存在足够长的时间来支持该决定。与微服务类似，糟糕的设计决策将代价高昂。它们可能看起来简化了组件，但它们可能会增加组件之间通信的复杂性并且更难以控制和管理。
