0:00 微服务与网关（Microservices & API Gateways）

大家好，我叫Macro，今天我们谈论有关微服务和网关的话题。我是Mashape的CTO,也同时是开源网关Kong的开发者之一。Kong是一个API网关，今天我们就来窥探一下它究竟是怎么工作的以及它如何运用到你的微服务架构中去。

0:23 主题（Topics）

为了明白我们为什么需要API网关，我将从单体架构vs微服务架构谈起。这两个有什么不同点呢？然后我会介绍API网关模式以及它是如何适应“面向微服务”的架构的。然后我们会讨论Kong以及NGINX。

0:47 单体架构（Monolithic Architecture）

Ok，过去几年我们目睹的一件事就是从单体应用到面向微服务的架构的过渡。我们都熟悉单体应用程序，以及它们通常的工作原理，这是一个简单的展示。我们把所有的东西都放到一块。而且通常也只有一个数据存储。

通过在多个服务器上重复部署相同的巨大代码块，可以横向扩展单体应用程序。所以每次我们调整应用程序时，我们其实相当于是在改动这些被放在一起的所有的模块，因为他们是一体的。

1:45 单体应用的优缺点（Monolithic Application Pros and Cons）

每一种做法，都有利弊。单体应用程序可以比较容易地构建，而且是以更小的代码库来开始。我们可以在同一个代码库中构建和开发所有内容，这意味着我们不用担心模块化以及如何把不同的组件放在一起来共同工作这些事情。

而且测试起来也简单。通常当我们测试一个单体应用时，我们一开始就只面对一个应用，然后测试我们集成的单元测试。我们只需要面对一个应用就够了。

而且，很多IDE对单体应用已经支持的非常好了。比如Eclipse围绕着单体应用就提供了很多成熟的测试工具，包括idea也是。

但，你也许也发现了一个代码库(codebase)的问题，随着代码量的急剧膨胀，我们把所有的都放在一个代码库里显然不是一种理想的选择。随着时间的推移，越来越多的功能需要构建进去，代码越来越多，在一个地方跟踪代码将变得更加的困难。

由于这些原因，团队在一个大的代码库上迭代将会变慢。再来说个事情，比如我现在要更换数据库存储方案，或者想要使用一种新的技术。在单体应用中，这样的改动通常是非常痛苦的。

由于上面所有的原因，你开始扩张你的组织。然后发生的事情就是团队内部沟通成本变得更昂贵，因为理解代码库里的代码究竟是干什么的变得更加困难。

3:55 微服务架构（Microservice-Oriented Architecture）

在过去的几年里（一两年吧），我们亲眼目睹了我们的应用架构向微服务转变的这个过程。容器在这个转变中也出了很大的力气，因为它围绕微服务创建了一些伟大的工具，这一部分我们稍后会具体谈到。

在一个微服务架构中，你把应用拆分成不同的模块（component）。于是取而代之的是多个不同的service被彼此独立的部署，彼此独立的伸缩。在上面的这个例子中，客户的订单和发票，这些模块将会被分别部署在他们自己的server上。

这些service之间的通信机制可以是多种格式的，通常是HTTP 或者 RPC（以及事件发布订阅的方式）。有时候你也可为每个模块分配不同的数据存储schema。这样的话，我们就把每个模块的能力都隔离开了，而且你还让它独立于其他模块而工作。

这样也意味着很多时候你可能需要通过事件源机制来搞定一些事件触发。在这个例子中，客户端创建一个新的订单。你就可以不用让客户端创建订单并且生成发票，取而代之的是，你可以创建一个新的订单，然后Orders这个模块push一个生成发票事件，然后其他的模块可以监听这个事件，然后来异步生成发票。

这样的话，你算是构建了一个异步的应用程序，它没有依赖于客户端并且它可以自主的为你生成发票。这也就是意味着，如果Invoices模块down了，可以在稍后重试生成发票。

5:47 微服务架构的优缺点（Microservice-Oriented Application Pros and Cons）