本系列文章主要由risingstack系列博客的翻译构成，从 Node.js入手了解接触当下十分流行的微服务架构。
微服务之前：单体式架构
单体式架构(monolithic way) 是软件开发中很常用的模式，尤其像 rails 等框架可以很方便的帮助我们实现一个初具规模的应用。这一个应用提供我们所需的所有功能：处理 HTTP 请求、执行主要逻辑、数据库操作、与浏览器/客户端通信、鉴权处理等等。但是任何一处地方的改动若想生效都需要重新构建、部署整个应用，这对大规模、含有老旧代码的应用带来了严峻的挑战，某个模块中的 bug 就可能拖垮整个网站。但这还不是唯一的问题，在大规模应用中，即使我们知道问题出在某个地方，我们还是必须要运行所有的应用实例来启动服务，对开发人员来说其开发成本也大幅上升。除此之外，我们在开发代码时一直在讲究组件化、模块化，却在部署应用时让仍然将其整体打包放到一个统一的环境中去，当一些模块是 CPU 敏感而一些模块是内存敏感时就不得不对硬件作出妥协。
在下图所示的应用中，单体式架构集成了所有的功能。那么当用户大量上传图片时，用于处理图片的接口的压力与风险需要整个应用来共同承担，因此对于主应用的稳定性提出了很大的挑战。此时，通常有两个选择：一是通过运行多个单体应用的实例来扩大规模；二是将这些逻辑放到微服务中。
单体式服务示例
转化为微服务架构
微服务是将原来一个巨大的单体应用分解为多个微型的、可以互相连接的服务架构。上文提到的单体应用可以转化为如下的微服务形式：
微服务示例
微服务的优点
-
渐进式设计
微服务最大的优点就是永远不需要我们从头重写整个应用程序，只要以微服务的形式增加新的功能，并插入到现有的应用中即可。
-
易维护
每个微服务的功能代码独立存在，维护成本低
-
扩展性高
回到上文提到的问题：如果你的用户们突然大量上传图片怎么办？ 在微服务中，你可以只对处理图片的 API 进行扩容，这比单体式架构中要处理整个应用要好的多，对么？
-
易部署
每个微服务只有少量的依赖，所以更容易部署，很适合敏捷开发。
-
系统弹性大
因为整个应用是由多个微服务组成的，所以即使某些功能失效了也不会拖垮整个服务的运行。
微服务带来新的挑战
微服务模式并不是系统设计的银弹，它帮助我们解决了很多麻烦，但也带来了很多新的挑战。
-
微服务之间的通信
很多微服务之间会互相依赖，那么彼此的通信就是首先要面临的问题。我们一起来看看最常见的选择：
-
使用 HTTP APIs
微服务可以暴露 HTTP 接口以供其他服务使用。为什么是HTTP?
HTTP是事实上的、标准的信息交换方式,每个语言都有某种类似的HTTP客户端。现在也有很多的工具集来帮助我们实现，并不用重新造轮子。 -
使用消息队列
微服务之间另一种通信方式是使用消息队列如 RabbitMQ或 ZeroMQ。这种通信方式在长时间运行任务或大量处理中非常有用。一个很好的例子是 EmailAPI--当一封邮件要被发送时就将其放入到一个队列中，然后 EmailAPI会依次处理并发送邮件。
-
-
服务发现
当微服务之间想要通信的时候，还必须能够首先找到这些服务。为此，我们需要一个具有一致性、高可用的分布式系统。以 Image API为例，主应用程序必须知道它在哪儿能够找到它所需要的服务，即主应用程序需要能够获取到这些服务的地址。
有用的工具/库
在这儿列出了一些常用来构建微服务应用的项目。通过接下来的文章，你会更加了解如何使用它们。
最后
这是接触微服务系列文章的第一篇，接下来我们会探索如何在 Node 应用中使用服务发现。
网友评论