本篇为高并发程序设计系列第二篇，主要内容为：

多进程并发模型

一：模型简介

“进程是操作系统提供的最古老的也是最重要的抽象概念之一。即使可以利用的CPU只有一个，但它们也支持并发操作的能力。它们将一个单独的CPU变换成多个虚拟的CPU。没有进程的抽象，现代计算将不复存在。”

摘录来自: Andrews Tanenbaum. “现代操作系统（原书第3版） (计算机科学丛书)。”

该系列上篇博文提到过，因为CPU的速度越来越快，更多的进程倾向为I/O密集型。而对于I/O密集型进程来说，如果只启动单个进程，则CPU的大部分时间因为等待I/O完成而白白浪费。所以即便只有一个单核CPU，通过启动多个进程来提供服务，可以更高效地利用CPU的计算能力，并发处理多个任务。

另外，如果是在一个多核环境，启动多个进程可以充分利用多核，进行并行运算。

基于以上两个原因，多进程并发模型自然而来。

本篇为高并发程序设计系列第一篇，主要内容为：

1. 高并发程序设计相关概念
2. 高并发与高吞吐率讨论

一：基本概念

1.并发与并行

并发（concurrency）:

逻辑上具备同时处理多个任务的能力

并行（parallesim）：

物理上在同一时刻执行多个并发任务

我们通常会说程序是并发设计的，也就是说它允许多个任务同时执行，但实际上并不一定真在同一时刻发生。在单核处理器上，它们能以间隔方式切换执行。而并行则依赖多核处理器等物理设备，让多个任务真正在同一时刻执行，它代表了当前程序运行状态。简单点说，并行是并发设计的理想执行模式。《Go语言学习笔记》

并发示例：

多道程序设计中，CPU划分时间片，轮流执行每个请求任务，时间片到期后，换到下一个

什么是注册中心

注册中心可以说是 一个“通讯录”，它记录了服务和服务地址的映射关系。在服务启动时，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址，进行调用。

常见的注册中心及对比

业界有许多成熟的注册中心实现，下图中对一些常见的注册中心做一对比：

ZooKeeper是一款经典的服务注册中心产品（虽然它最初的定位并不在于此），在很长一段时间里，它是国人在提起RPC服务注册中心时心里想到的唯一选择，这很大程度上与Dubbo在中国的普及程度有关。

Consul和Eureka都出现于2014年，Consul在设计上把很多分布式服务治理上要用到的功能都包含在内，可以支持服务注册、健康检查、配置管理、Service Mesh等。而Eureka则借着微服务概念的流行，与SpringCloud生态的深度结合，也获取了大量的用户。

去年开源的Nacos，则携带着阿里巴巴大规模服务生产经验，试图在服务注册和配置管理这个市场上，提供给用户一个新的选择。

而本文要介绍的discovery是Eureka的go语言实现版本，由bilibili开发并开源。

原文:gRPC Name Resolution
翻译整理: 陈进涛 译文链接:【译】gRPC名称解析。 转载请保留原文出处和译文译者和出处。

概览

gRPC支持将DNS作为默认名称系统。 在各种部署中使用了许多其他类型的名称系统。 我们支持足够通用的API，以支持各种名称系统和名称的相应语法。 各种语言的gRPC客户端库将提供一种插件机制，以便可以插入用于不同名称系统的解析器。

详细设计

名称语法

用于 gRPC 通道构造的完全限定的自包含名称系统使用 RFC 3986中定义的URI 语法.

URI scheme指示要使用的解析程序插件。 如果未指定scheme前缀或scheme未知，则默认使用dns scheme。URI路径指示要解析的名称。

大多数gRPC实现都支持以下URI schemes：

一：信号概念

在计算机科学中，信号（英语：Signals）是Unix、类Unix以及其他POSIX兼容的操作系统中进程间通讯的一种有限制的方式。它是一种异步的通知机制，用来提醒进程一个事件已经发生。当一个信号发送给一个进程，操作系统中断了进程正常的控制流程，此时，任何非原子操作都将被中断。如果进程定义了信号的处理函数，那么它将被执行，否则就执行默认的处理函数。

二：常见信号梳理

在linux系统中执行kill -l可以列出所有当前系统支持的信号列表：

原文:Concepts of Job Control

来源：

The GNU C Library Reference Manual, for version 2.32.

Copyright © 1993–2020 Free Software Foundation, Inc.

翻译整理: 陈进涛 译文链接:【译】控制终端概念。 转载请保留原文出处和译文译者和出处。

28.1控制终端概念

交互式shell的基本用途是从用户终端读取命令，并创建进程来执行这些命令指定的程序。这样做的方式是使用fork (参考 Creating a Process) and exec (参考 Executing a File).

一个简单的命令可能只启动一个进程，但是一个命令使用多个进程也是很常见的。如果在shell命令中使用’ | ‘操作符，则显式地请求几个程序在它们自己的进程中。但即使只运行一个程序，它也可以在内部使用多个进程。例如，一个编译命令，如’ cc -c foo。通常使用四个进程(尽管通常在任何时候只有两个)。如果运行make，它的任务是在单独的进程中运行其他程序。

属于单个命令的进程称为进程组或作业。这就是为什么你可以同时操作它们所有。 例如，输入C-c发送信号SIGINT来终止前台进程组中的所有进程。

会话是一组更大的进程。通常，来自单个登录的所有进程都属于同一个会话。

每个进程都属于一个进程组。当一个进程被创建时，它将成为与其父进程相同的进程组和会话的成员。您可以使用setpgid函数将其放在另一个进程组中，前提是该进程组属于同一会话。

将进程放入不同会话的唯一方法是使用setsid函数使其成为新会话的初始进程或会话首进程（session leader）。这也将会话首进程放到一个新的进程组中，并且您不能再次将其移出该进程组。

通常，新的会话是由系统登录程序创建的，会话领导者是运行用户登录shell的进程。

支持作业控制的shell必须安排控制哪一个作业可以在任何时候使用终端。否则，可能会有多个作业试图同时从终端读取数据，并且搞不清楚应该由哪个进程接收用户输入的信息。为了防止这种情况发生，shell必须使用本章中描述的协议与终端驱动程序合作。

shell一次只允许一个进程组无限制地访问控制终端。这被称为控制终端上的前台作业。由shell管理的、正在执行而不访问终端的其他进程组称为后台作业。

如果后台作业需要从其控制终端读取数据，则终端驱动程序会停止该作业;如果设置了TOSTOP模式，写入也一样。用户可以通过键入SUSP字符(参见特殊字符)来停止前台作业，程序可以通过发送SIGSTOP信号来停止任何作业。shell负责注意作业何时停止，向用户通知它们，并提供机制，允许用户以交互方式继续停止的作业，并在前台和后台之间切换作业。

查看 Access to the Terminal, 以获取关于控制终端 I/O 的更多信息.

原文:Load Balancing in gRPC June 15, 2017 makdharma, Google
翻译整理: 陈进涛 译文链接:【译】gRPC负载均衡。 转载请保留原文出处和译文译者和出处。

这篇文章描述了在部署gRPC时看到的各种负载平衡场景。如果您使用具有多个后端的gRPC，则此文档适合您。

大规模gRPC部署通常具有许多相同的后端实例和许多客户端。 每个服务器都有一定的容量。 负载平衡用于在可用服务器之间最佳地分配来自客户端的负载。

为何选用gRPC?

gRPC是在HTTP/2之上实现的现代RPC协议。HTTP/2是一个第7层(应用层)协议，运行在TCP协议(第4层-传输层)之上，TCP协议运行在IP协议(第3层-网络层)之上。与传统的HTTP/REST/JSON机制相比，gRPC有许多优点，例如:

1. 二进制协议（HTTP/2）
2. 在一个连接上多路复用多个请求(HTTP/2)
3. 协议头压缩(HTTP/2)
4. 强类型服务和消息定义(Protobuf)
5. 多种语言的惯用客户端/服务器库实现

此外，gRPC与生态系统组件无缝集成，例如服务发现，名称解析器，负载平衡器，跟踪和监视等。

负载均衡选项

代理模式还是客户端模式？

注意：代理负载平衡在某些文献中也称为服务器端负载平衡

原文:Load Balancing in gRPC
翻译整理: 陈进涛 译文链接:【译】gRPC负载均衡。 转载请保留原文出处和译文译者和出处。

范围

这篇文档解释了gRPC中的负载均衡设计

背景

基于每次调用的负载均衡

值得注意的是，gRPC中的负载平衡是基于每个调用，而不是基于每个连接。换句话说，即使所有请求都来自一个客户端，我们仍然希望它们在所有服务器上实现负载平衡。

负载均衡方法

在讨论gRPC细节之前，我们先探讨一些实现负载平衡的常用方法。

UNIX环境高级编程第九章有如下一道习题

9.2 编写一段程序调用fork并使子进程建立一个新的会话。验证子进程变成了进程组组长且不再有控制终端。

下边给出博主的解答，仅供参考。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

void
main()
{
    pid_t   pid, sid, gid;
    if((pid = fork()) < 0) {
        perror("fork error");
    } else if (pid > 0) { /*parent*/
        if((open("/dev/tty", 0)) == -1) {
            perror("没有控制终端，open /dev/tty 失败");
        } else {
            printf("父进程有控制终端，open /dev/tty 成功\n");
        }
        exit(0);
    } else { /*child*/
        if((sid = setsid()) == (pid_t) -1) {
            perror("setsid error");
        }
        if((gid = getpgrp()) == getpid()) {
            printf("子进程成为进程组组长\n");
        }
        //如果当前进程有控制终端(Controlling Terminal)的话，那么/dev/tty就是当前进程的控制终端的设备特殊文件
        if((open("/dev/tty", 0)) == -1) {
            perror("子进程没有控制终端，open /dev/tty 失败");
        }
    }
}

1.什么是微服务？

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。

2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通讯。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力，服务可以用不同的编程语言与数据库等元件实作[1]。

2.解决了什么问题？

2.1 传统的WEB应用核心