微服务架构-快速指南

上次更新时间：2019年3月7日

1.微服务架构简介

微服务是管理安排的体系结构设计，其中应用程序作为不同的最小自治管理单元的集合来工作。它是一种产品设计方法，其重点是将应用程序分解为具有非常典型的界面的单工作模块。这些模块可以由负责整个管理生命周期的小组*地传达和工作。

“小规模”一词暗示着对微服务的估计，该微服务必须由一个单独的改进小组（5至10个设计人员）来进行。在这种策略中，将巨大的应用程序隔离到最少的自治单元中。

随着前端技术的发展，开发方法正在发生巨大变化。如今，这些公司更喜欢选择独立的前端和后端项目。这些项目使用服务相互通信。微服务是为各种目的而开发的这些服务API的原子形式。微服务体系结构是系统设计，其中每个后端处理模块都作为微服务API的设置暴露于前端。这允许后端独立于前端中发生的事情。

微服务架构为每个原子功能任务提供API。例如，考虑一个社交媒体网站。社交媒体网站可以具有微服务，用于获取用户的帖子，帖子的喜欢和评论，用户个人资料详细信息等。这些服务都是原子性的，因此其中一项服务中的任何问题都不会真正影响系统的功能

2. Web开发架构的历史

从一开始，Web开发架构就一直在不断发展。较早的Web应用程序以单个服务器的形式启动，该服务器拥有Web资源并处理诸如Controller，模型和业务对象之类的文件。这些服务器中的后端代码与数据库和前端紧密耦合。在这种情况下，网页是在服务器端呈现的，然后再将其发送回前端。这种架构被称为整体架构。这种架构有很多缺点。它们在下图中显示。

整体架构与其资源紧密耦合。这限制了其实施的灵活性。代码逻辑上的任何细微中断都会影响完成Web应用程序。由于前端和后端的紧密耦合，它已经消耗了很多硬件资源。由于诸如会话共享，资源共享和数据库事务同步之类的问题，进一步扩展它会很困难。在单片架构中，整个代码都部署在单个服务器上。该服务器将根据需要进一步扩展。在此，无论特定模块上的负载如何，都需要在需要时扩展和升级整个系统。随着系统的发展，单片式架构开始变得复杂，并使其难以管理整个系统结构。代码库的模块化将为开发人员减少对特定模块进行编码时破坏其他模块的可能性提供了很大的帮助。

最重要的是，整体架构将要求开发人员具有前端和后端的知识。由于实际原因，这些资源通常很昂贵。这就需要设计前端和后端可以分开的体系结构。由于前端渲染完全依赖于后端开发，因此多个开发人员无法单独拆分工作。这阻碍了持续的开发过程。另外，随着代码开始变得复杂，并且需要实施的检查数量增加，这也会减慢整个开发过程。

3. Web开发架构的演变

多年来，随着ajax请求的出现，这种情况发生了变化。 Ajax请求允许用户获取数据而无需刷新整个页面。但是，这些端点仅发送XML数据。 AJAX请求最初是通过普通的servlet端点服务的。随着API的增加，授权AJAX请求变得越来越复杂。需要一种更好的方式来在共同级别上执行请求。这些基于Servlet的实现中的另一个挑战是对调用的托管授权。由于没有定义用于管理服务授权的通用机制，因此这些端点开始被外部用户滥用。最后，出现的主要问题是减少数据负载以支持较慢的网络。 Servlet请求的正常数量远远超出了预期。这减慢了数据通话的速度。这使得服务器端呈现更好的选择。

这是Web服务出现的时候。出现的第一种Web服务是SOAP服务。 SOAP服务和Ajax改变了数据交换的方式。 SOAP服务引入了严格定义数据交换标准和授权数据请求的方式。有了SOAP服务，前端的情况就开始发生变化。通过AJAX请求，前端开始与后端松散耦合。但是，AJAX并不是一种整齐的处理方式。在一个通用级别上管理ajax请求的URL很困难。随着系统开始变得复杂，分布式代码始终会导致更多错误。而且，XML消息模板与响应格式的紧密结合也引起了对更加灵活的Web服务的需求。 REST服务应运而生。

这产生了前端框架，该框架定义了更干净的方法来对完全基于REST服务的网页进行编码。诸如Angular，VueJS，Backbone JS之类的框架应运而生。这些框架由提供所需数据的服务支持。他们利用REST API调用在前端上呈现页面。通过前端和后端之间的这种松散耦合，整个编码模式开始进行转换。独立的后端服务器提供了扩展和仅后端集中化的灵活性，而前端则在轻量级实例上运行。但是，此功能带来了涉及太多端点的复杂体系结构。这种结构使完全独立于前端的项目管理变得充满挑战。因此需要简化这些复杂的后端。

这就是微服务体系结构出现的方式。微服务体系结构是将后端划分为微型服务器小模块的体系结构。这些微服务器为系统的特定模块提供服务。例如，考虑银行网站的情况。与贷款，保险，银行，信用卡和借记卡有关的服务可以隔离到单独的服务器中。这些服务器可以独立插入和拔出。这种体系结构可确保一台服务器的故障不会影响另一台服务器的体系结构。

4.微服务架构–现实生活中的例子

上图很好地描述了用于简单运输系统的微服务体系结构。可以看出，运输系统具有四个不同的模块。店面，帐户服务，库存服务和运输服务。所有这些模块都分为独立运行的微型服务器。在此，应注意，尽管这些服务器独立运行，但API服务将由单个Web应用程序或移动应用程序访问。

配置移动应用程序或Web应用程序以从多个端点获取数据很困难。由于流量可能不是直接来自单个端点的，所以这将使整个体系结构混乱，并使系统不安全。为了解决此问题，我们需要将模块带到一个通用平台，该平台将Web服务调用路由到相应的微型服务器。这项工作由API网关完成。

API网关是代理服务器或执行多项工作的IHS的一层。微服务架构中的网关执行以下任务：

根据访问的URL将API请求路由到正确的服务器
阻止API请求（如果它们来自未经授权的来源）
筛选可能试图影响服务器性能的垃圾邮件API请求

可以使用许多不同的技术来构建API网关。可用于构建API网关的常规选项包括NGINX，Apache和COMODO IHS。这些是简单的服务，它们运行并侦听独立服务器上的特定端口。此服务稍后进一步根据子域或路径路由请求。该网关非常易于配置，对于基础微服务器的初级保护非常有用。

5.微服务架构的挑战

微服务架构尽管简单，但却是处理的巨大责任。服务器数量越多，维护它们的责任就越大。本节讨论微服务架构面临的主要挑战。我们还将讨论其中大多数的解决方法。

5.1服务器管理

使用微服务，正在运行的服务器实例的数量一直在增加。这种体系结构有助于保持服务器之间的依赖性较低。但是，与此同时，它们增加了管理它们的复杂性。随着模块数量的增加，要管理的组件数量也随之增加。每个模块都会添加一台服务器，这会使管理员感到麻烦。有了自动扩展功能后，系统将变得更糟，因为服务器将不断增加自身，因此需要更好的业务流程层。

这些问题可以通过两种主要方法来解决。其中之一是配置CI / CD管道，以确保完整的模块可以自动测试并跨实例部署，而无需对其进行配置。这将在很大程度上减少服务器管理的工作负担。这种方法将要求使用测试驱动开发（TDD）。这涉及测试的开发，以确保仅在代码通过这些步骤集时才完成部署。在此自动部署系统中跳过测试可能会冒风险并削弱系统。

解决此问题的另一种方法是在带有AWS Codestar的AWS Elastic beantalk等系统上设置自动扩展编排。这些系统不仅可以帮助您自动执行代码构建和部署过程，还可以帮助您构建可以根据所需参数自动扩展自身的应用程序。

5.2路由管理

随着服务器数量的增加，需要很好地管理服务器的路由。这使得必须遵循正确的约定，术语和相对URL。当涉及到负载平衡时，多个服务器的路由管理可能会变得棘手。我们需要确保正确的实例使用各自的URL进行路由。此外，还需要在公共层上实施防火墙保护，以确保不损害代理层。

5.3微服务之间的内部通信

在单片架构中，不同的API和服务之间的通信非常简单，因为代码位于同一基础上。使用微服务，任何相关的操作将开始变得复杂。在微服务架构中，需要使用消息传递队列来协调服务器之间的通信。当相互依赖性更大时，这些队列可能变得复杂。因此，如果系统具有更多内部依赖性，则应谨慎使用微服务架构。通常可以通过正确组合模块来解决此问题。进行适当的分组以减少内部通信将有助于使系统平稳。

6.微服务架构–扩展

微服务架构涉及两种不同类型的扩展。本节将在此处详细讨论这些缩放类型。

6.1 X缩放或水平缩放

这种类型的缩放涉及跨可用内核的控制器缩放。该架构涉及提供更高的计算能力，并根据需要扩展整个系统。这非常简单，涉及更多资源。该系统基于系统的集体监视。

在水平缩放体系结构中，系统组件分为子部分并以水平体系结构排列。在将系统实现为MVC体系结构时，通常使用这种类型的缩放比例。在这种水平布置中，微型服务器充当控制器。

6.2 Y缩放

在这种类型的系统中，系统资源树垂直增长。系统会根据需要为每个模块不断添加更多机器。在垂直扩展体系结构中，每个微服务服务器都分别进行扩展。他们有各自的负载平衡层来支持其体系结构。除了这些之外，额外的路由层还有助于将API调用路由到这些负载均衡器。因此，API调用在被服务之前至少要经过两个反向代理服务器。

Y缩放涉及多层，这增加了资源安排的复杂性。 Y缩放时的失败很难跟踪和指出。在达到根本原因之前，需要注意多个检查点。

7.微服务架构–通信

微服务架构中最重要的方面是其内部通信。微服务架构涉及内部基于SOA的身份验证和授权的编排。微服务之间的内部通信取决于以下规则和工作流程原则。

高凝聚力：每个子模块都需要划分为执行专用任务的特定原子子模块。这些应分为尽可能小的模块。
独立：每个子模块应尽可能独立于其他子模块。以编程方式，它们根本不应该连接。唯一存在的连接是基于相互消息队列的通信
以业务领域为中心：应按业务领域对模块进行划分，而不是多层模块化。
测试自动化：每个模块的测试应自动化，以确保集成测试不会失败。此外，测试自动化

微服务使用管理披露作为手册来发现它们之间的对应关系。那时的微服务通过无状态服务器（例如通过HTTP请求/消息总线）相互通信。这些微服务利用应用程序接口（API）相互对话。微服务在其内部进行传递之后，它们会将静态物质发送到基于云的容量管理，该管理可以通过内容传递网络（CDN）将其专门传递给客户。

8.微服务架构的优势

与常规的处理方式相比，微服务架构具有许多优势。这些优势在于系统的结构方式。系统的结构不完善也可能导致严重的后果。正确构建的微服务系统的优点如下所示。

简化的服务器独立模块，使开发新模块时更容易添加
使用API网关简化API路由
更高的安全性，可防止任何特定模块中的代码故障
允许开发人员在每个模块上独立工作
允许根据需要进行模块明智的部署。
自动缩放仅针对需要的模块完成

有了这些优点，也会带来一系列的缺点。这些将在以下部分中讨论

9.微服务架构的缺点

在单片架构中，整个系统立即部署到服务器。这允许系统以紧密集成的方式进行测试。这样可以确保不会因依赖服务而导致故障。但是，在微服务架构中，通常的做法是分别部署和测试每个模块。因此，如果某个特定模块依赖于另一个模块，则在部署之前需要始终注意对其进行集成和测试。这消除了在开发中具有模块化的灵活性。

在微服务架构中，随着服务器数量的不断增加，跟踪资源将变得很棘手。正确地平衡负载是一个挑战。必须经常监视未充分利用的资源，并将其转移到最佳系统，以确保成本得到优化。队列中的下一个挑战是其授权。

API的授权是非常重要的方面。通常，在微服务架构的情况下，使用JWT令牌对API进行授权。与将授权层集成在单个代码库中的单片架构不同，在微服务架构中，如果需要在每个模块中完成代码，将变得具有挑战性。因此，它需要编排可以在同一级别管理授权的其他授权机制。

10.微服务架构的最佳用例

微服务架构是一种非常有用的架构。但是，这并不是所有情况下的最佳解决方案。我们需要仔细选择在哪里使用微服务架构。本节介绍了最适合微服务架构的精确用例。

微服务架构非常适合用于满足以下条件的系统：

该系统包含独立的模块，可以将其分开以实现特定的目的。
该系统具有特定的模块，与其他模块相比，它们需要更大的扩展性
该系统可以分为前端和API代码
这些模块不是紧密耦合的，但偶尔需要内部通信
该系统仅依赖于API，不需要任何服务器端页面呈现。
数据存储对于每个模块都是独立的，可以独立管理

12.结论

微服务体系结构是一种基于SOA的体系结构，有助于简化涉及多个模块的系统。利用微服务架构，可以增加扩展特定模块智能资源的整体灵活性。这种体系结构有助于开发本质上是模块化的并且在前端和后端方面是隔离的系统。

这种类型的体系结构有助于使开发人员并行处理多个模块，而不会引起代码库冲突。这样可以更好地进行项目协作和管理。但是，随之而来的是挑战性的业务流程编排的风险。在进行系统部署之前，需要集成这些服务，并且需要测试消息队列和通信。此外，微服务架构也承担着更大的责任。

翻译自: https://www.javacodegeeks.com/2014/06/microservice-architecture-a-quick-guide.html