用微服务之前，你应该知道的微服务知识

目前，微服务正在改变我们构建应用程序的方式。当讨论软件体系架构时，微服务无疑是最热门的趋势之一。现在，有越来越多的开发人员开始考虑使用或已经采用了微服务。

微服务是传统软件构造方法的替代选项，它让开发人员在构建复杂的软件应用时，可以具有更高的灵活性、可伸缩性以及便利性。世界上的诸多知名公司，比如 Amazon、Netflix、eBay、Spotify、Uber 和 Groupon 等都已经意识到使用微服务带来的优势。

本文总结了关于微服务的一些知识，可以方便你更快上手使用微服务。

微服务是什么？

使用微服务意味着以松耦合的模式来构建应用程序。在微服务模式下，我们会将程序分割成几个小的应用服务，每个小的服务代表一个独立的业务目标。

将复杂的应用拆解为多个小的微服务后，每个服务可以使用合适的编程语言（比如 Node.js、Java、PHP 等）单独进行开发和维护。

微服务让开发团队可以自由选择他们最喜欢的技术栈，不用再担心自己或别人开发的应用因为技术栈的不同而对整个应用造成影响。与单体架构时代相比，这使得开发人员可以更高效地操作和运维，并且对应用的正常运行更有信心。

但是，这并不意味着我们可以完全抛弃单体架构。在单体架构与微服务架构的选择问题上，很多公司十分谨慎。确实也应该这样，做好准确地评估是十分重要的举措。

所以，我们接下来一起看看微服务与单体架构之间的差异。

单体架构与微服务架构的对比

单体架构意味着整个系统需要创建一个独立单元作为所有功能模块的基础。该独立单元包括数据库操作、业务逻辑、后台处理等。所有这些组件可以一次部署并在同一服务器上运行。

系统的所有功能都编写在一个单独的代码库中，后续的所有更新也均在该代码库中进行。随着业务功能的扩展，应用程序会变得太过复杂而无法处理，这使得扩展变得十分棘手。当代码库较大时，为系统拓展新功能将会成为非常大的挑战，这会严重限制系统开发和运维的灵活性和创造力。

单体架构意味着代码过耦合。如果其中某个模块存在问题，那么整个系统将崩溃，导致用户无法使用。整个系统仅仅因为一个小小的错误导致整体无法使用，这是非常危险的。

另一方面，与单体架构不同，微服务体系结构由多个微小的服务组成，服务之间通过相应的 API 进行通信。由于每个服务代表了独立的功能，因此可以针对某个服务进行独立更新、部署和扩展，而不影响其他的微服务模块。

单体架构主要应用在下面几个场景：

• 正在开发的应用程序比较简单，并且编写的代码模块使用了相同的语言和框架。

• 如果你想要通过简单地启动应用程序来快速便捷地进行测试，并且

• 整个应用程序后期没有太多新的功能特性引发整个应用程序的变更。

为什么选择使用微服务？

选择使用微服务的原因主要有以下几个方面：

可扩展性

在微服务架构中，每个服务都可以相互独立地进行扩展。这意味着每个功能都可以独立运行，从而各个团队可以选择最合适的技术栈。并且，项目团队可以估算每个功能模块的成本，在需要时进行相应的修改和调整。

高生产力

微服务绝对是大型项目团队的必经之路。当他们处理费时费力的大型项目时，微服务模式允许团队将项目分为几个相互独立的服务。

这些服务独立运行。 这意味着团队之间可以在无需协调的情况下从事同一项目。从事特定微服务的团队可以自行制定决策，而无需等待其他团队的响应。如果要开始某个新功能模块的开发，他们完全可以自由选择要编写微服务的语言，而不再需要与其他团队正在使用的技术栈进行协调。

敏捷性

敏捷开发是当今大多数开发团队所追求的目标。微服务架构允许将整个团队分成几个负责独立服务的小团队。这不仅赋予了他们自主决策的权利，而且在多数情况下，可以通过缩短开发周期来提高生产效率。

可重用性

使用微服务意味着大型项目需要集成的代码量会减少。项目中不同功能的代码可以独立运行，这意味着我们可以将这些功能代码作为基础代码或者其他功能代码的补充。这样一来，开发者可以节省大量时间，因为他们不必再重新造轮子，只需要拿来即用，省时省力。

另外，所有这些功能模块都是可以替换的。因此，如果应用程序的某个功能模块已经过时，那么可以轻松地对其进行重构或变更替换，而不会破坏整个项目的功能点。更重要的是，我们可以随时根据项目的目标和性能需要进行更改。

微服务面临的挑战

在决定将项目迁移到微服务架构之前，你应该了解一下未来可能面临的一些挑战：

服务间通信复杂

对于微服务架构，应用程序由几个独立运行的服务组成，不同服务间的通信需要谨慎地配置。服务模块之间会有相应的请求，这些都需要开发人员进行处理。对于服务间的通信，很多时候需要添加一些额外的代码以保证服务间通信的正常进行。如果微服务项目较大，服务间的通信可能会导致一些复杂情况的产生。

更多的维护成本

与所有组件运行在同一单元中的单体架构不同，微服务具有更多的数据库，需要更完善的事务管理。另外，每个独立的单元都必须分别部署和监控。这意味着项目团队将不得不花费更多的时间和精力来做运维工作。

测试环节更加复杂

采用单体架构时，我们只需要在某个服务器上启动应用程序，并确保程序可以正常连接数据库即可。而对于微服务架构，我们拥有了更多的服务和数据库，我们必须确保所有的服务以及数据库正常，才能进行下一步的测试工作。在某些情况下，某一个服务或者数据库的异常都会导致测试失败，同时影响到其他服务的正常部署和测试。

这意味着在测试上，微服务需要花费更多时间。因为测试接口会有很多，并且每个功能测试需要与其他过程分开进行。

虽然上面提到了微服务的一些缺点，但非常重要的一点是，这些问题都有一些相应的解决方案。

微服务与 Docker

微服务通常部署在容器中，这些容器提供微服务正常运行必须的操作系统环境。

Docker 是最受欢迎的容器解决方案之一。Docker 是虚拟机的轻量级系统，可帮助开发人员更有效地管理和部署微服务。

使用 Docker，每个微服务都放置和运行在 Docker 镜像和 Docker 容器中，并且完全独立于宿主系统环境。

Docker 通过在其 Docker 宿主机上共享操作系统内核，来实现自己独立的虚拟操作系统环境的需求。

Docker 允许将微服务拆分为更小的代码段，并通过 Dockerfiles 文件将其创建为 Docker 镜像。这些 Dockerfile 使得将单个服务整合到整个微服务变得更加容易。

微服务系统通常由多个 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 集群。

借助 k8s，可以实现很多功能：

• 将整个应用拆分成在不同云环境中运行的小容器

• 整合及编排容器

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

• 即时扩展应用程序并加速应用上线时间

• 从一家主机供应商迁移到另一家主机供应商，整个过程无需进行重大更改即可实现

• 通过配置文件确保应用程序完全按照规范运行，方便进行管理

• 可以实现自动重启，复制和扩展应用程序，保证程序能够独立修复

构建微服务架构

我们可以在许多不同的框架中构建微服务。下面几个是目前较受欢迎的，推荐给大家：

• Spring Boot with Spring Cloud —基于 Java Spring Cloud 的全栈微服务框架，扩展功能丰富。

• Vert.x —运行于 JVM 之上的一个工具，支持选择不同语言并提供简单的 API 接口。

• Akka —一款 Actor 模型框架，非常适合响应式微服务。

• Quarkus —用于构建模块化微服务应用程序的 Kurbernetes Native Java 框架

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

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

• 如何部署微服务

  
  

• 下面是几种选择。也可以选择其中的几个合并使用进行微服务部署。

• 云上部署，拥有非常好的扩展能力，可以为不同地区的用户提供相应服务

• 容器部署，可以大大缩短产品上线时间，同时可以轻松扩展应用并快速解决问题

• PaaS（Platform-as-a-Service，平台即服务）部署，从云提供商租用开发工具，基础架构和操作系统

• Serverless 部署，应对弹性的高峰流量场景时考虑使用该部署方式

• 构建自己的 IT 基础设施，如果有足够的资源，可以考虑使用该方式部署。

• 如何对微服务进行监控

  
  

• 有很多监控工具供你挑选使用，下面是我的一些推荐：

• Datadog—该工具常用于业务监控、日志追踪分析以及异常告警。在异常检测及性能监控方面非常高效。

• Dynatrace—一款由 AI 驱动的平台，可用于监控动态混合云环境。

• NewRelic—一款用于云环境的集中监控及报告的监控工具。

• Splunk—一款用于日志分析的轻便工具。

• AppDynamix—一款实时监控应用程序和服务器性能的工具。

• — 一个开源的性能监控及网络监控工具。

• 如何自动化CI/CD过程

  
  

• 从完整的云基础架构设置到使用 Kubernetes 在云中交付应用程序和服务，Microtica涵盖整个软件交付自动化过程。Microtica 针对开发人员在云中开发、测试和代码部署的方式制定了相应标准。这让他们的工作在未来的项目中得以复用。

• 如何进行测试

  
  

• 下面是我们使用的一些方法：

• 使用Mocha+Chai进行单元集成测试

• 使用Postman进行 API 自动化测试。我们为每个公共 API 定义了一个测试用例，在每天凌晨时执行它们，并立即获得测试报告。如果出现问题时，我们会立即修复问题并将变更部署到生产环境。

何时使用微服务？

在以下几个情况，微服务架构是最佳解决方案：

• 项目未来会有很多新功能

• 项目经常发布新功能

• 项目有多个子域名及子服务

• 公司业务正在计划扩张

• 项目有一个大型团队可以同时处理不同的微服务

• 拥有敏捷的、跨职能的团队并且正在进行大型的项目协作

• 但是，在开始使用微服务架构前，请务必仔细考虑下面几个问题：

• 项目需要多少存储空间？如果项目依赖本地存储，则将无法灵活地进行服务扩展。应用也将无法处理大量工作负载。

• 应用程序是事件驱动吗？如果是这样，那么程序应该能实现异步处理，因为你的应用程序将跨多台机器进行部署扩展。

• 需要灵活的消息传输机制。微服务项目中有多个事件源，并且都必须对其进行处理。因此，需要一个强大的消息传递模型。

• 由于微服务将使用其 API 进行通信，因此创建 API 通信模式是必不可少的。

• 微服务需要一个更加安全的模型，该模型允许一个微服务仅能访问其所需的资源，而不会使其他微服务受到安全威胁。 微服务在软件体系架构方面进行了重大的革命。在构建微服务应用时，应认真考虑各种情况。 Netflix、Amazon、Uber 和 Spotify 决定将微服务架构应用于构建各自大型复杂的应用程序，以充分利用微服务的特有优势。然而，能够充分做到微服务架构并发挥其优势的，仅仅是科技巨头中的一小部分而已。 但是，是否迁移到微服务应取决于项目以及团队结构。这对整个公司来说都是非常重要的，因此在使用微服务之前，应该认真进行讨论和评估。

原文链接：

https://hackernoon.com/how-to-start-using-microservices-0e1z3