【翻译】微服务与Node.js 1：微服务的前世今生

本系列文章主要由risingstack系列博客的翻译构成，从 Node.js入手了解接触当下十分流行的微服务架构。

微服务之前：单体式架构

单体式架构(monolithic way) 是软件开发中很常用的模式，尤其像 rails 等框架可以很方便的帮助我们实现一个初具规模的应用。这一个应用提供我们所需的所有功能：处理 HTTP 请求、执行主要逻辑、数据库操作、与浏览器/客户端通信、鉴权处理等等。但是任何一处地方的改动若想生效都需要重新构建、部署整个应用，这对大规模、含有老旧代码的应用带来了严峻的挑战，某个模块中的 bug 就可能拖垮整个网站。但这还不是唯一的问题，在大规模应用中，即使我们知道问题出在某个地方，我们还是必须要运行所有的应用实例来启动服务，对开发人员来说其开发成本也大幅上升。除此之外，我们在开发代码时一直在讲究组件化、模块化，却在部署应用时让仍然将其整体打包放到一个统一的环境中去，当一些模块是 CPU 敏感而一些模块是内存敏感时就不得不对硬件作出妥协。

在下图所示的应用中，单体式架构集成了所有的功能。那么当用户大量上传图片时，用于处理图片的接口的压力与风险需要整个应用来共同承担，因此对于主应用的稳定性提出了很大的挑战。此时，通常有两个选择：一是通过运行多个单体应用的实例来扩大规模；二是将这些逻辑放到微服务中。

单体式服务示例

转化为微服务架构

微服务是将原来一个巨大的单体应用分解为多个微型的、可以互相连接的服务架构。上文提到的单体应用可以转化为如下的微服务形式：

微服务示例

微服务的优点

• 渐进式设计

  微服务最大的优点就是永远不需要我们从头重写整个应用程序，只要以微服务的形式增加新的功能，并插入到现有的应用中即可。

• 易维护

  每个微服务的功能代码独立存在，维护成本低

• 扩展性高

  回到上文提到的问题：如果你的用户们突然大量上传图片怎么办？ 在微服务中，你可以只对处理图片的 API 进行扩容，这比单体式架构中要处理整个应用要好的多，对么？

• 易部署

  每个微服务只有少量的依赖，所以更容易部署，很适合敏捷开发。

• 系统弹性大

  因为整个应用是由多个微服务组成的，所以即使某些功能失效了也不会拖垮整个服务的运行。

微服务带来新的挑战

微服务模式并不是系统设计的银弹，它帮助我们解决了很多麻烦，但也带来了很多新的挑战。

• 微服务之间的通信

  很多微服务之间会互相依赖，那么彼此的通信就是首先要面临的问题。我们一起来看看最常见的选择：

  • 使用 HTTP APIs

    微服务可以暴露 HTTP 接口以供其他服务使用。为什么是HTTP?
    HTTP是事实上的、标准的信息交换方式,每个语言都有某种类似的HTTP客户端。现在也有很多的工具集来帮助我们实现，并不用重新造轮子。

  • 使用消息队列

    微服务之间另一种通信方式是使用消息队列如 RabbitMQ或 ZeroMQ。这种通信方式在长时间运行任务或大量处理中非常有用。一个很好的例子是 EmailAPI--当一封邮件要被发送时就将其放入到一个队列中，然后 EmailAPI会依次处理并发送邮件。

• 服务发现

当微服务之间想要通信的时候，还必须能够首先找到这些服务。为此，我们需要一个具有一致性、高可用的分布式系统。以 Image API为例，主应用程序必须知道它在哪儿能够找到它所需要的服务，即主应用程序需要能够获取到这些服务的地址。

有用的工具/库

在这儿列出了一些常用来构建微服务应用的项目。通过接下来的文章，你会更加了解如何使用它们。

• HTTP APIs

  • hapi
  • superagent

• 消息队列

  • RabbitMQ
  • amqp

• 服务发现

  • etcd
  • conf.d

最后

这是接触微服务系列文章的第一篇，接下来我们会探索如何在 Node 应用中使用服务发现。

点此阅读原文