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