如今,微服务正在彻底颠覆我们构建应用程序的方式。这是软件架构方面最热门的趋势之一。越来越多的开发人员正在采用它。

微服务是单体方法的替代方案,它为开发人员提供构建复杂软件应用程序所需的灵活性、可扩展性和简单性。世界各地的公司都已经认识到他们通过微服务获得的优势。亚马逊、Netflix、eBay、Spotify、Uber、Groupon 和 SoundCloud 只是其中的一部分。

在这里,我们总结了您需要了解的有关微服务的所有信息,以便开始使用。这些是我们将讨论的主题:

• 什么是微服务?

• 单体与微服务架构

• 为什么选择微服务?

• 微服务的挑战

• 微服务和 Docker

• 微服务和 Kubernetes

• 构建微服务架构

• 什么时候使用微服务?

什么是微服务?

使用微服务意味着**从松散耦合的服务创建应用程序。**该应用程序由几个小服务组成,每个服务代表一个单独的业务目标。它们可以单独开发和轻松维护之后,它们在复杂的应用程序中结合在一起。您还可以使用不同的编程语言,如 Node.js、Java、PHP 等。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--aOcbYa1H--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://miro.medium.com /max/1500/0%2AZjJw2O60DqkXJmrD)

微服务让开发团队可以自由选择他们最喜欢的技术堆栈。他们让他们不必担心它会对他们正在开发的应用程序产生影响。与使用单体架构时相比,这使他们能够更快地运行并更有信心。

然而,这并不意味着我们应该完全消除和忘记单体架构。在选择他们应该使用的架构类型时,许多公司仍在苦苦挣扎——单体或微服务。

所以,让我们看看有什么区别。

单体与微服务架构

拥有单体架构意味着创建单个单元作为所有功能组件的基础。这包括数据库操作、业务逻辑、后台处理等。它们都一次部署并运行在同一台服务器上。

一切都在一个代码库中,所有更新都在其中进行。这使得扩展变得棘手,因为应用程序变得太复杂而无法处理。当代码库更大时,添加更多功能会成为更大的问题。这限制了灵活性并且没有为新想法留下空间。

**单体架构意味着进程紧密耦合。**如果只有其中一个出现问题,整个架构就会崩溃。这是非常危险的,因为整个应用程序可能由于一个小错误而失败。

另一方面,微服务架构由单独的服务而不是单个单元组成。这些服务代表通过 API 进行通信的独立代码库。由于每个服务都代表一个单独的功能,您还可以独立更新、部署和扩展它。这不会影响其他微服务。

单体架构在以下情况下更好:

• 你正在开发的应用程序很简单,一切都使用相同的语言和框架,

• 您想通过简单地启动应用程序来快速轻松地进行测试,

• 并且您没有太多新功能会触发整个应用程序的发布。

为什么选择微服务?

微服务更适合您的应用程序有几个原因:

可扩展性

在微服务架构中,每个服务都与其他服务分开扩展。这意味着每个功能都独立运行,允许团队选择最合适的技术堆栈。此外,他们可以估算每个功能的成本,并在需要时进行修改。

生产力

微服务绝对是大型团队的必经之路。当他们从事需要大量时间和精力的大型项目时,微服务方法允许团队将它们分成几个独立的服务。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--tXn2uH_I--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://miro.medium .com/max/1500/0%2Al_a64vigEFjcfvq9)

这些服务独立运行。这意味着**团队成员将能够在同一个项目上工作,而无需大量协调。**从事特定微服务的团队可以自己做出决定,而无需等待其他人。对于初学者来说,他们可以自由选择他们想要编写微服务的语言。他们不必与其他团队正在使用的技术堆栈进行协调。

敏捷

敏捷是当今大多数开发团队所追求的目标。微服务架构**允许一个大团队分成几个负责单独服务的小团队。**这给了他们自主权,以及通过更短的开发周期提高效率的可能性。

可重用性

使用微服务意味着将一小段代码配对到一个大型应用程序中。这些代表应用程序不同功能的部分也可以独立运行。这意味着**您可以将它们用作其他功能的基础或附加功能。**开发人员可以节省大量时间,因为他们不必总是从头开始编写代码。

此外,所有这些部件都可以更换。因此,如果应用程序的某个功能变得过时,它可以很容易地被重新编写和重新添加。这不会破坏整个应用程序的功能。您始终可以根据团队目标和绩效进行更改。

挑战

在决定迁移到微服务架构之前,您还应该了解可能出现的挑战:

通信复杂度

既然应用程序由几个独立运行的不同服务组成,那么应该仔细设置它们之间的通信。开发人员必须处理的模块之间会有请求。他们可能还必须添加一些额外的代码来保持流程的进行。 如果微服务的数量很大,它们之间的通信可能会导致很多并发症。

需要更多的努力

与一切都在同一个单元中的单体架构不同,微服务有更多的数据库,需要更好的事务管理。更重要的是,每个独立的单元都必须单独部署和监控。这意味着团队将不得不花费时间和精力来监控每个单独的服务并为部署做好准备。

测试多个单元

在整体方法中,您只需要启动服务器上的单个单元并确保它已连接到数据库。现在您有了更多的服务和数据库,**在测试整个应用程序之前,您必须分别确认它们。**在某些情况下,其中一个服务可以阻止测试阶段并停止其余的部署服务。

这意味着微服务需要更多的测试时间。您将有很多接口要测试,并且每个测试过程都必须与其他过程分开完成。

除了所有这些挑战之外,重要的是要说明正确类型的自动化、工具和开发人员在各自领域都是摇滚明星,每项挑战都可以得到解决。

Docker 和微服务

微服务通常部署在容器中——充当微服务包装的虚拟操作系统环境。 Docker 是最流行的容器解决方案之一。Docker是一个轻量级的虚拟机系统,可帮助开发人员更有效地管理和部署微服务。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--kqTLgyFW--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://miro.medium.com /max/1500/0%2AiwFnXWACxg9XeC8O)

使用 Docker,每个微服务都放置在一个Docker 映像和一个Docker 容器中。这些部分完全独立于主机环境。

Docker 通过在其 Docker 主机上共享操作系统的内核,取代了拥有自己的虚拟操作系统环境的需要。

Docker 允许将微服务拆分为更小的代码片段,并通过名为 Dockerfiles 的文件创建为 Docker 镜像。这些 Dockerfile 使将微服务链接到大型应用程序变得更加容易。

微服务系统通常由多个 Docker 容器构建,这些容器通过虚拟网络进行协调。由于容器必须进行通信,Docker 构建了 Docker Compose 环境,允许服务器之间进行通信。

Docker 经常与 Kubernetes 混在一起。但是,这两个不是竞争对手。事实上,它们的组合可以带来更好的结果。让我们分解一下。

微服务和 Kubernetes

Kubernetes(k8s 或“kube”)是一个用于自动部署、扩展和管理容器的开源系统。 它最初由 Google 工程师开发。从那时起,谷歌在容器中运行一切,每周生成超过 20 亿个容器部署。

开发人员正在大规模采用 Kubernetes,以使他们的生活更轻松。他们通过一个Kubernetes 社区进行连接,该社区拥有数千名贡献者和许多认证合作伙伴。

通过将正在运行的容器组合并在一起,**Kubernetes 创建了易于管理的集群。**您可以在各种云中管理这些集群,包括公共云、私有云和混合云。这就是为什么 Kubernetes 用于托管设置为非常快速扩展的云原生应用程序。

因此,Kubernetes 不是 Docker 的替代品。 Docker 也不会取代 Kubernetes。它们都可以独立运行。然而,当配对时,他们可以从彼此身上获得很大的好处。

Docker 是一种安装在计算机上并运行容器化应用程序的软件。如果您的计算机上安装了 Docker,则可以使用 Kubernetes 自动执行容器操作,如管理、网络、安全、扩展等。如果您的 Docker 安装在多个 Docker 主机或节点上,则可以执行此操作。由 Kubernetes 管理的一组节点称为 Kubernetes 集群。

你可以用 Kubernetes 做很多事情:

• 将应用拆分为在不同云环境上运行的小容器

• 集成和编排容器

• 管理代码库并有效地测试单独的输入和输出

• 立即扩展应用程序并加快上市时间

• 从一个托管供应商迁移到另一个托管供应商,而无需对您的流程进行重大更改

• 使用配置文件可以确保您的应用程序完全按照您的规范运行。您可以以声明方式管理它们

• 自动重启、复制和扩展应用程序,使其能够独立修复

构建微服务架构

您可以在许多不同的框架中构建微服务。以下是最受欢迎的:

• Spring Boot with Spring Cloud — 一个 Java 框架,具有各种扩展,用于 Spring Cloud 上的全栈微服务。

• Vert.x — 在 JVM 上运行的工具,允许您选择语言并提供简单的 API。

• Akka — 基于参与者的框架,非常适合反应式微服务。

• Quarkus — 用于构建模块化微服务应用程序的 Kubernetes 原生 Java 框架。

• Falcon — 一个专注于质量控制并针对微服务进行优化的 Python 框架。

• Molecular — 支持事件驱动架构的 Node.js 微服务框架。

如何部署微服务?

有几种选择。您也可以组合其中的一些。

• 在云端,以获得扩展和服务来自不同位置的大量用户的能力,

• 使用容器,以缩短上市时间、轻松扩展并快速解决问题。

• 作为 PaaS(平台即服务),从云提供商处租用开发工具、基础设施和操作系统,

• 无服务器,当预计流量很大时,通过

• 构建您自己的 IT 基础架构,如果您有资源来执行此操作。

使用什么云提供商?

以下是一些选项:

• AWS 拥有大量的服务,几乎适用于任何一种技术。

• Azure 是 .NET 堆栈的最佳解决方案,有助于开发、数据存储和托管解决方案。

• Google Cloud Platform 解决了可访问的 AI 和数据分析问题,并为 Kubernetes 提供了强大的支持。

• Digital Ocean 支持一键应用和标准分发,8个数据中心区域统一定价。

如何监控微服务?

您可以使用许多工具。以下是一些建议:

• Datadog — 我们使用它来监控、跟踪日志分析和警报。当涉及到错误检测和性能下降时,它非常有效。

• Dynatrace — 用于监控动态混合云环境的人工智能平台。

• NewRelic — 云环境的集中监控和报告工具。

• Splunk — 用于日志分析的灵活工具。

• AppDynamix — 实时监控应用程序和服务器性能。

• Zabbix — 用于性能监控的开源网络。

如何自动化 CI/CD 流程?

• Microtica 涵盖了从完整的云基础架构设置到使用 Kubernetes 在云中交付应用程序和服务的整个软件交付自动化过程。 Microtica 标准化了我们的开发人员在云中开发、测试和部署代码的方式。它使他们的工作可重用于未来的项目。

用什么测试?

这是我们使用的:

• Mocha+Chai 用于单元集成测试和

• Postman 用于 API 测试自动化。我们为每个公共 API 定义了一个测试用例。我们在每天结束时执行它们并立即获得报告。当出现问题时,我们会立即修复并部署到生产环境。

微服务实践

有很多做法,但让我们看看一些最常见的做法:

• 微前端 — 整体式 Web 界面被分成几个独立的组件,这些组件作为微服务进行通信

• 持续交付 — 如果您只需要更改一项功能而无需更改其他功能

• 领域驱动设计 — 解决紧耦合微服务的挑战

• 每个服务的数据库 - 虽然这需要团队之间更多的沟通,但每个微服务中的数据库带来更多的可持续性

什么时候使用微服务?

在以下情况下,微服务架构是最佳解决方案:

• 你有许多新功能即将推出,

• 您将经常发布功能,

• 你有很多子域,

• 贵公司正计划发展,

• 你有一个庞大的团队,可以同时处理不同的微服务,

• 或者您有敏捷的跨职能团队在大型项目上进行协作。

但是,在开始之前,请不要错过这些注意事项:*

• 您需要多少存储空间? 如果您依赖本地存储,您将无法灵活地扩展和扩展。您将无法处理大型工作负载。

• 您的应用程序是事件驱动的吗? 如果是,您应该能够异步处理,因为您的应用程序将跨越多台机器。

• 需要灵活的消息传递。 将有多个事件源,它们都必须被处理。这就是为什么您需要一个健壮的消息传递模型。

• 创建 API 通信模式 也是强制性的,因为微服务将使用其 API 进行通信。

• 你需要一个更安全的模型,它允许一个微服务只访问它需要的资源,而不会使其他微服务面临安全威胁。

微服务在软件架构方面进行了一场重大革命。在构建应用程序时,您应该认真考虑它们。 Netflix、亚马逊、优步和 Spotify 只是已决定在其大型复杂应用程序中利用微服务优势的部分科技巨头。

但是,迁移到微服务应该取决于项目和团队结构。这对整个公司来说都是一笔大买卖,所以你应该认真讨论。