微服务架构概述 An Overview of Micro services Architecture by Khoa Dinh

对微服务架构未来趋势的介绍。 在这篇文章中，我们将讨论微服务如何工作，有什么好处，以及在实施时应该注意什么。

什么是微服务架构？
将软件应用程序设计为可独立部署的服务套件的一种特殊方式

- 马丁福勒

微服务架构是近年来流行的一个新词汇，但其背后的想法并不新鲜。事实上，它与几年前非常流行的SOA模式类似。微服务和SOA都是将应用程序分解为更小的服务，以便更高效地扩展和管理应用程序生命周期。尽管如此，正如Martin Fowler的综合帖子中所解释的那样。虽然SOA是一个非常普遍的概念，可能意味着很多事情，但微服务体系结构描述了使用非常小的服务构建应用程序的特定方式，每种方法都专注于做好一件事情。

微服务获得普及背后有两个原因。首先，随着软件变得越来越复杂，传统的单体架构不再需要可扩展性和快速开发周期。微服务如何提供帮助，我们将在下一节中看到。其次，由Netflix领导的大型互联网公司在实施微服务体系结构方面的成功，对于考虑切换的人来说起到了很大的激励作用与动力。

那么她是如何工作的？

解释微服务的最好方法是将其与建立应用程序的旧单体方式进行比较，所以让我们快速回顾一下。

在传统的三层设计中，服务器端应用程序扮演着中间层的角色，处理业务逻辑以及从数据库层向客户端（网页浏览器，移动应用程序，物联网等）提供数据。该应用程序被编写为一个统一的代码库，并且所有内容都在同一个进程中运行。通过在多台服务器上复制相同的单体应用程序来完成扩展。

在微服务体系结构中，单体应用被分解为多个小型，细粒度，可独立部署的服务。这些服务可独立部署的事实非常重要，它使得一些微服务变得更加重要，使用便利。这些服务可以由不同的团队并行开发，使用最适合其目的的不同技术栈。而且，由于它们是独立部署的，因此可以独立进行扩展。例如，可以在配备强大处理器但内存较低的服务器上扩展CPU数量较多但不需要太多内存的服务。我们只能扩展我们想要的服务，而不是全部。

如果服务如此独立和孤立，我们应该如何在它们之间共享代码？那么，这是一个寻找平衡点的问题。虽然在服务之间共享代码允许重用现有功能并保持DRY原则，但它也增加了服务的耦合性。一种解决方案是仅共享技术库，并且可以将常用功能制作为其他服务可以调用的独立服务。这其实是我们接下来的事情，服务之间的沟通。

这些微服务之间的通信可以通过两种主要方式完成：HTTP和消息队列（Azure服务总线，RabbitMQ，Apache Kafka等）。基本上，HTTP是直接通信，应该在您希望从其他服务立即响应时使用。另一方面，消息队列的发布/订阅机制更多的是“启动并忽略Fire and Forget”的方式。

最后，由于服务非常精细，客户端应用程序通常需要与多个服务进行交互以获取所需的数据。要允许更改服务而不影响客户端，请使用API​​网关。 API网关是隐藏所有微服务的抽象层，为客户端留下一个端点进行通信。到达网关的请求将被代理/路由到相应的服务。网关还可以帮助我们轻松监视服务的使用情况。

（上图）传统的单体服务架构

（上图）微服务架构

虽然旧的整体架构过去运行良好，但在目前的世界中，应用程序需要经常部署新功能并且需要始终开启，但这只是过时。一小部分的更改需要测试，重新构建和重新部署整个应用程序。而且由于一切运行在同一个过程中，未处理的异常可能会导致整个单体系统的崩溃。

另一方面，微服务体系结构具有更加灵活和易恢复性
服务本身非常简单，专注于只做一件事情，所以他们更容易测试并确保更高的质量。
每种服务都可以使用最适合的技术和工具进行构建，从而实现多边形持久性等。对于项目的其余部分，您不必拘泥于早期的技术选择。
多个开发人员和团队可以在此架构下独立提供。这对于持续交付来说非常重要，可以在保持系统其他部分稳定的同时实现频繁发布。

如果服务出现故障，它只会影响直接依赖它的部件（如果有这些部件的话）。其他部分将继续运行良好。

你应该注意的事情：

与其他模式和体系结构相同，微服务体系结构不是解决所有问题的银弹。虽然它解决了旧的单体应用程序中的很多问题，但它也引入了我们需要考虑的新问题。
随着大量移动部件的发展，与单体架构相比，微服务处于不同的复杂程度。部署和维护生产中的微服务应用程序需要具备显着的DevOps技能。虽然单体应用程序可以部署到小型应用程序服务器集群中，但微服务中的每个服务都需要拥有自己的集群以实现故障转移和弹性。为这些集群添加负载平衡器和消息传递层也不是微不足道的工作。强大的自动化发布脚本技能需要能够利用持续交付优势。
微服务系统本质上是分布式的，分布式系统很难建立。以前一个简单的方法调用可能现在是远程过程调用，REST或异步消息。开发人员现在需要更多地考虑诸如服务之间的网络延迟，容错，版本控制等问题。虽然这些属性在系统中总是很好，但他们肯定需要花费更多的精力来构建。
尽管服务更容易自行测试，但端到端测试更加困难。由于代码流是复杂的，因此可能很难找出链中哪里出了问题。

总结结论：

微服务体系结构是以敏捷的方式设计和构建高度可伸缩的应用程序的一种非常有前途的方式。 虽然我们看到了实现微服务系统所面临的挑战，但在我看来，随着架构获得普及，更多工具和框架将用于支持它，大多数解决方案将在不久的将来得到解决。 目前我正在研究创建一个用于培训目的的内部项目，我认为这是一个尝试微服务架构的绝好机会，因为我们不必过多担心生产等方面的困难。 在我们尝试过之后，我会再写一篇关于实际结果的文章。