Everything You Need to Know to Get Started with Microservices What are Microservices? Monolithic vs. Microservices Architecture Why choose Microservices? Challenges Docker and Microservices Microservices and Kubernetes Building Microservices architecture

2025-05-25

开始使用微服务需要了解的一切

什么是微服务?

单片架构与微服务架构

为什么选择微服务?

挑战

Docker 和微服务

微服务和 Kubernetes

构建微服务架构

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

微服务是单体架构的替代方案,它为开发人员提供了构建复杂软件应用程序所需的灵活性、可扩展性和简易性。世界各地的公司都已认识到微服务带来的优势。亚马逊、Netflix、eBay、Spotify、Uber、Groupon 和 SoundCloud 等公司都已在实践中。

在这里,我们总结了入门微服务所需了解的所有内容。以下是我们将要讨论的主题:

  • 什么是微服务?
  • 单片架构与微服务架构
  • 为什么选择微服务?
  • 微服务的挑战
  • 微服务和 Docker
  • 微服务和 Kubernetes
  • 构建微服务架构
  • 何时使用微服务?

什么是微服务?

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

微服务

微服务让开发团队可以自由选择他们最喜欢的技术栈。他们无需担心这些技术栈会对正在开发的应用程序造成影响。与使用单体架构相比,这让他们能够更快地完成工作,并且更有信心。

然而,这并不意味着我们应该完全消除和忘记单体架构。许多公司在选择应该使用的架构类型(单体架构还是微服务架构)时仍然很纠结。

那么,让我们看看有什么区别。

单片架构与微服务架构

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

所有代码都集中在一个代码库中,所有更新都在这里进行。这使得扩展变得棘手,因为应用程序变得过于复杂,难以处理。当代码库变得更大时,添加更多功能会成为一个更大的问题。这限制了灵活性,并且没有留下任何空间来容纳新的想法。

单片架构意味着各个进程紧密耦合。只要其中一个进程出现问题,整个架构就会崩溃。这非常危险,因为一个小错误就可能导致整个应用程序崩溃。

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

在以下情况下,单片架构更好:

  • 你正在开发的应用程序很简单,并且所有内容都使用相同的语言和框架,
  • 您希望通过简单地启动应用程序来快速轻松地进行测试,
  • 并且没有太多新功能可以触发整个应用程序的发布。

为什么选择微服务?

微服务更适合您的应用程序的原因如下:

可扩展性

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

生产率

对于大型团队来说,微服务无疑是最佳选择。由于大型项目耗费大量时间和精力,微服务方法允许团队将项目拆分成多个独立的服务。

微服务的可扩展性

这些服务独立运行。这意味着团队成员无需过多协调即可在同一个项目上工作。开发特定微服务的团队可以自行决策,无需等待其他团队的决策。首先,他们可以自由选择编写微服务的语言。他们无需与其他团队使用的技术栈进行协调。

敏捷

敏捷是当今大多数开发团队追求的目标。微服务架构允许大型团队拆分成几个负责不同服务的小型团队。这不仅赋予了他们自主权,还可能通过更短的开发周期来提高效率。

可重用性

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

此外,所有这些部件都可以替换。因此,如果应用程序的某个功能过时了,可以轻松地重写并重新添加。这不会影响整个应用程序的功能。您可以随时根据团队目标和绩效进行更改。

挑战

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

沟通的复杂性

由于应用程序由多个独立运行的服务组成,因此应谨慎设置它们之间的通信。开发人员必须处理模块之间的请求。他们可能还需要添加一些额外的代码来保持流程的顺畅。如果微服务数量庞大,它们之间的通信可能会带来许多复杂问题。

需要更多努力

与所有组件都集中于同一单元的单体架构不同,微服务架构拥有更多数据库,需要更完善的事务管理。此外,每个独立单元都必须单独部署和监控。这意味着团队需要投入大量时间和精力来监控每个独立服务,并使其做好部署准备。

测试多个单元

在单体应用方法中,您只需启动服务器上的单个单元并确保其已连接到数据库。现在您有了更多服务和数据库,您必须分别确认每个服务和数据库,然后才能测试整个应用。在某些情况下,其中一个服务可能会阻塞测试阶段,并停止其余服务的部署。

这意味着微服务需要更多的测试时间。你需要测试大量的接口,而且每个测试过程都必须与其他测试过程分开进行。

除了所有这些挑战之外,非常重要的是要指出,正确的自动化、工具和各自领域的顶尖开发人员可以解决所有挑战。

Docker 和微服务

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

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

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

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

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

Docker 经常与 Kubernetes 混淆。然而,这两者并非竞争对手。事实上,它们的结合可以带来更好的结果。让我们来详细分析一下。

微服务和 Kubernetes

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

为了让开发者的工作更轻松,开发者们正在大规模采用 Kubernetes 。他们通过拥有数千名贡献者和众多认证合作伙伴的Kubernetes 社区进行交流。

Kubernetes通过将正在运行的容器组合并在一起,创建易于管理的集群。您可以在各种云平台(包括公有云、私有云和混合云)中管理这些集群。正因如此,Kubernetes 才被用于托管那些需要快速扩展的云原生应用程序。

因此,Kubernetes 并非 Docker 的替代品。Docker 也无法取代 Kubernetes。它们都可以独立运行。然而,如果搭配使用,它们可以互利共赢。

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

使用 Kubernetes 可以做很多事情:

  • 将应用程序拆分成在不同云环境中运行的小容器
  • 集成和编排容器
  • 管理代码库并有效测试单独的输入和输出
  • 立即扩展应用程序并加快上市时间
  • 从一个托管供应商迁移到另一个托管供应商,而无需对流程进行重大更改
  • 使用配置文件可以确保应用程序完全按照你的规范运行。你可以声明式地管理它们
  • 自动重启、复制和扩展应用程序,使其能够独立修复

构建微服务架构

您可以使用多种不同的框架构建微服务。以下是一些最流行的框架:

  • Spring Boot 与 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、亚马逊、Uber 和 Spotify 等科技巨头都已决定利用微服务的优势来构建其大型复杂应用程序

然而,迁移到微服务应该取决于项目和团队结构。这对整个公司来说意义重大,所以你应该认真讨论一下。

文章来源:https://dev.to/microtica/everything-you-need-to-know-to-get-started-with-microservices-5243
PREV
领域驱动设计的概念解释复杂性挑战领域驱动设计中的重要术语领域驱动设计的示例领域驱动设计的优势领域驱动设计的缺点结论
NEXT
7 个 DevOps 误区 – 破除误区 1:DevOps 就是 CI/CD 误区 2:DevOps 意味着 NoOps 误区 3:自动化消除所有瓶颈 误区 4:一刀切的持续交付管道 误区 5:DevOps 就是工具 误区 6:软件发布与 Amazon/Facebook/Google 相同 误区 7:始终发布 总结