下载掌阅APP，畅读海量书库
立即打开
正如我之前所提到的，使用微服务架构的初期，不需要采用很多新技术。事实上，采用新技术可能会适得其反。随着微服务架构的逐步推进，我们应该不断地寻找和关注由系统分布程度不断提升所带来的问题，并根据具体问题寻找应对的技术。
技术确实对微服务这一概念的推广发挥了很大的作用。了解那些可以帮助你充分利用这种架构的工具将是成功的关键。实际上，采用微服务要求你对相关的技术有非常深入的理解，因为你以往对逻辑架构和物理架构区别的理解可能并不到位。如果你参与设计微服务架构，那么你需要对两大架构进行广泛的了解。
在后续章节中，我们将详细探讨这些技术。在此之前，本章会简要介绍其中的一些技术。如果你决定使用微服务，它们可能会对你有所帮助。
随着你管理的进程数量的不断增加，了解系统在生产环境中的运行状态将变得越发困难。这也会导致故障排除变得更难。我们将在第10章更深入地探讨这些问题，但至少，我强烈建议在采用微服务架构之前，将实现日志聚合作为先决条件。
虽然我说过在使用微服务的初期，要谨慎引入过多的新技术，但是日志聚合工具至关重要，你应该将其视为采用微服务的先决条件。
日志聚合系统可以收集和汇总所有服务的日志，并提供一个日志分析中心，甚至将其作为主动警报机制的一部分。在这一领域有很多选择，可以满足各种情况下的要求。出于不少原因，我很喜欢使用 Humio，不过主流公有云供应商所提供的简单的日志服务已经足够帮助你起步了。
你可以通过实现关联 ID（correlation IDs）让这些日志聚合工具更加有用，其中每单个 ID 用于标记一组相关服务的调用。例如，由某个用户交互而触发的调用链。通过将此 ID 记录在每条日志中，要过滤出指定调用链相关的日志就变得非常容易，这也让故障排除变得更加容易。
随着系统的复杂性不断增加，考虑采用一些工具变得必不可少，这些工具能够帮助更好地探索系统，跨多个服务进行追踪分析、检测瓶颈，并提出你之前没有考虑到的问题。一些开源工具就可以提供这些功能。例如 Jaeger，它专注于分布式追踪。
而 Lightstep 和 Honeycomb 这类产品（图1-9）进一步实现了这些想法。它们代表了超越传统监控方法的新一代工具，使探索运行系统的状态变得更加容易。即便你使用过很多传统工具，但仍然有必要了解此类工具提供的功能。它们是从头开始构建的，目的在于解决微服务架构的运维人员必然会遇到和处理的各种问题。
图1-9：Honeycomb 提供的分布式追踪功能可以让你确定跨多个微服务的操作所花费的时间
理想情况下，你会希望隔离运行每个微服务实例，这可以确保一个微服务的问题不会影响到另一个。例如，CPU 占用率过高会影响其他微服务。虚拟化技术是在现有硬件之上构建独立执行环境的一种方法，但是当考虑微服务的大小时，普通的虚拟化技术可能会非常“重”，而容器则提供了一种更轻量的方法来为服务实例提供可以隔离执行的环境，从而缩短新容器实例的启动时间，这对许多架构来说也更具成本效益。
在开始使用容器后，你会意识到还需要一些东西来帮助你在众多底层设备上管理这些容器。像 Kubernetes 这样的容器编排平台正是做这种工作的，它可以按照服务需要的方式分发容器实例，比如，按照服务所需的健壮性和吞吐量来分发。同时，它也让你能够更加有效地利用底层设备。在第8章中，我们将继续探讨运行时隔离、容器和 Kubernetes 等内容。
不过，不要急于采用 Kubernetes，即便是容器也别着急采用。与传统的部署技术相比，它们绝对具有显著的优势，但如果只有几个微服务，则很难证明采用它们是有必要的。在管理部署的开销开始变成令人头疼的问题后，再开始考虑服务的容器化和使用 Kubernetes 比较合适。但是，如果你已经开始使用它们，尽量让其他人为你维护 Kubernetes 集群，比如使用公有云供应商的托管服务。自己运维 Kubernetes 集群可是个大工程！
尽管使用微服务让我们远离了单体架构下的共享数据库，但我们仍需要找到在微服务之间共享数据的方法，特别是当组织想从批量报告转向实时反馈时，因为这样做可以让组织更快地做出反应。因此，那些让流数据的传输和处理（通常是在具有大量数据的场景中）变得简单的产品在采用微服务架构的团队中备受欢迎。
对许多人来说，选择 Apache Kafka 作为微服务环境中流数据传输的工具是有充分理由的，其消息的持久性和压缩，以及处理大量消息的扩展能力等都非常有用。并且 Kafka 已开始以 KSQLDB 的形式实现流数据的处理。当然，你也可以将其与 Apache Flink 等其他专门的流数据处理解决方案一起使用。Debezium 是一个开源工具，旨在帮助通过 Kafka 从现有数据源按流数据方式传输数据，确保传统数据源可以成为基于流技术架构中的一部分。在第4章中，我们将了解流技术如何在微服务的集成中发挥作用。
公有云供应商，或者具体地说，三大公有云供应商——Google Cloud、微软 Azure 和 AWS——提供了大量的托管服务和部署选项来管理应用。随着微服务架构规模的不断扩大，越来越多的工作将会进入运维范畴。公有云供应商提供大量托管服务，包括托管数据库实例或 Kubernetes 集群，或消息代理、分布式文件系统等。通过使用这些托管服务，你可以将大量工作分配给能够更好地处理这些任务的第三方。
公有云产品中特别令人感兴趣的是与 无服务器 （serverless）相关的产品。这些产品隐藏了底层服务器，允许你在更高的抽象级别上工作。无服务器技术包括消息代理、存储解决方案和数据库。云函数平台备受关注，因为它围绕代码部署提供了很好的抽象。你不必担心需要多少台服务器来运行服务，只需部署代码并让底层平台按需处理对应的实例即可。我们将在第8章更详细地介绍无服务器技术。