9月30号，著名的免费HTTPS证书供应商更新了他们的根证书。

从老的方式：

更新到了：

根据官方的文档：https://letsencrypt.org/docs/certificate-compatibility/

Android>7 iOS>10 ubuntu>16的系统应该不会收到影响

然而，悲剧的是，AWS的Lambda的runtime，似乎使用的是很老的证书系统，从.Net Core写的Lambda访问Let's Encrypt搭建的网站的话，会出现SSL的链接错误。

由于无法更改Lambda的runtime，研究下来似乎只有重新签名才能解决问题。

简单步骤如下：（ubuntu+nginx+certbot）

1.首先更新certbot到>1.6

sudo snap install --classic certbot

certbot --version

2.1和2.2选一个做

2.1 （推荐）更新位于/etc/letsencrypt/renewal/下的网站配置文件

添加preferred_chain = ISRG Root X1来指定chain

然后运行命令强制重新签名

sudo certbot renew --force-renewal

2.2 （不推荐）不更新配置文件，强行更新

sudo certbot renew --force-renewal --preferred-chain 'ISRG Root X1'

更新完毕后，从AWS的Lambda就可以访问你的Let's Encrypt网站，HTTPS，而不出现SSL错误了。

Any application that can be compiled to WebAssembly, will be compiled to WebAssembly eventually.

-- Ending's law

JavaScript诞生起到现在已经成为最流行的编程语言(之一)，背后正是由Web及相关技术发展所推动的。JS应用正在变得越来越复杂（各种前后端技术、扩展到了手机APP、桌面），但这也暴露出了JS的问题：

• 语法灵活导致开发大型项目困难
• 性能在一些场景下不如C/C++等其他语言

一些公司研发了各种框架/语言/工具来尝试补救，比较有名的有微软的TypeScript(强类型，提升代码健壮性)、Google的Dart(新的虚拟机直接运行Dart提升性能)，Firefox的asm.js(JS 的子集，引擎针对性能优化)。

那么，WebAssembly，于2015年诞生，2018年发布了1.0版本，被预言为未来的标准，现在已经被4大浏览器(FF,Chrome,Safri,Edge)支持的技术，到底是什么呢？

WebAssembly介绍

WebAssembly是一种新的编码方式，可以在现代的网络浏览器中运行 － 它是一种低级的类汇编语言，具有紧凑的二进制格式，可以接近原生的性能运行，并为诸如C / C ++等语言提供一个编译目标，以便它们可以在Web上运行。它也被设计为可以与JavaScript共存，允许两者一起工作。（MDN官方定义）

简单来说，WebAssembly不是一门编程语言，而是一份字节码标准。WebAssembly字节码是一种抹平了不同CPU架构的机器码，WebAssembly字节码不能直接在任何一种CPU架构上运行，但由于非常接近机器码，可以非常快的被翻译为对应架构的机器码，因此WebAssembly运行速度和机器码接近。（和Java bytecode一个思路）

目前能编译成 WebAssembly 字节码的高级语言有：

• AssemblyScript : 语法和TypeScript一致
• c\c++ : 大量现成的库，后面的例子里面我们会用C
• Rust
• Kotlin : 文档;

用WebAssembly结合C和JS

其实使用WebAssembly最简单的方式是用TS写AssemblyScript（非常简单，只要注意类型的限制就行）。但是出于利用现有C库的考虑，我在下面例子里会使用WebAssembly把C和JS结合在一起。

安装

参见https://webassembly.org/getting-started/developers-guide/ ，我的工作环境是win10的WSL Ubuntu

> git clone https://github.com/emscripten-core/emsdk.git
> cd emsdk
> ./emsdk install latest
> ./emsdk activate latest
> source ./emsdk_env.sh --build=Release //每次打开新命令行都要跑，或者把内容复制到你的bashrc里

编译

我们先用C语言写一个简单的fibonacci数量计算：

#include <emscripten.h>

EMSCRIPTEN_KEEPALIVE
int fib(int n) {
  int i, t, a = 0, b = 1;
  for (i = 0; i < n; i++) {
    t = a + b;
    a = b;
    b = t;
  }
  return b;
}

这里的emscripten.h是emsdk提供的头文件,EMSCRIPTEN_KEEPALIVE标记的函数,在编译的时候不会被treeshake.

我们创建一个项目，把这段C代码保存到在/c/fib.c

我们尝试把这段代码编译：

> emcc ./c/fib.c -o ./out/fib.js
> ll out

我们看到编译出了两个文件，fib.js（胶水代码）、fib.wasm（字节码）。当然，这两个文件有点大，94k和22k，那是因为我们没有启用编译优化，我们可以加个参数编译：

> emcc -O3 ./c/fib.c -o ./out/fib.js

里面的-O3代表优化级别（数字越大，优化级别越高），再ll看下，fib.js是12k，fib.wasm是85个字节

NodeJS调用wasm

为了方便演示不同调用方式，我们把刚才的编译命令加个选项，暴露出ccall和cwrap

> emcc -O3 ./c/fib.c -o ./out/fib.js -s EXTRA_EXPORTED_RUNTIME_METHODS='["ccall", "cwrap"]'

从nodejs调用wasm是非常简单的，创建一个js文件直接引用生成的js，有三种调用方式:

const em_module = require('./out/fib');

em_module.onRuntimeInitialized = () => { //确认runtime初始化完毕
    console.log("--      call with _   --");
    console.log(em_module._fib(12)); // 如果不care类型安全,直接加_调用
    console.log("--      ccall         --");
    console.log(em_module.ccall("fib", 'number', ['number'],[12])); // 用ccall定义入参和出参
    console.log("--      cwrap         --");
    let fib = em_module.cwrap("fib", 'number', ['number']); // 用cwrap得到函数
    console.log(fib(12));
};

Web调用wasm

两种方式:1.使用生成的胶水代码:

<script src="/out/fib.js"></script>
<script>
  Module.onRuntimeInitialized = _ => {
    //三种调用方式：加_直接调用、ccall、cwrap
    const fib = Module.cwrap('fib', 'number', ['number']);
    console.log(fib(12));
  };
</script>

2.或者更好，在支持WebAssembly的现代浏览器上，直接load字节码wasm文件：

<script>
 (async () => {
    const response = await fetch('/out/fib.wasm');
    const buffer = await response.arrayBuffer();
    const module = await WebAssembly.compile(buffer);
    const instance = await WebAssembly.instantiate(module);
    const result = instance.exports.fib(12);
    console.log(result);
 })();
</script>

如果你的web server正确配置了MIME type：Content-Type: application/wasm的话，代码可以进一步简化为：

<script>
 (async () => {
    const fetchPromise = fetch('/out/fib.wasm');
    const { instance } = await WebAssembly.instantiateStreaming(fetchPromise);
    const result = instance.exports.fib(12);
    console.log(result);
 })();
</script>

编译现有的C语言库

接下来，我们尝试调用webp（library to encode and decode images in WebP format）这个C的库。先拉下项目:

> git clone https://github.com/webmproject/libwebp

然后写个简单的版本号调用文件web.c(参考webp的API定义):

#include "emscripten.h"
#include "src/webp/encode.h"

EMSCRIPTEN_KEEPALIVE
int version() {
  return WebPGetEncoderVersion();
}

通过-I参数把整个项目所有的代码都指给编译器:

> emcc -O3 -I libwebp webp.c libwebp/src/{dec,dsp,demux,enc,mux,utils}/*.c -s EXTRA_EXPORTED_RUNTIME_METHODS='["ccall", "cwrap"]' -o ./out/webp.js

浏览器里调用生成的wasm:

<script src="/out/webp.js"></script>
<script>
  Module.onRuntimeInitialized = _ => {
    const api = {
      version: Module.cwrap('version', 'number', []),
    };
    console.log(api.version());
  };
</script>

Telling a programmer there's already a library to do Something is like telling a songwriter there's already a song about love.

-- Enix Jin

前两篇：

• 从零开始的Microservices服务搭建(一)
• 从零开始的Microservices服务搭建(二)

微服务，通过把系统解耦成一个个“微小”的服务解决了大型系统的复杂性问题。然而，在享受分布式系统的好处的同时，我们也会面临分布式系统的复杂性带来的问题。比如，如何跨多个微服务管理分布式事务？

第三步的代码在这里

什么是分布式事务？

当微服务架构将大型系统分解为自封装的小服务时，它同时也破坏了事务。

这意味着大型系统中的本地事务现在会被分布到按顺序调用的多个微服务中。

以下是使用本地事务的客户订单示例：

在上面的客户订单示例中，如果用户将Put Order操作发送到系统，系统将创建一个本地数据库事务。 如果任何步骤失败，则事务回滚。ACID（A:原子性，C:一致性，I:隔离性，D:耐久性），由数据库系统来保证。

然而，当我们使用微服务架构时，我们创建了CustomerMicroservice和OrderMicroservice，它们都有独立的数据库。客户订单就会变成这样：

当用户发送Put Order请求时，将分别调用两个微服务并存到他们自己的数据库中。由于事务现在跨多个数据库，因此它现在被视为分布式事务。

有什么问题呢？

在单一系统中，ACID由数据库来保证，在微服务架构中，我们需要考虑以下问题：

我们如何保持事务的原子性？

在数据库系统中，原子性意味着一个事务中所有步骤要么都完成要么都没有完成。 默认情况下，基于微服务的系统没有全局事务协调器。 在上面的示例中，如果CreateOrder方法失败，我们如何回滚CustomerMicroservice应用的更改？

我们是否针对并发请求隔离用户操作？

如果一个Object正在由一个事务写入的，同时（在事务结束之前），如果有人访问改对象，系统应该返回旧数据还是将更新数据？ 在上面的示例中，一旦UpdateCustomerFund成功但仍在等待CreateOrder的响应，当前客户资金信息请求是否会返回变更后的金额？

解决方案

上述问题对于基于微服务的系统很重要。否则，你无法判断事务是否已成功完成。

大致思考下，有以下两种模式可以解决问题：（我选择后者，原因后面会讲）

• 两阶段提交
• SAGA (来自于1987年Hector GM和Kenneth Salem论文)

两段提交

两段提交被广泛用于数据库系统。 在某些情况下，你可以使用两段提交进行微服务。但是，事实上，两段提交在微服务架构中被认为是不切实际的。

那什么是两阶段提交呢？

正如其名称提示，两段提交有两个阶段：准备阶段和提交阶段。

在准备阶段，将要求所有微服务准备一些可以原子方式完成的数据更改。一旦准备好所有微服务，提交阶段将要求所有微服务进行实际更改。

所以，两段提交通常需要有一个全局协调器(Coordinator)来维护事务的生命周期，协调器需要在准备和提交阶段调用微服务。

还是客户下单的例子，如果用两段提交：

在上面的示例中，当用户发送放置订单请求时，协调器将首先创建包含所有上下文信息的全局事务。然后它会告诉CustomerMicroservice准备用创建的交易更新客户资金。接着，CustomerMicroservice将检查客户是否有足够的资金来进行交易。一旦CustomerMicroservice可以执行更改，它将锁定对象的进一步更改并告诉协调器它已准备好。同时，在OrderMicroservice中创建订单时会发生同样的事情。一旦协调器确认所有微服务都准备好应用他们的更改，它就会要求他们通过请求提交事务来应用他们的更改。此时，所有对象都将被解锁。

如果在任何时候单个微服务无法准备，协调器将中止事务并开始回滚过程。比如以下的回滚图：

使用两段提交的好处

两段提交是一种非常强大的一致性协议。首先，准备和提交阶段保证事务是原子的。事务将以所有微服务成功返回或所有微服务没有任何改变而结束。其次，两段提交允许读写分离。 这意味着在协调器提交更改之前，字段上的更改不可见。

两段提交的缺点

虽然两段提交能解决事务问题，但对于微服务是不推荐的。原因？因为它是同步阻塞的。

协议需要在事务完成之前锁定更改对象。在上面的例子里，如果客户下订单，则将为客户锁定“资金”字段。 这会防止客户申请新订单。这是在两段提交里有道理的，因为如果“准备好的”对象在声称它已“准备好”之后发生了更改，那么提交阶段可能无法正常工作。

在数据库系统中，事务通常在50毫秒级别。但是，微服务在远程调用方面存在长时间延迟的可能性，尤其是需要与外部服务（比如支付服务）集成时。锁可能成为系统性能瓶颈。此外，如果一个事务请求锁定另一个事务需要的资源时，非常可能有两个事务相互锁定（死锁）。

SAGA

Saga模式是另一种广泛使用的分布式事务模式。与同步的两段提交不同，Saga模式是异步和响应式的。在Saga模式中，分布式事务由所有相关微服务上的异步本地事务完成。微服务通过事件总线(Event Bus)相互通信。

以下是客户订单示例的Saga模式图：

在上面的示例中，OrderMicroservice收到下订单的请求。它首先启动本地事务以创建订单，然后发出OrderCreated事件。CustomerMicroservice会在收听到此事件时尝试更新客户资金。如果从账户成功扣款，则会发出CustomerFundUpdated事件，表示交易结束。

如果某个微服务无法完成其本地事务，其他微服务将运行补偿事务(compensation transactions)以回滚更改。 以下是补偿交易的Saga模式图：

Saga模式的优点

Saga模式的一大优势是它很好的支持了耗时长的交易。因为每个微服务仅关注其自己的本地原子事务，所以即使某个微服务运行很长时间，也不会阻塞其他微服务。同时，Saga也允许事务等待期间用户的新订单。此外，由于所有本地事务都是并行发生的，因此任何对象都没有锁定。

Saga模式的缺点

Saga模式很难调试，特别是当事务涉及多个微服务时。此外，如果系统变得复杂，事件消息队列可能变得难以维护。Saga模式的另一个缺点是它没有读取隔离。例如，客户可以看到正在创建的订单成功了，但在下一秒，订单将因补偿交易而被删除。

代码(这里)的一些说明

• 在第二步代码的基础上，增加了一个微服务：Order，账户系统就在原先的Auth上扩展（因为懒）
• 引入了RabbitMQ作为事件消息队列

比如我们通过gateway，登录之后下一个订单：

order微服务收到消息之后会执行订单创建并往消息队列OrderCreated里发布一个orderid：

@Post({url: "/"})
async sendMessage(req) {
    let user = await encryption.getAuthentication(req);
    // 1.create order
    // 2.send to queue
    if (user) {
        await mqTools.sendToQueue("OrderCreated", {orderid: req.body.orderid});
        return {success: true, body: req.body, nodePort: global.config.servicePort};
    }
}

账户系统在听到这个消息后去操作账户：

//app.ts
mqTools.subscribe("OrderCreated").subscribe((msg) => {
  return customerService.handleOrderMessage(msg);
});

//customerService.ts
async handleOrderMessage(msg: string) {
    let message = JSON.parse(msg);
    logger.debug(`handle order id:${message.orderid}`);
    let success = false;
    if (success) {
        // success
        await this.updateCustomerFund();
        // current no one interested in this message
        await mqTools.sendToQueue("CustomerFundUpdated", {orderid: message.orderid});
    } else {
        // fail
        await mqTools.sendToQueue("CustomerFundFailed", {orderid: message.orderid});
    }
}

如果处理失败，order微服务会监听到CustomerFundFailed里的消息：

//orderService.ts
async handleCustomerFundMessage(msg: string) {
    let message = JSON.parse(msg);
    logger.debug(`handle order fail id:${message.orderid}`);
    await this.compensateOrder(message.orderid);
}

可以观察到两个微服务的日志：

So much complexity in software comes from trying to make one thing do two things.

And the rest of the complexity comes from making two things do one thing.

-- Enix Jin

上一篇：从零开始的Microservices服务搭建(一)

基于微服务架构为软件开发带来了许多好处，包括小型开发团队、更短的开发周期、语言选择的灵活性、服务可扩展性等。

然而，不幸的是，微服务还引入了分布式系统的许多复杂问题。其中第一个挑战就是如何在微服务架构中实现灵活、安全、有效的身份验证（Authentication）和授权（Authorization）方案。

名词解释：

• 验证（Authentication）: 你是谁（Who you are），一般采用用户名+密码方式
• 授权（Authorization）: 你能做什么（What you can do），比如你能否对某个资源做删除操作

传统应用中的Authentication和Authorization

我们先看下在传统应用中，这个问题一般是怎么解决的：

• 当用户登录时，应用程序的安全模块验证用户的身份
• 在验证用户是合法的之后，为用户创建Session，并且将唯一的Session ID与Session相关联。Session中会存储登录用户信息，例如用户名、角色
• 服务器将Session ID返回给客户端
• 客户端将Session ID记录为cookie，并在后续请求中将其发送到服务端
• 服务可以使用Session ID来验证用户的身份、权限，而无需每次都输入用户名和密码进行身份验证

大致流程如下图：

Microservices中的Authentication和Authorization

在微服务架构下，应用程序被分成多个微服务，每个微服务器只实现一个模块的业务逻辑。 在拆分之后，需要对每个微服务的访问请求进行身份验证和授权。如果您参考传统应用的实现，你将遇到以下问题：

• 验证和授权需要在每个微服务中重复实现。（虽然我们可以使用代码库来重用部分代码，但这反过来会导致所有微服务依赖于特定的代码库及其版本，从而影响微服务语言/框架选择的灵活性）
• 微服务应遵循单一责任原则。 微服务只处理单个业务逻辑。 身份验证和授权的全局逻辑不应放在微服务实现中。
• HTTP是无状态协议。对于服务器，每次用户的HTTP请求是独立的。无状态意味着服务器可以根据需要将客户端请求发送到集群中的任何节点。HTTP的无状态设计对负载平衡有明显的好处。由于没有状态，用户请求可以分发到任何服务器。对于不需要身份验证的服务，例如浏览新闻页面，没有问题。但是，许多服务（例如在线购物和企业管理系统）是需要验证用户身份的。因此，需要以基于HTTP协议的方式保存用户的登录状态，以防止用户需要对每个请求执行验证。传统方式是使用服务器端的Session来保存用户状态。由于服务器是有状态的，无法水平扩展。

解决方案？

基于保留服务器端Session（不推荐）的解决大致有如下几个：

• 1.负载均衡确保同一用户每次都访问同一个集群节点 （负载均衡会做的比较复杂，而且万一处于某种原因需要切换节点，会造成session丢失）
• 2.Session复制，把session完整同步到每个节点上（服务器越多，对内存和带宽的消耗越大）
• 3.独立的Session服务器，所有服务的Session存在一个共享的存储上（比如Redis）

但是，既然我们最初的设计就是基于REST的微服务，我们决定抛弃Session，采用Token的方式：

Token和Session之间的主要区别在于存储的位置不同。Session集中存储在服务器中，而Token由用户自己持有，并且通常以localStorage的形式存储在浏览器中。Token编码用户的身份信息，并且每次将请求发送到服务器时，服务器因此可以确定访问者的身份并确定其是否可以访问所请求的资源。

在上一篇里，我们把Gateway做为外部请求的唯一入口。这意味着所有请求都通过Gateway，有效地隐藏了微服务。我们能不能在Gateway上来做Authentication和Authorization呢？当然是可以的。我们甚至能更进一步，把Token机制的一个缺点一起解决掉。

我们知道为了保证服务器的无状态，我们一般把token放在HTTP的头里面，每次发送时都由服务器解析这个token，从而获取里面的payload、有效期等信息（比如JWT）。Token机制的一个问题是Token一旦发出去了，在有效期内是无法撤消的。但是现在有了Gateway这个统一入口，我们可以把JWT Token在Gateway转换成不透明的外部令牌。每次请求时，Gateway负责把这个外部令牌转换成内部微服务使用的JWT Token。这样在保持微服务无状态的情况下，我们顺便解决了Token无法撤消的问题，如下图：

Step2的source code在这里

Gateway暴露login和logout的方法，注意为了简化代码，我们没有把Token->JWT的内容放到Redis里面，而是直接在内存里的一个Map。我们也假设了所有的微服务使用了同一个JWT key（虽然稍微做扩展就能区分）。

@Post("/login")
async login(req) {
    let authService = global.microservices.get("/api/auth");
    if (authService && authService.nodes.filter(node => node.active === 1).length > 0) {
        ...
        let uuid = uuidv4();
        global.token.set(uuid, resp.body.jwt);
        return {token: uuid};
    } else {
        throw new serviceException("no active auth service!", 400, "auth service fail!");
    }
}

@Delete("/logout")
async logout(req) {
    if (req.get("token")) {
        global.token.delete(req.get("token"));
    }
    return {success: true};
}

Gateway的proxy部分也稍作修改，如果能根据Token获取到JWT，就把它写在header里面发送给微服务。（参加代码）

最后，为了测试权限系统，我们对message微服务稍做修改：

@Get("")
async list() {
    return {success: true, nodePort: global.config.servicePort};
}

@Post({
    url: "",
    callbacks: [async (req, res, next) => {
        logger.debug(req.get("jwt"));
        let user = await encryption.getAuthentication(req);
        if (user.username === "enixjin") {
            next();
        } else {
            res.status(403).jsonp({error: `your are:${user.username}, only enixjin could access this api`});
        }
    }]
})
async sendMessage(req) {
    return {success: true, body: req.body, nodePort: global.config.servicePort};
}

可以看到GET方法对所有登录用户开放，而POST方法只对JWT的payload里解出的username为enixjin的用户开放。

简单的测试下：

登录：

然后我们用这个token去访问message微服务

如果尝试用不同用户的token去发布一个message时候，服务器正确的返回了403：

总结&Next

Step2的代码实现了下面的目标：

• 由Gateway实现了登录
• token->jwt的转换、存储使得系统更安全，并且注销成为可能
• 最大程度的使microservice独立运行，只需要考虑自己的业务逻辑

后面的计划：微服务之间的互相调用问题、熔断、恢复、隔离等

Architecture（架构）一词源于建筑学，指建筑物在大尺度上是如何靠内部支撑物相互结合而稳固构造的方式

Architect（架构师）是为满足软件设计目标而在较大尺度上进行整体构思的角色

-- 架构、架构师的定义

建议读本文前先找几本关于Microservice的书阅读一下，我的Slack bookshare里面有几本。

相比设计思想一脉相承的SOA（Service Oriented Architecture），Microservices 是一种把服务分解到更细粒度，松耦合的架构风格。

使用微服务，你的代码将被分解为独立的服务，而这些服务可以用不同的语言开发、部署在不同的地方、作为单独的进程运行。这样的架构风格提供了更高的模块化，使程序更易于开发、测试、部署，最重要的是，更改和维护。（和敏捷开发契合度很高）

市面上有很多微服务的框架，Java的有Spring Cloud和Dubbo（不推荐，缺少很多组件且曾经多年没人维护，使用老旧的RPC），NodeJS也有Seneca和Moleculer可选。不过对于有理想和追求的程序员来说，有什么比自己亲手搭建一个能使自己更了解这种架构呢？（只知道调用API，调整别人的配置有什么意思!）

搭建前的一些技术decision:

• 微服务的通信全部基于REST(REST服务的搭建不是重点，为了省代码，使用我的小框架@jinyexin/core)
• 自己实现中央式（即微服务之间不相互注册）服务注册、发现，不依赖eureka或者zookeeper
• 对外REST服务全部走Gateway，做到对Web端/APP端，拆分微服务和不拆分零区别

第一步的目标：

• Gateway：实现服务的注册、发现，REST请求的代理
• message：一个简单的信息服务
• auth：用户的注册、登录服务(整个系统的用户验证会在第二步考虑)

搭建第一步的代码在这里

Gateway

我们把所有的服务注册信息放在一个map里面，key或者说name就是服务的介入点URL，value里面包含了所有已经发现的微服务节点。

类型定义如下：

export type Microservice = {
    name: string; //example: /api/message
    nodes: Array<{ host: string, port: number, lastHeartbeat?: Date }>;
}

在gateway上提供的注册、心跳服务如下(GatewayController)：

@Get("")
async list() {
    return Array.from(global.microservices.values());
}

@Post("")
async register(req) {
    ...//解析注册请求并加入到map里面
}

@Put("")
async heartbeat(req) {
    ...//心跳，更新map中每个服务节点的最后心跳时间
}

同时，我们实现了一个非常简单的代理（ProxyController），把所有其他请求都代理到相应的microservice节点上，如果有多个可用节点就随机抽一个。（代码略）

最后，我们在Gateway的启动代码app.ts里加了一小段逻辑来踢出60秒内没有心跳的节点：

setInterval(
    () => {
        global.microservices.forEach((microservice: Microservice) => {
            let now = new Date();
            microservice.nodes = microservice.nodes.filter(node => (now.getTime() - node.lastHeartbeat.getTime()) <= 60 * 1000);
        })
    },
    10 * 1000
);

整个Gateway的有效代码仅仅200左右

微服务 Message & Auth

由于我们的目标是验证这个微服务框架，Message和auth只是两个个不同的服务而已。每个服务的关键在于启动时app.ts的注册和发送心跳到Gateway：

httpTools
    .sendHttp("localhost", 3000, "/api/gateway", "POST", JSON.stringify({
        "name": endpoint,
        "nodes": [
            {"host": "localhost", "port": global.config.servicePort}
        ]
    }))
    .then(() => {
        logger.info(`success connected to gateway`);
        application.init();
        setInterval(() => {
            httpTools.sendHttp("localhost", 3000, "/api/gateway", "PUT", JSON.stringify({
                "name": endpoint,
                "nodes": [
                    {"host": "localhost", port: global.config.servicePort}
                ]
            })).then(logger.silly);
        }, 30 * 1000);
    })
    .catch(() => {
        logger.error("fail to register, exit.");
        process.exit(0);
    });

每个微服的有效代码量在50行左右

启动及节点的扩展

我们使用pm2作为我们的进程管理工具。

在pm2的配置文件中（source），我们启动一个Gateway在3000，message服务分别起两个实例在4000和4001，auth服务在5000

（或者你想玩下容器的话，可以用docker起上述的4个节点。Dockerfile已经包含在项目里，启动命令可参考docker run -p 3000:3000 gateway）

这样，在每个子项目都已经npm i && npm run build之后，我们可以直接在根目录上运行pm2 start来个启动整个微服务群：

或者输入pm2 monit来进行监控：

好了，接下来我们所有的测试工作都是通过在3000端口，这个唯一对外服务的API Gateway来进行的。

我们可以发送一个请求来查看节点的注册状况（{Get} http://localhost:3000/api/gateway ）：

可以看到三个节点都顺利注册完成：

让我们再试试有两个节点的message微服务（{Get} http://localhost:3000/api/message ）：

多刷几次，发现body中的端口号在变，说明访问是随机分发给活着的节点的

最后，我们试下auth的login接口({Post} http://localhost:3000/api/auth/login ):

可以看到post的请求body和返回body都被正确处理了

总结&Next

微服务并没有什么神秘的，我们用区区几百行代码，就从零开始搭起了一个微服务的架子。通过搭建这个简单的例子，是不是对服务发现、注册，Gateway的运行原理有了更多的了解呢？

预告：这只能说是个雏形，下一步，我们会关心实际点的应用例子：Authentication（你是谁）和Authorization（你能干什么）如何在微服务中的解决方案。

从50年代的 Lisp 开始，函数式编程已经存在很长时间了。（在过去的几年里的Clojure、Scala、Erlang 和Elixir)。那么，函数式编程也就是FP(Functional Programming)到底是什么？和命令式编程(Imperative programming)有什么区别？有什么有点和缺点？如果真的像FP鼓吹者说的那样完美，为啥实际应用中不多见？

什么是函数式编程？

要回答这些问题，我们要先来看看函数式编程的定义。像OO(面向对象)的编程思想一样，FP(函数式)编程也只是一个programming paradigm而以。这个想法大致来说，包含两点：

• 一切都是纯函数
• 没有共享状态、可变状态、没有副作用
• 用纯函数构建一切

第一条很容易理解，函数是一等公民，你可以把函数赋予变量，也可以把函数作为参数传给其他函数或作为返回值。

对于第二条来说，我们写程序中经常用到的常量(let a = 0;)就不存在了。有些介绍FP的文章笼统的描述为FP里所有的变量都是final的，这其实是误解。FP里面没有变量的概念，全部是纯函数，取代前面那段代码的应该是：let a = () =>0;。没错，a虽然可以看作一个final的变量，但其实看作一个返回0的纯函数而以。

对于第三条，一个常见的疑问就是：没有变量还能正常写逻辑吗？答案是：完全可以。λ演算和图灵机已经被证明了是具有同样能力，任何命令式语言能做的函数式语言也都能做到。(比如Lisp、ML、Haskell)。

比如反转字符串的方法，完全可以不用临时变量而用递归：

function reverse(str:string) {
  if(str.length === 0) {
    return str;
  }
  else {
    return reverse(str.substr(1, str.length)) + str.substring(0, 1);
  }
}

函数式编程的优点

看到上面那段递归，可能有人就会问了：为什么我要吃饱了撑的把代码写这么奇葩？递归不是吃内存又慢么？还别说，如果能完全函数式，好处可是大大的有！

测试

如果一个方法是纯函数的，意为着这个方法的返回值依赖且只依赖于输入值。我不需要去mock一大堆全局的依赖来测试这个方法了。我只需要提供输入值，然后检查下返回值是不是预期的就行，不要太简单。

调试

在实际的项目中，你有没有被有些无法确定触发条件的bug而烦恼呢？函数式编程可没有这种烦恼，如果一个函数在某个输入值下出错，他就一定会每次都出错！更妙的是，由于一定没有读取、改变全局变量啊什么的，只要输入一样，无论是本机、测试机、还是生产机，都必然能重现出这个错误！想想以前去服务器上打log、翻日志，企图重现某个bug的日子，现在能在本地重现，是不是有点小激动！

并发及部署

假设我们有如下一段程序：

let a = funcA();
let b = funcB();
let c = funcC(a,b);
//或者更functional的写法
let c = funcC(funcA(),funcB());
//或者惰性求值
let c = funcC(funcA,funcB);

如果funcA和funcB都是比较耗时的，我能不能把这两个function改成并行跑呢？在指令式环境下，这需要仔细分析、评估funcA和funcB是否使用/修改了外部资源、有没有互相影响后才行。而如果是纯FP的话，甚至编译器就可以自动完成这两个function的拆分和并发工作，因为两个不同的function，必然是不互相影响的。

基于相同的道理，在FP的场景下，我如果修改了funcA,比如说修正了一个bug。我不需要重启整个应用，只要有办法热替换这个funcA就行了（目标：100%在线时间达成！）。

如何处理纯函数的side effect

上面一部分介绍了函数式编程的好处。那么，在一个真实的项目里，我们需要把我们的信息打印到某个地方，我们需要读取用户的输入，我们需要通过网络发送请求到其他服务。绝大部分情况下一个真实的项目的目的就是对现有资源产生修改：文件修改、数据库修改等。我们怎么可能通过纯函数（没有side effect）来构建一个必然会产生side effect的系统呢？

一个简短的回答是：能，但是他们利用函数式的规则“作弊”了，就像很多数学家一样。

当然，这里的作弊，是指他们利用规则上的漏洞，撑开了足够大的口子（事实上一个大象都能通过的口子），来实现系统。他们主要做了以下两点：

• 依赖注入DI
• 懒加载

依赖注入

让我们从一个简单的打日志函数来说起吧：

//version IP
function log(message: string): void {
  const date = new Date().toISOString();
  console.log(`${date}: ${message}`);
}

很显然，这个函数是不纯的。首先它依赖于系统的时间，其次他依赖于console来进行IO。我们如何把这个改成纯函数呢？答案是依赖注入:把所有的依赖变成参数注入进来。

//version FP
function log(message: string, date: Date, cnsl: Console): void {
  const dt = date.toISOString();
  cnsl.log(`${dt}: ${message}`);
}

乍一看这有点蠢，因为某种意义上说，我们只是把side effect抛给上一层调用方了。然而，仔细想想，这样的改动会带来前一段说过的函数式编成的各种好处。

举个例子：IP版本的log函数是很难测试的，因为你每次调用都会hit到不同的时间值。FP版本的就没有这个问题：

const date = {toISOString: () => ``};
const cnsl = {
  log: (msg) => msg
};
log("hello world", date, cnsl);

在上面的例子中，我们把log转换成了纯函数，不依赖全局变量比如Date、console，只要给定相同的参数祖，一定会得到相同的结果。上面我们轻易的mock了Data和consle。那我们是不能能靠这种转换，创建一个正常的应用呢？理论上是可能的。我们可以用DI，把所有的动态依赖一层一层网上推，直到应用的启动命令为止。

app(new Date(),cnsl,aaa,bbb,ccc,...,blabla);//with 100 other parameters

有点难以接受是吧，但是，如果说启动命令参数过多是一个可以理解的缺点，另外一个缺点就是过深的参数传递。

以React为例子：React中上下层组件的数据传递是通过constructor注入props或事件回调来实现的。现在我们假设有6层的组件嵌套，第1层组件与6层组件需要处理同一份数据会怎么样？第一层不断的向子组件传递数据，然后子组件向外抛事件，这条组件链上的所有组件都必须要缓存监听这个数据。那么，如果中间有一个组件不小心处理了这个数据并且错了会怎么样？这个时候你只能一层层的往外排查所有的组件，因为整个过程是黑盒，你根本不知道到底是哪个组件搞得事，排查这么多层是不是想想都有点小激动呢？（这也是为什么会有Redux、Mobx的原因之一）

顺便一提React，最近出了个Hooks来解决类似的，组件嵌套过深时如何传播数据的问题。额，通过建立一个监听所有组件生命周期的hook注入机制（我们函数式编程是不存在全局变量的，这辈子都不会有，嘿嘿）

懒加载

让我们先来看这段绕口令：一个side effect并不是一个side effect直到这个side effect实际被调用。怎么理解呢，先看如下代码：

function lunch(): void {
  //Detonate a nuclear bomb
}

一经调用，如假包换的发射一枚核弹。当然，如果我们不想引发doomsday的话，我们可以利用下first-class functions，把这个函数包装下：

function readyToLunch(): Function {
  return lunch;
}
let bomb1 = readyToLunch();
//no nuclear bomb lunched!
let bomb2 = readyToLunch();
bomb1 === bomb2; //true

你看，我们还顺便验证了这个readyToLunch是个纯函数，即每次调用的返回值是同一个。事实上，我们可以用这种方式构建一个系统执行的链，把系统中的所有逻辑都通过懒加载来实现。

我写了个简单的Chain Promise的例子，项目源代码在这里。达到的效果是这样的。

let chain = ChainPromise.from(promise)
  .map(x => {
    //remove me to make this function pure
    console.log(x, "+1");
    return x + 1;
  })
  .map(x => {
    //remove me to make this function pure
    console.log(x, "+2");
    return Promise.resolve(x + 2);
  })
  .flatMap(x => {
    //remove me to make this function pure
    console.log(x, "*", x);
    return x * x;
  })
  .map(x => {
    //remove me to make this function pure
    console.log(x, "-5");
    return x - 5;
  });
chain.subscribe(console.log, console.error);

这一串操作，map或者flatmap之后，所产生的chain是个确定的值。因为每个函数都是懒加载，如果第一个promise没有被resolve或者没有人subscribe，是不会被执行的。没执行=没有side effect，problem resolved！

以下为这个chain promise的代码（也就20行不到而已）：

export class ChainPromise {
  static of = (v: any) => new ChainPromise(() => Promise.resolve(v));
  static from = (v: Promise<any>) => new ChainPromise(() => v);

  constructor(public f: (...args) => Promise<any>) {
  }

  map(g): ChainPromise {
    return new ChainPromise(x => Promise.resolve(this.f(x)).then(v => g(v)));
  }

  flatMap(g): ChainPromise {
    return new ChainPromise(x => Promise.resolve(this.f(x))).map(g);
  }

  subscribe(onSuccess?: Function, onFail?: Function): void {
    Promise.resolve(this.f()).then(x => onSuccess(x)).catch(e => onFail(e));
  }
}

这样的懒加载在现实世界里有应用的例子么？假设我们有几千万几亿行数据要处理，FP的纯函数就能帮上大忙了。我们可以用纯函数实现我们自己版本的map和reduce，支持并发计算。当然，在CPU上跑这个是很没效率的，因为最大并发数量被CPU核心所限制（4核、8核、16核）。我们需要把这些纯函数跑在GPU上。（1.我们希望并发越大越好 2.每个计算任务其实不复杂 3.每个计算都是纯函数）

为了在GPU上跑这些计算任务，你就需要切实的描述出这些计算任务，然而又不执行他们，是不是就是上面的chain promise了。理想情况下，我们还需要一个框架来帮我们读取所有数据，分配到GPU上，并收集汇总数据。是的，我说的就是机器学习框架TensorFlow。

比如实现两个数字相加的逻辑，在TensorFlow里面是这么写的：

node1 = tf.constant(3.0, tf.float32)
node2 = tf.constant(4.0, tf.float32)
node3 = tf.add(node1, node2)

总结

函数式编程是个好东西。虽然我们几乎不可能在一个真实的系统中完全以纯函数来实现，但这并不妨碍我们以函数式编程来实现我们系统中的某些组件，并享受它带来的各种好处。

前两篇：

（一）前言&RPC

（二）SOAP

（三）REST

（四）GraphQL（Next？）

Talk is cheap. Show me the code.

先放个GraphQL的代码，在这里。（竟然是一个月前的代码了，写文章还是不能拖拉啊）

如同上一篇文章所说，REST是现在API设计的绝对主流思想，但也不是没有缺点的。比如太多的HTTP请求，抓取了过多的信息等。当然，现在有好多各种各样的框架、协议尝试对REST做一些改进。比如HAL、Swagger、OData JSON API。（以上几个都可以花时间浏览下，还是很有启发的）

还有很多小的工程或者项目的内部工具都是为了更加爽快的使用REST而诞生的。我不想一一列举这些工具，这里只是从设计角度，假设我们自己要设计一个基于REST的改进工具，我们会对这个工具有那些要求：

1.最小化HTTP请求数量

每个HTTP请求都是有代价的，握手、延迟、解析甚至如果在移动平台上过多HTTP请求对手机电池的消耗都是必须考虑的。理想情况下，我们的新API设计，需要允许客户端需要有能力在最小的HTTP请求数中，得到需要的数据。

2.最小化payload

和上个目标一样，受限于带宽、CPU、内存等等因素，理想情况下，我们的新API设计，需要能够发送且只发送客户端需要的最小数据。当然，为了实现这个目标，客户端需要有能力描述要求的数据内容。

3.可读性要强

从SOAP中获取的教训，API的交互要简单。对程序员来说，如果能用curl、wget或者类似的简单工具直接交互才是最好的。

4.类型支持

另外一个我们从RPC和SOAP中学到的教训是，服务器和客户端之间的协议（contracts）非常有用。因为如果用JSON的话，所有字段本质上都是string类型传输的，如果有强类型系统（type systems）来做检测就更好了。顺便一提，这也是为什么我一直支持typescript开发nodejs系统的原因，在正式、多人的项目里，强类型系统对开发的帮助是在是太重要了。

比如说，我们可以定义博客的数据结构：

type posts {
  title:String
  description:String
  create_date:Date
  tags:[String]
  author:User
}

5.查询语言的支持

多年来，设计大型系统时一个非常重要的原则就是“separation of concerns”。然而，不幸的是，大部分系统，最后都变成了拥有一个暴复杂逻辑的中央数据层的怪物。假设子系统A、B、C需要用户数据，但是他们对数据的形状什么的都有各自的特殊要求。理想的设计是提供一个统一的，支持对数据的形状进行裁剪、过滤的接口。这么看来，一种简单的查询语言是最符合我们要求的。

理论上SQL是符合我们的要求的，唯一的问题是SQL太复杂，而且和基本上已经成为事实数据格式标准的JSON不是太友好。我们可以考虑类似mongodb的做法，以选择特定field为例：

select title,description from posts; // SQL

db.posts.find(
  { },
  { title: 1, description: 1, _id: 0 }
)  //mongodb

所以，我们的新查询语言可以是这样的：

{
  posts {
    title
    description
    author {
      name
    }
  }
}

恩，事实上，上面的简单类型系统加上这个简单的查询语言，就是GraphQL了。记住，GraphQL只是一个specification，只是一个规格定义，并不牵涉到任何具体的语言、实现、客户端。在我的这个小例子里面,语言上我用了typescript，框架上用了express，数据库只是内存里的一个数组而已。

引入GraphQL并不意味着需要改写现有的系统接口，GraphQL可以看做一个前端和后端之间的灵活有效的业务逻辑层。后面的数据源可以是一个SQL数据库、一个Microservice、甚至是另外一个API。

对代码的一些说明：

server.ts:

// check auth here
let checkAuth = (req, res, next) => {
  // console.log(req.headers.jwt);
  next();
};

app.use('/graphql', checkAuth, graphqlHTTP({
  schema: schema,
  // rootValue: root,
  graphiql: true //Set to false if you don't want graphiql enabled
}));

实现了一个简单的权限校验函数checkAuth,引入了schema定义，在/graphql开放了网页版测试客户端。

UserType.ts:

export const UserType = new GraphQLObjectType({
  name: "user",
  fields: {
    id: {
        type: new GraphQLNonNull(GraphQLInt),
        description: "id of user"
    },
    username: {
        type: new GraphQLNonNull(GraphQLString),
        description: "username of user"
    },
    password: {
        type: new GraphQLNonNull(GraphQLString),
        args: {
            "hide": {
                type: GraphQLBoolean,
                defaultValue: true
            }
        },
        description: "password of user, default is hide",
        resolve: (_, { hide }) => {
            if (hide) {
                return "******";
            } else {
                return _.password;
            }
        }
    }
  }
});

用户的强类型定义，等同于官方的这种定义方式。一个比较有趣的地方是我在这个定义里面默认隐藏了密码字段的值，只有当你覆盖默认设置password(hide:false)时才会显示密码。

UserQuery.ts:

export let userQuery = () => ({
    users: {
        type: new GraphQLList(UserType),
        resolve: () => {
            return db;
        }
    },
    user: {
        type: UserType,
        args: {
            "id": {
                type: new GraphQLNonNull(GraphQLInt)
            }
        },
        resolve: (_, {
            id
        }) => {
            return db.find(u => u.id === id);
        }
    }
});

定义了我们这个graphql会暴露2个查询接口，现实所有用户的users和按照id查询的单个用户查询user。

GraphQL虽然是一种强大而灵活的工具，优点已经在上面阐述过了。然而，公平的说，GraphQL也有自己的缺点：

1.数据集成和错误处理

因为很多时候，GraphQL在系统里起到了数据网关、Gateway的作用。不同的数据源如何整合、异步的数据处理、各个不同系统之间混乱的架构关系等都是不小的挑战。另外、如果后台的部分数据服务不可用，该如何报错？REST的用HTTP status code来表示状态的方法无法沿用到整合了多个后台数据源的GraphQL上。

2.Cache

高度灵活的动态查询意味着难以缓存，你可能需要使用类似Apollo提供的Cache一样，设计一套复杂的逻辑。

3.CPU消耗

解析、验证、类型检测一个查询语句是一个非常消耗CPU的动作。特别是在NodeJS这种默认单CPU的环境下面

总结：

API设计的选型对整个系统的健壮性、可扩展性是影响非常大的。挑选一个合适当前项目的设计是架构师的主要工作之一。不要把自己限制在某个特定的设计上，合适才是最重要的。如果我要给一个状态机做接口，明显RPC风格的更合适；如果大部分是数据的CRUD，那一定要用REST。如果都有，混合两种风格的API也未尝不可。

前两篇：

（一）前言&RPC

（二）SOAP

（三）REST（now）

接下来，在RPC和SOAP之后，我们迎来了REST。

REST（Representational State Transfer），实际上一般指的是RESTful的架构风格，是由Roy Fielding在2000年的这篇著名论文里提出的。

那REST到底对API设计做了什么改进呢？先来回顾一下前面两篇文章里介绍的RPC和SOAP，RPC类似于系统和系统之间讲黑话，SOAP改进了RPC，使之有了统一“普通话”。但是“普通话”是不是最优解呢？我们来看一个调用远程系统创建用户时可能遇到的接口名：

createUser() //很平常的命名

insertUser() //也可以接受

chuangjianyonghu() //别说你没看到过

chuangjianUser() //土洋结合

cjyh() //中文拼音首字母缩写

api123321() //恩，保密工作做的不错？

根本就有无穷种可能性好伐？那么，我们能不能有一个接口的规范？比如，对于任何系统，暴露出来的创建用户一定是createUser？REST以一种革命性的抽象，巧妙的解决了这个问题。

SOAP虽然工作在HTTP之上，但实际上并没有好好的利用HTTP，所有的内容都在request和response的body里面。那如何好好利用HTTP协议本身呢？

答案就是：面向资源（resource）

加上利用HTTP协议本身。包括协议中的8种方法：OPTIONS,GET,HEAD,POST,PUT,DELETE, TRACE,CONNECT，REST, 以及HTTP response status codes：2xx,4xx,5xx，HTTP Header的定义，HTTP 是无状态的等特性。

其中最最关键的抽象是把系统的交互看成一个对有名字的资源的访问。

比如上面用户相关的REST接口：

{GET}     /users            //获取用户列表，返回User[]
{POST}    /users            //创建用户,返回id
{GET}     /users/1          //获取id为1的用户信息,返回User
{PUT}     /users/1          //更新id为1的用户信息,返回User
{DELETE}  /users/1          //删除id为1的用户信息,无返回或者返回是否命中
{GET}     /users?name=enix  //搜索名字为enix的用户列表,返回User[]
......

你看，他即不是黑话，也不是自由度很高的普通话，而是在现有的、已经被广泛使用的一种通信规范（HTTP）的基础上来设计接口。用一个URI（Uniform Resource Identifiers），上面例子里面的/users来代表user这个资源，所有的接口都利用HTTP的特性在这个URI上做文章。如果你遵守REST的规范来设计接口的话，所有人设计出来的API基本都是一样的。

网上介绍REST的文章太多了，这里只提一点，不要设计出RPC风格的伪REST接口。下面是两个例子。

给用户发送消息的接口,很多系统会设计成这样：

{POST}   /sendSMSMessageToUser
body:{"userid":1,"message":"hello there"}

在思想上，这还是个面向方法的RPC接口，我们需要转换思想，面向资源。

正确的REST style的方法是这样的：

{POST}   /users/1/message
body:{"message":"hello there"}

虽然这两种方式看起来很像，但是我们的关注点从sendXXXX这个方法，转移到了user的message这个resource上面了。（另外，后面的例子里面把sms也去掉了，因为这是server端的问题，client端只需要表达需要给用户发送消息就行了，至于是email还是sms，只是server端的实现细节罢了）

另外一个经典的伪REST接口类型：

{POST} /users/login
body:{"username":"enix","password":123456}

恩，这是一个很普通的用户登录接口，但是很多系统里面，这样的登录接口，不管成功失败，返回的HTTP status code统一都是200！！！

HTTP status 200 body:{success:true,data:{...}}     //登录成功
HTTP status 200 body:{success:false,data:{...}}    //登录失败

上面响应技术上讲叫做envelope（还记得SOAP的xml里面的SOAP-ENV:Envelope吗？），就是把所有结果包在一个信封里面，信封外面写着远程调用的结果，一般是成功或者失败，实际响应内容放到子一级的data里。所以这还是一个RPC style的接口！

而正确的接口应该这么返回：

HTTP status 200 body:{token:"..."}    //登录成功
HTTP status 403 body:{message:"..."}  //登录失败

Remember, HTTP status code is your envelope in REST!!!

REST的优点

Uniform Interface：这个前面已经提到过了，系统之间交互，有一个可预期的接口实在是太重要了。

Stateless：曾几何时，系统扩容绕不开的一个话题就是session同步。HTTP请求本身就是无状态的，怎么保持用户的登录状态呢？大部分系统使用了session机制，也就是浏览器里面记录一个sessionid，对应服务器里面的一块内存，内存里面记录了用户的信息。这个机制在单服务器的时候工作完美，但是当服务器需要扩展性能时，比方说前面加了个负载均衡，后面变成了两台服务器时，就会带来一个问题：如何在保持session同步？要么两个服务器内存同步要么存到第三方（memcache或者redis），比如下面这个典型的配置： 而REST接口是无状态的，依赖header里面token，每次都实时解析（JWT了解一下），虽然略微牺牲了一点性能（其实绝大部分情况只是把header里面的“token” decode&verify一下，不会牵涉到数据库读取，相比去memcache里面同步session，未必性能更差），但是在扩展性能的时候实在太方便了！性能不够？实时顶几台服务器上去。性能过剩？随便下线几台服务器也不在话下。这是热插拔，少了启动时要去cache同步所有session的这个预热过程。

Cache：过去，你可能需要在应用级别（上图的每个instance）里自己实现cache逻辑。如果使用REST的话，cache的相关处理就能提到更高级的地方（load balancing）来做了。为什么呢？因为所有的资源访问都暴露在HTTP层了。比如前面那个例子里的/users，{GET} /users/:id这个URL是可以被cache的，只有当有人去POST或者PUT、DELETE过这个URL时，才需要刷新缓存。更妙的是，应用层根本不需要再去关心缓存了，不需要到处写@Cacheable("users")了，完全可以交给前面的一层去做！

REST的缺点

健谈：和SOAP的罗嗦（报文体积大）不同，REST接口倾向于健谈（发送请求多）。这其实和现在的前后端划分有关系。以前，大家都利用jsp asp php等类似的技术，在服务端组织数据、生成页面，然后返回给浏览器。现在，因为不止有web端，我们可能还有手机app端、微信端、桌面端，给每个程序开发一套接口是很不经济的。统一接口使用REST的代价就是请求变多了。不再是后端算好所有东西给前端了，前端也有了自己的框架（angular react）和自己的逻辑，后端只是提供数据，也就是资源给前端了。以前一个HTTP请求就能搞定的事情，现在可能要发好多个。特别是在HTTP/2还没有完全普及的现在，浏览器同时发出的请求数量是有限制的（HTTP/1.1可以看这里的表格）。

TMI：Too Many Information或者说Overfetching。比如说我有一个博客的首页，我需要load一个post的列表，我会发一个简单的list请求

{GET}     /posts

返回的结果可能是

HTTP status 200
body:[
  {
      "title" : "hello",
      "author" : {...},
      "description" : "world",
      ...   //以及其他20个字段
  },
  ...
]

作为一个blog的首页，我可能只需要title、author、description这三个字段就行了，另外20个字段我完全不关心啊。当然，你可以用sparse fieldsets或者类似的技术来避免这个问题。然而这个问题是REST面向资源的设计的nature所带来的，很难彻底避免（GraphQL对REST的改进之一就是为了解决这个痛点）。

扩展阅读：

REST论文的主要作者在2017年的Reflections on the REST Architectural Style and “Principled Design of the Modern Web Architecture”

一个哥们写了一篇黑REST的文章REST is the new SOAP

然后被另外一个哥们的一篇A Response to REST is the new SOAP驳得体无完肤，还是很有趣的。

下一篇预告：GraphQL

SOAP is what most people would consider a moderate success.

-- Don Box <A Brief History of SOAP>

上一篇：前言&RPC

（二）SOAP（90s）

RPC之后的下一个主流API设计风潮就是SOAP了。

SOAP（Simple Object Access Protocol）由Dave Winer, Don Box, Bob Atkinson, 和 Mohsen Al-Ghosein 在1998年为微软所设计。

这几个设计人员敏锐的观察到了RPC的最大缺陷：没有统一标准。使用RPC就好比发明团伙内部的黑话一样，更精简、更加保密、更加可定制，坏处就是要求双方（sender,receiver）也要懂黑话，而且一旦大家都说一种黑话了，换黑话就困难了。（是不是能联想到某些RPC框架了？）

于是，这个很有雄心的协议使用了XML来进行应用间通信，相当于说：“大家都别说各自的黑话了，都说用我这个普通话交流”。实际上，由于已经有XML-RPC（微软做事比较拖拉，前面的Dave Winer等不急在1998年提交的），只要给XML添加一个行为类型系统就能定义出这种“普通话”了。

时至今日，在这种“普通话”上已经发展出了一套复杂的技术链，你可能已经想到了，就是Web Service。由WSDL（Web Services Description Language）提供接口功能说明、由XML schema定义XML的结构类型、由UDDI（Universal Description Discovery and Integration）来做服务发现。

Web Service火了一段时间。然而，可悲的是，人们发现它创造的问题比解决的多。。。所以，现在，你会发现，现在越来越少的新接口是使用SOAP开发的了。

还是先说下SOAP的优点吧：

SOAP最大的好处：标准化了接口。相比于直接野蛮调用远程方法，SOAP给出了一个平台无关的、可预期的、类型安全的接口描述。WSDL用XML格式描述了哪个服务器提供什么服务，怎样找到它，以及该服务使用怎样的接口规范。从自己和对方沟通确定这个RPC应该用什么黑话来沟通相比，使用SOAP有一个可预期的标准流程：

1. 获得该服务的WSDL描述
2. 根据WSDL构造一条格式化的SOAP请求发送给服务器
3. 接收一条同样SOAP格式的应答
4. 根据先前的WSDL解码数据

这一统一，使得大部分语言和他们的IDE都实现直接从WSDL里面生成文档和访问代码。

另外一个好处是鼓励了从面向方法到面向接口的转换。虽然这可能并不是SOAP设计目的，但接口的定义的存在，或多或少的把原先RPC粗暴的暴露方法变成了暴露接口。面向接口编程的好处是不言而喻的（文章太多，感兴趣可自行搜索）。同时，面向接口使得不同语言，不同技术的互相访问变的更便捷了。你只要暴露出你服务的wsdl就行了，我可以根据定义用我自己的语言来开发，终于不用再调用别人的sdk了。

SOAP的缺点也同样耀眼：

SOAP是一种罗嗦，且难以置信的罗嗦的接口。你几乎无法在没有一大堆工具的帮助下使用SOAP。你需要工具来写测试、你需要工具来监听请求和响应、你需要工具来解析XML、你需要工具从XML中按照定义再解析出需要的数据，等等、等等。如果有一个REST的接口，我打开浏览器，一分钟之内就可以测好，如果是SOAP的话。。。今天仍然有好多老系统在用SOAP，但是当你开发一个新系统时，你会发现如果使用Web Service太过于笨重了。

SOAP的罗嗦也带来了另外一个问题：理论性能不佳。比如说访问一个远程的方法getOpenData，理论上我只需要发送下列信息到endpoint：(伪代码)

getOpenData?name=enix  

而如果你用SOAP的话...

<?xml version = "1.0"?>  
<SOAP-ENV:Envelope  
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"
   SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">
   <SOAP-ENV:Body xmlns:m = "http://www.xyz.org/quotations">
      <m:getOpenData>
         <m:name>enix</m:name>
      </m:getOpenData>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>  

而且，请记住，返回值也一定是这么一坨XML。在以前网速慢、流量贵的时候，这样发来发去简直就是犯罪！！！另外，解析、构建XML都不是一件简单的事情（SAX还是DOM？），解析和构建也非常消耗性能！！！

最后也是最重要的，SOAP本质上只是RPC的一种扩展及优化罢了。设计思路上仍然是以方法为中心的，比如上面例子中的getOpenData，本质上还是服务方的一个非常底层的方法暴露给调用方而已。系统还是存在强耦合性。

PLUS：这里有一段Java vs .Net的视频Java 4-EVER（墙外），里面爸爸声嘶力竭试图挽回学JAVA的孩子时喊出的“They(MS) actually enable us to send XML-message through SOAP! Through SOAP”很有喜感。

下一篇预告：REST

"There is no such thing as a new idea. It is impossible. We simply take a lot of old ideas and put them into a sort of mental kaleidoscope."

-- 马克·吐温 <马克·吐温自传>

我自己的几个工具（@jinyexin/core, @jinyexin/corecli, @jinyexin/wechat）是基于REST设计的，在定义应该由框架自动生成哪些REST接口的时候，总是感觉到有很多痛点（下文谈到REST的时候会讲）。于是GraphQL进入了我的视线。

为了比较各种API设计的优劣，我想先回顾下历史上各个时代的API设计理念，从而理解为什么我们需要“又”一种新的API设计方式。

历史上，按照时间的先后，大致出现过4种主流的设计：

• RPC
• SOAP
• REST
• GraphQL

前言：新技术的成本核算

新技术是总让人着迷的，但在给一个组织、一个团队或者一个框架引入一种新的技术或工具时，有很多东西需要衡量。比如：学习的成本、把旧的功能在将来的某个时间点转换成新技术的成本、某段时间内维护新旧两套技术的成本等。有了这么多成本的考量，新技术必须显著的“更快、更高、更强”才行。（奥利匹克格言）

GraphQL在大部分应用场景中，在我看来，是利大于弊的。

（一）RPC（远古时期，60s-90s）

RPC(Remote Procedure Call), 中文“远程方法调用”。几乎可以算是一种最最古老的API设计模式了。

60年代，计算机刚刚诞生的时候，每台计算机都有几间房间那么大。（参见下图）

少的可怜的带宽和计算能力、计算机数量使得当时的工程师优先考虑远程方法调用，而不是互相暴露的数据接口这种更通用的方法。（API驱动的开发当时还只是理论上的事情）

一直到90年代为止，以CORBA（Common Object Request Broker Architecture），Java的RMI（Remote Method Invocation）为代表，绝大部分计算机都以RPC这种交互模式工作。

RPC有自己的优点。对于开发人员来说，RPC的设计理念是使远程方法调用体验、写法都和本地方法调用一样。RPC屏蔽了网络细节，虽然缓慢得多且不太可靠，但RPC使得跨系统的异步调用保持了代码连续性。

请注意，直到今天为止，在执行某些不可靠或者异步的操作时(数据库操作、外部HTTP服务调用)，我们仍然为了保持代码的连续性而在奋斗（如：有了async/await,你仍然需要promise）

RPC的另外一个优点是对数据结构没有任何限制，RPC的关注点是方法，只要方法需要，任何格式或者结构的数据都能传给远程方法，任何格式或者结构的数据都能被远程方法返回，非常灵活。RPC的灵活也带来了性能方面的优势，相比于固定于XML格式的SOAP，限制在HTTP上的REST、GraphQL。RPC可以任何你认为合理的方式来实现，在追求极致性能的场合下，还是有很大的用武之地的。

然而，RPC的优点也造成了RPC的缺点。

首先，保持代码的连续性需要上下文。RPC从设计上，就混淆了本地代码和远程代码，把本地系统和远程系统紧紧的耦合在一起。还记得高内聚低耦合（High cohesion & Low coupling）的设计标准么？很长一段时间，访问远程系统的主流方式是引入对方的SDK。

另外，相对于更关注于数据的接口设计方式，这种高耦合的还让开发人员很难区分本地和远程代码的边界。我需要知道这么多远程系统的代码级实现细节吗？我需要捕获发生在远程系统错误吗？怎么处理这些错误？如果远程系统没有响应怎么办？相应调用失败后如何重试？

RPC的另外一个重要缺点是API的扩散。理论上来说，一个RPC服务应该暴露一组少量且完备的API，足以且只足以让客户端完成指定任务。然而，大量的调用节点（方法），几乎没有数据结构，使得这项任何非常有挑战性。在实际的项目中，特别是长期大的项目或者开发人员变动时，很难使这些暴露给客户端的方法地稳定且保持在一个合理的数量上。

另外，RPC也缺少统一的标准。RPC的核心模块：通讯、序列化，通讯可以TCP可以HTTP，序列化和反序列化更有无数的坑。微服务名著Building Microservices里面就在一直吐槽RPC的坑和缺点。

下集预告：SOAP

把原先项目里自己顺手实现的简单DI抽了出来

https://github.com/enixjin/simpleDependencyInjection

https://github.com/enixjin/blockchain
说明有空再补。。。

如果你使用的是Typescript>1.7，或者NodeJS>7.6， 那么你就已经可以使用新的async/await语法来部分代替原来的promise写法了。

先来看一个最简单的例子

Promise写法：

doSomethingWithPromise(): Promise<string> {  
        return Promise.resolve("success");
    }

doSomethingWithPromise().then(result=>console.log(`result is ${result}`));// result is success  

aysnc/await写法：

async doSomething(){  
        return Promise.resolve("success");
    }
let result = await doSomething();  
console.log(`result is ${result}`);// result is success  

网上基本所有的关于async/await的例子都差不多这个意思。

怎么样，把代码从异步回调地狱里面解救出来了吧。类似同步代码的感觉是不是让你蠢蠢欲动，把以前所有的代码都翻新成async/await？(事实上只能翻新Server端的，浏览器现在还不全部支持)

然而你会很快面对一个事实：即使你有了async/await，以同步风格编写代码有时是不可能的，至少不是简单的。

给我一个例子：

假设我们要做一个批萨，大概有以下步骤：

• 做饼（dough）
• 做酱（sauce）
• 尝一下酱，根据口味决定放什么样的奶酪（cheese）

让我们先直接用async/await随便写一个，代码如下：

async function makePizza(sauceType = 'red') {

    let dough  = await makeDough();
    let sauce  = await makeSauce(sauceType);
    let cheese = await grateCheese(sauce.determineCheese());

    dough.add(sauce);
    dough.add(cheese);

    return dough;
}

这个代码足够简单，逻辑简单明了，先做饼，再做酱，然后决定奶酪。只有一个问题：我们把所有的事情线性一个一个做了，我们应该允许JavaScript引擎并行的跑这些任务！

所以，现在我们的代码是这样跑的：

|-------- dough --------> |-------- sauce --------> |-- cheese -->

然后我们期望我们的代码能这样跑：

|-------- dough -------->
|-------- sauce --------> |-- cheese -->

所以，我们可以改进下我们的代码：

async function makePizza(sauceType = 'red') {

    let [ dough, sauce ] = await Promise.all([makeDough(), makeSauce(sauceType)]);
    let cheese = await grateCheese(sauce.determineCheese());

    dough.add(sauce);
    dough.add(cheese);

    return dough;
}

恩，比上个版本好一点了，虽然我们用到了Promise.all来并行出发2个任务。但是仔细想想，如果做饼和做酱的时间不一样长呢？比如做酱的时间要远远短于做饼的时间？结果就会变成这样：

|-------- dough -------->
|--- sauce --->           |-- cheese -->

实际上决定奶酪这件事情，在酱做好之后就能直接做了，不需要等待饼做完。

让我们尝试完全用Promise来解决这个问题：

function makePizza(sauceType = 'red') {

  let doughPromise  = makeDough();
  let saucePromise  = makeSauce(sauceType);
  let cheesePromise = saucePromise.then(sauce => {
    return grateCheese(sauce.determineCheese());
  });

  return Promise.all([ doughPromise, saucePromise, cheesePromise ])
    .then(([ dough, sauce, cheese ]) => {
      dough.add(sauce);
      dough.add(cheese);
      return dough;
  });
}

执行的结果应该就是我们期望的：

|--------- dough --------->
|---- sauce ----> |-- cheese -->

我们可以尝试把代码改成async/await风格的：

async function makePizza(sauceType = 'red') {

    let doughPromise = makeDough();
    let saucePromise = makeSauce(sauceType);

    let sauce  = await saucePromise;
    let cheese = await grateCheese(sauce.determineCheese());
    let dough  = await doughPromise;

    dough.add(sauce);
    dough.add(cheese);

    return dough;
}

然而，你一定注意到了我们必须先建好饼和酱的Promise并执行他们，再调用await来同步的获取执行结果。恩，这种写法其实比纯promise的写法没有高明到哪里去。。。

总结：即使你准备使用async/await，你仍然需要彻底了解Promise的机制和原理，必要的时候，不要犹豫使用Promise

想想也许我的孩子长大之后不知道Google、Twitter、YouTube、Facebook，从没看过美剧日剧，还真是有点后怕。

附：王小波1996的一篇文章

二十多年前，我在云南插队。当地气候炎热，出产各种热带水果，就是没有椰子。整个云南都不长椰子，根据野史记载，这其中有个缘故。据说，在三国以前，云南到处都是椰子，树下住着幸福的少数民族。众所周知，椰子有很多用处，椰茸可以当饭吃，椰子油也可食用。椰子树叶里的纤维可以织粗糙的衣裙，椰子树干是木材。这种树木可以满足人的大部分需要，当地人也就不事农耕，过着悠闲的生活。

忽一日，诸葛亮南征来到此地，他要教化当地人，让他们遵从我们的生活方式：干我们的活，穿我们的衣服，服从我们的制度。这件事起初不大成功，当地人没看出我们的生活方式有什么优越之处。首先，秋收春种，活得很累，起码比摘椰子要累；其次，汉族人的衣着在当地也不适用。就以诸葛先生为例，那身道袍料子虽好，穿在身上除了捂汗和捂痱子，捂不出别的来；至于那顶道冠，既不遮阳，也不挡雨，只能招马蜂进去做窝。当地天热，摘两片椰树叶把羞处遮遮就可以了。至于汉朝的政治制度，对当地的少数民族来说，未免太过烦琐。诸葛先生磨破了嘴皮子，言必称孔孟，但也没人听。他不觉得自己的道理不对，却把帐算在了椰子树身上：下了一道命令，一夜之间就把云南的椰树砍了个精光；免得这些蛮夷之人听不进圣贤的道理。没了这些树，他说话就有人听了——对此，我的解释是，诸葛亮他老人家南征，可不是一个人去的，还带了好多的兵，砍树用的刀斧也可以用来砍人，砍树这件事说明他手下的人手够用，刀斧也够用。当地人明白了这个意思，就怕了诸葛先生。我这种看法你尽可以不同意——我知道你会说，诸葛亮乃古之贤人，不会这样赤裸裸地用武力威胁别人；所以，我也不想坚持这种观点。

对于此事，野史上是这么解释的：蛮夷之人，有些稀奇之物，就此轻狂，胆敢渺视天朝大邦；没了这些珍稀之物，他们就老实了。这就是说，云南人当时犯有轻狂的毛病，这是一种道德缺陷。诸葛先生砍树，是为了纠正这种毛病，是为他们好。我总觉得这种说法有点太过惊世骇俗。人家有几样好东西，活得好一点，心情也好一点，这就是轻狂；非得把这些好东西毁了，让人家心情沉痛，这就是不轻狂——我以为这是野史作者的意见，诸葛先生不是这样的人。

野史是不能当真的，但云南现在确实没有椰子，而过去是有的。所以这些椰树可能是诸葛亮砍的。假如这不是耍野蛮，就该有种道义上的解释。我觉得诸葛亮砍椰子时，可能是这么想的：人人理应生来平等，但现在不平等了：四川不长椰树，那里的人要靠农耕为生；云南长满了椰树，这里的人就活得很舒服。让四川也长满椰树，这是一种达到公平的方法，但是限于自然条件，很难做到。所以，必需把云南的椰树砍掉，这样才公平。假如有不平等，有两种方式可以拉平：一种是向上拉平，这是最好的，但实行起来有困难；比如，有些人生来四肢健全，有些人则生有残疾，一种平等之道是把所有的残疾人都治成正常人，这可不容易做到。另一种是向下拉平，要把所有的正常人都变成残疾人就很容易：只消用铁棍一敲，一声惨叫，这就变过来了。诸葛先生采取的是向下拉平之道，结果就害得我吃不上椰子。在云南时，我觉得嘴淡时就啃几个木瓜。木瓜淡而无味，假如没熟透，啃后满嘴都是麻的。但我没有抱怨木瓜树，这种树内地也是不长的。假如它的果子太好吃，诸葛先生也会把它砍光啦。

我这篇文章题目在说椰子，实质在谈平等问题，挂羊头卖狗肉，正是我的用意。人人理应生来平等，这一点人人都同意。但实际上是不平等的，而且最大的不平等不是有人有椰子树，有人没有椰子树。如罗素先生所说，最大的不平等是知识的差异——有人聪明有人笨，这就是问题之所在。这里所说的知识、聪明是广义的，不单包括科学知识，还包括文化素质，艺术的品味，等等。这种椰子树长在人脑里，不光能给人带来物质福利，还有精神上的幸福；这后一方面的差异我把它称为幸福能力的差异。有些作品，有些人能欣赏，有些人就看不懂，这就是说，有些人的幸福能力较为优越。这种优越最招人嫉妒。消除这种优越的方法之一就是给聪明人头上一闷棍，把他打笨些。但打轻了不管用，打重了会把脑子打出来，这又不是我们的本意。另一种方法则是：一旦聪明人和傻人起了争执，我们总说傻人有理。久而久之，聪明人也会变傻。这种法子现在正用着呢。