微服务架构的内容，原因和方法 ——8个关键点来帮助您立即开始

多年来，我们一直在构建系统，并在这方面做得越来越好。这些年来，也出现了一些技术，架构模式和最佳实践。微服务是领域驱动设计，持续交付，平台和基础设施自动化，可扩展系统，多语言编程和持久性等领域出现的架构模式之一。

简而言之，什么是微服务架构？

罗伯特·C·马丁（Robert C. Martin）创造了 single responsibility principle 这一术语，即“将出于同样原因而改变的事物聚集在一起，并将因不同原因而改变的事物分开。”

微服务体系结构采用相同的方法，并将其扩展到松散耦合的服务，这些服务可以独立地开发、部署和维护。这些服务中的每一个都负责独立的任务，并且可以通过简单的API与其他服务进行通信，以解决更大的复杂业务问题。

微服务架构的主要优点

由于组成服务很小，因此可以从一开始由一个或多个小团队构建，这些团队之间由服务边界分隔开，这使得在需要时更容易扩展开发工作。

一旦开发，这些服务也可以彼此独立地部署，因此易于识别热服务并且可以独立于整个应用程序进行扩展。微服务还提供改进的故障隔离，从而在一个服务中出现错误的情况下，不必让整个应用程序停止运行。修复错误后，只要为相应的服务重新部署即可，而不是重新部署整个应用程序。

微服务架构带来的另一个优势是可以更容易地选择最适合所需功能（服务）的技术堆栈（编程语言，数据库等），而不是需要采用更标准化、一刀切的方法。

我们如何开始使用微服务架构？

希望您现在确信微服务架构可以提供超越传统架构的一些独特优势，并且您已经开始为下一个项目考虑这种方法。

接下来的问题是“该如何开始？” ，还有 “是否有一套准则可以帮助我可以更好的构建微服务架构？”
好吧，我给出的答案恐怕是“没有”。

虽然这可能听起来不那么让你感到前途坦荡，但是许多采用微服务架构的组织都遵循了一些相同的规律，并最终取得了成功。下面我们一起来讨论一下：

1. 如何分解

使我们的工作更轻松的方法之一可能是定义与业务能力相对应的服务。业务能力是企业为了给最终用户提供价值所做的事情。

识别业务能力和相应的服务需要对业务有深度了解。例如，电商平台的业务功能可能包括以下内容。
●产品目录管理
●库存管理
●订单管理
●交货管理
●用户管理
●产品推荐
●产品评论管理

一旦确定了业务能力，就可以根据每一个确定的业务能力构建所需的服务。。

每个服务都可以由不同的团队拥有，他们将成为该特定领域的专家，并成为最适合这些特定服务的技术专家。这通常会产生更稳定的API边界和更稳定的团队。

2.构建和部署

在确定这些小服务的服务边界后，可以由一个或多个小团队使用最适合的技术来开发它们。例如，您可以选择在Java中使用MySQL数据库和Scala/Scale的产品推荐服务来构建用户服务。

开发完成后，可以使用任何可用的CI服务器（Jenkins，TeamCity，Go等）设置CI / CD管道，以运行自动化测试用例，并将这些服务独立部署到不同的环境（集成，QA，分段，生产等）、

3.精心设计个性化服务

在设计服务时，要仔细定义它们并考虑将要公开的内容，将使用哪些协议与服务进行交互等。

隐藏服务的任何复杂性和实现细节非常重要，并且只公开服务的客户端所需的内容。如果暴露了不必要的细节，以后就很难更改相应的服务，因为想要确定谁依赖于当前服务的各个部分，就需要付出大量的辛勤工作。此外，在独立地部署服务时，将大大的失去灵活性。

下图显示了设计微服务时常见的错误之一：

如图中所示，这里我们采用服务（服务1）并将服务所需的所有信息存储到数据库中。当创建另一个需要相同数据的服务（服务2）时，我们直接从数据库访问该数据。

在某些情况下，这种方法似乎合理且合乎逻辑 - 可能很容易访问SQL数据库中的数据或将数据写入SQL数据库，或者服务2所需的API可能不容易获得。

一旦采用这种方法，在确定什么是隐藏的和什么不是隐藏的过程中，就会立即失去控制。而且，如果模式需要更改，则进行更改的灵活性将丢失，因为您不知道谁在使用数据库，也不知道更改是否会中断服务2。

正确的解决方法，如下：

服务2应该访问服务1并避免直接进入数据库，因此为可能需要的各种模式更改保留了最大的灵活性。只要确保公开的API测试通过，就不必担心系统的其他部分。

如上所述，请仔细选择服务之间的通信协议。例如，如果选择Java RMI，则不仅API的用户限制使用基于JVM的语言，而且此外，协议本身非常脆弱，因为难以保持与API的向后兼容性。

最后，在向客户端提供客户端库以使用该服务时，请仔细考虑，因为最好避免重复集成代码。当出现此错误时，如果客户端依赖不必要的详细信息，它还可以限制在API中进行的更改。

4.分散事物

有些组织已经在微服务方面取得了成功，并且遵循了一个模型，在这个模型中，构建服务的团队负责处理与该服务相关的所有事情。他们都是开发、部署、维护和支持它的人。没有专门的支持或维护团队。

实现同样目标的另一种方法是拥有一个内部开源模型。通过采用这种方法，需要更改服务的开发人员可以检查代码，处理功能并自行提交PR，而不是等待服务所有者获取并处理所需的更改。

要使此模型正常工作，需要提供适当的技术文档以及每项服务的设置说明和指导，以便任何人都可以轻松地获取和处理服务。

这种方法的另一个潜在优势是，它让开发人员专注于编写高质量的代码，因为他们知道还有其他人会关注它。

还有一些架构模式可以帮助分散事物。例如，您可能拥有一个架构，其中服务集合通过中央消息总线进行通信。

该总线处理来自不同服务的消息的路由。像RabbitMQ这样的消息代理就是一个很好的例子。

随着时间的推移，人们开始将越来越多的逻辑放入这个中央总线，并开始越来越多地了解您的域名。随着它变得更加智能化，这实际上可能成为一个问题，因为当需要跨团队之间进行协调变更的时候，将变得难以开展。

我对这些类型的架构的一般建议是让它们保持相对“愚蠢”，让它们只处理路由。基于事件的架构似乎在这些场景中运行良好。

5.部署

为任何依赖的API编写消费者驱动合同（CDC）非常重要。这是为了确保该API中的新更改不会破坏您的API。

在CDC中，每个消费者API在单独的合同中捕获他们对供应商的期望。所有这些合同都与供应商共享，以便他们深入了解他们必须为每个客户履行的义务。

CDC必须在部署之前以及对API进行任何更改之前完全通过。它还可以帮助供应商了解依赖于它的服务以及其他服务的依赖性。

在部署独立的微服务时，有两种常见的模型。

每个操作系统的多个微服务

首先，每个操作系统可以部署多个微服务。使用此模型，可以节省自动化某些事情的时间，例如，不必为每个服务提供主机。

这种方法的缺点是它限制了独立更改和扩展服务的能力。它还造成了管理依赖关系的困难。例如，如果使用Java编写，同一主机上的所有服务都必须使用相同版本的Java。此外，这些独立的服务可能会对其他正在运行的服务产生不必要的副作用，这是一个很难重现和解决的问题。

每个操作系统一个微服务

由于上述挑战，第二个模型（每个操作系统部署一个微服务）是首选。

使用此模型，服务更加孤立，因此更容易管理依赖关系并独立扩展服务。但你可能会问自己“这不是很贵”吗？其实并不是。

解决此问题的传统解决方案是使用Hypervisors，在同一主机上配置多个虚拟机。这种解决方案方法成本效率低，因为管理程序进程本身正在消耗一些资源，当然，配置的虚拟机越多，消耗的资源就越多。这就是容器模型获得良好牵引力的地方，也是首选。Docker是该模型的一个实现。

在生产中对现有微服务API进行更改

微服务模型通常面临的另一个常见问题是当其他人在生产中使用它时，确定如何对现有的微服务API进行更改。对微服务API进行更改可能会破坏依赖于它的微服务。

有很多不同的方法来解决这个问题。

首先，对API进行版本控制，并在API需要更改时，部署新版本的API，同时保持第一个版本。然后可以按照自己的节奏升级从属服务以使用较新的版本。一旦迁移了所有从属服务以使用更新的微服务的新版本，就可以将其关闭。

这种方法的一个问题是很难维护各种版本。任何新的更改或错误修复都必须在两个版本中完成。

因此，可以考虑另一种方法，即当需要更改时，在同一个服务中实现另一个端点。一旦所有服务都充分利用了新的端点，就可以删除旧的端点。

这种方法的独特优势在于维护服务更容易，因为始终只有一个版本API在运行。

6.制定标准

当有多个团队独立处理不同的服务时，最好引入一些标准和最佳实践 —— 例如错误处理，其实不难预料，如果没有提供标准和最佳实践，每个服务都可能以不同的方式处理错误，毫无疑问会写出大量不必要的代码。

从长远来看，创建像PayPal的API样式指南这样的标准总是有帮助的。让别人知道API的功能以及创建API时持续完善API的文档也很重要。有一些像Swagger这样的工具非常有助于整个API生命周期的开发，包括从设计和文档到测试和部署。为API创建元数据并让用户使用它，以便让他们能够更多地了解它并更有效地使用它。

服务依赖

在微服务架构中，随着时间的推移，每项服务的开始取决于越来越多的服务。随着服务的增长，这会引入更多问题，例如，服务实例的数量及其位置（主机+端口）可能会动态变化。此外，数据共享的协议和格式可能因服务而异。

在这个位置API网关和服务发现变得非常有用。实现API网关成为所有客户端的单一入口点，API网关可以为每个客户端公开不同的API。

API网关还可以实现安全性，例如验证客户端是否有权执行请求。有一些像Zookeeper这样的工具可用于服务发现（虽然它不是为此目的而构建的）。有更多的现代工具，如etcd和Hashicorp的Consul将服务发现视为一等公民，在这个问题上它们绝对值得关注。

7.故障

需要了解的一点是，微服务默认情况下不具备弹性。服务会出现故障。由于依赖服务的失败，可能会发生故障。此外，由于各种原因（例如代码中的错误，网络超时等）也可能会出现故障。

微服务架构的关键在于确保整个系统在某个部分出现错误时不会受到影响或出现故障。

有像隔板和断路器的模式，可以帮助您实现更好的防护性。

隔板

隔板模式将应用程序的元素隔离到池中，因此如果其中一个发生故障，其他的部分将继续工作。这种模式被称为隔板，因为它类似于船体的分段隔板。如果一艘船的船体受损，只有受损部分充满了水，这可以防止船下沉。

断路器

断路器模式将受保护的函数调用包含在断路器对象中，对该对象进行故障监视。一旦故障超过阈值，断路器就会跳闸，并且所有对断路器的进一步调用都会返回错误，而不会在某个配置的超时时间内进行受保护的调用。

超时结束后，断路器允许一些呼叫通过，如果它们成功，则断路器恢复正常状态。在断路器发生故障的时间段内，可以通知用户系统的某个部分损坏，系统的其余部分仍然可以使用。

请注意，为应用程序提供所需的弹性级别可能是一个多维度的挑战 。

8.监控和记录

微服务本质上是分布式的，并且对各个服务的监视和记录可能是一个挑战。很难通过并关联每个服务实例的日志并找出个别错误。就像单片应用程序一样，没有单一的地方可以监控微服务。

日志聚合

为了解决这些问题，优选的方法是利用集中日志服务来聚合来自每个服务实例的日志。用户可以从一个集中位置搜索这些日志，并在出现某些消息时配置警报。

标准工具已被各种企业广泛使用。ELK Stack是最常用的解决方案，其中日志记录守护进程、日志存储、收集和聚合日志，这些日志可以通过ElasticSearch索引的Kibana仪表板进行搜索。

统计聚合

与日志聚合类似，统计聚合（如CPU和内存使用）也可以集中使用和存储。像Graphite这样的工具在推送到中央存储库和以有效的方式存储方面做得很好。

当其中一个下游服务无法处理请求时，应该有一种触发警报的方法，这时候在每个服务中进行API的健康检查变得非常重要——它们返回有关系统健康状况的信息。

健康检查客户端可以是监控服务或负载平衡器，它调用端点在特定时间间隔内定期检查服务实例的健康状况。即使所有下游服务都是健康的，服务之间仍然可能存在下游通信问题。Netflix的Hystrix项目等工具能够识别这些类型的问题。

最后一件事

现在我们已经介绍了微服务架构，那么关于为什么要部署微服务架构，或者考虑开始部署，我想提出最后一条建议：

• 从小开始 -
  当您刚刚开始开发微服务时，请从一到两个服务开始，并从中学习，随着时间和经验的积累，您会了解更多。

我祝愿您在这条激动人心的微服务架构之路上取得最大的成功。

Jetinder Singh是Hashmap的高级Tempus IIoT / IoT开发人员，负责跨行业的工作，拥有一批创新技术专家和领域专家，为我们的客户加速高价值的业务成果。

转载于:https://blog.51cto.com/14228156/2359131