这篇博文将向你展示如何使用 Docker 和 OpenFaaS 框架构建你自己的 Serverless 树莓派集群。大家常常问我能用他们的集群来做些什么？而这个应用完美匹配卡片尺寸的设备——只需添加更多的树莓派就能获取更强的计算能力。

“Serverless” （无服务器）是事件驱动架构的一种设计模式，与“桥接模式”、“外观模式”、“工厂模式”和“云”这些名词一样，都是一种抽象概念。

图片：3 个 Raspberry Pi Zero

这是我在本文中描述的集群，用黄铜支架分隔每个设备。

Serverless 是什么？它为何重要？

行业对于 “serverless” 这个术语的含义有几种解释。在这篇博文中，我们就把它理解为一种事件驱动的架构模式，它能让你用自己喜欢的任何语言编写轻量可复用的功能。更多关于 Serverless 的资料。

Serverless 架构也引出了“功能即服务服务”模式，简称 FaaS

Serverless 的“功能”可以做任何事，但通常用于处理给定的输入——例如来自 GitHub、Twitter、PayPal、Slack、Jenkins CI pipeline 的事件；或者以树莓派为例，处理像红外运动传感器、激光绊网、温度计等真实世界的传感器的输入。

Serverless 功能能够更好地结合第三方的后端服务，使系统整体的能力大于各部分之和。

了解更多背景信息，可以阅读我最近一偏博文：功能即服务（FaaS）简介。

概述

我们将使用 OpenFaaS，它能够让主机或者集群作为支撑 Serverless 功能运行的后端。任何能够使用 Docker 部署的可执行二进制文件、脚本或者编程语言都能在 OpenFaaS 上运作，你可以根据速度和伸缩性选择部署的规模。另一个优点是，它还内建了用户界面和监控系统。

这是我们要执行的步骤：

• 在一个或多个主机上配置 Docker （树莓派 2 或者 3）；
• 利用 Docker Swarm 将它们连接；
• 部署 OpenFaaS；
• 使用 Python 编写我们的第一个功能。

Docker Swarm

Docker 是一项打包和部署应用的技术，支持集群上运行，有着安全的默认设置，而且在搭建集群时只需要一条命令。OpenFaaS 使用 Docker 和 Swarm 在你的可用树莓派上传递你的 Serverless 功能。

我推荐你在这个项目中使用带树莓派 2 或者 3，以太网交换机和强大的 USB 多端口电源适配器。

准备 Raspbian

把 Raspbian Jessie Lite 写入 SD 卡（8GB 容量就正常工作了，但还是推荐使用 16GB 的 SD 卡）。

注意：不要下载成 Raspbian Stretch 了

社区在努力让 Docker 支持 Raspbian Stretch，但是还未能做到完美运行。请从树莓派基金会网站下载 Jessie Lite 镜像。

我推荐使用 Etcher.io 烧写镜像。

在引导树莓派之前，你需要在引导分区创建名为 ssh 的空白文件。这样才能允许远程登录。

接通电源，然后修改主机名

现在启动树莓派的电源并且使用 ssh 连接：

$ ssh [email protected]

默认密码是 raspberry

使用 raspi-config 工具把主机名改为 swarm-1 或者类似的名字，然后重启。

当你到了这一步，你还可以把划分给 GPU （显卡）的内存设置为 16MB。

现在安装 Docker

我们可以使用通用脚本来安装：

$ curl -sSL https://get.docker.com | sh

这个安装方式在将来可能会发生变化。如上文所说，你的系统需要是 Jessie，这样才能得到一个确定的配置。

你可能会看到类似下面的警告，不过你可以安全地忽略它并且成功安装上 Docker CE 17.05：

WARNING: raspbian is no longer updated @ https://get.docker.com/  
Installing the legacy docker-engine package...  

之后，用下面这个命令确保你的用户帐号可以访问 Docker 客户端：

$ usermod pi -aG docker

如果你的用户名不是 pi，那就把它替换成你的用户名。

修改默认密码

输入 $sudo passwd pi，然后设置一个新密码，请不要跳过这一步！

重复以上步骤

现在为其它的树莓派重复上述步骤。

创建你的 Swarm 集群

登录你的第一个树莓派，然后输入下面的命令：

$ docker swarm init
Swarm initialized: current node (3ra7i5ldijsffjnmubmsfh767) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join \
    --token SWMTKN-1-496mv9itb7584pzcddzj4zvzzfltgud8k75rvujopw15n3ehzu-af445b08359golnzhncbdj9o3 \
    192.168.0.79:2377

你会看到它显示了一个口令，以及其它节点加入集群的命令。接下来使用 ssh 登录每个树莓派，运行这个加入集群的命令。

等待连接完成后，在第一个树莓派上查看集群的节点：

$ docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS  
3ra7i5ldijsffjnmubmsfh767 *   swarm1              Ready               Active              Leader  
k9mom28s2kqxocfq1fo6ywu63     swarm3              Ready               Active  
y2p089bs174vmrlx30gc77h4o     swarm4              Ready               Active  

恭喜你！你现在拥有一个树莓派集群了！

更多关于集群的内容

你可以看到三个节点启动运行。这时只有一个节点是集群管理者。如果我们的管理节点死机了，集群就进入了不可修复的状态。我们可以通过添加冗余的管理节点解决这个问题。而且它们依然会运行工作负载，除非你明确设置了让你的服务只运作在工作节点上。

要把一个工作节点升级为管理节点，只需要在其中一个管理节点上运行 docker node promote <node_name> 命令。

注意： Swarm 命令，例如 docker service ls 或者 docker node ls 只能在管理节点上运行。

想深入了解管理节点与工作节点如何保持一致性，可以查阅 Docker Swarm 管理指南。

OpenFaaS

现在我们继续部署程序，让我们的集群能够运行 Serverless 功能。OpenFaaS 是一个利用 Docker 在任何硬件或者云上让任何进程或者容器成为一个 Serverless 功能的框架。因为 Docker 和 Golang 的可移植性，它也能很好地运行在树莓派上。

如果你支持 OpenFaaS，希望你能 星标 OpenFaaS 的 GitHub 仓库。

登录你的第一个树莓派（你运行 docker swarm init 的节点），然后部署这个项目：

$ git clone https://github.com/alexellis/faas/
$ cd faas
$ ./deploy_stack.armhf.sh
Creating network func_functions  
Creating service func_gateway  
Creating service func_prometheus  
Creating service func_alertmanager  
Creating service func_nodeinfo  
Creating service func_markdown  
Creating service func_wordcount  
Creating service func_echoit  

你的其它树莓派会收到 Docer Swarm 的指令，开始从网上拉取这个 Docker 镜像，并且解压到 SD 卡上。这些工作会分布到各个节点上，所以没有哪个节点产生过高的负载。

这个过程会持续几分钟，你可以用下面指令查看它的完成状况：

$ watch 'docker service ls'
ID                  NAME                MODE                REPLICAS            IMAGE                                   PORTS  
57ine9c10xhp        func_wordcount      replicated          1/1                 functions/alpine:latest-armhf  
d979zipx1gld        func_prometheus     replicated          1/1                 alexellis2/prometheus-armhf:1.5.2       *:9090->9090/tcp  
f9yvm0dddn47        func_echoit         replicated          1/1                 functions/alpine:latest-armhf  
lhbk1fc2lobq        func_markdown       replicated          1/1                 functions/markdownrender:latest-armhf  
pj814yluzyyo        func_alertmanager   replicated          1/1                 alexellis2/alertmanager-armhf:0.5.1     *:9093->9093/tcp  
q4bet4xs10pk        func_gateway        replicated          1/1                 functions/gateway-armhf:0.6.0           *:8080->8080/tcp  
v9vsvx73pszz        func_nodeinfo       replicated          1/1                 functions/nodeinfo:latest-armhf  

我们希望看到每个服务都显示 “1/1”。

你可以根据服务名查看该服务被调度到哪个树莓派上：

$ docker service ps func_markdown
ID                  IMAGE                                   NODE    STATE  
func_markdown.1     functions/markdownrender:latest-armhf   swarm4  Running  

状态一项应该显示 Running，如果它是 Pending，那么镜像可能还在下载中。

在这时，查看树莓派的 IP 地址，然后在浏览器中访问它的 8080 端口：

$ ifconfig

例如，如果你的 IP 地址是 192.168.0.100，那就访问 http://192.168.0.100:8080 。

这是你会看到 FaaS UI（也叫 API 网关）。这是你定义、测试、调用功能的地方。

点击名称为 “func\_markdown” 的 Markdown 转换功能，输入一些 Markdown（这是 Wikipedia 用来组织内容的语言）文本。

然后点击 “invoke”。你会看到调用计数增加，屏幕下方显示功能调用的结果。

部署你的第一个 Serverless 功能：

这一节的内容已经有相关的教程，但是我们需要几个步骤来配置树莓派。

获取 FaaS-CLI

$ curl -sSL cli.openfaas.com | sudo sh
armv7l  
Getting package https://github.com/alexellis/faas-cli/releases/download/0.4.5-b/faas-cli-armhf  

下载样例

$ git clone https://github.com/alexellis/faas-cli
$ cd faas-cli

为树莓派修补样例模版

我们临时修改我们的模版，让它们能在树莓派上工作：

$ cp template/node-armhf/Dockerfile template/node/
$ cp template/python-armhf/Dockerfile template/python/

这么做是因为树莓派和我们平时关注的大多数计算机使用不一样的处理器架构。

了解 Docker 在树莓派上的最新状况，请查阅： 你需要了解的五件事。

现在你可以跟着下面为 PC、笔记本和云端所写的教程操作，但我们在树莓派上要先运行一些命令。

• 使用 OpenFaaS 运行你的第一个 Serverless Python 功能

注意第 3 步：

• 把你的功能放到先前从 GitHub 下载的 faas-cli 文件夹中，而不是 ~/functinos/hello-python 里。
• 同时，在 stack.yml 文件中把 localhost 替换成第一个树莓派的 IP 地址。

集群可能会花费几分钟把 Serverless 功能下载到相关的树莓派上。你可以用下面的命令查看你的服务，确保副本一项显示 “1/1”：

$ watch 'docker service ls'
pv27thj5lftz        hello-python        replicated          1/1                 alexellis2/faas-hello-python-armhf:latest  

继续阅读教程： 使用 OpenFaaS 运行你的第一个 Serverless Python 功能

关于 Node.js 或者其它语言的更多信息，可以进一步访问 FaaS 仓库。

检查功能的指标

既然使用 Serverless，你也不想花时间监控你的功能。幸运的是，OpenFaaS 内建了 Prometheus 指标检测，这意味着你可以追踪每个功能的运行时长和调用频率。

指标驱动自动伸缩

如果你给一个功能生成足够的负载，OpenFaaS 将自动扩展你的功能；当需求消失时，你又会回到单一副本的状态。

这个请求样例你可以复制到浏览器中：

只要把 IP 地址改成你的即可。

http://192.168.0.25:9090/graph?g0.range_input=15m&g0.stacked=1&g0.expr=rate(gateway_function_invocation_total%5B20s%5D)&g0.tab=0&g1.range_input=1h&g1.expr=gateway_service_count&g1.tab=0  

这些请求使用 PromQL（Prometheus 请求语言）编写。第一个请求返回功能调用的频率：

rate(gateway_function_invocation_total[20s])  

第二个请求显示每个功能的副本数量，最开始应该是每个功能只有一个副本。

gateway_service_count  

如果你想触发自动扩展，你可以在树莓派上尝试下面指令：

$ while [ true ]; do curl -4 localhost:8080/function/func_echoit --data "hello world" ; done

查看 Prometheus 的 “alerts” 页面，可以知道你是否产生足够的负载来触发自动扩展。如果没有，你可以尝试在多个终端同时运行上面的指令。

当你降低负载，副本数量显示在你的第二个图表中，并且 gateway_service_count 指标再次降回 1。

结束演讲

我们现在配置好了 Docker、Swarm， 并且让 OpenFaaS 运行代码，把树莓派像大型计算机一样使用。

希望大家支持这个项目，星标 FaaS 的 GitHub 仓库。

你是如何搭建好了自己的 Docker Swarm 集群并且运行 OpenFaaS 的呢？在 Twitter @alexellisuk 上分享你的照片或推文吧。

观看我在 Dockercon 上关于 OpenFaaS 的视频

我在 Austin 的 Dockercon 上展示了 OpenFaaS。——观看介绍和互动例子的视频： https://www.youtube.com/embed/-h2VTE9WnZs

有问题？在下面的评论中提出，或者给我发邮件，邀请我进入你和志同道合者讨论树莓派、Docker、Serverless 的 Slack channel。

想要学习更多关于树莓派上运行 Docker 的内容？

我建议从 你需要了解的五件事 开始，它包含了安全性、树莓派和普通 PC 间微妙差别等话题。

• Dockercon tips: Docker & Raspberry Pi
• Control GPIO with Docker Swarm
• Is that a Docker Engine in your pocket??

via: https://blog.alexellis.io/your-serverless-raspberry-pi-cluster/

作者：Alex Ellis 译者：haoqixu 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

探索函数式编程，通过它让你的程序更具有可读性和易于调试

当 Brendan Eich 在 1995 年创造 JavaScript 时，他原本打算将 Scheme 移植到浏览器里 。Scheme 作为 Lisp 的方言，是一种函数式编程语言。而当 Eich 被告知新的语言应该是一种可以与 Java 相比的脚本语言后，他最终确立了一种拥有 C 风格语法的语言（也和 Java 一样），但将函数视作一等公民。而 Java 直到版本 8 才从技术上将函数视为一等公民，虽然你可以用匿名类来模拟它。这个特性允许 JavaScript 通过函数式范式编程。

JavaScript 是一个多范式语言，允许你自由地混合和使用面向对象式、过程式和函数式的编程范式。最近，函数式编程越来越火热。在诸如 Angular 和 React 这样的框架中，通过使用不可变数据结构可以切实提高性能。不可变是函数式编程的核心原则，它以及纯函数使得编写和调试程序变得更加容易。使用函数来代替程序的循环可以提高程序的可读性并使它更加优雅。总之，函数式编程拥有很多优点。

什么不是函数式编程

在讨论什么是函数式编程前，让我们先排除那些不属于函数式编程的东西。实际上它们是你需要丢弃的语言组件（再见，老朋友）：

• 循环：

  • while
  • do...while
  • for
  • for...of
  • for...in
• 用 var 或者 let 来声明变量
• 没有返回值的函数
• 改变对象的属性 (比如: o.x = 5;)

• 改变数组本身的方法：

  • copyWithin
  • fill
  • pop
  • push
  • reverse
  • shift
  • sort
  • splice
  • unshift

• 改变映射本身的方法：

  • clear
  • delete
  • set

• 改变集合本身的方法：

  • add
  • clear
  • delete

脱离这些特性应该如何编写程序呢？这是我们将在后面探索的问题。

纯函数

你的程序中包含函数不一定意味着你正在进行函数式编程。函数式范式将 纯函数 pure function 和 非纯函数 impure function 区分开。鼓励你编写纯函数。纯函数必须满足下面的两个属性：

• 引用透明：函数在传入相同的参数后永远返回相同的返回值。这意味着该函数不依赖于任何可变状态。
• 无副作用：函数不能导致任何副作用。副作用可能包括 I/O（比如向终端或者日志文件写入），改变一个不可变的对象，对变量重新赋值等等。

我们来看一些例子。首先，multiply 就是一个纯函数的例子，它在传入相同的参数后永远返回相同的返回值，并且不会导致副作用。

function multiply(a, b) {
  return a * b;
}

下面是非纯函数的例子。canRide 函数依赖捕获的 heightRequirement 变量。被捕获的变量不一定导致一个函数是非纯函数，除非它是一个可变的变量（或者可以被重新赋值）。这种情况下使用 let 来声明这个变量，意味着可以对它重新赋值。multiply 函数是非纯函数，因为它会导致在 console 上输出。

let heightRequirement = 46;

// Impure because it relies on a mutable (reassignable) variable.
function canRide(height) {
  return height >= heightRequirement;
}

// Impure because it causes a side-effect by logging to the console.
function multiply(a, b) {
  console.log('Arguments: ', a, b);
  return a * b;
}

下面的列表包含着 JavaScript 内置的非纯函数。你可以指出它们不满足两个属性中的哪个吗？

• console.log
• element.addEventListener
• Math.random
• Date.now
• $.ajax (这里 $ 代表你使用的 Ajax 库)

理想的程序中所有的函数都是纯函数，但是从上面的函数列表可以看出，任何有意义的程序都将包含非纯函数。大多时候我们需要进行 AJAX 调用，检查当前日期或者获取一个随机数。一个好的经验法则是遵循 80/20 规则：函数中有 80％ 应该是纯函数，剩下的 20％ 的必要性将不可避免地是非纯函数。

使用纯函数有几个优点：

• 它们很容易导出和调试，因为它们不依赖于可变的状态。
• 返回值可以被缓存或者“记忆”来避免以后重复计算。
• 它们很容易测试，因为没有需要模拟（mock）的依赖（比如日志，AJAX，数据库等等）。

你编写或者使用的函数返回空（换句话说它没有返回值），那代表它是非纯函数。

不变性

让我们回到捕获变量的概念上。来看看 canRide 函数。我们认为它是一个非纯函数，因为 heightRequirement 变量可以被重新赋值。下面是一个构造出来的例子来说明如何用不可预测的值来对它重新赋值。

let heightRequirement = 46;

function canRide(height) {
  return height >= heightRequirement;
}

// Every half second, set heightRequirement to a random number between 0 and 200.
setInterval(() => heightRequirement = Math.floor(Math.random() * 201), 500);

const mySonsHeight = 47;

// Every half second, check if my son can ride.
// Sometimes it will be true and sometimes it will be false.
setInterval(() => console.log(canRide(mySonsHeight)), 500);

我要再次强调被捕获的变量不一定会使函数成为非纯函数。我们可以通过只是简单地改变 heightRequirement 的声明方式来使 canRide 函数成为纯函数。

const heightRequirement = 46;

function canRide(height) {
  return height >= heightRequirement;
}

通过用 const 来声明变量意味着它不能被再次赋值。如果尝试对它重新赋值，运行时引擎将抛出错误；那么，如果用对象来代替数字来存储所有的“常量”怎么样？

const constants = {
  heightRequirement: 46,
  // ... other constants go here
};

function canRide(height) {
  return height >= constants.heightRequirement;
}

我们用了 const ，所以这个变量不能被重新赋值，但是还有一个问题：这个对象可以被改变。下面的代码展示了，为了真正使其不可变，你不仅需要防止它被重新赋值，你也需要不可变的数据结构。JavaScript 语言提供了 Object.freeze 方法来阻止对象被改变。

'use strict';

// CASE 1: 对象的属性是可变的，并且变量可以被再次赋值。
let o1 = { foo: 'bar' };

// 改变对象的属性
o1.foo = 'something different';

// 对变量再次赋值
o1 = { message: "I'm a completely new object" };


// CASE 2: 对象的属性还是可变的，但是变量不能被再次赋值。
const o2 = { foo: 'baz' };

// 仍然能改变对象
o2.foo = 'Something different, yet again';

// 不能对变量再次赋值
// o2 = { message: 'I will cause an error if you uncomment me' }; // Error!


// CASE 3: 对象的属性是不可变的，但是变量可以被再次赋值。
let o3 = Object.freeze({ foo: "Can't mutate me" });

// 不能改变对象的属性
// o3.foo = 'Come on, uncomment me. I dare ya!'; // Error!

// 还是可以对变量再次赋值
o3 = { message: "I'm some other object, and I'm even mutable -- so take that!" };


// CASE 4: 对象的属性是不可变的，并且变量不能被再次赋值。这是我们想要的！！！！！！！！
const o4 = Object.freeze({ foo: 'never going to change me' });

// 不能改变对象的属性
// o4.foo = 'talk to the hand' // Error!

// 不能对变量再次赋值
// o4 = { message: "ain't gonna happen, sorry" }; // Error

不变性适用于所有的数据结构，包括数组、映射和集合。它意味着不能调用例如 Array.prototype.push 等会导致本身改变的方法，因为它会改变已经存在的数组。可以通过创建一个含有原来元素和新加元素的新数组，而不是将新元素加入一个已经存在的数组。其实所有会导致数组本身被修改的方法都可以通过一个返回修改好的新数组的函数代替。

'use strict';

const a = Object.freeze([4, 5, 6]);

// Instead of: a.push(7, 8, 9);
const b = a.concat(7, 8, 9);

// Instead of: a.pop();
const c = a.slice(0, -1);

// Instead of: a.unshift(1, 2, 3);
const d = [1, 2, 3].concat(a);

// Instead of: a.shift();
const e = a.slice(1);

// Instead of: a.sort(myCompareFunction);
const f = R.sort(myCompareFunction, a); // R = Ramda

// Instead of: a.reverse();
const g = R.reverse(a); // R = Ramda

// 留给读者的练习:
// copyWithin
// fill
// splice

映射 和 集合 也很相似。可以通过返回一个新的修改好的映射或者集合来代替使用会修改其本身的函数。

const map = new Map([
  [1, 'one'],
  [2, 'two'],
  [3, 'three']
]);

// Instead of: map.set(4, 'four');
const map2 = new Map([...map, [4, 'four']]);

// Instead of: map.delete(1);
const map3 = new Map([...map].filter(([key]) => key !== 1));

// Instead of: map.clear();
const map4 = new Map();

const set = new Set(['A', 'B', 'C']);

// Instead of: set.add('D');
const set2 = new Set([...set, 'D']);

// Instead of: set.delete('B');
const set3 = new Set([...set].filter(key => key !== 'B'));

// Instead of: set.clear();
const set4 = new Set();

我想提一句如果你在使用 TypeScript（我非常喜欢 TypeScript），你可以用 Readonly<T>、ReadonlyArray<T>、ReadonlyMap<K, V> 和 ReadonlySet<T> 接口来在编译期检查你是否尝试更改这些对象，有则抛出编译错误。如果在对一个对象字面量或者数组调用 Object.freeze，编译器会自动推断它是只读的。由于映射和集合在其内部表达，所以在这些数据结构上调用 Object.freeze 不起作用。但是你可以轻松地告诉编译器它们是只读的变量。

TypeScript 只读接口

好，所以我们可以通过创建新的对象来代替修改原来的对象，但是这样不会导致性能损失吗？当然会。确保在你自己的应用中做了性能测试。如果你需要提高性能，可以考虑使用 Immutable.js。Immutable.js 用持久的数据结构 实现了链表、堆栈、映射、集合和其他数据结构。使用了如同 Clojure 和 Scala 这样的函数式语言中相同的技术。

// Use in place of `[]`.
const list1 = Immutable.List(['A', 'B', 'C']);
const list2 = list1.push('D', 'E');

console.log([...list1]); // ['A', 'B', 'C']
console.log([...list2]); // ['A', 'B', 'C', 'D', 'E']


// Use in place of `new Map()`
const map1 = Immutable.Map([
  ['one', 1],
  ['two', 2],
  ['three', 3]
]);
const map2 = map1.set('four', 4);

console.log([...map1]); // [['one', 1], ['two', 2], ['three', 3]]
console.log([...map2]); // [['one', 1], ['two', 2], ['three', 3], ['four', 4]]


// Use in place of `new Set()`
const set1 = Immutable.Set([1, 2, 3, 3, 3, 3, 3, 4]);
const set2 = set1.add(5);

console.log([...set1]); // [1, 2, 3, 4]
console.log([...set2]); // [1, 2, 3, 4, 5]

函数组合

记不记得在中学时我们学过一些像 (f ∘ g)(x) 的东西？你那时可能想，“我什么时候会用到这些？”，好了，现在就用到了。你准备好了吗？f ∘ g读作 “函数 f 和函数 g 组合”。对它的理解有两种等价的方式，如等式所示： (f ∘ g)(x) = f(g(x))。你可以认为 f ∘ g 是一个单独的函数，或者视作将调用函数 g 的结果作为参数传给函数 f。注意这些函数是从右向左依次调用的，先执行 g，接下来执行 f。

关于函数组合的几个要点:

1. 我们可以组合任意数量的函数（不仅限于 2 个）。
2. 组合函数的一个方式是简单地把一个函数的输出作为下一个函数的输入（比如 f(g(x))）。

// h(x) = x + 1
// number -> number
function h(x) {
  return x + 1;
}

// g(x) = x^2
// number -> number
function g(x) {
  return x * x;
}

// f(x) = convert x to string
// number -> string
function f(x) {
  return x.toString();
}

// y = (f ∘ g ∘ h)(1)
const y = f(g(h(1)));
console.log(y); // '4'

Ramda 和 lodash 之类的库提供了更优雅的方式来组合函数。我们可以在更多的在数学意义上处理函数组合，而不是简单地将一个函数的返回值传递给下一个函数。我们可以创建一个由这些函数组成的单一复合函数(就是 (f ∘ g)(x))。

// h(x) = x + 1
// number -> number
function h(x) {
  return x + 1;
}

// g(x) = x^2
// number -> number
function g(x) {
  return x * x;
}

// f(x) = convert x to string
// number -> string
function f(x) {
  return x.toString();
}

// R = Ramda
// composite = (f ∘ g ∘ h)
const composite = R.compose(f, g, h);

// Execute single function to get the result.
const y = composite(1);
console.log(y); // '4'

好了，我们可以在 JavaScript 中组合函数了。接下来呢？好，如果你已经入门了函数式编程，理想中你的程序将只有函数的组合。代码里没有循环（for, for...of, for...in, while, do），基本没有。你可能觉得那是不可能的。并不是这样。我们下面的两个话题是：递归和高阶函数。

递归

假设你想实现一个计算数字的阶乘的函数。 让我们回顾一下数学中阶乘的定义：

n! = n * (n-1) * (n-2) * ... * 1.

n! 是从 n 到 1 的所有整数的乘积。我们可以编写一个循环轻松地计算出结果。

function iterativeFactorial(n) {
  let product = 1;
  for (let i = 1; i <= n; i++) {
    product *= i;
  }
  return product;
}

注意 product 和 i 都在循环中被反复重新赋值。这是解决这个问题的标准过程式方法。如何用函数式的方法解决这个问题呢？我们需要消除循环，确保没有变量被重新赋值。递归是函数式程序员的最有力的工具之一。递归需要我们将整体问题分解为类似整体问题的子问题。

计算阶乘是一个很好的例子，为了计算 n! 我们需要将 n 乘以所有比它小的正整数。它的意思就相当于：

n! = n * (n-1)!

啊哈！我们发现了一个解决 (n-1)! 的子问题，它类似于整个问题 n!。还有一个需要注意的地方就是基础条件。基础条件告诉我们何时停止递归。 如果我们没有基础条件，那么递归将永远持续。 实际上，如果有太多的递归调用，程序会抛出一个堆栈溢出错误。啊哈！

function recursiveFactorial(n) {
  // Base case -- stop the recursion
  if (n === 0) {
    return 1; // 0! is defined to be 1.
  }
  return n * recursiveFactorial(n - 1);
}

然后我们来计算 recursiveFactorial(20000) 因为……，为什么不呢？当我们这样做的时候，我们得到了这个结果：

堆栈溢出错误

这里发生了什么？我们得到一个堆栈溢出错误！这不是无穷的递归导致的。我们已经处理了基础条件(n === 0 的情况)。那是因为浏览器的堆栈大小是有限的，而我们的代码使用了越过了这个大小的堆栈。每次对 recursiveFactorial 的调用导致了新的帧被压入堆栈中，就像一个盒子压在另一个盒子上。每当 recursiveFactorial 被调用，一个新的盒子被放在最上面。下图展示了在计算 recursiveFactorial(3) 时堆栈的样子。注意在真实的堆栈中，堆栈顶部的帧将存储在执行完成后应该返回的内存地址，但是我选择用变量 r 来表示返回值，因为 JavaScript 开发者一般不需要考虑内存地址。

")

递归计算 3! 的堆栈（三次乘法）

你可能会想象当计算 n = 20000 时堆栈会更高。我们可以做些什么优化它吗？当然可以。作为 ES2015 (又名 ES6) 标准的一部分，有一个优化用来解决这个问题。它被称作 尾调用优化 proper tail calls optimization （PTC）。当递归函数做的最后一件事是调用自己并返回结果的时候，它使得浏览器删除或者忽略堆栈帧。实际上，这个优化对于相互递归函数也是有效的，但是为了简单起见，我们还是来看单一递归函数。

你可能会注意到，在递归函数调用之后，还要进行一次额外的计算（n * r）。那意味着浏览器不能通过 PTC 来优化递归；然而，我们可以通过重写函数使最后一步变成递归调用以便优化。一个窍门是将中间结果（在这里是 product）作为参数传递给函数。

'use strict';

// Optimized for tail call optimization.
function factorial(n, product = 1) {
  if (n === 0) {
    return product;
  }
  return factorial(n - 1, product * n)
}

让我们来看看优化后的计算 factorial(3) 时的堆栈。如下图所示，堆栈不会增长到超过两层。原因是我们把必要的信息都传到了递归函数中（比如 product）。所以，在 product 被更新后，浏览器可以丢弃掉堆栈中原先的帧。你可以在图中看到每次最上面的帧下沉变成了底部的帧，原先底部的帧被丢弃，因为不再需要它了。

using PTC")

递归计算 3! 的堆栈（三次乘法）使用 PTC

现在选一个浏览器运行吧，假设你在使用 Safari，你会得到 Infinity（它是比在 JavaScript 中能表达的最大值更大的数）。但是我们没有得到堆栈溢出错误，那很不错！现在在其他的浏览器中呢怎么样呢？Safari 可能现在乃至将来是实现 PTC 的唯一一个浏览器。看看下面的兼容性表格：

PTC 兼容性

其他浏览器提出了一种被称作 语法级尾调用 syntactic tail calls （STC）的竞争标准。“语法级”意味着你需要用新的语法来标识你想要执行尾递归优化的函数。即使浏览器还没有广泛支持，但是把你的递归函数写成支持尾递归优化的样子还是一个好主意。

高阶函数

我们已经知道 JavaScript 将函数视作一等公民，可以把函数像其他值一样传递。所以，把一个函数传给另一个函数也很常见。我们也可以让函数返回一个函数。就是它！我们有高阶函数。你可能已经很熟悉几个在 Array.prototype 中的高阶函数。比如 filter、map 和 reduce 就在其中。对高阶函数的一种理解是：它是接受（一般会调用）一个回调函数参数的函数。让我们来看看一些内置的高阶函数的例子：

const vehicles = [
  { make: 'Honda', model: 'CR-V', type: 'suv', price: 24045 },
  { make: 'Honda', model: 'Accord', type: 'sedan', price: 22455 },
  { make: 'Mazda', model: 'Mazda 6', type: 'sedan', price: 24195 },
  { make: 'Mazda', model: 'CX-9', type: 'suv', price: 31520 },
  { make: 'Toyota', model: '4Runner', type: 'suv', price: 34210 },
  { make: 'Toyota', model: 'Sequoia', type: 'suv', price: 45560 },
  { make: 'Toyota', model: 'Tacoma', type: 'truck', price: 24320 },
  { make: 'Ford', model: 'F-150', type: 'truck', price: 27110 },
  { make: 'Ford', model: 'Fusion', type: 'sedan', price: 22120 },
  { make: 'Ford', model: 'Explorer', type: 'suv', price: 31660 }
];

const averageSUVPrice = vehicles
  .filter(v => v.type === 'suv')
  .map(v => v.price)
  .reduce((sum, price, i, array) => sum + price / array.length, 0);

console.log(averageSUVPrice); // 33399

注意我们在一个数组对象上调用其方法，这是面向对象编程的特性。如果我们想要更函数式一些，我们可以用 Rmmda 或者 lodash/fp 提供的函数。注意如果我们使用 R.compose 的话，需要倒转函数的顺序，因为它从右向左依次调用函数（从底向上）；然而，如果我们想从左向右调用函数就像上面的例子，我们可以用 R.pipe。下面两个例子用了 Rmmda。注意 Rmmda 有一个 mean 函数用来代替 reduce 。

const vehicles = [
  { make: 'Honda', model: 'CR-V', type: 'suv', price: 24045 },
  { make: 'Honda', model: 'Accord', type: 'sedan', price: 22455 },
  { make: 'Mazda', model: 'Mazda 6', type: 'sedan', price: 24195 },
  { make: 'Mazda', model: 'CX-9', type: 'suv', price: 31520 },
  { make: 'Toyota', model: '4Runner', type: 'suv', price: 34210 },
  { make: 'Toyota', model: 'Sequoia', type: 'suv', price: 45560 },
  { make: 'Toyota', model: 'Tacoma', type: 'truck', price: 24320 },
  { make: 'Ford', model: 'F-150', type: 'truck', price: 27110 },
  { make: 'Ford', model: 'Fusion', type: 'sedan', price: 22120 },
  { make: 'Ford', model: 'Explorer', type: 'suv', price: 31660 }
];

// Using `pipe` executes the functions from top-to-bottom. 
const averageSUVPrice1 = R.pipe(
  R.filter(v => v.type === 'suv'),
  R.map(v => v.price),
  R.mean
)(vehicles);

console.log(averageSUVPrice1); // 33399

// Using `compose` executes the functions from bottom-to-top.
const averageSUVPrice2 = R.compose(
  R.mean,
  R.map(v => v.price),
  R.filter(v => v.type === 'suv')
)(vehicles);

console.log(averageSUVPrice2); // 33399

使用函数式方法的优点是清楚地分开了数据（vehicles）和逻辑（函数 filter，map 和 reduce）。面向对象的代码相比之下把数据和函数用以方法的对象的形式混合在了一起。

柯里化

不规范地说， 柯里化 currying 是把一个接受 n 个参数的函数变成 n 个每个接受单个参数的函数的过程。函数的 arity 是它接受参数的个数。接受一个参数的函数是 unary，两个的是 binary，三个的是 ternary，n 个的是 n-ary。那么，我们可以把柯里化定义成将一个 n-ary 函数转换成 n 个 unary 函数的过程。让我们通过简单的例子开始，一个计算两个向量点积的函数。回忆一下线性代数，两个向量 [a, b, c] 和 [x, y, z] 的点积是 ax + by + cz。

function dot(vector1, vector2) {
  return vector1.reduce((sum, element, index) => sum += element * vector2[index], 0);
}

const v1 = [1, 3, -5];
const v2 = [4, -2, -1];

console.log(dot(v1, v2)); // 1(4) + 3(-2) + (-5)(-1) = 4 - 6 + 5 = 3

dot 函数是 binary，因为它接受两个参数；然而我们可以将它手动转换成两个 unary 函数，就像下面的例子。注意 curriedDot 是一个 unary 函数，它接受一个向量并返回另一个接受第二个向量的 unary 函数。

function curriedDot(vector1) {
  return function(vector2) {
    return vector1.reduce((sum, element, index) => sum += element * vector2[index], 0);
  }
}

// Taking the dot product of any vector with [1, 1, 1]
// is equivalent to summing up the elements of the other vector.
const sumElements = curriedDot([1, 1, 1]);

console.log(sumElements([1, 3, -5])); // -1
console.log(sumElements([4, -2, -1])); // 1

很幸运，我们不需要把每一个函数都手动转换成柯里化以后的形式。Ramda 和 lodash 等库可以为我们做这些工作。实际上，它们是柯里化的混合形式。你既可以每次传递一个参数，也可以像原来一样一次传递所有参数。

function dot(vector1, vector2) {
  return vector1.reduce((sum, element, index) => sum += element * vector2[index], 0);
}

const v1 = [1, 3, -5];
const v2 = [4, -2, -1];

// Use Ramda to do the currying for us!
const curriedDot = R.curry(dot);

const sumElements = curriedDot([1, 1, 1]);

console.log(sumElements(v1)); // -1
console.log(sumElements(v2)); // 1

// This works! You can still call the curried function with two arguments.
console.log(curriedDot(v1, v2)); // 3

Ramda 和 lodash 都允许你“跳过”一些变量之后再指定它们。它们使用置位符来做这些工作。因为点积的计算可以交换两项。传入向量的顺序不影响结果。让我们换一个例子来阐述如何使用一个置位符。Ramda 使用双下划线作为其置位符。

const giveMe3 = R.curry(function(item1, item2, item3) {
  return `
    1: ${item1}
    2: ${item2}
    3: ${item3}
  `;
});

const giveMe2 = giveMe3(R.__, R.__, 'French Hens');   // Specify the third argument.
const giveMe1 = giveMe2('Partridge in a Pear Tree');  // This will go in the first slot.
const result = giveMe1('Turtle Doves');               // Finally fill in the second argument.

console.log(result);
// 1: Partridge in a Pear Tree
// 2: Turtle Doves
// 3: French Hens

在我们结束探讨柯里化之前最后的议题是 偏函数应用 partial application 。偏函数应用和柯里化经常同时出场，尽管它们实际上是不同的概念。一个柯里化的函数还是柯里化的函数，即使没有给它任何参数。偏函数应用，另一方面是仅仅给一个函数传递部分参数而不是所有参数。柯里化是偏函数应用常用的方法之一，但是不是唯一的。

JavaScript 拥有一个内置机制可以不依靠柯里化来做偏函数应用。那就是 function.prototype.bind 方法。这个方法的一个特殊之处在于，它要求你将 this 作为第一个参数传入。 如果你不进行面向对象编程，那么你可以通过传入 null 来忽略 this。

1function giveMe3(item1, item2, item3) {
  return `
    1: ${item1}
    2: ${item2}
    3: ${item3}
  `;
}

const giveMe2 = giveMe3.bind(null, 'rock');
const giveMe1 = giveMe2.bind(null, 'paper');
const result = giveMe1('scissors');

console.log(result);
// 1: rock
// 2: paper
// 3: scissors

总结

我希望你享受探索 JavaScript 中函数式编程的过程。对一些人来说，它可能是一个全新的编程范式，但我希望你能尝试它。你会发现你的程序更易于阅读和调试。不变性还将允许你优化 Angular 和 React 的性能。

这篇文章基于 Matt 在 OpenWest 的演讲 JavaScript the Good-er Parts. OpenWest 将在 6/12-15 ,2017 在 Salt Lake City, Utah 举行。

作者简介：

Matt Banz - Matt 于 2008 年五月在犹他大学获得了数学学位毕业。一个月后他得到了一份 web 开发者的工作，他从那时起就爱上了它！在 2013 年，他在北卡罗莱纳州立大学获得了计算机科学硕士学位。他在 LDS 商学院和戴维斯学区社区教育计划教授 Web 课程。他现在是就职于 Motorola Solutions 公司的高级前端开发者。

via: https://opensource.com/article/17/6/functional-javascript

作者：Matt Banz 译者：trnhoe 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

这是并发网络服务器系列的第二节。第一节 提出了服务端实现的协议，还有简单的顺序服务器的代码，是这整个系列的基础。

这一节里，我们来看看怎么用多线程来实现并发，用 C 实现一个最简单的多线程服务器，和用 Python 实现的线程池。

该系列的所有文章：

• 第一节 - 简介
• 第二节 - 线程
• 第三节 - 事件驱动

多线程的方法设计并发服务器

说起第一节里的顺序服务器的性能，最显而易见的，是在服务器处理客户端连接时，计算机的很多资源都被浪费掉了。尽管假定客户端快速发送完消息，不做任何等待，仍然需要考虑网络通信的开销；网络要比现在的 CPU 慢上百万倍还不止，因此 CPU 运行服务器时会等待接收套接字的流量，而大量的时间都花在完全不必要的等待中。

这里是一份示意图，表明顺序时客户端的运行过程：

这个图片上有 3 个客户端程序。棱形表示客户端的“到达时间”（即客户端尝试连接服务器的时间）。黑色线条表示“等待时间”（客户端等待服务器真正接受连接所用的时间），有色矩形表示“处理时间”（服务器和客户端使用协议进行交互所用的时间）。有色矩形的末端表示客户端断开连接。

上图中，绿色和橘色的客户端尽管紧跟在蓝色客户端之后到达服务器，也要等到服务器处理完蓝色客户端的请求。这时绿色客户端得到响应，橘色的还要等待一段时间。

多线程服务器会开启多个控制线程，让操作系统管理 CPU 的并发（使用多个 CPU 核心）。当客户端连接的时候，创建一个线程与之交互，而在主线程中，服务器能够接受其他的客户端连接。下图是该模式的时间轴：

每个客户端一个线程，在 C 语言里要用 pthread

这篇文章的 第一个示例代码 是一个简单的 “每个客户端一个线程” 的服务器，用 C 语言编写，使用了 phtreads API 用于实现多线程。这里是主循环代码：

while (1) {
  struct sockaddr_in peer_addr;
  socklen_t peer_addr_len = sizeof(peer_addr);

  int newsockfd =
      accept(sockfd, (struct sockaddr*)&peer_addr, &peer_addr_len);

  if (newsockfd < 0) {
    perror_die("ERROR on accept");
  }

  report_peer_connected(&peer_addr, peer_addr_len);
  pthread_t the_thread;

  thread_config_t* config = (thread_config_t*)malloc(sizeof(*config));
  if (!config) {
    die("OOM");
  }
  config->sockfd = newsockfd;
  pthread_create(&the_thread, NULL, server_thread, config);

  // 回收线程 —— 在线程结束的时候，它占用的资源会被回收
  // 因为主线程在一直运行，所以它比服务线程存活更久。
  pthread_detach(the_thread);
}

这是 server_thread 函数：

void* server_thread(void* arg) {
  thread_config_t* config = (thread_config_t*)arg;
  int sockfd = config->sockfd;
  free(config);

  // This cast will work for Linux, but in general casting pthread_id to an 这个类型转换在 Linux 中可以正常运行，但是一般来说将 pthread_id 类型转换成整形不便于移植代码
  // integral type isn't portable.
  unsigned long id = (unsigned long)pthread_self();
  printf("Thread %lu created to handle connection with socket %d\n", id,
         sockfd);
  serve_connection(sockfd);
  printf("Thread %lu done\n", id);
  return 0;
}

线程 “configuration” 是作为 thread_config_t 结构体进行传递的：

typedef struct { int sockfd; } thread_config_t;

主循环中调用的 pthread_create 产生一个新线程，然后运行 server_thread 函数。这个线程会在 server_thread 返回的时候结束。而在 serve_connection 返回的时候 server_thread 才会返回。serve_connection 和第一节完全一样。

第一节中我们用脚本生成了多个并发访问的客户端，观察服务器是怎么处理的。现在来看看多线程服务器的处理结果：

$ python3.6 simple-client.py  -n 3 localhost 9090
INFO:2017-09-20 06:31:56,632:conn1 connected...
INFO:2017-09-20 06:31:56,632:conn2 connected...
INFO:2017-09-20 06:31:56,632:conn0 connected...
INFO:2017-09-20 06:31:56,632:conn1 sending b'^abc$de^abte$f'
INFO:2017-09-20 06:31:56,632:conn2 sending b'^abc$de^abte$f'
INFO:2017-09-20 06:31:56,632:conn0 sending b'^abc$de^abte$f'
INFO:2017-09-20 06:31:56,633:conn1 received b'b'
INFO:2017-09-20 06:31:56,633:conn2 received b'b'
INFO:2017-09-20 06:31:56,633:conn0 received b'b'
INFO:2017-09-20 06:31:56,670:conn1 received b'cdbcuf'
INFO:2017-09-20 06:31:56,671:conn0 received b'cdbcuf'
INFO:2017-09-20 06:31:56,671:conn2 received b'cdbcuf'
INFO:2017-09-20 06:31:57,634:conn1 sending b'xyz^123'
INFO:2017-09-20 06:31:57,634:conn2 sending b'xyz^123'
INFO:2017-09-20 06:31:57,634:conn1 received b'234'
INFO:2017-09-20 06:31:57,634:conn0 sending b'xyz^123'
INFO:2017-09-20 06:31:57,634:conn2 received b'234'
INFO:2017-09-20 06:31:57,634:conn0 received b'234'
INFO:2017-09-20 06:31:58,635:conn1 sending b'25$^ab0000$abab'
INFO:2017-09-20 06:31:58,635:conn2 sending b'25$^ab0000$abab'
INFO:2017-09-20 06:31:58,636:conn1 received b'36bc1111'
INFO:2017-09-20 06:31:58,636:conn2 received b'36bc1111'
INFO:2017-09-20 06:31:58,637:conn0 sending b'25$^ab0000$abab'
INFO:2017-09-20 06:31:58,637:conn0 received b'36bc1111'
INFO:2017-09-20 06:31:58,836:conn2 disconnecting
INFO:2017-09-20 06:31:58,836:conn1 disconnecting
INFO:2017-09-20 06:31:58,837:conn0 disconnecting

实际上，所有客户端同时连接，它们与服务器的通信是同时发生的。

每个客户端一个线程的难点

尽管在现代操作系统中就资源利用率方面来看，线程相当的高效，但前一节中讲到的方法在高负载时却会出现纰漏。

想象一下这样的情景：很多客户端同时进行连接，某些会话持续的时间长。这意味着某个时刻服务器上有很多活跃的线程。太多的线程会消耗掉大量的内存和 CPU 资源，而仅仅是用于上下文切换 ^注1 。另外其也可视为安全问题：因为这样的设计容易让服务器成为 DoS 攻击 的目标 —— 上百万个客户端同时连接，并且客户端都处于闲置状态，这样耗尽了所有资源就可能让服务器宕机。

当服务器要与每个客户端通信，CPU 进行大量计算时，就会出现更严重的问题。这种情况下，容易想到的方法是减少服务器的响应能力 —— 只有其中一些客户端能得到服务器的响应。

因此，对多线程服务器所能够处理的并发客户端数做一些 速率限制 就是个明智的选择。有很多方法可以实现。最容易想到的是计数当前已经连接上的客户端，把连接数限制在某个范围内（需要通过仔细的测试后决定）。另一种流行的多线程应用设计是使用 线程池。

线程池

线程池 很简单，也很有用。服务器创建几个任务线程，这些线程从某些队列中获取任务。这就是“池”。然后每一个客户端的连接被当成任务分发到池中。只要池中有空闲的线程，它就会去处理任务。如果当前池中所有线程都是繁忙状态，那么服务器就会阻塞，直到线程池可以接受任务（某个繁忙状态的线程处理完当前任务后，变回空闲的状态）。

这里有个 4 线程的线程池处理任务的图。任务（这里就是客户端的连接）要等到线程池中的某个线程可以接受新任务。

非常明显，线程池的定义就是一种按比例限制的机制。我们可以提前设定服务器所能拥有的线程数。那么这就是并发连接的最多的客户端数 —— 其它的客户端就要等到线程空闲。如果我们的池中有 8 个线程，那么 8 就是服务器可以处理的最多的客户端并发连接数，哪怕上千个客户端想要同时连接。

那么怎么确定池中需要有多少个线程呢？通过对问题范畴进行细致的分析、评估、实验以及根据我们拥有的硬件配置。如果是单核的云服务器，答案只有一个；如果是 100 核心的多套接字的服务器，那么答案就有很多种。也可以在运行时根据负载动态选择池的大小 —— 我会在这个系列之后的文章中谈到这个东西。

使用线程池的服务器在高负载情况下表现出 性能退化 —— 客户端能够以稳定的速率进行连接，可能会比其它时刻得到响应的用时稍微久一点；也就是说，无论多少个客户端同时进行连接，服务器总能保持响应，尽最大能力响应等待的客户端。与之相反，每个客户端一个线程的服务器，会接收多个客户端的连接直到过载，这时它更容易崩溃或者因为要处理所有客户端而变得缓慢，因为资源都被耗尽了（比如虚拟内存的占用）。

在服务器上使用线程池

为了改变服务器的实现，我用了 Python，在 Python 的标准库中带有一个已经实现好的稳定的线程池。（concurrent.futures 模块里的 ThreadPoolExecutor） ^注2 。

服务器创建一个线程池，然后进入循环，监听套接字接收客户端的连接。用 submit 把每一个连接的客户端分配到池中：

pool = ThreadPoolExecutor(args.n)
sockobj = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sockobj.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sockobj.bind(('localhost', args.port))
sockobj.listen(15)

try:
    while True:
        client_socket, client_address = sockobj.accept()
        pool.submit(serve_connection, client_socket, client_address)
except KeyboardInterrupt as e:
    print(e)
    sockobj.close()

serve_connection 函数和 C 的那部分很像，与一个客户端交互，直到其断开连接，并且遵循我们的协议：

ProcessingState = Enum('ProcessingState', 'WAIT_FOR_MSG IN_MSG')

def serve_connection(sockobj, client_address):
    print('{0} connected'.format(client_address))
    sockobj.sendall(b'*')
    state = ProcessingState.WAIT_FOR_MSG

    while True:
        try:
            buf = sockobj.recv(1024)
            if not buf:
                break
        except IOError as e:
            break
        for b in buf:
            if state == ProcessingState.WAIT_FOR_MSG:
                if b == ord(b'^'):
                    state = ProcessingState.IN_MSG
            elif state == ProcessingState.IN_MSG:
                if b == ord(b'$'):
                    state = ProcessingState.WAIT_FOR_MSG
                else:
                    sockobj.send(bytes([b + 1]))
            else:
                assert False

    print('{0} done'.format(client_address))
    sys.stdout.flush()
    sockobj.close()

来看看线程池的大小对并行访问的客户端的阻塞行为有什么样的影响。为了演示，我会运行一个池大小为 2 的线程池服务器（只生成两个线程用于响应客户端）。

$ python3.6 threadpool-server.py -n 2

在另外一个终端里，运行客户端模拟器，产生 3 个并发访问的客户端：

$ python3.6 simple-client.py  -n 3 localhost 9090
INFO:2017-09-22 05:58:52,815:conn1 connected...
INFO:2017-09-22 05:58:52,827:conn0 connected...
INFO:2017-09-22 05:58:52,828:conn1 sending b'^abc$de^abte$f'
INFO:2017-09-22 05:58:52,828:conn0 sending b'^abc$de^abte$f'
INFO:2017-09-22 05:58:52,828:conn1 received b'b'
INFO:2017-09-22 05:58:52,828:conn0 received b'b'
INFO:2017-09-22 05:58:52,867:conn1 received b'cdbcuf'
INFO:2017-09-22 05:58:52,867:conn0 received b'cdbcuf'
INFO:2017-09-22 05:58:53,829:conn1 sending b'xyz^123'
INFO:2017-09-22 05:58:53,829:conn0 sending b'xyz^123'
INFO:2017-09-22 05:58:53,830:conn1 received b'234'
INFO:2017-09-22 05:58:53,831:conn0 received b'2'
INFO:2017-09-22 05:58:53,831:conn0 received b'34'
INFO:2017-09-22 05:58:54,831:conn1 sending b'25$^ab0000$abab'
INFO:2017-09-22 05:58:54,832:conn1 received b'36bc1111'
INFO:2017-09-22 05:58:54,832:conn0 sending b'25$^ab0000$abab'
INFO:2017-09-22 05:58:54,833:conn0 received b'36bc1111'
INFO:2017-09-22 05:58:55,032:conn1 disconnecting
INFO:2017-09-22 05:58:55,032:conn2 connected...
INFO:2017-09-22 05:58:55,033:conn2 sending b'^abc$de^abte$f'
INFO:2017-09-22 05:58:55,033:conn0 disconnecting
INFO:2017-09-22 05:58:55,034:conn2 received b'b'
INFO:2017-09-22 05:58:55,071:conn2 received b'cdbcuf'
INFO:2017-09-22 05:58:56,036:conn2 sending b'xyz^123'
INFO:2017-09-22 05:58:56,036:conn2 received b'234'
INFO:2017-09-22 05:58:57,037:conn2 sending b'25$^ab0000$abab'
INFO:2017-09-22 05:58:57,038:conn2 received b'36bc1111'
INFO:2017-09-22 05:58:57,238:conn2 disconnecting

回顾之前讨论的服务器行为：

1. 在顺序服务器中，所有的连接都是串行的。一个连接结束后，下一个连接才能开始。
2. 前面讲到的每个客户端一个线程的服务器中，所有连接都被同时接受并得到服务。

这里可以看到一种可能的情况：两个连接同时得到服务，只有其中一个结束连接后第三个才能连接上。这就是把线程池大小设置成 2 的结果。真实用例中我们会把线程池设置的更大些，取决于机器和实际的协议。线程池的缓冲机制就能很好理解了 —— 我 几个月前 更详细的介绍过这种机制，关于 Clojure 的 core.async 模块。

总结与展望

这篇文章讨论了在服务器中，用多线程作并发的方法。每个客户端一个线程的方法最早提出来，但是实际上却不常用，因为它并不安全。

线程池就常见多了，最受欢迎的几个编程语言有良好的实现（某些编程语言，像 Python，就是在标准库中实现）。这里说的使用线程池的服务器，不会受到每个客户端一个线程的弊端。

然而，线程不是处理多个客户端并行访问的唯一方法。下一节中我们会看看其它的解决方案，可以使用异步处理，或者事件驱动的编程。

• 注1：老实说，现代 Linux 内核可以承受足够多的并发线程 —— 只要这些线程主要在 I/O 上被阻塞。这里有个示例程序，它产生可配置数量的线程，线程在循环体中是休眠的，每 50 ms 唤醒一次。我在 4 核的 Linux 机器上可以轻松的产生 10000 个线程；哪怕这些线程大多数时间都在睡眠，它们仍然消耗一到两个核心，以便实现上下文切换。而且，它们占用了 80 GB 的虚拟内存（Linux 上每个线程的栈大小默认是 8MB）。实际使用中，线程会使用内存并且不会在循环体中休眠，因此它可以非常快的占用完一个机器的内存。
• 注2：自己动手实现一个线程池是个有意思的练习，但我现在还不想做。我曾写过用来练手的 针对特殊任务的线程池。是用 Python 写的；用 C 重写的话有些难度，但对于经验丰富的程序员，几个小时就够了。

via: https://eli.thegreenplace.net/2017/concurrent-servers-part-2-threads/

作者：Eli Bendersky 译者：GitFuture 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

这是关于并发网络服务器编程的第一篇教程。我计划测试几个主流的、可以同时处理多个客户端请求的服务器并发模型，基于可扩展性和易实现性对这些模型进行评判。所有的服务器都会监听套接字连接，并且实现一些简单的协议用于与客户端进行通讯。

该系列的所有文章：

• 第一节 - 简介
• 第二节 - 线程
• 第三节 - 事件驱动

协议

该系列教程所用的协议都非常简单，但足以展示并发服务器设计的许多有趣层面。而且这个协议是 有状态的 —— 服务器根据客户端发送的数据改变内部状态，然后根据内部状态产生相应的行为。并非所有的协议都是有状态的 —— 实际上，基于 HTTP 的许多协议是无状态的，但是有状态的协议也是很常见，值得认真讨论。

在服务器端看来，这个协议的视图是这样的：

总之：服务器等待新客户端的连接；当一个客户端连接的时候，服务器会向该客户端发送一个 * 字符，进入“等待消息”的状态。在该状态下，服务器会忽略客户端发送的所有字符，除非它看到了一个 ^ 字符，这表示一个新消息的开始。这个时候服务器就会转变为“正在通信”的状态，这时它会向客户端回送数据，把收到的所有字符的每个字节加 1 回送给客户端 ^注1 。当客户端发送了 $ 字符，服务器就会退回到等待新消息的状态。^ 和 $ 字符仅仅用于分隔消息 —— 它们不会被服务器回送。

每个状态之后都有个隐藏的箭头指向 “等待客户端” 状态，用于客户端断开连接。因此，客户端要表示“我已经结束”的方法很简单，关掉它那一端的连接就好。

显然，这个协议是真实协议的简化版，真实使用的协议一般包含复杂的报文头、转义字符序列（例如让消息体中可以出现 $ 符号），额外的状态变化。但是我们这个协议足以完成期望。

另一点：这个系列是介绍性的，并假设客户端都工作的很好（虽然可能运行很慢）；因此没有设置超时，也没有设置特殊的规则来确保服务器不会因为客户端的恶意行为（或是故障）而出现阻塞，导致不能正常结束。

顺序服务器

这个系列中我们的第一个服务端程序是一个简单的“顺序”服务器，用 C 进行编写，除了标准的 POSIX 中用于套接字的内容以外没有使用其它库。服务器程序是顺序，因为它一次只能处理一个客户端的请求；当有客户端连接时，像之前所说的那样，服务器会进入到状态机中，并且不再监听套接字接受新的客户端连接，直到当前的客户端结束连接。显然这不是并发的，而且即便在很少的负载下也不能服务多个客户端，但它对于我们的讨论很有用，因为我们需要的是一个易于理解的基础。

这个服务器的完整代码在这里；接下来，我会着重于一些重点的部分。main 函数里面的外层循环用于监听套接字，以便接受新客户端的连接。一旦有客户端进行连接，就会调用 serve_connection，这个函数中的代码会一直运行，直到客户端断开连接。

顺序服务器在循环里调用 accept 用来监听套接字，并接受新连接：

while (1) {
  struct sockaddr_in peer_addr;
  socklen_t peer_addr_len = sizeof(peer_addr);

  int newsockfd =
      accept(sockfd, (struct sockaddr*)&peer_addr, &peer_addr_len);

  if (newsockfd < 0) {
    perror_die("ERROR on accept");
  }

  report_peer_connected(&peer_addr, peer_addr_len);
  serve_connection(newsockfd);
  printf("peer done\n");
}

accept 函数每次都会返回一个新的已连接的套接字，然后服务器调用 serve_connection；注意这是一个 阻塞式 的调用 —— 在 serve_connection 返回前，accept 函数都不会再被调用了；服务器会被阻塞，直到客户端结束连接才能接受新的连接。换句话说，客户端按 顺序 得到响应。

这是 serve_connection 函数：

typedef enum { WAIT_FOR_MSG, IN_MSG } ProcessingState;

void serve_connection(int sockfd) {
  if (send(sockfd, "*", 1, 0) < 1) {
    perror_die("send");
  }

  ProcessingState state = WAIT_FOR_MSG;

  while (1) {
    uint8_t buf[1024];
    int len = recv(sockfd, buf, sizeof buf, 0);
    if (len < 0) {
      perror_die("recv");
    } else if (len == 0) {
      break;
    }

    for (int i = 0; i < len; ++i) {
      switch (state) {
      case WAIT_FOR_MSG:
        if (buf[i] == '^') {
          state = IN_MSG;
        }
        break;
      case IN_MSG:
        if (buf[i] == '$') {
          state = WAIT_FOR_MSG;
        } else {
          buf[i] += 1;
          if (send(sockfd, &buf[i], 1, 0) < 1) {
            perror("send error");
            close(sockfd);
            return;
          }
        }
        break;
      }
    }
  }

  close(sockfd);
}

它完全是按照状态机协议进行编写的。每次循环的时候，服务器尝试接收客户端的数据。收到 0 字节意味着客户端断开连接，然后循环就会退出。否则，会逐字节检查接收缓存，每一个字节都可能会触发一个状态。

recv 函数返回接收到的字节数与客户端发送消息的数量完全无关（^...$ 闭合序列的字节）。因此，在保持状态的循环中遍历整个缓冲区很重要。而且，每一个接收到的缓冲中可能包含多条信息，但也有可能开始了一个新消息，却没有显式的结束字符；而这个结束字符可能在下一个缓冲中才能收到，这就是处理状态在循环迭代中进行维护的原因。

例如，试想主循环中的 recv 函数在某次连接中返回了三个非空的缓冲：

1. ^abc$de^abte$f
2. xyz^123
3. 25$^ab$abab

服务端返回的是哪些数据？追踪代码对于理解状态转变很有用。（答案见 ^{注 2} ）

多个并发客户端

如果多个客户端在同一时刻向顺序服务器发起连接会发生什么事情？

服务器端的代码（以及它的名字 “顺序服务器”）已经说的很清楚了，一次只能处理 一个 客户端的请求。只要服务器在 serve_connection 函数中忙于处理客户端的请求，就不会接受别的客户端的连接。只有当前的客户端断开了连接，serve_connection 才会返回，然后最外层的循环才能继续执行接受其他客户端的连接。

为了演示这个行为，该系列教程的示例代码 包含了一个 Python 脚本，用于模拟几个想要同时连接服务器的客户端。每一个客户端发送类似之前那样的三个数据缓冲 ^注3 ，不过每次发送数据之间会有一定延迟。

客户端脚本在不同的线程中并发地模拟客户端行为。这是我们的序列化服务器与客户端交互的信息记录：

$ python3.6 simple-client.py  -n 3 localhost 9090
INFO:2017-09-16 14:14:17,763:conn1 connected...
INFO:2017-09-16 14:14:17,763:conn1 sending b'^abc$de^abte$f'
INFO:2017-09-16 14:14:17,763:conn1 received b'b'
INFO:2017-09-16 14:14:17,802:conn1 received b'cdbcuf'
INFO:2017-09-16 14:14:18,764:conn1 sending b'xyz^123'
INFO:2017-09-16 14:14:18,764:conn1 received b'234'
INFO:2017-09-16 14:14:19,764:conn1 sending b'25$^ab0000$abab'
INFO:2017-09-16 14:14:19,765:conn1 received b'36bc1111'
INFO:2017-09-16 14:14:19,965:conn1 disconnecting
INFO:2017-09-16 14:14:19,966:conn2 connected...
INFO:2017-09-16 14:14:19,967:conn2 sending b'^abc$de^abte$f'
INFO:2017-09-16 14:14:19,967:conn2 received b'b'
INFO:2017-09-16 14:14:20,006:conn2 received b'cdbcuf'
INFO:2017-09-16 14:14:20,968:conn2 sending b'xyz^123'
INFO:2017-09-16 14:14:20,969:conn2 received b'234'
INFO:2017-09-16 14:14:21,970:conn2 sending b'25$^ab0000$abab'
INFO:2017-09-16 14:14:21,970:conn2 received b'36bc1111'
INFO:2017-09-16 14:14:22,171:conn2 disconnecting
INFO:2017-09-16 14:14:22,171:conn0 connected...
INFO:2017-09-16 14:14:22,172:conn0 sending b'^abc$de^abte$f'
INFO:2017-09-16 14:14:22,172:conn0 received b'b'
INFO:2017-09-16 14:14:22,210:conn0 received b'cdbcuf'
INFO:2017-09-16 14:14:23,173:conn0 sending b'xyz^123'
INFO:2017-09-16 14:14:23,174:conn0 received b'234'
INFO:2017-09-16 14:14:24,175:conn0 sending b'25$^ab0000$abab'
INFO:2017-09-16 14:14:24,176:conn0 received b'36bc1111'
INFO:2017-09-16 14:14:24,376:conn0 disconnecting

这里要注意连接名：conn1 是第一个连接到服务器的，先跟服务器交互了一段时间。接下来的连接 conn2 —— 在第一个断开连接后，连接到了服务器，然后第三个连接也是一样。就像日志显示的那样，每一个连接让服务器变得繁忙，持续了大约 2.2 秒的时间（这实际上是人为地在客户端代码中加入的延迟），在这段时间里别的客户端都不能连接。

显然，这不是一个可扩展的策略。这个例子中，客户端中加入了延迟，让服务器不能处理别的交互动作。一个智能服务器应该能处理一堆客户端的请求，而这个原始的服务器在结束连接之前一直繁忙（我们将会在之后的章节中看到如何实现智能的服务器）。尽管服务端有延迟，但这不会过度占用 CPU；例如，从数据库中查找信息（时间基本上是花在连接到数据库服务器上，或者是花在硬盘中的本地数据库）。

总结及期望

这个示例服务器达成了两个预期目标：

1. 首先是介绍了问题范畴和贯彻该系列文章的套接字编程基础。
2. 对于并发服务器编程的抛砖引玉 —— 就像之前的部分所说，顺序服务器还不能在非常轻微的负载下进行扩展，而且没有高效的利用资源。

在看下一篇文章前，确保你已经理解了这里所讲的服务器/客户端协议，还有顺序服务器的代码。我之前介绍过了这个简单的协议；例如 串行通信分帧 和 用协程来替代状态机。要学习套接字网络编程的基础，Beej 的教程 用来入门很不错，但是要深入理解我推荐你还是看本书。

如果有什么不清楚的，请在评论区下进行评论或者向我发送邮件。深入理解并发服务器！

• 注1：状态转变中的 In/Out 记号是指 Mealy machine。
• 注2：回应的是 bcdbcuf23436bc。
• 注3：这里在结尾处有一点小区别，加了字符串 0000 —— 服务器回应这个序列，告诉客户端让其断开连接；这是一个简单的握手协议，确保客户端有足够的时间接收到服务器发送的所有回复。

via: https://eli.thegreenplace.net/2017/concurrent-servers-part-1-introduction/

作者：Eli Bendersky 译者：GitFuture 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

IBM 的 Ken Parmelee 说：“微服务和 API 是产品，我们需要以这种方式思考。”

领导 IBM 的 API 网关和 Big Blue 开源项目的的 Ken Parmelee 对以开源方式 “进攻” API 以及如何创建微服务和使其伸缩有一些思考。

Parmelee 说：“微服务和 API 是产品，我们需要以这种方式思考这些问题。当你开始这么做，人们依赖它作为它们业务的一部分。这是你在这个领域所做的关键方面。”

他在最近的北欧 APIs 2017 平台峰会登上讲台，并挑战了一些流行的观念。

“快速失败不是一个很好的概念。你想在第一场比赛中获得一些非常棒的东西。这并不意味着你需要花费大量的时间，而是应该让它变得非常棒，然后不断的发展和改进。如果一开始真的很糟糕，人们就不会想要用你。”

他谈及包括 OpenWhisk 在内的 IBM 现代无服务器架构，这是一个 IBM 和 Apache 之间的开源伙伴关系。 云优先的基于分布式事件的编程服务是这两年多来重点关注这个领域的成果；IBM 是该领域领先的贡献者，它是 IBM 云服务的基础。它提供基础设施即服务（IaaS）、自动缩放、为多种语言提供支持、用户只需支付实际使用费用即可。这次旅程充满了挑战，因为他们发现服务器操作需要安全、并且需要轻松 —— 匿名访问、缺少使用路径、固定的 URL 格式等。

任何人都可以在 30 秒内在 https://console.bluemix.net/openwhisk/ 上尝试这些无服务器 API。“这听起来很有噱头，但这是很容易做到的。我们正在结合 Cloud Foundry 中完成的工作，并在 OpenWhisk 下的 Bluemix 中发布了它们，以提供安全性和可扩展性。”

他说：“灵活性对于微服务也是非常重要的。 当你使用 API 在现实世界中工作时，你开始需要跨云进行扩展。”这意味着从你的内部云走向公共云，并且“对你要怎么做有一个实在的概念很重要”。

在思考“任何云概念”的时候，他警告说，不是“将其放入一个 Docker 容器，并到处运行。这很棒，但需要在这些环境中有效运行。Docker 和 Kubernetes 有提供了很多帮助，但是你想要你的操作方式付诸实施。” 提前考虑 API 的使用，无论是在内部运行还是扩展到公有云并可以公开调用 - 你需要有这样的“架构观”，他补充道。

Parmelee 说：“我们都希望我们所创造的有价值，并被广泛使用。” API 越成功，将其提升到更高水平的挑战就越大。

API 是微服务或“服务间”的组成部分。

他说，API 的未来是原生云的 - 无论你从哪里开始。关键因素是可扩展性，简化后端管理，降低成本，避免厂商锁定。

你可以在下面或在 YouTube 观看他整整 23 分钟的演讲。

via: http://superuser.openstack.org/articles/deploy-multi-cloud-serverless-cloud-foundry-apis-scale/

作者：Superuser 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Android 模拟器是否改善到足以取代 Genymotion

一直以来有关于选择 android 模拟器或者 Genymotion 的争论，我看到很多讨论最后以赞成 Genymotion 而告终。我根据我周围最常见的情况收集了一些数据，基于此，我将连同 Genymotion 全面评估 android 模拟器。

结论剧透：配置正确时，Android 模拟器比 Genymotion 快。

使用带 Google API 的 x86（32位）镜像、3GB RAM、四核CPU。

• 哈，很高兴我们知道了最终结果
• 现在，让我们深入

免责声明：我已经测试了我看到的一般情况，即运行测试。所有的基准测试都是在 2015 年中期的 MacBook Pro 上完成的。无论何时我提及 Genymotion 指的都是 Genymotion Desktop。他们还有其他产品，如 Genymotion on Cloud＆Genymotion on Demand，但这里没有考虑。我不是说 Genymotion 是不合适的，但运行测试比某些 Android 模拟器慢。

关于这个问题的一点背景，然后我们将转到具体内容上去。

过去：我有一些基准测试，继续下去。

很久以前，Android 模拟器是唯一的选择。但是它们太慢了，这是架构改变的原因。对于在 x86 机器上运行的 ARM 模拟器，你能期待什么？每个指令都必须从 ARM 转换为 x86 架构，这使得它的速度非常慢。

随之而来的是 Android 的 x86 镜像，随着它们摆脱了 ARM 到 x86 平台转化，速度更快了。现在，你可以在 x86 机器上运行 x86 Android 模拟器。

• 问题解决了！！！
• 没有！

Android 模拟器仍然比人们想要的慢。随后出现了 Genymotion，这是一个在 virtual box 中运行的 Android 虚拟机。与在 qemu 上运行的普通老式 android 模拟器相比，它相当稳定和快速。

我们来看看今天的情况。

我在持续集成的基础设施上和我的开发机器上使用 Genymotion。我手头的任务是摆脱持续集成基础设施和开发机器上使用 Genymotion。

• 你问为什么？
• 授权费钱。

在快速看了一下以后，这似乎是一个愚蠢的举动，因为 Android 模拟器的速度很慢而且有 bug，它们看起来适得其反，但是当你深入的时候，你会发现 Android 模拟器是优越的。

我们的情况是对它们进行集成测试（主要是 espresso）。我们的应用程序中只有 1100 多个测试，Genymotion 需要大约 23 分钟才能运行所有测试。

在 Genymotion 中我们面临的另一些问题是：

• 有限的命令行工具（GMTool）。
• 由于内存问题，它们需要定期重新启动。这是一个手动任务，想象在配有许多机器的持续集成基础设施上进行这些会怎样。

进入 Android 模拟器

首先是尝试在它给你这么多的选择中设置一个，这会让你会觉得你在赛百味餐厅一样。最大的问题是 x86 或 x86\_64 以及是否有 Google API。

我用这些组合做了一些研究和基准测试，这是我们所想到的。

鼓声……

• 比赛的获胜者是带 Google API 的 x86
• 但是如何胜利的？为什么？

嗯，我会告诉你每一个问题。

x86\_64 比 x86 慢

• 你问慢多少。
• 28.2% 多！！！

使用 Google API 的模拟器更加稳定，没有它们容易崩溃。

这使我们得出结论：最好的是带 Google API 的x86。

在我们抛弃 Genymotion 开始使用模拟器之前。有下面几点重要的细节。

• 我使用的是带 Google API 的 Nexus 5 镜像。
• 我注意到，给模拟器较少的内存会造成了很多 Google API 崩溃。所以为模拟器设定了 3GB 的 RAM。
• 模拟器有四核。
• HAXM 安装在主机上。

基准测试的时候到了

从基准测试上你可以看到除了 Geekbench4，Android 模拟器都击败了 Genymotion，我感觉更像是virtual box 击败了 qemu。

欢呼模拟器之王

我们现在有更快的测试执行时间、更好的命令行工具。最新的 Android 模拟器创下的新的记录。更快的启动时间之类。

Goolgle 一直努力让

Android 模拟器变得更好

如果你没有在使用 Android 模拟器。我建议你重新试下，可以节省一些钱。

我尝试的另一个但是没有成功的方案是在 AWS 上运行 Android-x86 镜像。我能够在 vSphere ESXi Hypervisor 中运行它，但不能在 AWS 或任何其他云平台上运行它。如果有人知道原因，请在下面评论。

PS：VMWare 现在可以在 AWS 上使用，在 AWS 上使用 Android-x86 毕竟是有可能的。

作者简介：

嗨，我的名字是 Sumit Gupta。我是来自印度古尔冈的软件/应用/网页开发人员。我做这个是因为我喜欢技术，并且一直迷恋它。我已经工作了 3 年以上，但我还是有很多要学习。他们不是说如果你有知识，让别人点亮他们的蜡烛。

当在编译时，我阅读很多文章，或者听音乐。

如果你想联系，下面是我的社交信息和 email。

via: https://www.plightofbyte.com/android/2017/09/03/genymotion-vs-android-emulator/

作者：Sumit Gupta 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出