Tsing Wind - 清风徐来水波不兴

2021年度计划

Thu, 25 Mar 2021 07:59:41 +0800

今年的计划：

http2
- 查看http2(翻译)的RFC
- 在fasthttp中实现http2功能
- 学习使用gRPC
工具
- 实现http压测工具httpit
- 实现hping
- 实现tcping
幼儿园
- 阅读
- 识中文字
健康
- 保护眼睛
- 坚持锻炼
未完待续

golang调度器笔记

Fri, 27 Nov 2020 08:25:05 +0800

CPU寄存器

汇编代码所做的工作就是把数据在内存和寄存器中搬来搬去或做一些基础的数学和逻辑运算。

通用寄存器：rax, rbx, rcx, rdx, rsi, rdi, rbp, rsp, r8, r9, r10, r11, r12, r13, r14, r15寄存器。CPU对这16个通用寄存器的用途没有做特殊规定，程序员和编译器可以自定义其用途。rsp 栈顶寄存器和rbp栈基址寄存器:这两个寄存器都跟函数调用栈有关，其中rsp寄存器一般用来存放函数调用栈的栈顶地址，而rbp寄存器通常用来存放函数的栈帧起始地址，编译器一般使用这两个寄存器加一定偏移的方式来访问函数局部变量或函数参数。
程序计数寄存器（PC寄存器，有时也叫IP寄存器）：rip寄存器。它用来存放下一条即将执行的指令的地址，这个寄存器决定了程序的执行流程；
段寄存器：fs和gs寄存器。一般用它来实现线程本地存储（TLS），比如AMD64 linux平台下go语言和pthread都使用fs寄存器来实现系统线程的TLS，在本章线程本地存储一节和第二章详细分析goroutine调度器的时候我们可以分别看到Linux平台下Pthread线程库和go是如何使用fs寄存器的。

内存

内存中的每个字节都有一个地址
任何大于一个字节的变量在内存中都存储在相邻连续的的几个内存单元之中；
大端存储模式指数据的高字节保存在内存的低地址中，低字节保存在内存的高地址中；小端存储模式指数据的高字节保存在内存的高地址中，低字节保存在内存的低地址中。

函数调用栈

进程在内存中的布局主要分为4个区域：代码区，数据区，堆和栈。在详细讨论栈之前，先来简单介绍一下其它区域。

代码区，包括能被CPU执行的机器代码（指令）和只读数据比如字符串常量，程序一旦加载完成代码区的大小就不会再变化了。
数据区，包括程序的全局变量和静态变量（c语言有静态变量，而go没有），与代码区一样，程序加载完毕后数据区的大小也不会发生改变。
堆，程序运行时动态分配的内存都位于堆中，这部分内存由内存分配器负责管理。该区域的大小会随着程序的运行而变化，即当我们向堆请求分配内存但分配器发现堆中的内存不足时，它会向操作系统内核申请向高地址方向扩展堆的大小，而当我们释放内存把它归还给堆时如果内存分配器发现剩余空闲内存太多则又会向操作系统请求向低地址方向收缩堆的大小。从这个内存申请和释放流程可以看出，我们从堆上分配的内存用完之后必须归还给堆，否则内存分配器可能会反复向操作系统申请扩展堆的大小从而导致堆内存越用越多，最后出现内存不足，这就是所谓的内存泄漏。值的一提的是传统的c/c++代码就必须小心处理内存的分配和释放，而在go语言中，有垃圾回收器帮助我们，所以程序员只管申请内存，而不用管内存的释放，这大大降低了程序员的心智负担，这不光是提高了程序员的生产力，更重要的是还会减少很多bug的产生。

函数调用栈

函数调用栈简称栈，在程序运行过程中，不管是函数的执行还是函数调用，栈都起着非常重要的作用，它主要被用来：

保存函数的局部变量；
向被调用函数传递参数；
返回函数的返回值；
保存函数的返回地址。返回地址是指从被调用函数返回后调用者应该继续执行的指令地址，在汇编指令一节介绍call指令时我们将会对返回地址做更加详细的说明。

每个函数在执行过程中都需要使用一块栈内存用来保存上述这些值，我们称这块栈内存为某函数的栈帧(stack frame)。

寄存器rbp和rsp始终指向正在执行的函数的栈帧。

rbp，一般用来指向函数栈帧的起始位置
rsp，始终指向函数调用栈栈顶

说明

调用函数时，参数和返回值都是存放在调用者的栈帧之中，而不是在被调函数之中；
假如目前正在执行C函数，且函数调用链为A()->B()->C()，所以以栈帧为单位来看的话，C函数的栈帧目前位于栈顶；
CPU硬件寄存器rsp指向整个栈的栈顶，当然它也指向C函数的栈帧的栈顶，而rbp寄存器指向的是C函数栈帧的起始位置；
每个函数的栈帧大小可能都不同，因为不同的函数局部变量的个数以及所占内存的大小都不尽相同；
有些编译器比如gcc会把参数和返回值放在寄存器中而不是栈中，go语言中函数的参数和返回值都是放在栈上的；

汇编指令

里先对AT&T格式的汇编指令格式做一个简要的说明：

AT&T格式的汇编指令中，寄存器名需要加%作为前缀；
有2个操作数的指令中，第一个操作数是源操作数，第二个是目的操作数。例如 mov %eax,%esi，这条指令表示把eax寄存器中的值拷贝给esi；
立即操作数需要加上$符号做前缀，如 “mov $0x1 %rdi” 这条指令中第一个操作数不是寄存器，也不是内存地址，而是直接写在指令中的一个常数，这种操作数叫做立即操作数。这条指令表示把数值0x1放入rdi寄存器中。
寄存器间接寻址的格式为 offset(%register)，如果offset为0，则可以略去偏移不写直接写成(%register)。何为间接寻址呢？其实就是指指令中的寄存器并不是真正的源操作数或目的操作数，寄存器的值是一个内存地址，这个地址对应的内存才是真正的源或目的操作数，比如 mov %rax, (%rsp)这条指令，第二个操作数(%rsp)中的寄存器的名字用括号括起来了，表示间接寻址，rsp的值是一个内存地址，这条指令的真实意图是把rax寄存器中的值赋值给rsp寄存器的值（内存地址）对应的内存，rsp寄存器本身的值不会被修改，作为比较，我们看一下 mov %rax, %rsp 这条指令，这里第二个操作数仅仅少了个括号，变成了直接寻址，意思完全不一样了，这条指令的意思是把rax的值赋给rsp，这样rsp寄存器的值被修改为跟rax寄存器一样的值了。offset表示偏移，如-0x8(%rbp)，-0x8就是偏移量，整个表示rbp寄存器里面保存的地址值先减去8（因为偏移是负8）得到的地址对应的内存。
与内存相关的一些指令的操作码会加上b, w, l和q字母分别表示操作的内存是1，2，4还是8个字节，比如指令 movl $0x0,-0x8(%rbp) ，这条指令操作码movl的后缀字母l说明我们要把从-0x8(%rbp) 这个地址开始的4个内存单元赋值为0。

常用指令详解

mov指令

mov src dst
mov %rsp,%rbp       # 直接寻址，把rsp的值拷贝给rbp，相当于 rbp = rsp
mov -0x8(%rbp),%edx # 源操作数间接寻址，目的操作数直接寻址。从内存中读取4个字节到edx寄存器
mov %rsi,-0x8(%rbp) # 源操作数直接寻址，目的操作数间接寻址。把rsi寄存器中的8字节值写入内存

add/sub

add src dst
sub src dst
sub $0x350,%rsp  # 源操作数是立即操作数，目的操作数直接寻址。rsp = rsp - 0x350
add %rdx,%rax    # 直接寻址。rax = rax + rdx
addl $0x1,-0x8(%rbp) # 源操作数是立即操作数，目的操作数间接寻址。内存中的值加1（addl后缀字母l表示操作内存中的4个字节）

call/ret指令

1
2

call src
ret

call指令执行函数调用。CPU执行call指令时首先会把rip寄存器中的值入栈，然后设置rip值为目标地址，又因为rip寄存器决定了下一条需要执行的指令，所以当CPU执行完当前call指令后就会跳转到目标地址去执行。

ret指令从被调用函数返回调用函数，它的实现原理是把call指令入栈的返回地址弹出给rip寄存器。

#调用函数片段
0x0000000000400559 : callq 0x400526 <sum>
0x000000000040055e : mov   %eax,-0x4(%rbp)

#被调用函数片段
0x0000000000400526 : push   %rbp
......
0x000000000040053f : retq

上面代码片段中，调用函数使用callq 0x400526指令调用0x400526处的函数，0x400526是被调用函数的第一条指令所在的地址。被调用函数在0x40053f处执行retq指令返回调用函数继续执行0x40055e地址处的指令。注意这两条指令会涉及入栈和出栈操作，所以会影响rsp寄存器的值。

jmp/je/jle/jg/jge等等j开头的指令

这些都属于跳转指令，操作码后面直接跟要跳转到的地址或存有地址的寄存器，这些指令与高级编程语言中的 goto 和 if 等语句对应。用法示例：

1
2
3

jmp    0x4005f2
jle    0x4005ee
jl     0x4005b8

push/pop

1
2

push src
pop dst

专用于函数调用栈的入栈出栈指令，这两个指令都会自动修改rsp寄存器。

push入栈时rsp寄存器的值先减去8把栈位置留出来，然后把操作数复制到rsp所指位置。push指令相当于：

1
2

sub $8,%rsp
mov dst,(%rsp)

pop出栈时先把rsp寄存器所指位置的数据复制到目的操作数中，然后rsp寄存器的值加8。pop指令相当于：

1
2

mov (%rsp),dst
add $8,%rsp

leave指令

leave指令没有操作数，它一般放在函数的尾部ret指令之前，用于调整rsp和rbp，这条指令相当于如下两条指令：

1
2

mov %rbp,%rsp
pop %rbp

go汇编语言

寄存器

AMD64	rax	rbx	rcx	rdx	rsi	rdi	rbp	rsp	r8~r15	rip
GO汇编	AX	BX	CX	DX	SI	DI	BP	SP	R8~R15	PC

FP虚拟寄存器

主要用来引用函数参数。go语言规定函数调用时参数都必须放在栈上，比如被调用函数使用 first_arg+0(FP) 来引用调用者传递进来的第一个参数，用second_arg+8(FP)来引用第二个参数，以此类推，这里的first_arg和second_arg仅仅是一个帮助我们阅读源代码的符号，对编译器来说无实际意义，+0和+8表示相对于FP寄存器的偏移量。

SB虚拟寄存器

保存程序地址空间的起始地址。还记得在函数调用栈一节我们看过的进程在内存中的布局那张图吗，这个SB寄存器保存的值就是代码区的起始地址，它主要用来定位全局符号。go汇编中的函数定义、函数调用、全局变量定义以及对其引用会用到这个SB虚拟寄存器。对于这个虚拟寄存器，我们不用过多的关注，在代码中看到它时知道它是一个虚拟寄存器就行了。

操作数宽度（即操作数的位数）

go汇编中，寄存器的名字没有位数之分，比如AX寄存器没有什么RAX, EAX之类的名字，指令中一律只能使用AX。所以如果指令中有操作数寄存器或是指令需要访问内存，则操作码都需要带上后缀B(8位)、W(16位)、D(32位)或Q(64位)。

函数定义

以go runtime中的gogo函数为例：

// func gogo(buf *gobuf)
// restore state from Gobuf; longjmp
TEXT runtime·gogo(SB), NOSPLIT, $16-8
// ......

TEXT runtime·gogo(SB)：指明在代码区定义了一个名字叫gogo的全局函数（符号），该函数属于runtime包。
NOSPLIT：指示编译器不要在这个函数中插入检查栈是否溢出的代码。
$16-8：数字16说明此函数的栈帧大小为16字节，8说明此函数的参数和返回值一共需要占用8字节内存。因为这里的gogo函数没有返回值，只有一个指针参数，对于AMD64平台来说指针就是8字节。go语言中函数调用的参数和函数返回值都是放在栈上的，而且这部分栈内存是由调用者而非被调用函数负责预留，所以在函数定义时需要说明到底需要在调用者的栈帧中预留多少空间。

线程本地存储

线程本地存储又叫线程局部存储，其英文为Thread Local Storage，简称TLS，是线程私有的全局变量。

#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
#include <asm/prctl.h>
#include <sys/prctl.h>

__thread int g = 0;  // 1，这里增加了__thread关键字，把g定义成私有的全局变量，每个线程都有一个g变量

void *start(void *arg)
{
		printf("start, g[%p] : %d\n", &g, g); // 4，打印本线程私有全局变量g的地址和值

		g++; // 5，修改本线程私有全局变量g的值

		return NULL;
}

int main(int argc, char *argv[])
{
		pthread_t tid;

		g = 100;  // 2，主线程给私有全局变量赋值为100

		pthread_create(&tid, NULL, start, NULL); // 3，创建子线程执行start()函数
		pthread_join(tid, NULL);  // 6，等待子线程运行结束

		printf("main, g[%p] : %d\n", &g, g); // 7，打印主线程的私有全局变量g的地址和值

		return 0;
}

gcc编译器（其实还有线程库以及内核的支持）使用了CPU的fs段寄存器来实现线程本地存储，不同的线程中fs段基地址是不一样的，这样看似同一个全局变量但在不同线程中却拥有不同的内存地址，实现了线程私有的全局变量。

goroutine调度器概述

goroutine简介

goroutine是Go语言实现的用户态线程，主要用来解决操作系统线程太“重”的问题，所谓的太重，主要表现在以下两个方面：

创建和切换太重：操作系统线程的创建和切换都需要进入内核，而进入内核所消耗的性能代价比较高，开销较大；
内存使用太重：一方面，为了尽量避免极端情况下操作系统线程栈的溢出，内核在创建操作系统线程时默认会为其分配一个较大的栈内存（虚拟地址空间，内核并不会一开始就分配这么多的物理内存），然而在绝大多数情况下，系统线程远远用不了这么多内存，这导致了浪费；另一方面，栈内存空间一旦创建和初始化完成之后其大小就不能再有变化，这决定了在某些特殊场景下系统线程栈还是有溢出的风险。

用户态的goroutine则轻量得多：

goroutine是用户态线程，其创建和切换都在用户代码中完成而无需进入操作系统内核，所以其开销要远远小于系统线程的创建和切换；
goroutine启动时默认栈大小只有2k，这在多数情况下已经够用了，即使不够用，goroutine的栈也会自动扩大，同时，如果栈太大了过于浪费它还能自动收缩，这样既没有栈溢出的风险，也不会造成栈内存空间的大量浪费。

线程模型与调度器

对goroutine的调度，是指程序代码按照一定的算法在适当的时候挑选出合适的goroutine并放到CPU上去运行的过程，这些负责对goroutine进行调度的程序代码我们称之为goroutine调度器。用极度简化了的伪代码来描述goroutine调度器的工作流程大概是下面这个样子：

// 程序启动时的初始化代码
......
for i := 0; i < N; i++ { // 创建N个操作系统线程执行schedule函数
    create_os_thread(schedule) // 创建一个操作系统线程执行schedule函数
}

// 定义一个线程私有全局变量，注意它是一个指向m结构体对象的指针
// ThreadLocal用来定义线程私有全局变量
ThreadLocal self *m
//schedule函数实现调度逻辑
func schedule() {
    // 创建和初始化m结构体对象，并赋值给私有全局变量self
    self = initm()  
    for { //调度循环
          if (self.p.runqueue is empty) {
                 // 根据某种算法从全局运行队列中找出一个需要运行的goroutine
                 g := find_a_runnable_goroutine_from_global_runqueue()
           } else {
                 // 根据某种算法从私有的局部运行队列中找出一个需要运行的goroutine
                 g := find_a_runnable_goroutine_from_local_runqueue()
           }
          run_g(g) // CPU运行该goroutine，直到需要调度其它goroutine才返回
          save_status_of_g(g) // 保存goroutine的状态，主要是寄存器的值
     }
}

关系示意图

┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐  
  schedt grq                               
│                                       │  
                                           
│      .─.     .─.     .─.     .─.      │  
  ────( G )───( G )───( G )───( G )────    
│      `─'     `─'     `─'     `─'      │  
                                           
└ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘  
                                           
    .─.             .─.             .─.    
   ( G )           ( G )           ( G )   
    `┬'             `┬'             `┬'    
     │               │               │     
     Λ               Λ               Λ     
    ╱ ╲             ╱ ╲             ╱ ╲    
   ▕ m ▏           ▕ m ▏           ▕ m ▏   
    ╲ ╱             ╲ ╱             ╲ ╱    
     V               V               V     
     │               │               │     
   ┌─┴─┐           ┌─┴─┐           ┌─┴─┐   
   │ p │           │ p │           │ p │   
   └─┬─┘           └─┬─┘           └─┬─┘   
┌ ─ ─│─ ─ ┐     ┌ ─ ─│─ ─ ┐     ┌ ─ ─│─ ─ ┐
 lrq │           lrq │           lrq │     
│   .┴.   │     │   .┴.   │     │   .┴.   │
   ( G )           ( G )           ( G )   
│   `┬'   │     │   `┬'   │     │   `┬'   │
    .┴.             .┴.             .┴.    
│  ( G )  │     │  ( G )  │     │  ( G )  │
    `┬'             `┬'             `┬'    
│   .┴.   │     │   .┴.   │     │   .┴.   │
   ( G )           ( G )           ( G )   
│   `┬'   │     │   `┬'   │     │   `┬'   │
     │               │               │     
└ ─ ─ ─ ─ ┘     └ ─ ─ ─ ─ ┘     └ ─ ─ ─ ─ ┘

重要的结构体

结构体的定义全部位于Go语言的源代码路径下的runtime/runtime2.go文件之中。

stack结构体

stack结构体主要用来记录goroutine所使用的栈的信息，包括栈顶和栈底位置：

// Stack describes a Go execution stack.
// The bounds of the stack are exactly [lo, hi),
// with no implicit data structures on either side.
//用于记录goroutine使用的栈的起始和结束位置
type stack struct {  
    lo uintptr    // 栈顶，指向内存低地址
    hi uintptr    // 栈底，指向内存高地址
}

gobuf结构体

gobuf结构体用于保存goroutine的调度信息，主要包括CPU的几个寄存器的值：

type gobuf struct {
    // The offsets of sp, pc, and g are known to (hard-coded in) libmach.
    //
    // ctxt is unusual with respect to GC: it may be a
    // heap-allocated funcval, so GC needs to track it, but it
    // needs to be set and cleared from assembly, where it's
    // difficult to have write barriers. However, ctxt is really a
    // saved, live register, and we only ever exchange it between
    // the real register and the gobuf. Hence, we treat it as a
    // root during stack scanning, which means assembly that saves
    // and restores it doesn't need write barriers. It's still
    // typed as a pointer so that any other writes from Go get
    // write barriers.
    sp   uintptr  // 保存CPU的rsp寄存器的值
    pc   uintptr  // 保存CPU的rip寄存器的值
    g    guintptr // 记录当前这个gobuf对象属于哪个goroutine
    ctxt unsafe.Pointer
 
    // 保存系统调用的返回值，因为从系统调用返回之后如果p被其它工作线程抢占，
    // 则这个goroutine会被放入全局运行队列被其它工作线程调度，其它线程需要知道系统调用的返回值。
    ret  sys.Uintreg  
    lr   uintptr
 
    // 保存CPU的rbp寄存器的值
    bp   uintptr // for GOEXPERIMENT=framepointer
}

g结构体

g结构体用于代表一个goroutine，该结构体保存了goroutine的所有信息，包括栈，gobuf结构体和其它的一些状态信息。调度器代码可以通过g对象来对goroutine进行调度，当goroutine被调离CPU时，调度器代码负责把CPU寄存器的值保存在g对象的成员变量之中，当goroutine被调度起来运行时，调度器代码又负责把g对象的成员变量所保存的寄存器的值恢复到CPU的寄存器。：

// 前文所说的g结构体，它代表了一个goroutine
type g struct {
    // Stack parameters.
    // stack describes the actual stack memory: [stack.lo, stack.hi).
    // stackguard0 is the stack pointer compared in the Go stack growth prologue.
    // It is stack.lo+StackGuard normally, but can be StackPreempt to trigger a preemption.
    // stackguard1 is the stack pointer compared in the C stack growth prologue.
    // It is stack.lo+StackGuard on g0 and gsignal stacks.
    // It is ~0 on other goroutine stacks, to trigger a call to morestackc (and crash).
 
    // 记录该goroutine使用的栈
    stack       stack   // offset known to runtime/cgo
    // 下面两个成员用于栈溢出检查，实现栈的自动伸缩，抢占调度也会用到stackguard0
    stackguard0 uintptr // offset known to liblink
    stackguard1 uintptr // offset known to liblink

    ......
 
    // 此goroutine正在被哪个工作线程执行
    m              *m      // current m; offset known to arm liblink
    // 保存调度信息，主要是几个寄存器的值
    sched          gobuf
 
    ......
    // schedlink字段指向全局运行队列中的下一个g，
    //所有位于全局运行队列中的g形成一个链表
    schedlink      guintptr

    ......
    // 抢占调度标志，如果需要抢占调度，设置preempt为true
    preempt        bool       // preemption signal, duplicates stackguard0 = stackpreempt

   ......
}

m结构体

m结构体用来代表工作线程，它保存了m自身使用的栈信息，当前正在运行的goroutine以及与m绑定的p等信息，详见下面定义中的注释。：

type m struct {
    // g0主要用来记录工作线程使用的栈信息，在执行调度代码时需要使用这个栈
    // 执行用户goroutine代码时，使用用户goroutine自己的栈，调度时会发生栈的切换
    g0      *g     // goroutine with scheduling stack

    // 通过TLS实现m结构体对象与工作线程之间的绑定
    tls           [6]uintptr   // thread-local storage (for x86 extern register)
    mstartfn      func()
    // 指向工作线程正在运行的goroutine的g结构体对象
    curg          *g       // current running goroutine
 
    // 记录与当前工作线程绑定的p结构体对象
    p             puintptr // attached p for executing go code (nil if not executing go code)
    nextp         puintptr
    oldp          puintptr // the p that was attached before executing a syscall
   
    // spinning状态：表示当前工作线程正在试图从其它工作线程的本地运行队列偷取goroutine
    spinning      bool // m is out of work and is actively looking for work
    blocked       bool // m is blocked on a note
   
    // 没有goroutine需要运行时，工作线程睡眠在这个park成员上，
    // 其它线程通过这个park唤醒该工作线程
    park          note
    // 记录所有工作线程的一个链表
    alllink       *m // on allm
    schedlink     muintptr

    // Linux平台thread的值就是操作系统线程ID
    thread        uintptr // thread handle
    freelink      *m      // on sched.freem

    ......
}

p结构体

p结构体用于保存工作线程执行go代码时所必需的资源，比如goroutine的运行队列，内存分配用到的缓存等等。

type p struct {
    lock mutex

    status       uint32 // one of pidle/prunning/...
    link            puintptr
    schedtick   uint32     // incremented on every scheduler call
    syscalltick  uint32     // incremented on every system call
    sysmontick  sysmontick // last tick observed by sysmon
    m                muintptr   // back-link to associated m (nil if idle)

    ......

    // Queue of runnable goroutines. Accessed without lock.
    //本地goroutine运行队列
    runqhead uint32  // 队列头
    runqtail uint32     // 队列尾
    runq     [256]guintptr  //使用数组实现的循环队列
    // runnext, if non-nil, is a runnable G that was ready'd by
    // the current G and should be run next instead of what's in
    // runq if there's time remaining in the running G's time
    // slice. It will inherit the time left in the current time
    // slice. If a set of goroutines is locked in a
    // communicate-and-wait pattern, this schedules that set as a
    // unit and eliminates the (potentially large) scheduling
    // latency that otherwise arises from adding the ready'd
    // goroutines to the end of the run queue.
    runnext guintptr

    // Available G's (status == Gdead)
    gFree struct {
        gList
        n int32
    }

    ......
}

schedt结构体

schedt结构体用来保存调度器的状态信息和goroutine的全局运行队列。因为每个Go程序只有一个调度器，所以在每个Go程序中schedt结构体只有一个实例对象，该实例对象在源代码中被定义成了一个共享的全局变量，这样每个工作线程都可以访问它以及它所拥有的goroutine运行队列，我们称这个运行队列为全局运行队列。：

type schedt struct {
    // accessed atomically. keep at top to ensure alignment on 32-bit systems.
    goidgen  uint64
    lastpoll uint64

    lock mutex

    // When increasing nmidle, nmidlelocked, nmsys, or nmfreed, be
    // sure to call checkdead().

    // 由空闲的工作线程组成链表
    midle        muintptr // idle m's waiting for work
    // 空闲的工作线程的数量
    nmidle       int32    // number of idle m's waiting for work
    nmidlelocked int32    // number of locked m's waiting for work
    mnext        int64    // number of m's that have been created and next M ID
    // 最多只能创建maxmcount个工作线程
    maxmcount    int32    // maximum number of m's allowed (or die)
    nmsys        int32    // number of system m's not counted for deadlock
    nmfreed      int64    // cumulative number of freed m's

    ngsys uint32 // number of system goroutines; updated atomically

    // 由空闲的p结构体对象组成的链表
    pidle      puintptr // idle p's
    // 空闲的p结构体对象的数量
    npidle     uint32
    nmspinning uint32 // See "Worker thread parking/unparking" comment in proc.go.

    // Global runnable queue.
    // goroutine全局运行队列
    runq     gQueue
    runqsize int32

    ......

    // Global cache of dead G's.
    // gFree是所有已经退出的goroutine对应的g结构体对象组成的链表
    // 用于缓存g结构体对象，避免每次创建goroutine时都重新分配内存
    gFree struct {
        lock          mutex
        stack        gList // Gs with stacks
        noStack   gList // Gs without stacks
        n              int32
    }
 
    ......
}

重要的全局变量

allgs     []*g     // 保存所有的g
allm       *m    // 所有的m构成的一个链表，包括下面的m0
allp       []*p    // 保存所有的p，len(allp) == gomaxprocs

ncpu             int32   // 系统中cpu核的数量，程序启动时由runtime代码初始化
gomaxprocs int32   // p的最大值，默认等于ncpu，但可以通过GOMAXPROCS修改

sched      schedt     // 调度器结构体对象，记录了调度器的工作状态

m0  m       // 代表进程的主线程
g0   g        // m0的g0，也就是m0.g0 = &g0

goroutine调度器初始化

以下面这个简单的Hello World程序为例，通过跟踪其从启动到退出这一完整的运行流程来分析Go语言调度器的初始化、goroutine的创建与退出、工作线程的调度循环以及goroutine的切换等重要内容。

package main

import "fmt"

func main() {
    fmt.Println("Hello World!")
}

任何一个由编译型语言（不管是C，C++，go还是汇编语言）所编写的程序在被操作系统加载起来运行时都会顺序经过如下几个阶段：

从磁盘上把可执行程序读入内存；
创建进程和主线程；
为主线程分配栈空间；
把由用户在命令行输入的参数拷贝到主线程的栈；
把主线程放入操作系统的运行队列等待被调度执起来运行。

在主线程第一次被调度起来执行第一条指令之前，主线程的函数栈如下图所示：

┌────────────────────┐          
│▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
│▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
│▨▨▨▨▨▨▨kernel▨▨▨▨▨▨▨│          
│▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
│▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
├────────────────────┼─────┬─   
│□□□□□□□□□□□□□□□□□□□□│     │    
│□□□□□□□......□□□□□□□│     │main
│□□□□□□□□□□□□□□□□□□□□│    thread
├────────────────────┤     stack
│                    │     │    
│    argv[...]       │     │    
│                    │     │    
├────────────────────┤     │    
│                    │     │    
│       argc         │<-sp │    
│                    │     │    
├────────────────────┤     ▼    
│                    │          
│                    │          
│                    │          
│                    │          
│                    │          
└────────────────────┘

初始化g0

全局变量g0的主要作用是提供一个栈供runtime代码执行，因此这里主要对g0的几个与栈有关的成员进行了初始化，从这里可以看出g0的栈大约有64K，地址范围为 SP - 64*1024 + 104 ～ SP。

//runtime/asm_amd64.s : 96

// create istack out of the given (operating system) stack.
// _cgo_init may update stackguard.
//下面这段代码从系统线程的栈空分出一部分当作g0的栈，然后初始化g0的栈信息和stackgard
MOVQ$runtime·g0(SB), DI       //g0的地址放入DI寄存器
LEAQ(-64*1024+104)(SP), BX //BX = SP - 64*1024 + 104
MOVQBX, g_stackguard0(DI) //g0.stackguard0 = SP - 64*1024 + 104
MOVQBX, g_stackguard1(DI) //g0.stackguard1 = SP - 64*1024 + 104
MOVQBX, (g_stack+stack_lo)(DI) //g0.stack.lo = SP - 64*1024 + 104
MOVQSP, (g_stack+stack_hi)(DI) //g0.stack.hi = SP

运行完上面这几行指令后g0与栈之间的关系如下图所示：

                                       ┌────────────────────┐          
                                       │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
                                       │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
                                       │▨▨▨▨▨▨▨kernel▨▨▨▨▨▨▨│          
                                       │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
                                       │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
                                       ├────────────────────┼─────┬─   
┌───g0───────────────┐                 │□□□□□□□□□□□□□□□□□□□□│     │    
│                    │                 │□□□□□□□......□□□□□□□│     │main
│                    │                 │□□□□□□□□□□□□□□□□□□□□│    thread
│                    │                 ├────────────────────┤     stack
│       ......       │                 │    argv[...]       │◀─┐  │    
│                    │                 ├────────────────────┤  │  │    
│                    │                 │       argc         │  │  │    
│                    │                 ├────────────────────┤  │  │    
├────────────────────┤                 │       ......       │  │  │    
│    stackguard1     │━━━━━━━━┓        ├────────────────────┤  │  │    
├────────────────────┤        ┃        │       argv         │──┘  │    
│    stackguard0     │━━━━━━━━┫        ├────────────────────┤     ▼    
├────────────────────┤        ┃        │       argc         │          
│     stack.hi       │━━━━┓   ┃        ├────────────────────┤          
├────────────────────┤    ┃   ┃        │                    │          
│     stack.lo       │━━━━╋━━━┫        ├────────────────────┤          
└────────────────────┘    ┃   ┃        │                    │          
                          ┗━━━╋━━━━━━━━▶────────────────────┤<-sp      
                              ┃        │                    │          
                              ┃        │  64 * 1024 - 104   │          
                              ┃        │      bytes         │          
                              ┃        │                    │          
                              ┃        │                    │          
                              ┗━━━━━━━━▶────────────────────┘

主线程与m0绑定

runtime/asm_amd64.s : 188

//下面开始初始化tls(thread local storage,线程本地存储)
LEAQruntime·m0+m_tls(SB), DI //DI = &m0.tls，取m0的tls成员的地址到DI寄存器
CALLruntime·settls(SB) //调用settls设置线程本地存储，settls函数的参数在DI寄存器中

// store through it, to make sure it works
//验证settls是否可以正常工作，如果有问题则abort退出程序
get_tls(BX) //获取fs段基地址并放入BX寄存器，其实就是m0.tls[1]的地址，get_tls的代码由编译器生成
MOVQ$0x123, g(BX) //把整型常量0x123拷贝到fs段基地址偏移-8的内存位置，也就是m0.tls[0] = 0x123
MOVQruntime·m0+m_tls(SB), AX //AX = m0.tls[0]
CMPQAX, $0x123 //检查m0.tls[0]的值是否是通过线程本地存储存入的0x123来验证tls功能是否正常
JEQ 2(PC)
CALLruntime·abort(SB) //如果线程本地存储不能正常工作，退出程序

这段代码首先调用settls函数初始化主线程的线程本地存储(TLS)，目的是把m0与主线程关联在一起。设置了线程本地存储之后接下来的几条指令在于验证TLS功能是否正常，如果不正常则直接abort退出程序。

runtime/sys_linx_amd64.s : 658

// set tls base to DI
TEXT runtime·settls(SB),NOSPLIT,$32
//......
//DI寄存器中存放的是m.tls[0]的地址，m的tls成员是一个数组，读者如果忘记了可以回头看一下m结构体的定义
//下面这一句代码把DI寄存器中的地址加8，为什么要+8呢，主要跟ELF可执行文件格式中的TLS实现的机制有关
//执行下面这句指令之后DI寄存器中的存放的就是m.tls[1]的地址了
ADDQ$8, DI// ELF wants to use -8(FS)

  //下面通过arch_prctl系统调用设置FS段基址
MOVQDI, SI //SI存放arch_prctl系统调用的第二个参数
MOVQ$0x1002, DI// ARCH_SET_FS //arch_prctl的第一个参数
MOVQ$SYS_arch_prctl, AX //系统调用编号
SYSCALL
CMPQAX, $0xfffffffffffff001
JLS2(PC)
MOVL$0xf1, 0xf1 // crash //系统调用失败直接crash
RET

这里通过arch_prctl系统调用把m0.tls[1]的地址设置成了fs段的段基址。CPU中有个叫fs的段寄存器与之对应，而每个线程都有自己的一组CPU寄存器值，操作系统在把线程调离CPU运行时会帮我们把所有寄存器中的值保存在内存中，调度线程起来运行时又会从内存中把这些寄存器的值恢复到CPU，这样，在此之后，工作线程代码就可以通过fs寄存器来找到m.tls，

// runtime/asm_amd64.s : 194

ok:
   // set the per-goroutine and per-mach "registers"
   get_tls(BX)    //获取fs段基址到BX寄存器
   LEAQ   runtime·g0(SB), CX //CX = g0的地址
   MOVQ   CX, g(BX)  //把g0的地址保存在线程本地存储里面，也就是m0.tls[0]=&g0
   LEAQ   runtime·m0(SB), AX //AX = m0的地址

   // save m->g0 = g0
   MOVQ   CX, m_g0(AX)
   // save m0 to g0->m
   MOVQ   AX, g_m(CX)

把m0和g0绑定在一起，这样，之后在主线程中通过get_tls可以获取到g0，通过g0的m成员又可以找到m0，于是这里就实现了m0和g0与主线程之间的关联。从这里还可以看到，保存在主线程本地存储中的值是g0的地址，也就是说工作线程的私有全局变量其实是一个指向g的指针而不是指向m的指针，目前这个指针指向g0，表示代码正运行在g0栈。此时，主线程，m0，g0以及g0的栈之间的关系如下图所示：

   ┌───m0───────────────┐                  ┌────────────────────┐          
   │                    │                  │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
   │                    │                  │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
   │                    │                  │▨▨▨▨▨▨▨kernel▨▨▨▨▨▨▨│          
   │       ......       │                  │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
   │                    │                  │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
   │                    │                  ├────────────────────┼─────┬─   
   │                    │                  │□□□□□□□□□□□□□□□□□□□□│     │    
   ├────────────────────┤                  │□□□□□□□......□□□□□□□│     │main
   │       tls[1]       │                  │□□□□□□□□□□□□□□□□□□□□│    thread
   ├────────────────────┤<-fs              ├────────────────────┤     stack
┏━━│       tls[0]       │                  │    argv[...]       │◀─┐  │    
┃  ├────────────────────┤                  ├────────────────────┤  │  │    
┣━━│         g0         │◀━┓               │       argc         │  │  │    
┃  └────────────────────┘  ┃               ├────────────────────┤  │  │    
┃                          ┃               │       ......       │  │  │    
┃  ┌───g0───────────────┐  ┃               ├────────────────────┤  │  │    
┃  │                    │  ┃               │       argv         │──┘  │    
┃  │                    │  ┃               ├────────────────────┤     ▼    
┃  │                    │  ┃               │       argc         │          
┃  │       ......       │  ┃               ├────────────────────┤          
┃  │                    │  ┃               │                    │          
┃  │                    │  ┃               ├────────────────────┤          
┃  │                    │  ┃               │                    │          
┃  ├────────────────────┤  ┃ ┏━━━━━━━━━━━━━▶────────────────────┤<-sp      
┃  │         m          │━━┛ ┃             │                    │          
┃  ├────────────────────┤    ┃             │  64 * 1024 - 104   │          
┃  │    stackguard1     │━━━━╋━━━━┓        │      bytes         │          
┃  ├────────────────────┤    ┃    ┃        │                    │          
┃  │    stackguard0     │━━━━╋━━━━┫        │                    │          
┃  ├────────────────────┤    ┃    ┣━━━━━━━━▶────────────────────┘          
┃  │     stack.hi       │━━━━┛    ┃                                        
┃  ├────────────────────┤         ┃                                        
┃  │     stack.lo       │━━━━━━━━━┛                                        
┗━━▶────────────────────┘

初始化m0

osinit函数获取CPU核的数量并保存在全局变量ncpu之中，调度器初始化时需要知道当前系统有多少个CPU核。

//runtime/asm_amd64.s : 
//准备调用args函数，前面四条指令把参数放在栈上
MOVL16(SP), AX// AX = argc
MOVLAX, 0(SP)       // argc放在栈顶
MOVQ24(SP), AX// AX = argv
MOVQAX, 8(SP)       // argv放在SP + 8的位置
CALLruntime·args(SB)  //处理操作系统传递过来的参数和env，不需要关心

//对于linx来说，osinit唯一功能就是获取CPU的核数并放在global变量ncpu中，
//调度器初始化时需要知道当前系统有多少CPU核
CALLruntime·osinit(SB)  //执行的结果是全局变量 ncpu = CPU核数
CALLruntime·schedinit(SB) //调度系统初始化

接下来继续看调度器是如何初始化的。

// runtime/proc.go : 540


func schedinit() {
// raceinit must be the first call to race detector.
// In particular, it must be done before mallocinit below calls racemapshadow.
   
    //getg函数在源代码中没有对应的定义，由编译器插入类似下面两行代码
    //get_tls(CX)
    //MOVQ g(CX), BX; BX存器里面现在放的是当前g结构体对象的地址
    _g_ := getg() // _g_ = &g0

    ......

    //设置最多启动10000个操作系统线程，也是最多10000个M
    sched.maxmcount = 10000

    ......
   
    mcommoninit(_g_.m) //初始化m0，因为从前面的代码我们知道g0->m = &m0

    ......

    sched.lastpoll = uint64(nanotime())
    procs := ncpu  //系统中有多少核，就创建和初始化多少个p结构体对象
    if n, ok := atoi32(gogetenv("GOMAXPROCS")); ok && n > 0 {
        procs = n //如果环境变量指定了GOMAXPROCS，则创建指定数量的p
    }
    if procresize(procs) != nil {//创建和初始化全局变量allp
        throw("unknown runnable goroutine during bootstrap")
    }

    ......
}

前面我们已经看到，g0的地址已经被设置到了线程本地存储之中，schedinit通过getg函数（getg函数是编译器实现的，我们在源代码中是找不到其定义的）从线程本地存储中获取当前正在运行的g，这里获取出来的是g0，然后调用mcommoninit函数对m0(g0.m)进行必要的初始化，对m0初始化完成之后调用procresize初始化系统需要用到的p结构体对象，按照go语言官方的说法，p就是processor的意思，它的数量决定了最多可以有都少个goroutine同时并行运行。schedinit函数除了初始化m0和p，还设置了全局变量sched的maxmcount成员为10000，限制最多可以创建10000个操作系统线程出来工作。

这里我们需要重点关注一下mcommoninit如何初始化m0以及procresize函数如何创建和初始化p结构体对象。首先我们深入到mcommoninit函数中一探究竟。这里需要注意的是不只是初始化的时候会执行该函数，在程序运行过程中如果创建了工作线程，也会执行它，所以我们会在函数中看到加锁和检查线程数量是否已经超过最大值等相关的代码。

// runtime/proc.go : 651

func mcommoninit(mp *m) {
    _g_ := getg() //初始化过程中_g_ = g0

    // g0 stack won't make sense for user (and is not necessary unwindable).
    if _g_ != _g_.m.g0 {  //函数调用栈traceback，不需要关心
        callers(1, mp.createstack[:])
    }

    lock(&sched.lock)
    if sched.mnext+1 < sched.mnext {
        throw("runtime: thread ID overflow")
    }
    mp.id = sched.mnext
    sched.mnext++
    checkmcount() //检查已创建系统线程是否超过了数量限制（10000）

    //random初始化
    mp.fastrand[0] = 1597334677 * uint32(mp.id)
    mp.fastrand[1] = uint32(cputicks())
    if mp.fastrand[0]|mp.fastrand[1] == 0 {
        mp.fastrand[1] = 1
    }

    //创建用于信号处理的gsignal，只是简单的从堆上分配一个g结构体对象,然后把栈设置好就返回了
    mpreinit(mp)
    if mp.gsignal != nil {
        mp.gsignal.stackguard1 = mp.gsignal.stack.lo + _StackGuard
    }

    //把m挂入全局链表allm之中
    // Add to allm so garbage collector doesn't free g->m
    // when it is just in a register or thread-local storage.
    mp.alllink = allm

    // NumCgoCall() iterates over allm w/o schedlock,
    // so we need to publish it safely.
    atomicstorep(unsafe.Pointer(&allm), unsafe.Pointer(mp))
    unlock(&sched.lock)

    // Allocate memory to hold a cgo traceback if the cgo call crashes.
    if iscgo || GOOS == "solaris" || GOOS == "windows" {
        mp.cgoCallers = new(cgoCallers)
    }
}

这个函数把m0放入全局链表allm之中。

初始化allp

procresize函数，考虑到初始化完成之后用户代码还可以通过 GOMAXPROCS()函数调用它重新创建和初始化p结构体对象，而在运行过程中再动态的调整p牵涉到的问题比较多，所以这个函数的处理比较复杂，但如果只考虑初始化，相对来说要简单很多，所以这里只保留了初始化时会执行的代码：

// runtime/proc.go : 4382
func procresize(nprocs int32) *p {
    old := gomaxprocs //系统初始化时 gomaxprocs = 0

    ......

    // Grow allp if necessary.
    if nprocs > int32(len(allp)) { //初始化时 len(allp) == 0
        // Synchronize with retake, which could be running
        // concurrently since it doesn't run on a P.
        lock(&allpLock)
        if nprocs <= int32(cap(allp)) {
            allp = allp[:nprocs]
        } else { //初始化时进入此分支，创建allp 切片
            nallp := make([]*p, nprocs)
            // Copy everything up to allp's cap so we
            // never lose old allocated Ps.
            copy(nallp, allp[:cap(allp)])
            allp = nallp
        }
        unlock(&allpLock)
    }

    // initialize new P's
    //循环创建nprocs个p并完成基本初始化
    for i := int32(0); i < nprocs; i++ {
        pp := allp[i]
        if pp == nil {
            pp = new(p)//调用内存分配器从堆上分配一个struct p
            pp.id = i
            pp.status = _Pgcstop
            ......
            atomicstorep(unsafe.Pointer(&allp[i]), unsafe.Pointer(pp))
        }

        ......
    }

    ......

    _g_ := getg()  // _g_ = g0
    if _g_.m.p != 0 && _g_.m.p.ptr().id < nprocs {//初始化时m0->p还未初始化，所以不会执行这个分支
        // continue to use the current P
        _g_.m.p.ptr().status = _Prunning
        _g_.m.p.ptr().mcache.prepareForSweep()
    } else {//初始化时执行这个分支
        // release the current P and acquire allp[0]
        if _g_.m.p != 0 {//初始化时这里不执行
            _g_.m.p.ptr().m = 0
        }
        _g_.m.p = 0
        _g_.m.mcache = nil
        p := allp[0]
        p.m = 0
        p.status = _Pidle
        acquirep(p) //把p和m0关联起来，其实是这两个strct的成员相互赋值
        if trace.enabled {
            traceGoStart()
        }
    }
   
    //下面这个for 循环把所有空闲的p放入空闲链表
    var runnablePs *p
    for i := nprocs - 1; i >= 0; i-- {
        p := allp[i]
        if _g_.m.p.ptr() == p {//allp[0]跟m0关联了，所以是不能放任
            continue
        }
        p.status = _Pidle
        if runqempty(p) {//初始化时除了allp[0]其它p全部执行这个分支，放入空闲链表
            pidleput(p)
        } else {
            ......
        }
    }

    ......
   
    return runnablePs
}

这个函数代码比较长，但并不复杂，这里总结一下这个函数的主要流程：

使用make([]*p, nprocs)初始化全局变量allp，即allp = make([]*p, nprocs)
循环创建并初始化nprocs个p结构体对象并依次保存在allp切片之中
把m0和allp[0]绑定在一起，即m0.p = allp[0], allp[0].m = m0
把除了allp[0]之外的所有p放入到全局变量sched的pidle空闲队列之中

到此m0, g0, 和m需要的p完全关联在一起了。这时整个调度器相关的各组成部分之间的联系如下图所示：

   ┌────┬────allp───────┐            ┌───m0───────────────┐                                             
┏━━│[0] │    ......     │            │                    │                                             
┃  └────┴───────────────┘            │                    │                                             
┃                                    │                    │                                             
┃                                    │       ......       │             ┌────────────────────┐          
┃                                    │                    │             │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
┃                                    │                    │             │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
┃  ┌───p────────────────┐            │                    │             │▨▨▨▨▨▨▨kernel▨▨▨▨▨▨▨│          
┃  │                    │            ├────────────────────┤             │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
┃  │                    │      ┏━━━━━│         p          │             │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
┃  │                    │      ┃     ├────────────────────┤             ├────────────────────┼─────┬─   
┃  │                    │      ┃     │       ......       │             │□□□□□□□□□□□□□□□□□□□□│     │    
┃  │                    │      ┃     ├────────────────────┤             │□□□□□□□......□□□□□□□│     │main
┃  │      ......        │      ┃     │       tls[1]       │             │□□□□□□□□□□□□□□□□□□□□│    thread
┃  │                    │      ┃     ├────────────────────┤<-fs         ├────────────────────┤     stack
┃  │                    │      ┃  ┏━━│       tls[0]       │             │    argv[...]       │◀─┐  │    
┃  │                    │      ┃  ┃  ├────────────────────┤             ├────────────────────┤  │  │    
┃  │                    │      ┃  ┣━━│         g0         │◀━┓          │       argc         │  │  │    
┃  │                    │     ┏╋━━╋━▶└────────────────────┘  ┃          ├────────────────────┤  │  │    
┃  │                    │     ┃┃  ┃                          ┃          │       ......       │  │  │    
┃  ├────────────────────┤     ┃┃  ┃  ┌───g0───────────────┐  ┃          ├────────────────────┤  │  │    
┃  │         m          │━━━━━┛┃  ┃  │                    │  ┃          │       argv         │──┘  │    
┃  ├────────────────────┤      ┃  ┃  │                    │  ┃          ├────────────────────┤     ▼    
┃  │      ......        │      ┃  ┃  │                    │  ┃          │       argc         │          
┗━━▶────────────────────◀━━━━━━┛  ┃  │       ......       │  ┃          ├────────────────────┤          
                                  ┃  │                    │  ┃          │                    │          
                                  ┃  │                    │  ┃          ├────────────────────┤          
                                  ┃  │                    │  ┃          │                    │          
                                  ┃  ├────────────────────┤  ┃ ┏━━━━━━━━▶────────────────────┤<-sp      
                                  ┃  │         m          │━━┛ ┃        │                    │          
                                  ┃  ├────────────────────┤    ┃        │  64 * 1024 - 104   │          
                                  ┃  │    stackguard1     │━━━━╋━┓      │      bytes         │          
                                  ┃  ├────────────────────┤    ┃ ┃      │                    │          
                                  ┃  │    stackguard0     │━━━━╋━┫      │                    │          
                                  ┃  ├────────────────────┤    ┃ ┣━━━━━━▶────────────────────┘          
                                  ┃  │     stack.hi       │━━━━┛ ┃                                      
                                  ┃  ├────────────────────┤      ┃                                      
                                  ┃  │     stack.lo       │━━━━━━┛                                      
                                  ┗━━▶────────────────────┘

创建main goroutine

schedinit完成调度系统初始化后，返回到rt0_go函数中开始调用newproc() 创建一个新的goroutine用于执行mainPC所对应的runtime·main函数，看下面的代码：

// runtime/asm_amd64.s : 219
// create a new goroutine to start program
MOVQ  $runtime·mainPC(SB), AX // entry，mainPC是runtime.main
// newproc的第二个参数入栈，也就是新的goroutine需要执行的函数
PUSHQ  AX          // AX = &funcval{runtime·main},

// newproc的第一个参数入栈，该参数表示runtime.main函数需要的参数大小，因为runtime.main没有参数，所以这里是0
PUSHQ  $0
CALL  runtime·newproc(SB) // 创建main goroutine
POPQ  AX
POPQ  AX

// start this M
CALL  runtime·mstart(SB)  // 主线程进入调度循环，运行刚刚创建的goroutine

// 上面的mstart永远不应该返回的，如果返回了，一定是代码逻辑有问题，直接abort
CALL  runtime·abort(SB)// mstart should never return
RET

DATA  runtime·mainPC+0(SB)/8,$runtime·main(SB)
GLOB  Lruntime·mainPC(SB),RODATA,$8

newproc函数用于创建新的goroutine，它有两个参数，先说第二个参数fn，新创建出来的goroutine将从fn这个函数开始执行，而这个fn函数可能也会有参数，newproc的第一个参数正是fn函数的参数以字节为单位的大小。比如有如下go代码片段：

func start(a, b, c int64) {
    ......
}

func main() {
    go start(1, 2, 3)
}

编译器在编译上面的go语句时，就会把其替换为对newproc函数的调用，编译后的代码逻辑上等同于下面的伪代码

func main() {
    push 0x3
    push 0x2
    push 0x1
    runtime.newproc(24, start)
}

那为什么需要传递fn函数的参数大小给newproc函数呢？原因就在于newproc函数将创建一个新的goroutine来执行fn函数，而这个新创建的goroutine与当前这个goroutine会使用不同的栈，因此就需要在创建goroutine的时候把fn需要用到的参数先从当前goroutine的栈上拷贝到新的goroutine的栈上之后才能让其开始执行，而newproc函数本身并不知道需要拷贝多少数据到新创建的goroutine的栈上去，所以需要用参数的方式指定拷贝多少数据。

newproc函数是对newproc1的一个包装，这里最重要的准备工作有两个，一个是获取fn函数第一个参数的地址（代码中的argp），另一个是使用systemstack函数切换到g0栈，当然，对于我们这个初始化场景来说现在本来就在g0栈，所以不需要切换，然而这个函数是通用的，在用户的goroutine中也会创建goroutine，这时就需要进行栈的切换。

// runtime/proc.go : 3570

// Create a new g running fn with siz bytes of arguments.
// Put it on the queue of g's waiting to run.
// The compiler turns a go statement into a call to this.
// Cannot split the stack because it assumes that the arguments
// are available sequentially after &fn; they would not be
// copied if a stack split occurred.
//go:nosplit
func newproc(siz int32, fn *funcval) {
    //函数调用参数入栈顺序是从右向左，而且栈是从高地址向低地址增长的
    //注意：argp指向fn函数的第一个参数，而不是newproc函数的参数
    //参数fn在栈上的地址+8的位置存放的是fn函数的第一个参数
    argp := add(unsafe.Pointer(&fn), sys.PtrSize)
    gp := getg()  //获取正在运行的g，初始化时是m0.g0
   
    //getcallerpc()返回一个地址，也就是调用newproc时由call指令压栈的函数返回地址，
    //对于我们现在这个场景来说，pc就是CALLruntime·newproc(SB)指令后面的POPQ AX这条指令的地址
    pc := getcallerpc()
   
    //systemstack的作用是切换到g0栈执行作为参数的函数
    //我们这个场景现在本身就在g0栈，因此什么也不做，直接调用作为参数的函数
    systemstack(func() {
        newproc1(fn, (*uint8)(argp), siz, gp, pc)
    })
}

newproc1函数的第一个参数fn是新创建的goroutine需要执行的函数，注意这个fn的类型是funcval结构体类型，其定义如下：

type funcval struct {
    fn uintptr
    // variable-size, fn-specific data here
}

newproc1的第二个参数argp是fn函数的第一个参数的地址，第三个参数是fn函数的参数以字节为单位的大小，后面两个参数我们不用关心。这里需要注意的是，newproc1是在g0的栈上执行的。该函数很长也很重要，所以我们分段来看。

// runtime/proc.go : 3601

// Create a new g running fn with narg bytes of arguments starting
// at argp. callerpc is the address of the go statement that created
// this. The new g is put on the queue of g's waiting to run.
func newproc1(fn *funcval, argp *uint8, narg int32, callergp *g, callerpc uintptr) {
    //因为已经切换到g0栈，所以无论什么场景都有 _g_ = g0，当然这个g0是指当前工作线程的g0
    //对于我们这个场景来说，当前工作线程是主线程，所以这里的g0 = m0.g0
    _g_ := getg()

    ......

    _p_ := _g_.m.p.ptr() //初始化时_p_ = g0.m.p，从前面的分析可以知道其实就是allp[0]
    newg := gfget(_p_) //从p的本地缓冲里获取一个没有使用的g，初始化时没有，返回nil
    if newg == nil {
         //new一个g结构体对象，然后从堆上为其分配栈，并设置g的stack成员和两个stackgard成员
        newg = malg(_StackMin)
        casgstatus(newg, _Gidle, _Gdead) //初始化g的状态为_Gdead
         //放入全局变量allgs切片中
        allgadd(newg) // publishes with a g->status of Gdead so GC scanner doesn't look at uninitialized stack.
    }
   
    ......
   
    //调整g的栈顶置针，无需关注
    totalSize := 4*sys.RegSize + uintptr(siz) + sys.MinFrameSize // extra space in case of reads slightly beyond frame
    totalSize += -totalSize & (sys.SpAlign - 1)                  // align to spAlign
    sp := newg.stack.hi - totalSize
    spArg := sp

    //......
   
    if narg > 0 {
         //把参数从执行newproc函数的栈（初始化时是g0栈）拷贝到新g的栈
        memmove(unsafe.Pointer(spArg), unsafe.Pointer(argp), uintptr(narg))
        // ......
    }

这段代码主要从堆上分配一个g结构体对象并为这个newg分配一个大小为2048字节的栈，并设置好newg的stack成员，然后把newg需要执行的函数的参数从执行newproc函数的栈（初始化时是g0栈）拷贝到newg的栈，完成这些事情之后newg的状态如下图所示：

   ┌────┬────allp───────┐            ┌───m0───────────────┐                                             
┏━━│[0] │    ......     │            │                    │                                             
┃  └────┴───────────────┘            │                    │                                             
┃                                    │                    │                                             
┃                                    │       ......       │             ┌────────────────────┐          
┃                                    │                    │             │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
┃                                    │                    │             │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
┃  ┌───p────────────────┐            │                    │             │▨▨▨▨▨▨▨kernel▨▨▨▨▨▨▨│          
┃  │                    │            ├────────────────────┤             │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
┃  │                    │      ┏━━━━━│         p          │             │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│          
┃  │                    │      ┃     ├────────────────────┤             ├────────────────────┼─────┬─   
┃  │                    │      ┃     │       ......       │             │□□□□□□□□□□□□□□□□□□□□│     │    
┃  │                    │      ┃     ├────────────────────┤             │□□□□□□□......□□□□□□□│     │main
┃  │      ......        │      ┃     │       tls[1]       │             │□□□□□□□□□□□□□□□□□□□□│    thread
┃  │                    │      ┃     ├────────────────────┤<-fs         ├────────────────────┤     stack
┃  │                    │      ┃  ┏━━│       tls[0]       │             │    argv[...]       │◀─┐  │    
┃  │                    │      ┃  ┃  ├────────────────────┤             ├────────────────────┤  │  │    
┃  │                    │      ┃  ┣━━│         g0         │◀━┓          │       argc         │  │  │    
┃  │                    │     ┏╋━━╋━▶└────────────────────┘  ┃          ├────────────────────┤  │  │    
┃  │                    │     ┃┃  ┃                          ┃          │       ......       │  │  │    
┃  ├────────────────────┤     ┃┃  ┃  ┌───g0───────────────┐  ┃          ├────────────────────┤  │  │    
┃  │         m          │━━━━━┛┃  ┃  │                    │  ┃          │       argv         │──┘  │    
┃  ├────────────────────┤      ┃  ┃  │                    │  ┃          ├────────────────────┤     ▼    
┗━▶│      ......        │      ┃  ┃  │                    │  ┃          │       argc         │          
   └────────────────────◀━━━━━━┛  ┃  │       ......       │  ┃          ├────────────────────┤          
                                  ┃  │                    │  ┃          │                    │          
                                  ┃  │                    │  ┃          ├────────────────────┤          
                                  ┃  │                    │  ┃          │                    │          
                                  ┃  ├────────────────────┤  ┃ ┏━━━━━━━━▶────────────────────┤          
                                  ┃  │         m          │━━┛ ┃        │   &funcval{        │          
   ┌───newg─────────────┐         ┃  ├────────────────────┤    ┃        │    runtime·main}   │          
   │                    │         ┃  │    stackguard1     │━━━━╋━┓      ├────────────────────┤          
   │                    │         ┃  ├────────────────────┤    ┃ ┃      │         0          │          
   │                    │         ┃  │    stackguard0     │━━━━╋━┫      ├────────────────────┤          
   │       ......       │         ┃  ├────────────────────┤    ┃ ┃      │   return address   │          
   │                    │         ┃  │     stack.hi       │━━━━┛ ┃      │   of newproc       │          
   │                    │         ┃  ├────────────────────┤      ┃      ├────────────────────┤<-sp      
   │                    │         ┗━▶│     stack.lo       │━━━━━━┫      │                    │          
   ├────────────────────┤            └────────────────────┘      ┃      │       ......       │          
   │       m=nil        │                                        ┃      │                    │          
   ├────────────────────┤                                        ┗━━━━━━▶────────────────────┤          
   │    stackguard1     │                                                       ......                 
   ├────────────────────┤               ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━▶────────────────────┤     ▲    
   │    stackguard0     │━━━━━━━━━━━━━━━╋━━━━━━━┓                       │                    │     │    
   ├────────────────────┤               ┃       ┃                       │                    │     │    
   │     stack.hi       │━━━━━━━━━━━━━━━┛       ┃                       │     newg stack     │   heap   
   ├────────────────────┤                       ┣━━━━━━━━━━━━━━━━━━━━━━━▶────────────────────┤     │    
   │     stack.lo       │━━━━━━━━━━━━━━━━━━━━━━━┛                       │▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨▨│     │    
   └────────────────────┘                                               └────────────────────┴─────┴─

程序中多了一个我们称之为newg的g结构体对象，该对象也已经获得了从堆上分配而来的2k大小的栈空间，newg的stack.hi和stack.lo分别指向了其栈空间的起止位置。

//把newg.sched结构体成员的所有成员设置为0
    memclrNoHeapPointers(unsafe.Pointer(&newg.sched), unsafe.Sizeof(newg.sched))
   
    //设置newg的sched成员，调度器需要依靠这些字段才能把goroutine调度到CPU上运行。
    newg.sched.sp = sp  //newg的栈顶
    newg.stktopsp = sp
    //newg.sched.pc表示当newg被调度起来运行时从这个地址开始执行指令
    //把pc设置成了goexit这个函数偏移1（sys.PCQuantum等于1）的位置，
    //至于为什么要这么做需要等到分析完gostartcallfn函数才知道
    newg.sched.pc = funcPC(goexit) + sys.PCQuantum // +PCQuantum so that previous instruction is in same function
    newg.sched.g = guintptr(unsafe.Pointer(newg))

    gostartcallfn(&newg.sched, fn) //调整sched成员和newg的栈

…

`1`	`schedule()->execute()->gogo()->g2()->goexit()->goexit1()->mcall()->goexit0()->schedule()`

每个工作线程的执行流程和调度循环都一样，如下图所示：

                       ┌──────────────────┐                                               
                       │     mstart()     │                                               
                       └──────────────────┘                                               
                                 │                                                        
                                 ▼                                                        
                       ┌──────────────────┐                                               
                       │     mstart1()    │                                               
                       └──────────────────┘                                               
                                 │                                                        
                                 │                                                        
                                 │                                                        
┌────────────scheduling loop─────┼──────────────────┐              ┌──────g0 stack────┐   
│                                ▼                  │              │     ......       │   
│                      ┌──────────────────┐         │              ├──────────────────┤   
│          ┌──────────▶│    schedule()    │─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─▶│ mstart stack     │   
│          │           └──────────────────┘         │              ├──────────────────┤   
│          │                     │                  │              │ mstart1 stack    │◀─┐
│          │                     ▼                  │              ├──────────────────┤  │
│          │           ┌──────────────────┐         │              │ schedule stack   │  │
│          │           │     execule()    │         │              ├──────────────────┤  │
│          │           └──────────────────┘         │              │ execute stack    │  │
│          │                     │                  │              ├──────────────────┤  │
│          │                     │                  │              │ gogo stack       │  │
│          │                     ▼                  │              └──────────────────┘  │
│ ┌────────────────┐   ┌──────────────────┐         │                                    │
│ │ other runtime  │   │      gogo()      │         │                                    │
│ │  functions     │   └──────────────────┘         │                                    │
│ └────────────────┘             │                  │                                    │
│          ▲                     │                  │              ┌────────g0────────┐  │
│          │                     ▼                  │              │                  │  │
│          │           ┌──────────────────┐         │              ├──────────────────┤  │
│          │           │ user goroutine   │         │              │     ......       │  │
│          │           └──────────────────┘         │              ├──────────────────┤  │
│          │                     │                  │              │     sched.sp     │──┘
│          │                     │                  │              ├──────────────────┤   
│          │                     ▼                  │              │     ......       │   
│          │           ┌──────────────────┐         │              └──────────────────┘   
│          └───────────│     mcall()      │         │                                     
│                      └──────────────────┘         │                                     
│                                                   │                                     
└───────────────────────────────────────────────────┘

工作线程的执行流程：

初始化，调用mstart函数；
调用mstart1函数，在该函数中调用save函数设置g0.sched.sp和g0.sched.pc等调度信息，其中g0.sched.sp指向mstart函数栈帧的栈顶；
依次调用schedule->execute->gogo函数执行调度；
运行用户的goroutine代码；
用户goroutine代码执行过程中调用runtime中的某些函数，然后这些函数调用mcall切换到g0.sched.sp所指的栈并最终再次调用schedule函数进入新一轮调度，之后工作线程一直循环执行着3～5这一调度循环直到进程退出为止。

GPM 的状态流转

G 的状态流转：

┌──────────┐                                                      
│  _Gidle  │                                                      
└──────────┘                                                      
      │                             ┌───────────────────────┐     
   newproc                          │                       │     
      │                             ▼                       │     
      ▼                       ┏━━━━━━━━━━┓──────────┐       │     
┌──────────┐                  ┃          ┃          │       │     
│  _Gdead  │◀──────goexit─────┃_Grunning ┃◀─┐       │       │     
└──────────┘                  ┃          │  │       │       │     
      │                       ┗━━━━━━━━━━┫  │       │       │     
      │                             │    │  │       │       │     
  newproc       ┌──────────┐    park_m   │  │       │       │     
      │         │_Gwaiting │◀───────┘    │  │     enter    exit   
      ▼         └──────────┘             │  │    syscall syscall  
┏━━━━━━━━━━┓          │                  │  │       │       │     
┃          ┃          │                  │  │       │       │     
┃_Grunnable┃◀───ready─┘                  │  │       │       │     
┃          ┃                             │  │       │       │     
┗▲━━━━━━━━━┛◀─────────────Gosched────────┘  │       │       │     
 │    │                                     │       │       │     
 │    │                                     │       │       │     
 │    └──────────────execute────────────────┘       │       │     
 │                                                  ▼       │     
 │              exit                          ┌──────────┐  │     
 └────────────syscall0────────────────────────│_Gsyscall │──┘     
                                              └──────────┘

P 的状态流转：

	                                                            
     ┌──────────────startTheWorld─────────────┐             
     │                                        │             
     │                                        ▼             
┌────────┐                               ┌─────────┐        
│        │◀ ─ ─ ─ ─ ─ ─GC ─ ─ ─ ─ ─ ─ ─ ─│         │        
│_Pgcstop│                               │_Prunning│◀─┐     
│        │◀ ─ ─ ─GC ─ ─ ─   ┌─acquirep──▶│         │  │     
└────────┘               │  │            └┬────────┘  │     
     ▲  │                   │             │   │       │     
        │              ┌─┴──┴─┐           │   │       │     
     │  │              │      │  releasep │ enter    exit   
        └─procresize──▶│_Pidle│◀──retake──┘syscall syscall  
     │                 │      │               │       │     
                       └──────┘               │       │     
     │                     ▲                  ▼       │     
                           │             ┌─────────┐  │     
     │                     └───retake────┤         │  │     
      ─ ─ ─ ─GC ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│_Psyscall│──┘     
                                         │         │        
                                         └─────────┘

通常情况下（在程序运行时不调整 P 的个数），P 只会在上图中的四种状态下进行切换。当程序刚开始运行进行初始化时，所有的 P 都处于 _Pgcstop 状态，随着 P 的初始化（ runtime.procresize），会被置于 _Pidle。

当 M 需要运行时，会 runtime.acquirep 来使 P 变成 Prunning 状态，并通过 runtime.releasep 来释放。

当 G 执行时需要进入系统调用，P 会被设置为 _Psyscall，如果这个时候被系统监控抢占（ runtime.retake），则 P 会被重新修改为 _Pidle。

如果在程序运行中发生 GC，则 P 会被设置为 _Pgcstop，并在 runtime.startTheWorld 时重新调整为 _Prunning。

M 的状态变化：

 ┌────────┐                   ┌────────────┐
 │spinning│───G not found────▶│non-spinning│
 └────────┘       GC          └────────────┘
      ▲                              │      
      │                              │      
      │                              │      
      │                              ▼      
┌──────────┐                    ┌─────────┐ 
│notewakeup│◀────by other M─────│notesleep│ 
└──────────┘                    └─────────┘

参考资料

源码游记-goroutine调度器系列

英语学习规划

Thu, 12 Nov 2020 22:06:16 +0800

7-9岁全面发展阶段

7岁

报班学一套综合教材
开始正式学习语法、精读、拼写、写作
泛读分级读物300-1000本

精读

一句一句朗读出来，学习词汇、练习拼写、学习语法、做阅读理解、分析作者意图。可以从短篇开始。需要老师领着读，不建议家长操作。

习得

大量听大量读

Case Closed 名侦探柯南
Word Girl 单词女孩
Avatar 降世神通
Ben 10 少年骇客

Phonics推荐

国外
- Scholastic公司的Accelerated Reader、Guided Reading
- Reading A to Z 网站
国内
- 朗文机灵狗故事乐园和开心小读者
- 国家地理儿童百科
- 典范英语（牛津阅读树）

8岁

继续课程，重点学习口语、语法、精读和写作。

阅读推荐

Junie B. Jones系列
Magic Tree House系列
Arthur系列
Judy Moody系列和Stink系列
Geronimo Stilton系列

9岁

阅读推荐

Goosebumps系列
The Spiderwick Chronicles系列
Diary of a Wimpy Kid系列
Roald Dahl作品系列
- Charlie and the Chocolate Factory
- James and the Giant Peach
- Matilda
- The Witches
- The BFG
- Fantastic Mr Fox
Beverly Cleary作品
- Ramona系列
- Henry系列
- Mouse系列
Judy Blume作品
- Fudge系列
Andrew Clements的学校生活系列
The 39 CLUES系列
Guardians of Ga’Hoole系列
The underland Chronicles系列
Percy Jackson and the Olympians系列
The Heroes of Olympus

10岁

学得

加大学习读写的力度，系统复习语法知识，提高读写综合能力，并开始向学科英语和学术英语过渡。同时备考FCE证书。

习得

扩大知识面，广泛阅读历史、地理、自然科学、社会科学的non-fiction书籍、杂志、报刊，并多看科普节目、访谈节目、电影。

阅读推荐

How to Train Your Dragon 驯龙高手
Alex Rider 亚力克斯骑士
Warriors 猫武士
Harry Potter
Pendragon
The Indian in the Cupboard
Charlie Bone
Horrible Histories
The Secret Series
xxx照片

11-12

Sammy Keyes
Artemis Fowl
A Series of Unfortunate Events
The Hobbie和The Lord of the Rings三部曲
The Inheritance Cycle
The Hunger Games
His Dark Materials

每天花半小时到1小时听读，听多读少，特别是小说类。听力比阅读先行，听的比读的高两个年级。一套听，一套读。

在Golang中轻松使用ipset

Tue, 15 Sep 2020 10:26:01 +0800

前言

因为工作关系，需要使用ipset，但是截止目前，golang社区中对ipset的支持并不好。之前用的是go-ipset，只能满足基础的使用，而且只支持hash类型以及部分选项。所以萌生了全面封装golang版本ipset的想法，才有了gonetx/ipset的诞生。

功能

支持所有的ispet常用命令、类型以及实用的选项。

常用命令

支持增删改查导入导出等常用命令，用法可以参见快速开始和进阶使用。

全类型支持

支持所有ipset的方法类型

bitmap
hash
list

和数据类型

ip
net
mac
port
iface

灵活的选项

每种set类型都会有各自的选项，主要集中在创建和新增操作上。目前支持22个选项，常用的有

func Exist(exist bool) Option：创建set或添加entry时，若数据已存在报不报错；删除entry时不存在数据报不报错；
func Timeout(timeout time.Duration) Option：创建set或者添加entry时可以指定超时时间；
func MaxElem(maxElem uint) Option：指定hash方法类型的set容量；
func Family(family NetFamily) Option：指定hash方法类型的set网络协议簇；
func HashSize(hashSize uint) Option：指定hash方法类型的set初始化hash大小。

更多选项详情可以查看文档。

示例

通过示例可以更快地了解该包的使用。需要注意的是，使用该包之前，必须调用ispet.Check检查系统是否支持ispet操作以及版本是否大于v6.0。

快速开始

package main

import (
	"log"
	"time"

	"github.com/kiyonlin/gonetx/ipset"
)

func init() {
	if err := ipset.Check(); err != nil {
		panic(err)
	}
}

func main() {
	// create test set even it's exist
	set, _ := ipset.New("test", ipset.HashIp, ipset.Exist(true), ipset.Timeout(time.Hour))
	// output: test
	log.Println(set.Name())

	_ = set.Flush()

	_ = set.Add("1.1.1.1", ipset.Timeout(time.Hour))

	ok, _ := set.Test("1.1.1.1")
	// output: true
	log.Println(ok)

	ok, _ = set.Test("1.1.1.2")
	// output: false
	log.Println(ok)

	info, _ := set.List()
	// output: &{test hash:ip 4 family inet hashsize 1024 maxelem 65536 timeout 3600 216 0 [1.1.1.1 timeout 3599]}
	log.Println(info)

	_ = set.Del("1.1.1.1")

	_ = set.Destroy()
}

进阶使用

package main

import (
	"bytes"
	"io/ioutil"
	"log"
	"time"

	"github.com/kiyonlin/gonetx/ipset"
)

func init() {
	if err := ipset.Check(); err != nil {
		panic(err)
	}
}

func main() {
	// create test set even it's exist
	set, _ := ipset.New("test", ipset.HashIp,
		ipset.Exist(true), ipset.Timeout(time.Hour*3),
		ipset.Family(ipset.Inet), ipset.HashSize(1024),
		ipset.MaxElem(100000),
	)

	// Saved content:
	_ = ioutil.WriteFile("saved",
		[]byte("add test 1.1.1.1 timeout 3600 -exist\nadd test 1.1.1.2 timeout 3600 -exist\n"),
		0600)
	_ = set.RestoreFromFile("saved")

	data := &bytes.Buffer{}
	data.WriteString("add test 1.1.1.3 timeout 3600 -exist\n")
	data.WriteString("add test 1.1.1.4 timeout 3600 -exist\n")

	_ = set.Restore(data)

	info, _ := set.List()
	// output: &{test hash:ip 4 family inet hashsize 1024 maxelem 100000 timeout 10800 504 0 [1.1.1.3 timeout 3599 1.1.1.2 timeout 3599 1.1.1.1 timeout 3599 1.1.1.4 timeout 3599]}
	log.Println(info)

	_ = set.SaveToFile("saved")
	// cat saved:
	//create test hash:ip family inet hashsize 1024 maxelem 100000 timeout 10800
	//add test 1.1.1.3 timeout 3599
	//add test 1.1.1.2 timeout 3599
	//add test 1.1.1.1 timeout 3599
	//add test 1.1.1.4 timeout 3599
}

最后

有任何疑问或者改进，请提交issue或者PR。

Fasthttp系列——解析请求头

Fri, 21 Aug 2020 19:16:54 +0800

本系列通过解析fasthttp(v1.16.0)源码学习HTTP/1.1。

前言

上一篇文章我们学习了HTTP/1.1的请求行(Request Line)，下面我们继续学习请求头的解析。

请求头格式

HTTP/1.1的消息格式如下：

  HTTP-message   = start-line
                   *( header-field CRLF )
                   CRLF
                   [ message-body ]

start-line: 起始行
*( header-field CRLF ): 头字段+分隔符(\r\n)
CRLF: 空行
[ message-body ]: 可选的消息体

所有HTTP/1.1消息均包含一个起始行，其后是一系列头字段，由分隔符(\r\n)隔开，接着是一个空行(\r\n)，最后是可选的消息体。

上一篇文章学习的请求行就是起始行的一种，还有一种是状态行(Status Line)，我们会在之后讲解。

我们可以发现，每一个头字段后面都需要跟随一个分隔符(\r\n)，当某一行只有分隔符(\r\n)时，就意味着请求头数据已发送完毕。使用httpie就可以轻松查看一个真实的请求头数据：

$ http "www.baidu.com" -p H
# 请求行
GET / HTTP/1.1
# 请求头
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: www.baidu.com
User-Agent: HTTPie/1.0.3

解析请求头

我们再来看看fasthttp是如何解析请求头的。当fasthttp读取到完整的请求头数据后，开始解析请求头，并返回请求头的字节数：

func (h *RequestHeader) parse(buf []byte) (int, error) {
	m, err := h.parseFirstLine(buf)
	if err != nil {
		return 0, err
	}

	h.rawHeaders, _, err = readRawHeaders(h.rawHeaders[:0], buf[m:])
	if err != nil {
		return 0, err
	}
	var n int
	n, err = h.parseHeaders(buf[m:])
	if err != nil {
		return 0, err
	}
	return m + n, nil
}

我们看到了熟悉的parseFirstLine，解析请求行，接着继续读取并保存请求头的原始数据h.rawHeaders, _, err = readRawHeaders(h.rawHeaders[:0], buf[m:])。在readRawHeaders中我们可以看到(完整源码)：

func readRawHeaders(dst, buf []byte) ([]byte, int, error) {
	n := bytes.IndexByte(buf, '\n')
	if (n == 1 && buf[0] == '\r') || n == 0 {
		// empty headers
		return dst, n + 1, nil
	}
	for {
		m = bytes.IndexByte(b, '\n')
		// ...
		m++
		// ...
		if (m == 2 && b[0] == '\r') || m == 1 {
			// ...
			return dst, n, nil
		}
	}
}

目的就是找到单独的\r\n或者\n，一旦找到，就表示没有更多的请求头数据了。从源码中我们可以发现fasthttp兼容了以\n作为分隔符的数据格式。

最后是解析请求头信息n, err = h.parseHeaders(buf[m:])，解析成功后，返回第一行数据和请求头的总字节数。parseHeaders的代码比较长，就不再全部贴出来。

fasthttp在解析请求头时，使用了headerScanner这个结构体，调用next方法一行一行解析。

针对指定的头字段：Host，UserAgent，Content-Type，Content-Length，Connection和Transfer-Encoding，fasthttp会做一些特殊操作，我们会一一进行解析。其他头字段信息会存入h.h(源码)中：h.h = appendArgBytes(h.h, s.key, s.value, argsHasValue)。

我们先深入分析headerScanner.next()。

头字段

首先我们看看头字段的结构：

  header-field   = field-name ":" OWS field-value OWS

  field-name     = token
  field-value    = *( field-content / obs-fold )
  field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
  field-vchar    = VCHAR / obs-text

  obs-fold       = CRLF 1*( SP / HTAB )
                 ; obsolete line folding
                 ; see Section 3.2.4

每个头字段均由不区分大小写的字段名，后跟冒号(:)，可选的前导空白(OWS)，字段值和可选的尾随空白(OWS)组成。

注：OWS指的是optional whitespace，详情链接。

fasthttp的headerScanner就是头部扫描器，负责扫描请求头数据，解析出头字段的字段名(key)和字段值(value)，每次调用next()都解析一行数据。

根据标准，头字段名称紧跟着一个:，所以需要根据:的位置确认头字段名称的值。这里fasthttp加了一个处理：:之前不能有\n，因为此时这个头字段肯定是非法的。

解析出头字段名称后，fasthttp根据配置看需不需要标准化头名称，normalizeHeaderKey(s.key, s.disableNormalizing)，这是为了统一客户端发送的请求头字段名称格式，防止出现类似cONTENT-lenGTH的字段名而在使用时无法匹配的情况。

一般情况下，每个头字段的值在一行内，但是也有可能放在多行里(obs-fold)，举个例子：

# 一行
Header: value1, value2

# 多行
Header: value1,
        value2

这两种格式的值是等价的，想深入了解的可以查看这里。fasthttp也兼容了这种情况，然后对多行值进行格式化s.value, s.b, s.hLen = normalizeHeaderValue(s.value, oldB, s.hLen)。

最终获取到s.key和s.value。

处理头字段键值对

获取到头字段键值对后，对于一般的头字段，fasthttp将他们存储在h.h []argsKV切片中(h.h = appendArgBytes(h.h, s.key, s.value, argsHasValue))，argsKV具体结构如下：

type argsKV struct {
	key     []byte
	value   []byte
	noValue bool
}

为什么不直接存在map中呢？我们之后会讲解，主要是为了延迟解析以及内存复用。现在就想知道原因的可以查看youtu.be 13:42。

接下来我们讲讲几个特殊的头字段，以及fasthttp对它们的处理。不过在此之前，我们需要看懂这行代码：

`1`	`switch s.key[0] \| 0x20`

翻译一下就是将s.key[0]，即头字段名称的首字母，转为小写。原理也很简单，用一段代码解释：

A := 0b01000001
a := 0b01100001
x := 0b00100000 // 0x20
println(A|x == a) // true
println(a|x == a) // true

Host

Host头字段(详情)提供了目标URI的主机和端口信息，使服务器能够区分资源，同时为单个IP地址上的多个主机名的请求提供服务。Host具有指定的格式：

`1`	`Host = uri-host [ ":" port ] ; Section 2.7.1`

RFC7230中指明Host是必须字段。若Host不合法(未提供，提供多个，格式非法)，服务端必须响应400 Bad Request。

通过caseInsensitiveCompare(s.key, strHost)比较头字段名称和常量strHost，确定是否将其存入请求头的host字段：h.host = append(h.host[:0], s.value...)。

注：caseInsensitiveCompare也用到了0x20的技巧(源码)。

UserAgent

User-Agent头字段(详情)包含有关发起请求的用户代理的信息，服务器通常使用该信息来帮助识别报告的互操作性问题的范围，解决或调整响应以避免特定的用户代理限制以及进行分析有关浏览器或操作系统的使用。用户代理应该在每个请求中发送一个User-Agent字段。

它的结构如下：

`1`	`User-Agent = product *( RWS ( product / comment ) )`

该字段的值直接存入请求头的userAgent字段中。

ContentType

Content-Type头字段(详情)指定了请求的媒体类型。

常见的例子有：

1
2

  Content-Type: text/html; charset=ISO-8859-4
  Content-Type: application/json; charset=utf-8

该字段的值直接存入请求头的contentType字段中。

ContentLength

当请求中没有Transfer-Encoding头字段时，可以设置Content-Length头字段，为潜在的消息体提供预期的大小（八位字节的十进制数）；若包含Transfer-Encoding头字段，则无法设置Content-Length。

fasthttp使用parseContentLength(源码)解析具体的数值，并处理了溢出的情况，避免了通过协议元素长度产生的攻击。

若解析成功，fasthttp也会将原始的字节数据保存在h.contentLengthBytes = append(h.contentLengthBytes[:0], s.value...)中。

Connection

Connection头字段(详情)允许客户端控制当前连接。

Connection值是不区分大小写的，所以fasthttp使用bytes.Equal(s.value, strClose)来比较连接值是否为常量strClose("close")，并保存到connectionClose字段中，同时将原始的字节数据保存在h.h = appendArgBytes(h.h, s.key, s.value, argsHasValue)中。

TransferEncoding

Transfer-Encoding头字段(详情)列出与已经（或将要）应用于有效载荷主体以形成消息主体的传输编码序列相对应的传输编码名称。传输编码在这里定义，有兴趣的读者可以自行了解。

我们看看fasthttp的处理逻辑：

if !bytes.Equal(s.value, strIdentity) {
	h.contentLength = -1
	h.h = setArgBytes(h.h, strTransferEncoding, strChunked, argsHasValue)
}

因为identity已经被移除，所以fasthttp忽略了identity，且根据我们在Content-Length中学到的知识，此时应该忽略contentLength，所以将其设为-1，对应了Content-Length头字段的if h.contentLength != -1 {...}(源码)处理。最后把Transfer-Encoding头字段的值设为chunked。

收尾操作

解析完所有的头字段后，fasthttp进行了一些收尾操作：

if h.contentLength < 0 {
	h.contentLengthBytes = h.contentLengthBytes[:0]
}
if h.noHTTP11 && !h.connectionClose {
	// close connection for non-http/1.1 request unless 'Connection: keep-alive' is set.
	v := peekArgBytes(h.h, strConnection)
	h.connectionClose = !hasHeaderValue(v, strKeepAlive)
}

未设置h.contentLength时，清空h.contentLengthBytes
不是HTTP/1.1的情况下重新设置h.connectionClose的值(排除Connection: keep-alive的情况)

总结

请求头解析部分到这里就告一段落了，我们学习了不少请求头相关的知识，稍微总结：

每个请求头是根据分隔符(\r\n)分隔的，但可以包含多行值
空行代表请求头数据的终止
一些具体的请求头概念
使用scanner解析数据流
字母字符比较时使用0x20的小技巧

敬请期待之后的系列文章！ 👋

Fasthttp系列——请求行

Tue, 18 Aug 2020 14:08:37 +0800

本系列通过解析fasthttp(v1.16.0)源码学习HTTP/1.1。

第一行

WEB服务接收HTTP请求要做的第一件事，就是解析请求行(Request Line)。它的格式如下：

`1`	`request-line = method SP request-target SP HTTP-version CRLF`

method: 请求方法
SP: 空格
request-target: 请求目标
HTTP-version: HTTP版本
CRLF: 分隔符\r\n

对应到fasthttp中的代码是：

func (h *RequestHeader) parseFirstLine(buf []byte) (int, error) {
	bNext := buf
	var b []byte
	var err error
	for len(b) == 0 {
		if b, bNext, err = nextLine(bNext); err != nil {
			return 0, err
		}
	}

	// parse method
	n := bytes.IndexByte(b, ' ')
	if n <= 0 {
		return 0, fmt.Errorf("cannot find http request method in %q", buf)
	}
	h.method = append(h.method[:0], b[:n]...)
	b = b[n+1:]

	// parse requestURI
	n = bytes.LastIndexByte(b, ' ')
	if n < 0 {
		h.noHTTP11 = true
		n = len(b)
	} else if n == 0 {
		return 0, fmt.Errorf("requestURI cannot be empty in %q", buf)
	} else if !bytes.Equal(b[n+1:], strHTTP11) {
		h.noHTTP11 = true
	}
	h.requestURI = append(h.requestURI[:0], b[:n]...)

	return len(buf) - len(bNext), nil
}

我们可以看到fasthttp先调用nextLine方法，根据分隔符(\r\n)获取出第一行的所有字节数据b。

再根据b中第一个空格字节的位置解析出method，存入请求头对象中h.method = append(h.method[:0], b[:n]...)。

再根据b中最后一个空格的位置，解析出request-target和HTTP-version。

其中HTTP-version由h.noHTTP11保存一个bool值，不存在HTTP版本数据或者它不等于HTTP/1.1时，这个字段都为false。

而request-target也是直接保存到请求头对象中h.requestURI = append(h.requestURI[:0], b[:n]...)。

最后返回第一行的字节数，done！

请求方法

The method token indicates the request method to be performed on the target resource. The request method is case-sensitive.

我们注意到RFC中有提到请求method是大小写敏感的(The request method is case-sensitive)。

而且根据上面的解析过程，我们可以看出fasthttp获取到method时，直接保存在请求头中，并没有做任何检查。所以当请求端发送了不正确(比如用了小写)的method值时，服务端可以拒绝这次请求(400 Bad Request)。

所有的请求method可以在RFC7231中查看，之后也会细讲。

请求目标

客户端发送HTTP请求消息时，其中包含从目标URI派生的请求目标。请求目标有四种不同的格式，具体取决于请求的方法以及请求是否针对代理：

  request-target = origin-form
                 / absolute-form
                 / authority-form
                 / asterisk-form

之后的文章会针对请求目标做详细的分析，这里不再赘述。

总结

本系列的第一篇文章就这样结束了。我们了解了请求行的结构，并剖析了fasthttp是如何从数据流中解析这第一行请求数据。

敬请期待之后的系列文章！ 👋

解析Fiber路由管理

Tue, 23 Jun 2020 13:18:48 +0800

本文主要通过阅读Fiber源码，解析Fiber是如何管理路由的：

路由注册
路由匹配

环境：macos 10.15.4 + go 1.14.1 + fiber 1.12.1

路由注册

路由结构和路由器接口

首先看一下路由的结构(源码)：

// Route 存放了注册处理器的元数据
type Route struct {
	pos         int         // 路由栈中的位置
	use         bool        // 匹配路由前缀（中间件）
	star        bool        // 路由路径为'*'
	root        bool        // 路由路径为'/'
	path        string      // 美化的路由路径
	routeParser routeParser // 路由解析器
	routeParams []string    // 大小写敏感的参数 key

	Name     string    // 路由第一个处理器的名称
	Path     string    // 原始注册路由路径
	Method   string    // HTTP method
	Handlers []Handler // 所有处理器
}

以及路由器接口的定义(源码)：

type Router interface {
	// 注册中间件
	Use(args ...interface{}) *Route

	Get(path string, handlers ...Handler) *Route
	Head(path string, handlers ...Handler) *Route
	Post(path string, handlers ...Handler) *Route
	Put(path string, handlers ...Handler) *Route
	Delete(path string, handlers ...Handler) *Route
	Connect(path string, handlers ...Handler) *Route
	Options(path string, handlers ...Handler) *Route
	Trace(path string, handlers ...Handler) *Route
	Patch(path string, handlers ...Handler) *Route

	Add(method, path string, handlers ...Handler) *Route
	Static(prefix, root string, config ...Static) *Route
	All(path string, handlers ...Handler) []*Route
	// 路由组，有处理器时注册成中间件
	Group(prefix string, handlers ...Handler) *Group
}

App和Group结构都实现了Router接口，它们的Get、Head、Post、Put、Delete、Connect、Options、Trace和Patch方法是对Add方法的封装。App的Add方法其实也是对其register方法的封装，而Group的实现只是组装了路由路径，再直接调用App的相关方法。

`App`的注册方法

我们先看func (app *App) register(method, pathRaw string, handlers ...Handler) *Route方法(源码)：

func (app *App) register(method, pathRaw string, handlers ...Handler) *Route {
	// 一些检测工作
	// pathPretty 会根据 pathRaw 做一些额外的路径处理：大小写转换，清除后缀'/'等
	pathPretty := pathRaw
	// ...
	// 是不是中间件
	var isUse = method == "USE"
	// 是否通配符
	var isStar = pathPretty == "/*"
	// 是否根路径
	var isRoot = pathPretty == "/"
	// 解析路由路径
	var parsedRaw = parseRoute(pathRaw)
	var parsedPretty = parseRoute(pathPretty)

	// 增加全局的路由位置
	app.mutex.Lock()
	app.routes++
	app.mutex.Unlock()
	// 创建路由元数据
	route := &Route{
		pos:  app.routes,
		use:  isUse,
		star: isStar,
		root: isRoot,
		path:        pathPretty,
		routeParser: parsedPretty,
		routeParams: parsedRaw.params,
		Path:     pathRaw,
		Method:   method,
		Handlers: handlers,
	}
	// 假如是中间件，则为每种 HTTP methods 栈都追加路由
	if isUse {
		for m := range methodINT {
			app.addRoute(m, route)
		}
		return route
	}

	// 假如是 GET 方法，则补上 HEAD 方法
	if method == MethodGet {
		app.addRoute(MethodHead, route)
	}

	// 追加到路由栈
	app.addRoute(method, route)

	return route
}

我们稍微分析一下register做了什么事情：

一些检测工作，method参数是否合法，handlers是否为空，补全路由路径等
创建pathPretty，它是pathRaw的副本，然后做一些额外的路径处理：根据配置转换大小写；根据严格模式清除后缀/
生成路由元数据，其中解析路由路径这个操作会在后面详细分析
根据isUse判断是否为中间件，是的话，给每个HTTP Methods栈追加路由，并直接返回路由对象
若method是GET方法，则为HEAD路由栈追加同样的路由
给指定的method路由栈追加路由

这样，一个路由注册工作就完成了，非常直接了当。

`Group`的`Add`方法

接下来我们看一下Group的Add方法实现：

1
2
3

func (grp *Group) Add(method, path string, handlers ...Handler) *Route {
	return grp.app.register(method, getGroupPath(grp.prefix, path), handlers...)
}

非常简单，使用getGroupPath重新组装path，调用App的register方法。getGroupPath方法的实现也很简单：

func getGroupPath(prefix, path string) string {
	if path == "/" {
		return prefix
	}
	// 清除 prefix 的'/'后缀，再拼接 path
	return utils.TrimRight(prefix, '/') + path
}

解析路由路径

解析路由路径的工作，单独放在了path文件中，我们先来看看核心的routeParser和paramSeg结构：

// routeParser 保存了路径 segments 和参数名称
type routeParser struct {
	segs   []paramSeg
	params []string
}

// paramsSeg 保存了每个段的元数据
type paramSeg struct {
	Param      string	// 参数名
	Const      string	// 常量字符串
	IsParam    bool		// 是否参数
	IsOptional bool		// 是否可选
	IsLast     bool		// 是否最后一个段
	EndChar    byte		// 终止字符，是'/'， '-'， '.'的其中一个，默认为'/'
}

我们从上述注册方法中使用的func parseRoute(pattern string) (p routeParser)方法(源码)开始分析，再以/api/v1/:year-:month.:day/*/:param?当参数，作为例子讲解：

找到匹配串/，这是一个特殊情况，pattern变为api/v1/:year-:month.:day/*/:param?
找到匹配串api/，这是一个常量匹配串，所以生成一个常量segment，常量Const字段为api，终止字符为/，pattern变为v1/:year-:month.:day/*/:param?
找到匹配串v1/，这是一个常量匹配串，且上一个segment是常量类型，所以追加/v1到上一个segment的Const字段中，pattern变为:year-:month.:day/*/:param?
找到匹配串:year-，:开头，所以这个segment是一个参数，参数名为year，终止字符为-，pattern变为:month.:day/*/:param?
找到匹配串:month.，:开头，所以这个segment是一个参数，参数名为month，终止字符为.，pattern变为:day/*/:param?
找到匹配串:day/，:开头，所以这个segment是一个参数，参数名为day，终止字符为/，pattern变为*/:param?
找到匹配串*/，*开头，所以这个segment是一个参数，而且可选(*是通配符)，参数名为*，终止字符为/，pattern变为:param?
找不到分隔符，剩余的pattern作为匹配串，即:param?，:开头，所以这个segment是一个参数，?结尾，所以这个segment也是可选的，参数名为param，因为接下来pattern已经没有了，所以终止字符使用默认值/，且这个segment的IsLast字段标记为true

最终的routeParser结果为：

segs: [
{Param:"" Const:"api/v1" IsParam:false IsOptional:false IsLast:false EndChar:'/'},
{Param:"year" Const:"" IsParam:true IsOptional:false IsLast:false EndChar:'-'},
{Param:"month" Const:"" IsParam:true IsOptional:false IsLast:false EndChar:'.'},
{Param:"day" Const:"" IsParam:true IsOptional:false IsLast:false EndChar:'/'},
{Param:"*" Const"": IsParam:true IsOptional:true IsLast:false EndChar:'/'},
{Param:"param" Const"": IsParam:true IsOptional:true IsLast:true EndChar:'/}
]
params:["year" "month" "day" "*" "param"]

小结

路由注册到这里就差不多了，我们可以看到主要的工作就是解析路由路径，保存好元数据，供路由匹配使用。其实还剩下静态资源路由注册registerStatic没讲，它封装了fasthttp的相关方法，有兴趣的同学可以自行查看源码。

路由匹配

每当Http请求到达后，会由fasthttp解析，Fiber将rctx *fasthttp.RequestCtx包装为Fiber.Ctx对象，由app.next处理（详见源码）。没有匹配的路由，则尝试设置Method Not Allowed 405状态码（详见源码）。

app.next是处理的核心：

func (app *App) next(ctx *Ctx) bool {
	// TODO set unique INT within handler(), not here over and over again
	method := methodINT[ctx.method]
	// 路由栈长度
	lenr := len(app.stack[method]) - 1
	// 从上一个索引开始循环路由栈
	for ctx.indexRoute < lenr {
		// 增加路由索引，初始为-1
		ctx.indexRoute++
		route := app.stack[method][ctx.indexRoute]
		// 检查路由是否匹配请求路径
		match, values := route.match(ctx.path, ctx.pathOriginal)
		// 未匹配则继续查找
		if !match {
			continue
		}
		// 设置路由对象和路由路径参数对应的值
		ctx.route = route
		ctx.values = values
		// 执行路由的第一个处理器
		ctx.indexHandler = 0
		route.Handlers[0](ctx)
		// 停止扫描路由栈
		return true
	}
	// 默认设置 404 状态码
	ctx.SendStatus(404)
	ctx.SendString("Cannot " + ctx.method + " " + ctx.pathOriginal)
	return false
}

我们看看next做了什么事：

找到请求的method方法对应的路由栈
遍历路由栈，检查路由是否匹配请求路径，详细匹配过程见下文
匹配成功，为ctx设置路由对象和路由路径参数对应的值
执行该路由的第一个处理器
处理器中调用了ctx.Next()的话，可能继续遍历路由栈

匹配请求路径

接下来让我们瞅瞅路由如何去匹配请求路径：

func (r *Route) match(path, original string) (match bool, values []string) {
	// 根路径匹配
	if r.root && path == "/" {
		return true, values
		// 通配符匹配
	} else if r.star {
		values := getAllocFreeParams(1)
		values[0] = original[1:]
		return true, values
	}
	// 路由包含参数时
	if len(r.routeParams) > 0 {
		// 匹配参数
		if paramPos, match := r.routeParser.getMatch(path, r.use); match {
			// 从源请求路径中解析出参数值
			return match, r.routeParser.paramsForPos(original, paramPos)
		}
	}
	// 是否中间件
	if r.use {
		// 根路由或者路由路径是请求路径的前缀
		if r.root || strings.HasPrefix(path, r.path) {
			return true, values
		}
		// 路由路径和请求路径相同
	} else if len(r.path) == len(path) && r.path == path {
		return true, values
	}
	// 不匹配
	return false, values
}

路由匹配函数的匹配过程如下：

匹配根路径/
通配符路径/*，参数*的值就是源请求路径的去掉首字符之后的字符串original[1:]
路由包含参数的话，使用路由解析器匹配参数位置，匹配时，从源请求路径获取参数对应的值
中间件路由的情况下，根路由或者路由路径是请求路径的前缀也算匹配，例如/api匹配/api/v1
最后检查路径是否相等

路由参数匹配

带参数的路由匹配func (p *routeParser) getMatch(s string, partialCheck bool) ([][2]int, bool)方法，是最复杂的部分，我们单独拎出来讲，代码不贴了，详见源码：

根据参数数量，获取预分配内存的参数位置切片
遍历路由解析器routeParser中所有的segment
partLen = len(s)获取需要匹配的请求路径长度
先看常量类型的segment匹配：
- i = len(segment.Const)获取常量字符串长度
- partLen < i || (i == 0 && partLen > 0)先匹配长度
- s[:i] != segment.Const再匹配常量字符串值
- (partLen > i && s[i] != segment.EndChar)最后匹配终止符
- 若以上有不匹配的，则直接返回
再看参数类型的segment匹配，目标是计算出参数长度：
- 通配符参数
  - 当前segment是最后一个时，参数长度为剩余请求路径长度
  - 从右向左贪婪匹配(源码)最长的字符串长度，当作参数长度
- 非通配符参数，根据当前segment的终止符查找，没找到的话，参数长度为剩余请求路径长度
- segment不是可选参数且参数长度为0，直接返回
- 终止符不匹配，也直接返回
- 记录当前segment参数对应的位置，自增参数位置下标迭代器
根据匹配串的长度，调整请求路径切片和下一个参数起始位置
若请求路径未匹配完全，且不是部分匹配（中间件前缀匹配），则直接返回
成功返回参数切片位置和匹配成功标识

取得参数位置后，我们就可以在源请求路径中截取出参数对应的值(源码)。

总结

Fiber的路由管理使用了很简单的数据结构——slice，每种Http method对应一组路由栈，而不是像gin一样使用基数树这种数据结构，详细原因见文末。最后作一下总结：

注册路由时，分析路径，将其分段，保存元数据到路由栈中
匹配路由时，逐个匹配请求method对应的路由栈，匹配时执行相应的处理器

其他

Fiber作者Fenny关于为什么不使用基数树管理路由的回答：

We discussed using a radix tree, but we would lose the stack order flexibility (like express has).

Another thing I would like to mention which is misconception by many, the performance of decent routers will not impact your application.

When you have 10,000 routes, you still talking about nano seconds. If you have a database query in one of your handlers, the performance of the router would not matter anymore.

However, we made sure our router is 💯 regarding allocation and performance. And @René did an awesome job to replicate most key features of the expressjs path behaviour.

Which makes routes like /api/*/:param/:param2 ~> /api/joker/batman/robin/2/1 possible, only in Fiber.

基于延迟计算令牌桶的gofiber频率限制中间件实现

Sat, 20 Jun 2020 10:53:18 +0800

前言

后端的api接口一般都需要限制访问频率，一般的实现算法有令牌桶，漏桶等等。其中令牌桶支持突发流量，更合适访问流量整形。

关于令牌桶算法这里不再赘述，目前有两个golang限流器库，github.com/juju/ratelimit和golang.org/x/time/rate，采用了延迟计算的方式实现令牌桶算法。本文主要是基于golang.org/x/time/rate的限流器进行实现，有两篇相关的文章《Golang限流器time/rate使用介绍》和《Golang限流器time/rate实现剖析》，有兴趣的同学可以查看一下。

限流响应头

限流响应头主要涉及四个字段：

未超出频率限制时：
- X-RateLimit-Limit：请求限制总量，对应了令牌桶算法中的突发值Burst
- X-RateLimit-Remaining：目前还可以请求的次数
- X-RateLimit-Reset：多少秒才能恢复到满桶的状态
超出频率限制时：
- Retry-After：多少秒之后可以重试

golang.org/x/time/rate的Reserve方法返回一个*Reservation对象，根据它的Delay方法，我们可以知道本次请求是否超出了频率限制：

delay大于0，表示需要等待，即超出了频率限制。此时，我们根据delay转换成秒数(至少一秒)即可。
delay等于0，表示不需要等待，即未超出频率限制。此时，我们除了Burst，无法获取更多的有效信息。

为`Reservation`增加信息

因为Reservation缺少可以转化为X-RateLimit-Remaining和X-RateLimit-Reset的信息，我们需要在调用Reserve时，保存一些相关数据(源码位置)：

if ok {
    r.tokens = n
    r.timeToAct = now.Add(waitDuration)
    // store remaining tokens as integer
    // 1e-9 used to solve the problem of missing precision
    r.remainedTokens = int(math.Floor(tokens + 1e-9))
    r.reset = r.limit.durationFromTokens(float64(r.lim.burst) - tokens)
}

我们先看r.remainedTokens = int(math.Floor(tokens + 1e-9))，它保存了调用Reserve时，limiter剩余的整数token值。因为tokens是float64类型，会丢失一点精度，我们需要补全精度后，转为int类型。

再看r.reset = r.limit.durationFromTokens(float64(r.lim.burst) - tokens)，float64(r.lim.burst) - tokens是已经消耗掉的token数量，我们根据这个数量，转换为时长，即恢复这么多token还需要多长时间。

实现`fiber`频率限制中间件

Config

根据fiber中间件的实现规则，我们先创建一个配置结构：

type Config struct {
	// Filter 定义了是否跳过中间件的方法，默认是nil
	Filter func(*fiber.Ctx) bool
	// Limit 定义了请求频率的最大值，表示每秒Limit个请求，默认值是 10
	Limit int
	// Burst 是最大突发值，默认值是 10
	Burst int
	// Message 响应消息，默认值是 "Too many requests, please try again later."
	Message string
	// StatusCode 状态码，默认值是 429
	StatusCode int
	// Key 允许用户使用自定义handler生成自定义的 key，默认值是 
	// func(c *fiber.Ctx) string {
	//   return c.IP()
	// }
	Key func(*fiber.Ctx) string
	// Handler 触发频率限制时调用的 handler， 默认值是
	// func(c *fiber.Ctx) {
	//   c.Status(cfg.StatusCode).Format(cfg.Message)
	// }
	Handler func(*fiber.Ctx)
}

利用这些配置，用户可以根据自己的需求使用中间件。

New

func New(config ...Config) func(*fiber.Ctx)是中间件的工厂函数，根据用户传入的配置，返回一个fiber中间件。

我们需要缓存下所有的限制器对象，存放在limiters变量中，并用mu控制并发访问：

var (
	limiters = make(map[string]*rate.Limiter)
	mu       sync.Mutex
)

当api接口收到请求时，获取限制器的key，再根据key获取限制器，没找到的话根据配置为key新建一个限制器：

key := cfg.Key(c)

mu.Lock()
lim, ok := limiters[key]
if !ok {
    // Get a default limiter
    lim = rate.NewLimiter(rate.Limit(cfg.Limit), cfg.Burst)
    limiters[key] = lim
}
mu.Unlock()

然后，我们调用lim.Reserve获取一个*Reservation对象，根据其Delay()返回值确定有没有超出频率限制：

// Try to request
r := lim.Reserve()

// Check reservation's delay
if d := r.Delay(); d > 0 {
    cfg.Handler(c)

    // Return response with Retry-After header
    // https://tools.ietf.org/html/rfc7231#section-7.1.3
    // Set second value(at least one) to Retry-After header
    c.Set(fiber.HeaderRetryAfter, strconv.FormatInt(int64(math.Ceil(d.Seconds())), 10))

    return
}

// We can continue, update RateLimit headers
c.Set("X-RateLimit-Limit", strconv.Itoa(lim.Burst()))
c.Set("X-RateLimit-Remaining", strconv.Itoa(r.RemainedTokens()))
c.Set("X-RateLimit-Reset", strconv.FormatInt(int64(math.Ceil(r.Reset().Seconds())), 10))
// Bye!
c.Next()

其中X-RateLimit-Reset和Retry-After的值都转成秒为单位的整数，这是一个相对当前调用时间的值，客户端可以根据这个值作出相应的操作。

Set

最后，我们提供func Set(key string, lim *rate.Limiter)方法，用户可以根据自己的需求提前设置不同的限制器。比如针对不同的api用户，设置不同的访问频率以及突发值。

总结

本文主要针对api接口的频率限制需求，在golang.org/x/time/rate的基础上为Reservation对象增加方法，完善响应头中的信息，并应用到fiber框架中。

最后，我们可以发现基于令牌桶延迟计算实现频率限制的好处：

不需要定时器
不需要后台goroutine
不需要队列
支持突发流量

仓库资源：

基于golang.org/x/time/rate的rate包
fiber limiter

以上。

fiber+angular开发web

Wed, 17 Jun 2020 13:57:18 +0800

fiber是最近出道的一款基于fasthttp的web框架。

Fiber is an Express inspired web framework build on top of Fasthttp, the fastest HTTP engine for Go. Designed to ease things up for fast development with zero memory allocation and performance in mind.

我们可以用fiber快速开发api接口，再配合angular实现一个web项目。

环境：macos 10.15.4 + go 1.14.1 + fiber 1.11.1 + angular 9.1.6

新建项目

我们创建一个新的目录叫fiblar-demo：

`1`	`md fiblar-demo && cd fiblar-demo`

再使用go mod初始化项目：

`1`	`go mod init github.com/kiyonlin/fiblar-demo`

新建一个main.go文件，内容如下：

package main

import (
	"github.com/gofiber/fiber"
	"log"
)

func main() {
	// Create new Fiber instance
	app := fiber.New()

	// serve Single Page application on "/public"
	// assume static file at dist folder
	app.Static("/", "public")

	// intercept api routes
	apiGroup := app.Group("/api")
	{
		apiGroup.Get("/user", func(c *fiber.Ctx) {
			c.JSON(fiber.Map{"id": 1, "name": "kiyon"})
		})
	}

	// other routes just return `public/index.html`, angular will handle them
	app.Get("/*", func(c *fiber.Ctx) {
		if err := c.SendFile("public/index.html"); err != nil {
			c.Next(fiber.ErrInternalServerError)
		}
	})

	// Start server on http://localhost:3000
	log.Fatal(app.Listen(3000))
}

创建新的`angular`项目

使用angular-cli创建一个新的angular项目：

`1`	`ng new web`

编辑web/angular.json：

{
  "other-configs": {},
  "build": {
    "builder": "@angular-devkit/build-angular:browser",
    "options": {
      "outputPath": "../public"
    }
  }
}

这样就可以把编译后的angular项目输出到跟web同一级的public目录，上述基于fiber的程序会读取public目录下的文件。

接下来我们给web/src/app/app.component.ts加一下api请求：

// ...
export class AppComponent {
  title = 'web';

  user: any;

  constructor(private http: HttpClient) {
    this.http.get('/api/user').subscribe(data => this.user = data);
  }
}

这样进入首页后就会触发/api/user的请求，我们把获取到的user展示到页面web/src/app/app.component.html上：

  <!-- ... -->
  <!-- Resources -->
  <h1>User</h1>
  <p>{{user | json}}</p>
  <h2>Resources</h2>
  <p>Here are some links to help you get started:</p>
  <!-- ... -->

再在web/package.json中添加一个脚本，供开发时使用：

{
  "scripts": {
    "build": "ng build --prod",
    "build:watch": "ng build --watch"
  }
}

运行项目

我们使用air在开发过程中热更新服务，按照文档安装即可，以下是.air.conf的核心内容：

root = "."
tmp_dir = "tmp"
[build]
cmd = "go build -o ./tmp/main ./main.go"
bin = "tmp/main"
include_ext = ["go", "toml"]
exclude_dir = ["assets", "tmp", "vendor", "web"]

最后，我们执行air监听后端项目，执行cd web && yarn run build:watch监听前端项目，访问localhost:3000查看结果：

总结

本文展示了综合fiber和angular开发web项目的一个小例子，权当抛砖引玉，有兴趣的同学可以继续深入研究。最后，我们稍微做下总结：

通过fiber的静态文件服务，我们可以直接提供angular输出的html页面
服务端拦截api路由，前端调用接口时，加上api前缀即可，无跨域问题，其他路由交给angular处理

完整demo，以上。

(译)Angular Core 01 - Angular Templates 完全指南

Wed, 24 Oct 2018 08:25:08 +0000

在这篇文章(原文链接)中，我们将深入探讨Angular Core的一些高级功能！

您可能已经遇到过ng-template这个Angular核心指令，例如在使用ngIf/else或ngSwitch时。

ng-template指令和相关的ngTemplateOutlet指令是非常强大的Angular功能，支持各种高级用例。

这些指令经常与ng-container一起使用，因为这些指令被设计为一起使用，所以如果我们一次性学习它们将会有所帮助，因为我们将围绕每个指令有更多的上下文。

然后让我们看看这些指令启用的一些更高级的用例。注意：本文的所有代码都可以在此Github repository中找到。

`ng-template`指令简介

与名称一样，ng-template指令表示Angular模板：这意味着此标记的内容将包含模板的一部分，然后可以与其他模板一起组合以形成最终的组件模板。

Angular已经在我们一直使用的许多结构指令中使用了ng-template：ngIf，ngFor和ngSwitch。

让我们开始学习ng-template并举例说明。这里我们定义一个选项卡组件的两个选项卡按钮（稍后会详细介绍）：

@Component({
  selector: 'app-root',
  template: `      
      <ng-template>
          <button class="tab-button" 
                  (click)="login()">{{loginText}}</button>
          <button class="tab-button" 
                  (click)="signUp()">{{signUpText}}</button>
      </ng-template>
  `})
export class AppComponent {
    loginText = 'Login';
    signUpText = 'Sign Up'; 
    lessons = ['Lesson 1', 'Lessons 2'];

    login() {
        console.log('Login');
    }

    signUp() {
        console.log('Sign Up');
    }
}

你会注意到关于`ng-template`的第一件事

如果您尝试上面的示例，您可能会惊讶地发现此示例不会向屏幕呈现任何内容！

这是正常的，这是预期的行为。这是因为使用ng-template标签我们只是定义一个模板，但我们还没有使用它。

然后让我们找一个示例，我们可以使用一些最常用的Angular指令来渲染输出。

`ng-template`指令和`ngIf`

您可能在实现if/else方案时第一次遇到ng-template，例如这个：

<div class="lessons-list" *ngIf="lessons else loading">
  ... 
</div>

<ng-template #loading>
    <div>Loading...</div>
</ng-template>

这是ngIf/else功能的一种非常常见的用法：我们在等待数据从后端到达时显示备用loading模板。

我们可以看到，else子句指向一个名称为loading的模板。使用#loading语法通过模板引用为其分配了名称。

但除了那个模板之外，使用ngIf还会创建第二个隐式ng模板！让我们来看看幕后发生的事情：

<ng-template [ngIf]="lessons" [ngIfElse]="loading">
   <div class="lessons-list">
     ... 
   </div>
</ng-template>

<ng-template #loading>
    <div>Loading...</div>
</ng-template>

这就是内部发生的事情，因为Angular解析了简洁的*ngIf结构指令语法糖。让我们分解一下语法糖解析期间发生了什么：

应用结构指令ngIf的元素已移至ng-template中
使用[ngIf]和[ngIfElse]模板输入变量语法将*ngIf的表达式拆分并应用于两个单独的指令

这只是ngIf特定情况的一个例子。但是使用ngFor和ngSwitch也会发生类似的过程。

这些指令都是非常常用的，因此这意味着这些模板在Angular中无处不在，无论是隐式还是显式。

但基于这个例子，可能会想到一个问题：

如果有多个结构指令应用于同一个元素，这是如何工作的？

多种结构指令

让我们看看如果我们尝试在同一元素中使用ngIf和ngFor会发生什么：

<div class="lesson" *ngIf="lessons" 
       *ngFor="let lesson of lessons">
    <div class="lesson-detail">
        {{lesson | json}}
    </div>
</div>

这行不通！相反，我们会收到以下错误消息：

1
2
3

Uncaught Error: Template parse errors:
Can't have multiple template bindings on one element. Use only one attribute 
named 'template' or prefixed with *

这意味着它不可能将两个结构指令应用于同一个元素。为了做到这一点，我们必须做类似的事情：

<div *ngIf="lessons">
    <div class="lesson" *ngFor="let lesson of lessons">
        <div class="lesson-detail">
            {{lesson | json}}
        </div>
    </div>
</div>

在这个例子中，我们已经将ngIf指令移动到外部包装div，但为了使其工作，我们必须创建额外的div元素。

这个解决方案已经可以工作了，但有没有办法将结构指令应用到页面的一部分而不必创建额外的元素？

这正是ng-container结构指令允许我们做的！

`ng-container`指令

为了避免创建额外的div，我们可以改为使用ng-container指令：

<ng-container *ngIf="lessons">
    <div class="lesson" *ngFor="let lesson of lessons">
        <div class="lesson-detail">
            {{lesson | json}}
        </div>
    </div>
</ng-container>

正如我们所看到的，ng-container指令为我们提供了一个元素，我们可以将结构指令附加到页面的一部分，而不必为此创建额外的元素。

ng-container指令还有另一个主要用途：它还可以提供一个占位符，用于动态地将模板注入页面。

使用`ngTemplateOutlet`指令创建动态模板

能够创建模板引用并将它们指向其他指令（例如ngIf）只是一个开始。

我们也可以使用模板本身并使用ngTemplateOutlet指令在页面的任何位置实例化它：

`1`	`<ng-container *ngTemplateOutlet="loading"></ng-container>`

我们可以在这里看到ng-container如何帮助这个例子：我们使用它来在页面上实例化我们在上面定义的加载模板。

我们通过其模板引用#loading引用加载模板，我们使用ngTemplateOutlet结构指令来实例化模板。

我们可以根据需要向页面添加尽可能多的ngTemplateOutlet标记，并实例化许多不同的模板。传递给该指令的值可以是任何计算模板引用的表达式，稍后将详细介绍。

现在我们知道了如何实例化模板，让我们来谈谈模板可以访问的内容。

模板上下文

关于模板的一个关键问题是，它们内部可见什么？

模板是否有自己独立的变量范围，模板可以看到哪些变量？

在ng-template标签主体内部，我们可以访问外部模板中可见的相同上下文变量，例如lessons变量。

这是因为所有ng-template实例也可以访问嵌入它们的相同上下文。

但是每个模板也可以定义自己的输入变量集！实际上，每个模板都关联一个包含所有模板特定输入变量的上下文对象。

我们来看一个例子：

@Component({
  selector: 'app-root',
  template: `      
<ng-template #estimateTemplate let-lessonsCounter="estimate">
    <div> Approximately {{lessonsCounter}} lessons ...</div>
</ng-template>
<ng-container 
   *ngTemplateOutlet="estimateTemplate;context:ctx">
</ng-container>
`})
export class AppComponent {

    totalEstimate = 10;
    ctx = {estimate: this.totalEstimate};
  
}

以下是此示例的解释：

这个模板，与以前的模板不同，还有一个输入变量（也可能有几个）
输入变量名为lessonsCounter，它是通过ng-template属性使用前缀let-定义的
变量lessonsCounter在ng-template主体内部可见，但外部不可见
此变量的内容由其分配给属性let-lessonsCounter的表达式确定
该表达式针对上下文对象进行评估，与模板一起传递给ngTemplateOutlet以进行实例化
然后，对于要在模板内显示的任何值，此上下文对象必须具有名为estimate的属性
context对象通过context属性传递给ngTemplateOutlet，该属性可以接收任何求值为对象的表达式

鉴于上面的示例，这将呈现给屏幕：

`1`	`Approximately 10 lessons ...`

这为我们提供了如何定义和实例化我们自己的模板的良好概述。

我们还可以做的另一件事是在组件本身的层次上以编程方式与模板交互：让我们看看我们如何做到这一点。

Template References

与我们使用模板引用引用加载模板的方式相同，我们也可以使用ViewChild装饰器将模板直接注入到我们的组件中：

@Component({
  selector: 'app-root',
  template: `      
      <ng-template #defaultTabButtons>
          <button class="tab-button" (click)="login()">
            {{loginText}}
          </button>
          <button class="tab-button" (click)="signUp()">
            {{signUpText}}
          </button>
      </ng-template>
`})
export class AppComponent implements OnInit {

    @ViewChild('defaultTabButtons')
    private defaultTabButtonsTpl: TemplateRef<any>;

    ngOnInit() {
        console.log(this.defaultTabButtonsTpl);
    }

}

正如我们所看到的，通过向ViewChild装饰器提供模板引用名称defaultTabButtons，可以像任何其他DOM元素或组件一样注入模板。

这意味着模板也可以在组件类的级别访问，我们可以做一些事情，例如将它们传递给子组件！

我们想要这样做的一个例子是创建一个更可定制的组件，其中不仅可以传递配置参数或配置对象：我们还可以将模板作为输入参数传递。

具有模板部分`@Inputs`的可配置组件

让我们以tab容器为例，我们希望为组件的用户提供配置tab按钮外观的可能性。

下面是这样的，我们首先要为父组件中的按钮定义自定义模板：

@Component({
  selector: 'app-root',
  template: `      
<ng-template #customTabButtons>
    <div class="custom-class">
        <button class="tab-button" (click)="login()">
          {{loginText}}
        </button>
        <button class="tab-button" (click)="signUp()">
          {{signUpText}}
        </button>
    </div>
</ng-template>
<tab-container [headerTemplate]="customTabButtons"></tab-container>      
`})
export class AppComponent implements OnInit {

}

然后在tab容器组件上，我们可以定义一个input属性，它也是一个名为headerTemplate的模板：

@Component({
    selector: 'tab-container',
    template: `
    
<ng-template #defaultTabButtons>
    
    <div class="default-tab-buttons">
        ...
    </div>
    
</ng-template>
<ng-container 
  *ngTemplateOutlet="headerTemplate ? headerTemplate: defaultTabButtons">
    
</ng-container>
... rest of tab container component ...
`})
export class TabContainerComponent {
    @Input()
    headerTemplate: TemplateRef<any>;
}

在最后的组合示例中，这里有几件事情正在发生。让我们逐一来看：

为选项卡按钮定义了一个默认模板，名为defaultTabButtons
仅当input属性headerTemplate未定义时，才会使用此模板
如果定义了属性，则通过headerTemplate传递的自定义输入模板将用于显示按钮
headerTemplate使用ngTemplateOutlet属性在ng-container占位符中实例化
决定使用哪个模板（默认或自定义）是使用三元表达式，但如果该逻辑很复杂，我们也可以将其委托给控制器方法

此设计的最终结果是，如果未提供自定义模板，则tab容器将显示tab按钮的默认外观，但如果自定义模板可用，它将使用自定义模板。

总结和结论

核心指令ng-container，ng-template和ngTemplateOutlet结合在一起，使我们能够创建高度动态和可定制的组件。

我们甚至可以根据输入模板完全改变组件的外观和感觉，我们可以定义模板并在应用程序的多个位置实例化。

这只是这些功能可以组合的一种可能方式！

(译)Angular架构04-Redux，RxJs和NgrxStore-何时使用Store以及为什么？

Wed, 17 Oct 2018 13:27:04 +0000

这篇文章是正在进行的Angular架构系列的一部分，我们将在视图层和服务层一级介绍常见的设计问题和解决方案。这是完整系列：

视图层架构-智能组件与展示组件
视图层架构-容器与展示组件常见的设计缺陷
服务层架构-如何使用Observable数据服务构建Angular应用程序
服务层架构-Redux和Ngrx Store-何时使用Store？为什么？
服务层架构-Ngrx Store-架构指南

`Angular`服务层 - `store`架构

当前版本的Angular是对以前版本（AngularJs）的改进。视图层比以往更容易学习和使用。

但是服务层（也称为数据层）实际上是应用程序的功能核心提供了许多选项：

我们应该如何构建服务层？
我们应该使用store吗？
我们应该使用Redux吗？
我们应该使用普通的RxJs吗？
那么NgRx Store呢？

在Angular世界中非常受欢迎的一件事是store解决方案。

它们起源于React世界并经历了通常的技术采用曲线：大规模采用，认识到它不是一切的最终解决方案，然后在某些情况下使用它而不是其他情况。

为什么`store`在`React`中如此受欢迎？

为什么store在React世界变得如此受欢迎，是否有特定原因或是由于多种原因？这些原因是否也适用于Angular世界，还是有替代解决方案？ store解决了哪些问题？

您是否注意到有很多关于store解决方案的信息，但关于我们何时应该使用它们以及为什么使用它们的信息有限？让我们回顾一下这些问题。

何时使用Redux或store？
我们经常需要store吗？
为什么Redux在React世界中如此受欢迎？
Redux解决的问题是否也出现在Angular世界中？
store解决了什么问题？
什么类型的应用程序受益于store解决方案？
什么类型的工具与store解决方案相关联？
React和Angular中的单向数据流
store和可测试性
store和表现
store和工具
Redux vs Mobx
与Mobx和CycleJs进行工具比较
关于方法的提案
结论和建议

注意：下面有一个带有Ngrx DevTools演示的视频。此外，您可能希望在此另一篇文章中介绍集中存储模式和Ngrx Store - Angular Ngrx速成课程第1部分：Ngrx Store - Learn It By Understanding The Original Facebook Counter Bug。

何时使用`Redux`或`store`？

store起源于Redux世界，所以这将是最先看的知识，然后从那里学习。

让我们来看看React生态系统的react-howto指南，有什么建议？这是一个重要的引用：

你可能听说过Flux。那里有关于Flux的大量错误信息。许多人坐下来构建一个应用程序，并希望定义他们的数据模型，他们认为他们需要使用Flux来完成它。这是采用Flux的错误方法。

Redux的创建者也有这个著名的文章——You Might Not Need Redux，它可以应用于任何store解决方案。

然后在React How-To中还有另一个声明，它似乎同样适用于原始的Flux，Redux，Ngrx Store或任何store解决方案：

你会知道什么时候需要Flux。如果您不确定是否需要它，则不需要它。

基于此，看起来store不建议由一些原创作者系统使用。在这些文章中，我们得到的印象是创作者似乎担心store被视为一种适合所有解决方案的store。

但后来我们遇到了像这样的文章——I Always Seem to Need Redux

不知何故，即使store被他们自己的创作者谨慎推荐，他们仍然在React世界中大规模采用。

为什么会这样？我们试着回答这个问题。

什么时候建议使用`Flux`或`Redux`？

如果我们深入研究React How-To的文档，我们会得到一些关于何时从Flux中受益的迹象：

React组件按层次结构排列。大多数情况下，您的数据模型也遵循层次结构。在这些情况下，Flux不会给你带来太多帮助。但是，有时您的数据模型不是分层的。当您的React组件开始接收感觉无关的道具，或者您有少量组件开始变得非常复杂时，您可能想要查看Flux。

此外，如果我们深入研究问题，我们也会得到这些建议。如果符合以下情况，建议使用类似于store：

您有一段数据需要在您的应用中的多个位置使用，并通过属性传递它会使您的组件违反单一责任原则（即使他们的界面变得不那么有意义）

但也有这种情况：

有多个独立的参与者（通常是服务器和最终用户）可能会改变这些数据

因此，有几种情况建议将store解决方案与React一起使用。那么让我们看看它如何适合Angular。

具有并发更新的`store`和应用程序

如果我们仅基于最后一部分，只有少数应用程序即具有服务器推送要求的应用程序将受益于Flux。因为通常这时候我们有多个角色更新相同的数据，这就是源自Flux的原始Facebook计数问题。

有关原始计数器问题的更多详细信息，请查看最初的Flux演讲。

请注意，我们不需要让服务器推送到这种情况，使用setInterval进行长轮询或修改setTimeout中的数据会导致我们遇到相同的情况：多个角色同时编辑相同的数据。

我们可以肯定地说很多应用都没有这个问题，对吧？这是一个我们需要设计的重要问题，如果存在，但大多数应用程序都有它吗？可能不是，只有某类应用程序。

但是为什么Redux在React世界中被普遍采用呢？这留下了另一个原因。

`Redux`解决的最常见问题是什么？

Redux还解决了extraneous props问题。这一直是Redux在React世界中如此受欢迎的主要原因之一。

在Angular中，props feels extraneous是什么意思？ Props相当于Angular组件的@Input()成员变量。

因此，这意味着Redux可以帮助我们应对使用@Input()将输入传递到组件树上的组件的情况，但这些输入感觉无关紧要，因为此时不是应用程序的一部分。

例如，我们在组件树上传递了5或10个级别。树的叶子知道如何处理它，但对于中间的所有组件，这个输入是无关紧要的，并使该组件可重用性降低，而且更加依赖于应用程序。但这只是一个例子。

`extraneous props`，还有什么意思？

extraneous props问题似乎是一个普遍问题。

在某些情况下，组件在组件树中的完全不同的点上彼此依赖，并且将输入10级向上传递到树上，并且回调函数10级向下传递到树上，然后5级到另一个分支，这在复杂性上不可缩放。

发生这种情况时，还有其他情况：

在树的深处传递数据，并对组件树上的几个级别的事件做出反应
另一个问题是，我们在树中具有相互依赖的兄弟组件，它们代表屏幕上相同数据的不同视图，例如具有未读消息的文件夹列表，以及页眉上的未读消息计数器。

还有更多的例子。如果我们只有props或@Input()作为组件通信机制，我们会很快遇到麻烦。仅传递组件的输入不会复杂化。

这些场景实际上很常见，所以有我们的答案。

为什么`Redux`在`React`世界中如此受欢迎？

可能是因为它也解决了extraneous props问题：这意味着它为更复杂的组件交互场景提供了解决方案。

这是一个基本问题，没有它我们就无法构建更大的应用程序，而Redux解决了它。

几乎所有非平凡的应用程序都有这些场景，它确实不占用大型应用程序，大多数典型的企业应用程序都会有某种复杂的组件互通场景。

为什么`Redux`在这些情况下运行良好？

如果我们尝试使用像AngularJs的$scope.broadcast()这样的事件总线解决这些场景，我们将很容易地结束event soup场景，其中事件以意想不到的方式链接自己，并且很难推断应用程序。

这是因为事件可以很容易地转换为命令，使emitter知道接收器的内部。此外，还有可能意外地将事件链接在一起。

Redux看起来像一个事件总线，但事实并非如此。实际上，Redux存储是Command和Observable模式的组合。我们对store做的是，我们发送一个称为action的命令对象：

1
2
3

store.dispatch({
    type: 'REFRESH_MESSAGES'
});

我们将一个action发送到store，store将对store内的数据进行操作。但是action的emitter不知道store会用它做什么。

我们还可以从应用程序的完全不同的部分发送另一个操作：

store.dispatch({
    type: 'MARK_MESSAGE_AS_READ',
    payload: {
        messageId: 103
    }
});

store将处理它并更新消息列表。然后将消息发送到需要它的应用程序的任何部分。但接收端不知道是什么触发了新数据的生成：

从后端到达的新消息
刷新请求
消息被标记为已读

那么这与解耦和扩展复杂性有什么关系呢？

`store`如何允许分离的组件交互

使用新版本数据的组件（可能是消息列表和计数器）不知道是什么导致数据发生变化，就像我们订阅RxJs Observable时我们不知道什么触发了值的发出，我们只知道我们有新的值。

消费组件已经订阅了store，就像他们订阅了RxJs Observable一样。这种模式效果很好，因为我们必须尽力将发出的数据转换为命令，而事件总线则非常容易。

服务器推送怎么样？

我们现在说服务器也在不断地推送新数据，新消息。数据也通过调度操作推送：

store.dispatch({
    type: 'DISPLAY_NEW_MESSAGE',
    payload: {
        messageId: 104,
        userId: 3000,
        status: 'UNREAD',
        text: 'Hello World !'
    }
});

在所有情况下，都会收到一个新的消息列表并将其呈现为消息列表或未读消息的计数器。渲染的结果将是一致的：我们将不会有一个全部读取的消息列表和一个表示有3条未读消息的计数器。

这种情况是`store`闪耀的时候

store是解决可编辑数据和多个参与者问题的理想解决方案，但我们可以想象数据不会从服务器推送出来。在这种情况下，我们只有组件交互和协调问题，但我们没有竞争条件的可能性。

在这种情况下，我们试图解决的问题只是在组件树的多个断开连接的位置进行组件交互，对吗？

我们不再需要由多个并发角色编辑相同数据的解决方案。这导致了Redux和store的一个重要特征。

`store`是解决多个问题的复合解决方案，而不仅仅是一个问题

我们可以看到这个例子看到store是一个多责任的解决方案：

他们通过Observable模式解决了组件交互的问题
如果需要，它们提供客户端缓存，以避免重复的Ajax请求
它们提供了放置临时UI状态的位置，因为我们填写大型表单或者想要在路由器视图之间导航时在搜索表单中存储搜索条件
它们解决了允许多个参与者修改客户端瞬态数据的问题

store不仅仅解决其中一个问题，而是解决所有这些问题。

多责任解决方案有什么问题？

一个潜在的问题是那些问题并不总是在一起：你可能想要解决一个而不是另一个。并非每个应用程序都具有与Facebook相同的限制：它是全球最大的Web应用程序，拥有18亿用户。

假设您的应用程序是典型的企业应用程序，用户少于100个：您对客户端缓存的使用有限，并且可能没有服务器推送要求。您可能有服务器推送但数据通常是只读的。

在这种情况下，您可能无法从store架构中受益（稍后会详细介绍）。

此外，您可能需要涵盖复杂的组件交互方案，而无需将数据存储在内存中。这里的重要部分是这些问题并不总是在一起：它们聚集在一起，用于非常特殊的应用程序而不是其他应用程序。

`Redux`是否避免状态相关的问题？

重要的是要注意它不会，并且一般都没有其他全局存储解决方案，因为使用Redux我们正在创建一个大的全局应用程序级状态：存储是一个应用程序范围的单例服务。

全局应用程序状态的问题不是它创建的方式，而是它存在的事实。由于我们忘记清理它，因此很容易产生细微的错误。它实际上并没有改变我们仅使用纯reducer函数创建状态，或者全局状态是不可变的这一事实。

所有这些都有所帮助，但我们仍然创建了全局应用程序状态，主要问题仍然存在：它存在并且我们需要在所有正确的位置清理它，并且在复杂性方面不能很好地扩展。

但是如果需要的话，全局状态没有任何问题：到处都需要一些用户数据，为什么不加载一次并将其放入单例服务？

处理全局状态的最佳方式是什么？

避免全局应用程序状态的最佳方法是不创建它，除非它是必要的。现代应用程序确实需要比以前更多的状态：例如，当我们浏览应用程序时，我们在哪里保留给定搜索表单的最后搜索结果？

每当我们从详细信息返回到主表时，我们都不想重复搜索，即使我们触发了路由器导航。

我们可以使用临时的本地状态吗？

这些情况的理想情况是能够创建仅与该特定掌握细节设置的交互本地化的状态，并使其在使用后自动清理自身。

这就是Angular允许我们做的事情，我们将在稍后看到。

除了`store`之外，`Angular`世界还有替代解决方案吗？

在Angular中，我们有一整套内置的解决方案来处理复杂的组件交互场景。所有这些解决方案的核心是Angular依赖注入系统：

如果我们愿意，我们可以在组件树中深入注入服务
如果我们觉得它们本身紧密耦合，我们甚至可以将组件或服务注入彼此
我们可以创建可能存储或不存储数据的共享数据服务

但那只是开始。让我们回到主要细节场景：我们可以创建一个非全局服务，并使用分层注入器将其关联到页面的一部分。这意味着服务及其最终状态将透明地清理自己。

创建自我清理的本地状态

假设我们已经浏览了包含消息列表的应用程序的一部分，并且我们单击列表并转到消息的详细信息。

这是该路由的顶级组件：

@Component({
  selector: 'messages-container',
  providers: [MessagesService],
  template: `
        Messages Master Detail Container:
        <router-outlet></router-outlet>
  `
})
export class MessagesContainerComponent {

      ...

}

请注意providers属性中的MessagesService。这是什么意思？这意味着该服务不是应用程序范围的单例。因此，如果我们想要在打开和关闭多个详细信息时将主服务器的搜索结果保留在内存中，则MessagesService将是放置它而不是全局存储的理想位置。为什么？

因为MessagesService的这个实例是MessagesContainerComponent及其兄弟的本地实例。它只能在那里注入，而不是应用程序中的任何其他地方。

您还可以创建一个MessagesTableService并将其注入表的级别，使用它来加载和分页数据并且并排放置多个表，每个表都有自己的MessagesTableService实例。

关于这些仅由组件树的子集可见的本地服务的好处在于，当我们离开其路由时，它们与相关组件一起清理自己。

本地有状态服务可以实现为例如observable数据服务。

`Angular`和`store`——频繁的选择？

我们可以看到，在Angular中，我们可以使用许多组件间通信机制，而不仅仅是@Input()，我们还有一种自动创建和处理本地状态的机制。

在Angular，我们不一定受益于store来解决这些问题，还有许多其他内置解决方案。

很多时候，store被添加到应用程序中以获得类似于可观察的API以允许某些组件交互：为什么不简单地使用Observable？

添加存储是对应用程序整体架构的重要约束，它意味着创建大量的全局应用程序状态。如果内置更好的替代方案并不意味着这一点，为什么不考虑它们呢？

使用`store`有成本

该store确实解决了组件交互的问题，但它也创建了在应用程序中管理状态的需求，而在使用其他解决方案时可能不存在。

这可能意味着在Angular中，store解决方案比React更不常用？事实上，在最初的一段时间之后，React也会寻求其他解决方案，我们将会看到。

通常还提到了支持store解决方案选择的其他参数：性能，可测试性，工具以及保持应用程序可预测且易于推理的能力。让我们逐一介绍这些，从最后一个开始。

单向数据流

单向数据流是我们在React和Angular中都听到的一个重要属性：它被称为在应用程序中查找的属性，它确保它们是可预测且易于推理的。

`React`中的单向数据流

在最初的Flux会话中，单向数据流描述如下：用户触发action，将其分派到生成新模型的store并将其发送到视图。

但是视图在呈现时不能自己发送进一步的action，如果action的发送已经在进行，也不能发送另一个action。

避免这种情况看起来像基于原始演示文稿的Flux的主要目标之一，请看这里。这里是另一个参考。另外，请查看最初的Flux调度程序代码，其中在会谈中提到了检查。

React和Flux中的UI可预测性似乎主要通过在数据层上设置有益约束来实现：防止链式调度。

`Redux`和单向数据流

重要的是要注意Redux不能防止最初的Flux会谈中提到的链式调度场景。使用Redux，我们可以在原始Flux中触发订阅方法的另一个调度，如果已经调度了一个action，我们就无法触发另一个。

因此，强制执行单向数据流的需求似乎并不是Redux如此广泛采用的主要原因之一，因为通过设计并且至少根据原始Flux会谈中提供的定义，它不会阻止链式调度问题。

也许是因为它太过限制而且在实践中它并没有发生太多？

`Angular`中的单向数据流

在Angular中，我们还看到单向数据流被提及为允许我们以可预测的方式推断应用程序的属性。

但是关注点似乎有点不同：它不是关于对数据层施加约束，数据层可以是任何形式。

Angular中的单向数据流被描述为确保视图无法自行更新。那是什么意思？

开发模式下的单向数据流和渲染

渲染开始时，我们在一次扫描中浏览组件树，而在渲染期间组件不能在第二次传递时给出不同的结果或修改父组件。

基本上，评估模板中的表达式或触发某些组件生命周期方法的行为本身不会触发视图中的进一步更改，从而创建类似于AngularJs的多步藏检测的情况，这有时会导致不可预测的结果。

打破`Angular`单向数据流

想象一下，你正在向屏幕上打印一个随机数：如果你试图通过组件getter方法计算它并将其传递给模板表达式，我们将在开发模式中破坏应用程序，因为你第二次从上到下扫描没有得到相同的结果：

@Component({
  selector: 'messages-container',
  template: `
       {{randomNumber}}
  `
})
export class MessagesContainerComponent {

      ...


     get randomNumber() {
          return Math.random();
     }

}

试试吧，你应该得到：

`1`	`Expression has changed after it was checked`

因此，看起来确保UI中可预测的呈现行为并阻止视图自身更新，我们不一定需要采用类似于store的体系结构。

让我们回顾一下使用store的另一个常见原因：提高性能，接下来让我们回顾可测试性和工具。

`store`和性能

有时候store被认为是使应用程序更高效的一种方式，因为我们可以使用ImmutableJs或Deep Freeze这样的状态使状态不可变，然后我们可以在任何地方使用OnPush变更检测。

Angular变化检测机制开箱即用，并且行为非常直观。默认情况下，我们仅使用模板中的表达式作为表达式来检测更改，其余部分将被忽略（请查看此文章）。

OnPush实际上是一种优化，只有少数应用程序可能会从中受益，例如加载大量数据的应用程序（以及我们可以加载多少对用户仍然有用的数据），或者在非常有限的设备中运行的应用程序。

可以肯定地说，大多数应用程序都不属于这些类别（目前的智能手机）。但是如果我们仍然需要OnPush，我们可以在没有store的情况下使用它，特别是如果我们的数据大部分都是只读的话。

如果应用程序是某种类型的实时仪表板，如图表仪表板，则可能更好地限制数据或其他解决方案。我们甚至可以从更改检测中分离UI的一个分支并限制其渲染。

这里的要点是添加store确实意味着我们将使应用程序更高效或更容易优化，因为我们可以以完全独立的方式优化变更检测系统 - 这两个东西可以一起使用但是没有固有的联系。

采用store架构的另一个共同点是可测试性，让我们看一下，这是进入工具演示之前的最后一点。

`store`和可测试性

引入store经常提出的主要好处之一是它将提高应用程序的可测试性。

确实，reducer函数很容易测试，但是应用程序本身并没有通过引入store来测试，因为我们通过依赖注入系统注入依赖项而不是直接在组件内部创建它们。

假设一个应用程序没有很多数据修改或服务器和用户对数据的并发修改：该应用程序可能不需要存储，并且引入它不会使它更易于测试。

但最后也是最重要的是，我们获得了巨大的利益 - 工具。

`store`和工具

使用store的最大原因之一是它提供的工具生态系统。工具是惊人的，time traveling调试，能够将store状态附加到错误报告和热重新加载，这些是巨大的功能。

通过查看这个简短的视频来演示Ngrx DevTools。如果你从未见过它，它真的值得。

这些工具是惊人的，但看起来现在Redux不是必须在新的React应用程序中使用，那么它在工具方面如何工作？

`Redux`的常用替代方案

在最初采用Redux的一段时间之后，许多React应用程序正在使用MobX构建，MobX是Observable模式的变体。我们可以在文档中看到这个描述：

MobX为现有的数据结构（如对象，数组和类实例）添加了可观察的功能。

这可以通过使用@observable装饰器（ES.Next）注释您的类属性来完成。这是一个小代码示例：

class Todo {
    id = Math.random();
    @observable title = "";
    @observable finished = false;
}

如果您在NgRx Dev Tools上看到上面的视频，这看起来很熟悉吗？看一下，还有一些开发者工具就像Mobx的redux dev工具。

实际上，Mobx开发工具也使用相同的浏览器插件。基于这个例子，似乎拥有这种高级类型的工具我们不一定需要采用store架构。我们需要做的就是使用具有良好或不断发展的工具生态系统的Observable库编写我们的应用程序。

其他相关生态系统中的工具

另一个与流的概念和可观察模式及其变化相关的生态系统是CycleJs生态系统。以下是Flux，Redux和CycleJs生态系统中一些开发人员工具演示的视图。就在此之前，我们讨论了添加工具而不是使用预先定义的架构（通过@andaltaltz）。整个演讲很棒，但如果你选择一个适合你的应用程序的架构，那么在13:03的5分钟讨论会产生一些非常有趣的观点。

请注意，许多这种高级工具通常是跨生态系统进行的工作。

这里要记住的最重要的事情是，看起来还有其他方法可以在不采用store架构的情况下获得出色的工具。

结论

很可能Store架构最初在React世界中变得流行，因为它们解决了一些基本问题，React只是View没有（按设计）提供开箱即用的解决方案：

为解耦组件交互提供类似Observable的模式
为临时UI状态提供客户端容器
提供缓存以避免过多的HTTP请求
为多个参与者提供并发数据修改的解决方案
为工具提供一个钩子

然后半年到一年后，生态系统演变为仅在某些应用类型中采用store而不是其他应用类型。现在Angular世界可能会发生同样的事情，结果可能是一样的。让我们关注工具，RxJs 5的主要特性之一就是提高可调试性。

(译)Angular架构03-如何使用`Observable`数据服务构建`Angular`应用程序及常见的设计缺陷

Wed, 17 Oct 2018 08:25:57 +0000

这篇文章是正在进行的Angular架构系列的一部分，我们将在视图层和服务层一级介绍常见的设计问题和解决方案。这是完整系列：

视图层架构-智能组件与展示组件
视图层架构-容器与展示组件常见的设计缺陷
服务层架构-如何使用Observable数据服务构建Angular应用程序
服务层架构-Redux和Ngrx Store-何时使用Store？为什么？
服务层架构-Ngrx Store-架构指南

在这篇文章中，我们将看到如何围绕Observable数据服务的概念构建Angular应用程序。这是构建应用程序服务层的几种策略之一。我们来看看以下主题：

用于构建Angular应用程序的替代架构
什么是Observable数据服务
如何使用它
RxJs的subject以及如何使用它
BehaviourSubject以及如何使用它
如何构建Observable数据服务
要避免的陷阱
结论

如果您想看一个非常简单的方法来调试RxJs Observables，请看一下这篇文章 - 如何调试RxJs——一种调试Rxjs Observables的简单方法。

用于构建`Angular`应用程序的替代架构

有几种可能性可用于构建Angular应用程序。最近有一种趋势，用类似于Redux的风格构建具有单个原子状态的类似Flux的应用程序。以下是以这种方式构建应用程序的几种替代方法：

如果使用集中存储模式构建应用程序的应用程序，建议使用@ngrx/store指南。
如果使用Redux本身构建应用程序，请参阅此文章以获取更多详细信息和示例应用程序
如果使用Redux和单个状态原子的概念构建应用程序，但在Rxjs中实现它。请参阅此其他文章，了解其执行方式和示例应用

这篇文章将提供一个不使用单个状态原子的替代方案，并且包含使用Observable数据服务。如果你开始使用Observables和Angular，你可能想看看这篇文章，我们将讨论一些常见的故障情况。

什么是`Observable`数据服务

Observable数据服务是Angular可注入服务，可用于向应用程序的多个部分提供数据。可以将名为store的服务注入到需要数据的任何位置：

export class App {
    constructor(private todoStore: TodoStore, 
                private uiStateStore: UiStateStore) {
    }
}

在这种情况下，我们注入两个服务，一个包含应用程序数据，这是一个待办事项列表，另一个服务包含UI的当前状态：例如，当前显示给用户的错误消息。

如何使用`Observable`数据服务

数据服务公开了一个observable，例如TodoStore公开了todos observable。这个observable的每个值都是一个新的待办事项列表。

然后可以使用数据服务直接在模板中使用async管道：

<ul id="todo-list">
    <li *ngFor="let todo of todoStore.todos | async" >
        ...
    </li>
</ul>

如何修改服务的数据

服务中的数据通过调用它们的动作方法来修改，例如：

onAddTodo(description) {
    this.todoStore.addTodo(newTodo)
        .subscribe(
            res => {},
            err => {
                this.uiStateStore.endBackendAction();
            }
        );
}

然后，数据存储将根据操作方法调用为其数据发出新值，并且所有订户将接收新值并相应地更新。

关于`Observable`数据服务的一些有趣的事情

请注意，TodoStore的用户不知道是什么触发了新的todos列表：添加todo，删除todo或切换todo状态。 store的消费者只知道可以获得新值，并且视图将相应地进行调整。这有效地解耦了应用程序的多个部分，因为数据的使用者不知道何时发生了修改。

另请注意，注入存储的应用程序的智能组件没有任何状态变量，这是一件好事，因为这些是编程错误的常见来源。

另外值得注意的是，智能组件中没有一个是直接使用Http后端服务的，只有对存储的调用才能触发数据修改。

现在我们已经了解了如何使用Observable数据服务，让我们看看如何使用RxJ构建。

`RxJs`的`subject`以及如何使用它

Observable数据服务的核心是RxJs的subject。 subject实现Observer和Observable接口，这意味着我们可以使用它们来发出值以及注册订阅者。

subject不仅是传统的事件总线，而且更强大，因为它为所有RxJs功能操作提供了它。但从本质上讲，我们只是使用它来订阅，就像一个常规的observable：

1
2

let subject = new Subject();
subject.subscribe(value => console.log('Received new subject value: '))

但与常规observable不同，Subject也可用于向其订阅者发送值：

`1`	`subject.next(newValue);`

Subject有一个特殊性，妨碍我们使用它来构建Observable数据服务：如果我们订阅它，我们将得不到最后一个值，我们不得不等到应用程序的某个部分调用next()。

这引起了一个问题，特别是在程序引导情况下，应用程序仍在初始化并且并非所有订户都已注册，例如并非所有async管道都有机会自行注册，因为并非所有模板都已初始化。

`BehaviorSubject`以及如何使用它

解决方案是使用BehaviorSubject。这种类型的主题将在订阅时返回流的最后一个值，或者如果尚未发出值则返回初始状态：

`1`	`let BehaviorSubject = new BehaviorSubject(initialState);`

BehaviorSubject还有另一个有趣的属性：我们可以随时检索流的当前值：

`1`	`let currentValue = behaviorSubject.getValue();`

这使得BehaviorSubject成为Observable数据服务的核心。我们来看一个具体的例子。

如何构建`Observable`数据服务

您可以在此处找到store的完整示例，但这是该服务中最重要的部分：

@Injectable()
export class TodoStore {
    private _todos: BehaviorSubject<List<Todo>> = new BehaviorSubject(List([]));

    public readonly todos: Observable<List<Todo>> = this._todos.asObservable();

    constructor(private todoBackendService: TodoBackendService) {
        this.loadInitialData();
    }
    ...
}

我们可以看到store包含一个私有成员变量_todos，它是一个BehaviorSubject，其初始状态为Todos的空列表。

构造函数注入了Http后端服务，这是应用程序中使用此服务的唯一位置，应用程序的其余部分将注入TodoStore。

store在构建时被初始化，所以我们再次使用BehaviorSubject非常重要，否则这将无效。

但是使用额外的公共成员变量todos背后的原因是什么？

陷阱＃1 - 不要直接暴露`subject`

在此示例中，我们不直接将subject公开给store客户端，而是公开一个observable。

这是为了防止服务客户端自己直接发出存储值而不是调用操作方法，从而绕过存储。

避免`event soup`

直接暴露subject可能导致event soup应用，其中事件以难以理解的方式链接在一起。

直接访问subject的内部实现细节就像返回对对象的内部数据结构的内部引用：暴露内部意味着产生对象的控制并允许第三方发出值。

可能有一些有效的用例，但这很可能几乎不是预期的。

写一个`action`方法

在这种类型的应用程序中，操作只是store提供的方法。让我们看看如何构建addTodo操作：

addTodo(newTodo:Todo):Observable {
    let obs = this.todoBackendService.saveTodo(newTodo);

    obs.subscribe(
            res => {
                this._todos.next(this._todos.getValue().push(newTodo));
            });

    return obs;
}

这只是一种方法。我们称后端服务本身返回一个可观察的成功或错误。

我们订阅了相同的observable，并且在成功时我们通过将新todo添加到当前列表来计算新的待办事项列表。

陷阱＃2 - 避免重复的`HTTP`调用

在这个例子中要记住的一件事是，Http的可观察返回将有两个订阅者：一个在addTodo方法中，一个用户调用addTodo。

这将导致（由于observable默认工作的方式）重复的HTTP调用，因为设置了两个单独的处理链。有关此观点以及观察者可能会让我们感到惊讶的其他方式的详细信息，请参阅此文章。

要解决此问题，我们可以执行以下操作，以确保不会发生重复的http调用：

saveTodo(newTodo: Todo) : Observable> {
    var headers = new Headers();
    headers.append('Content-Type', 'application/json; charset=utf-8');

    return this.http.post('/todo', JSON.stringify(newTodo.toJS()),{headers}).publishLast().refCount();
}

要注意直接返回热可观察而不是HTTP冷可观察的权衡：没有重复的网络调用，但saveTodo的调用者可能无法自己执行某些操作（如重试）。

结论

Observable数据服务或存储是一种简单直观的模式，可以在不引入太多新概念的情况下利用Angular中功能响应式编程的强大功能。

熟悉的概念，如subject，基本上是一个事件总线，是这种模式的基础，这使得它比其他需要其他几个RxJs构造的模式更容易学习。

不直接暴露subject的一些预防措施可能足以使应用程序易于理解，但这取决于用例。

正如我们在陷阱部分中看到的那样，需要熟悉RxJs以及可观察的工作方式。查看以前的文章了解更多详情。

(译)Angular架构02-容器与展示组件常见的设计缺陷

Mon, 15 Oct 2018 20:36:31 +0000

这篇文章是正在进行的Angular架构系列的一部分，我们将在视图层和服务层一级介绍常见的设计问题和解决方案。这是完整系列：

视图层架构-智能组件与展示组件
视图层架构-容器与展示组件常见的设计缺陷
服务层架构-如何使用Observable数据服务构建Angular应用程序
服务层架构-Redux和Ngrx Store-何时使用Store？为什么？
服务层架构-Ngrx Store-架构指南

接下来我们来谈谈Angular组件架构：我们将介绍非常常见的组件设计和潜在的设计问题，您可能会在应用它时遇到这些问题。

通用组件设计（以及它的潜在问题）

Angular应用程序开发的一个非常重要的方面是应用程序组件设计：如何将不同类型的组件组合在一起，何时使用组件与指令，如何以及何时将组件中的功能提取到指令等。

Angular组件提供了许多可以以多种不同方式使用和组合的功能。这使我们可以根据情况采用各种各样的应用程序设计。

在这篇文章中，我们将讨论我们经常听到的一种特殊类型的设计。

容器组件与展示组件

我们将要讨论的设计方案是容器组件与展示组件之间的组件分离。

这是一种流行的设计，现在Angular生态系统中越来越多地使用它，因为现在Angular支持Component模型。该设计在Dan Abramov(@dan_abramov)的博客文章中介绍：

展示和容器组件

该文章适用于React，但这些概念也适用于任何允许基于组件的设计模型的生态系统，如Angular。

容器与展示设计的一个例子

因此，让我们举一个这个设计的快速示例，请记住，不同的术语用于命名不同类型的组件。

设计的核心思想是有不同类型的组件。使用与上述博客文章相同的术语，我们有：

容器组件：这些组件知道如何从服务层检索数据。请注意，路由的顶级组件通常是容器组件，这就是为什么这种类型的组件最初这样命名的原因
展示组件 - 这些组件只是将数据作为输入，并知道如何在屏幕上显示它。他们还可以发出自定义事件

让我们举一个这个设计的简单例子，它实际上已经包含了潜在的设计问题。为了让它更有趣，我建议如下：尝试在我提供示例时发现设计问题，我们将在本文后面讨论该问题。

如果您已经尝试过使用此设计，很可能您遇到了这个问题。

以响应式编写的顶级组件

那么让我们开始使用我们路由的顶级组件。让我们看一下用响应式编写的简单路由顶级组件：

@Component({
  selector: 'course-detail',
  templateUrl: './course-detail.component.html'
})
export class CourseDetailComponent implements OnInit {
  user$: Observable<User>;
  course$: Observable<Course>;
  lessons$: Observable<Lesson[]>;

  constructor(private route: ActivatedRoute, private coursesService: CoursesService,
     private newsletterService: NewsletterService, private userService:UserService) {}

  ngOnInit() {
      this.user$ = this.userService.user$;

      this.course$ = this.route.paramMap
          .map(params => params.get('id'))
          .switchMap(courseUrl => this.coursesService.findCourseByUrl(courseUrl));

      this.lessons$ = this.course$
         .switchMap(course => this.coursesService.findLessonsForCourse(course.id));
  }

    onSubscribe(email:string) {
        this.newsletterService.subscribeToNewsletter(email)
            .subscribe(
                () => alert('Subscription successful ...'),
                console.error);
    }
}

这是一个简单的组件，它显示了课程的详细信息：包含一个标题，其中包含课程摘要（以及新闻通讯框）和lesson列表。

因此，让我们分解一下我们在这个顶级组件中所拥有的内容以及它当前的设计方式：

该组件注入了路由器依赖项，但也有一些特定于应用程序的服务
该组件没有任何可以直接引用数据的变量，如lessons或courses
相反，组件在ngOnInit上声明了一些observable，它们是从服务层获得的其他observable派生的

顶级组件设计概述

此顶级组件将根据路由标识符参数定义如何从服务层获取数据。

这是响应式样式应用程序中的典型顶级组件，它不使用路由器数据预取（稍后将详细介绍）。此组件最初将不显示任何数据，它将对服务层执行一次或多次调用以获取数据。

请注意，组件只是定义了一组Observable，但是在组件类中没有进行任何订阅：那么数据如何显示呢？

顶级组件的模板

现在让我们看一下这个组件的模板，看看这些observable是如何被使用的：

<div class="screen-container">

    <course-detail-header [course]="course$ | async" [lessons]="lessons$ | async"
        [firstName]="(user$  | async).firstName" (subscribe)="onSubscribe($event)">
    </course-detail-header>

    <table class="table lessons-list card card-strong">
        <tbody>
        <tr *ngFor="let lesson of (lessons$ | async)">....</tr>
        </tbody>
    </table>
  
</div>

我们可以看到，我们正在使用observable，我们通过async管道订阅它们。然后，数据将应用于存在于此路由的顶级组件下的本地组件树：

多种类型的数据，包括用户，lessons和courses，将被传递到course-detail-header组件，以及lesson列表。这些组件负责呈现顶级组件检索的数据

关于多个订阅的说明

一件重要的事情：lessons$这个observable订阅了两次。在这种情况下，它不会造成问题，因为来自服务层的observable旨在防止对后端的多个请求，例如使用publishLast().refCount()。

请注意，这只是确保多个订阅不成问题的一种可能解决方案。现在让我们来看看顶层组件模板中使用的其中一个本地组件。我们将看到他们的设计非常不同。

研究展示组件的设计

顶级组件是一个容器组件，但是模板中使用的其他组件呢？

展示组件将负责获取输入数据并将其呈现给用户。例如，course-detail-header是一个展示组件。我们来看看这个组件的样子：

@Component({
    selector: 'course-detail-header',
    template: `
    <h2>{{course?.description}}</h2>
    <h5>Total lessons: {{lessons?.length}}</h5>
    <newsletter [firstName]="firstName" (subscribe)="onSubscribe($event)"></newsletter>
`, 
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class CourseDetailHeaderComponent {
    @Input()
    course: Course;
    @Input()
    lessons: Lesson[];
    @Input()
    firstName:string;
    @Output()
    subscribe = new EventEmitter();

    onSubscribe(email:string) {
        this.subscribe.emit(email);
    }
}

提醒：尝试通过此设计发现问题

正如我们所看到的，组件将一些数据作为input，然后呈现给屏幕。此组件与应用程序的服务层没有依赖关系，而是通过input接收其数据。

它还发出output，例如订阅output事件。但是这个事件来自哪里？我们可以看到，这是为了响应来自简报组件的具有相同名称的事件而被触发。

新闻通讯组件的外观如何，它是如何设计的？我们来看一下。

展示组件更深一层组件树

新闻通讯组件也是一个展示组件，因为它需要输入，显示订阅表单并在订阅时发出事件：

@Component({
    selector: 'newsletter',
    template: `
<fieldset class="newsletter">
    <legend>Newsletter</legend>
    <h5>Hello {{firstName}}, enter your email below to subscribe:</h5>
    <form>
        <input #email type="email" name="email">
        <input  type="button" class="button button-primary" value="Subscribe"
               (click)="subscribeToNewsletter(email)">
    </form>
</fieldset>
`,
    styleUrls: ['./newsletter.component.css']
})
export class NewsletterComponent {

    @Input()
    firstName:string;

    @Output()
    subscribe = new EventEmitter();

    subscribeToNewsletter(emailField) {
        this.subscribe.emit(emailField.value);
        emailField.value = '';
    }
}

因此，这是我们目前为新闻通讯组件设计的设计，所以让我们更详细地查看它，看看问题可能是什么。

这个设计的潜在问题

您可能已经注意到新闻稿组件中的一些与course-detail-header组件类似的内容：

input属性firstName
output事件subscribe

在这两个组件中重复这两个元素。所以看起来我们在这个设计中做了一些事情，这些事情可能无法在更大的组件树中很好地扩展，因为涉及很多重复。

让我们回顾一下这两个问题，看看我们怎么可能设计这个问题。

设计问题1 - 中间组件中的外来属性

看起来我们正在传递像firstName这样的input而不是本地组件树，以便像新闻稿组件这样的叶子组件使用它们。但是中间组件本身并没有使用input，它们只是将它们传递给子组件。

通常，本地组件树比此示例大得多，因此该问题可能会导致大量重复输入。

此外，更重要的是：如果我们使用第三方窗口小部件库并且我们使用其中一些组件作为中间组件，我们可能无法通过组件树传递所有必要的数据，具体取决于库的设计方式。

还有另一个与产出有关的类似问题。

设计问题2 - 在本地组件树上冒泡的自定义事件

正如我们所看到的，订阅事件也在组件树的多个层次上重复，这是因为设计自定义事件不会冒泡。

所以在这里我们还有一个代码重复问题，对于一个更大的例子，它不能很好地扩展，并且不能与第三方库一起工作 - 在这种情况下我们无法应用这种技术。

此外，订阅新闻通讯（对newsletterService的调用）的逻辑是在顶级路由组件上，而不是在新闻通讯组件上。

这是因为只有顶级组件才能访问服务层，但最终导致该组件可能会保留很多逻辑。

那么我们如何在Angular中解决这些问题呢？我们来看看可能的解决方案。

防止自定义事件冒泡

如果我们发现自己处于组件树中手动冒泡事件的情况，那么对于某些更简单的情况可能会很好。但是，如果事件冒泡/外来属性开始变得难以维护的话，这里有一个替代方案。

我们将通过一步一步的重构来呈现替代方案。让我们再次从顶级组件开始重构，看看新解决方案如何避免我们发现的问题。

如果您想查看与此类似的重构版本的视频版本，请查看此视频(Youtube)。

重构的顶级组件

让我们更改顶级组件，使其不再传递尽可能多的数据或从本地组件树接收尽可能多的事件。我们还删除新闻订阅逻辑。

新版本的顶级组件现在拥有的代码比以前少得多：

@Component({
  selector: 'course-detail',
  templateUrl: './course-detail.component.html'
})
export class CourseDetailComponent implements OnInit {
  course$: Observable<Course>;
  lessons$: Observable<Lesson[]>;

  constructor(private route: ActivatedRoute,
              private coursesService: CoursesService) {}

  ngOnInit() {

      this.course$ = this.route.paramMap
         .map(params => params.get('id'))
         .switchMap(courseUrl => this.coursesService.findCourseByUrl(courseUrl));

      this.lessons$ = this.course$
        .switchMap(course => this.coursesService.findLessonsForCourse(course.id));
  }
}

所以这看起来是一个好的开始。那么顶级组件模板呢？重构后新模板大部分相同，但course-detail-header组件除外：

1
2

<course-detail-header  [course]="course$ | async" [lessons]="lessons$ | async">
</course-detail-header>

这看起来比我们以前的版本好：我们看不到firstName的传递或者subscribe事件的冒泡。

那么在重构之后，course-detail-header中间组件现在是什么样子？

重构的中间组件

我们在这里可以看到，在重构之后，新版本的course-detail-header组件现在变得更加简单：

@Component({
    selector: 'course-detail-header',
    template: `
    <h2>{{course?.description}}</h2>
    <h5>Total lessons: {{lessons?.length}}</h5>
    <newsletter></newsletter>
`,
    changeDetection: ChangeDetectionStrategy.OnPush
})
export class CourseDetailHeaderComponent {
    @Input()
    course: Course;

    @Input()
    lessons: Lesson[];
}

该组件的新版本仍包含新闻通讯，但它不再是冒泡事件并传递组件本身不需要的数据。

所以这看起来比我们最初提出的版本要好很多。但现在订阅新闻通讯的功能在哪里？

现在让我们看看这个重构中的最后一个组件：叶子组件。

重构的叶子组件

正如我们所看到的，新闻通讯组件现在以完全不同的方式设计：

@Component({
    selector: 'newsletter',
    template: `
<fieldset class="newsletter">
    <legend>Newsletter</legend>
    <h5>Hello {{firstName}}, enter your email below to subscribe:</h5>
    <form>
        <input #email type="email" name="email">
        <input  type="button" class="button button-primary" value="Subscribe"
               (click)="subscribeToNewsletter(email)">
    </form>
</fieldset>
`})
export class NewsletterComponent implements OnInit {

    firstName:string;

    constructor(private userService: UserService,
        private newsletterService: NewsletterService) {}

    ngOnInit() {
        this.userService.user$.subscribe(user => this.firstName = user.firstName );
    }

    subscribeToNewsletter(email:string) {
        this.newsletterService.subscribeToNewsletter(email)
            .subscribe(
                () => alert('Subscription successful ...'),
                console.error);
    }
}

那么现在这个新版新闻通讯组件的最大设计差异是什么呢？

最大的区别实际上是这个新版本看起来很像容器组件！

正如我们所看到的，有时最好的解决方案是将服务深入到组件树中。这真的简化了本例中涉及的所有多个组件。

但是叶子组件的这种实现可以进一步改进，所以让我们进一步详细介绍这个设计，看看如何。

查看新的组件设计解决方案

这个特定组件树的新设计似乎更易于维护。不再冒泡自定义事件或通过组件树传递无关的input属性。

新闻通讯组件现在知道服务层，正在从中获取所有数据。它引用了新闻通讯服务，因此可以直接调用它。请注意，如果需要，此组件仍可以接收输入，稍后将详细说明。

利用`Angular`功能来获得更简单的设计

我们可以看到，在组件树的这个新版本中，我们现在正在利用Angular依赖注入系统在本地组件树中深入注入服务。

这允许深度嵌套的组件（如新闻通讯组件）直接从服务层接收数据，而不必通过输入接收数据。

这使得顶级组件和中间组件都更简单，并避免代码重复。它还允许将与服务层交互的逻辑深深地放入组件树中，如果这是最有意义的话。

当前新闻通讯组件实现的一个问题

这个新版本的新闻通讯组件只有一个问题：与以前版本的表现组件不同：

这个新版本不适用于OnPush变化检测！

使新闻通讯组件与`OnPush`兼容

在此之前您可能已经注意到，当我们切换组件以使用OnPush更改检测时，事情就会停止工作 - 即使我们没有在组件级别进行本地数据变动。

其中一个例子是当前版本的新闻通讯组件，它确实是不会反映模板上名字的新版本。

但是这里有一个与OnPush兼容的组件版本：

@Component({
    selector: 'newsletter',
    changeDetection: ChangeDetectionStrategy.OnPush,
    template: `
<fieldset class="newsletter">
    <legend>Newsletter</legend>
    <h5>Hello {{firstName$ | async }}, enter your email below to subscribe:</h5>
    ...
</fieldset>`})
export class NewsletterComponent implements OnInit {

    firstName$: Observable<string>;

    constructor( private userService: UserService,
        private newsletterService: NewsletterService) {}

    ngOnInit() {
        this.firstName$ = this.userService.user$.map(user =>  user.firstName );
    }

    subscribeToNewsletter(email:string) {
        this.newsletterService.subscribeToNewsletter(email)
            .subscribe(
                () => alert('Subscription successful ...'),
                console.error);
    }
}

那么这个新实现有什么不同呢？在这个版本的组件中，我们定义了一个名为firstName$的observable，我们已经使用async管道在模板中使用了它。

使用async管道将确保在发出新版本的firstName时（例如，当用户登录时）重新呈现组件，即使组件没有input - 因为sync管道将检测到observable发出了一个新值，因此它将标记该组件以进行重新渲染。

结论

因此，我们可以看到有许多可能的组件设计，具体取决于具体情况。如果需要，使用Angular依赖注入系统确实可以很容易地在组件树中深入注入服务。

因此，我们不一定必须通过组件树的多个级别传递数据和事件，因为这可能会因代码重复（以及其他问题）而导致可维护性问题。

但是，为什么在尝试应用容器+展示设计时，这种情况最终会如此发生？

因为自定义事件冒泡问题

这个设计可能最终被使用的一个主要原因可能是：在软件设计中，我们提供的名称可能会产生很大的影响。

而容器组件这个名称让我们认为只有路由的顶层组件应该具有这种类型的设计，并且它所使用的所有其他组件应该是展示性的，而事实并非如此。

容器这个名称并没有让我们想到像新闻通讯组件那样的叶子组件。

所以为了避免这个问题，这里有一个建议：如果我们需要为知道服务层的组件命名，并且有一个名称有助于应用程序设计讨论，我们可以调用它们，例如智能组件，并将术语容器保留为路由的顶级组件。

在实践中，根据需要混合和匹配多种类型的组件设计实际上更加实用，并且在必要时在树的不同级别使用不同类型的组件 - 根据需要混合不同的功能。

我希望你喜欢这篇文章，并且它有助于开始使用视图层设计。请务必查看上面架构系列上的其他文章！

(译)Angular架构01-智能组件与展示组件

Mon, 15 Oct 2018 14:04:46 +0000

这篇文章是正在进行的Angular架构系列的一部分，我们将在视图层和服务层一级介绍常见的设计问题和解决方案。这是完整系列：

视图层架构-智能组件与展示组件
视图层架构-容器与展示组件常见的设计缺陷
服务层架构-如何使用Observable数据服务构建Angular应用程序
服务层架构-Redux和Ngrx Store-何时使用Store？为什么？
服务层架构-Ngrx Store-架构指南

视图层架构简介

在构建Angular应用程序时，我们在开始时遇到的最常见问题是：我们如何构建应用程序？

我们可能会找到的直接答案是：我们将所有内容拆分为组件！但我们很快发现还有更多问题：

有哪些类型的组件？
组件应如何互动？
我应该将服务注入任何组件吗？
如何使我的组件可以跨视图重用？

我们将尝试通过将组件基本上分成两种类型来解答这个问题和其他问题（但还有更多内容）：

智能组件：有时也称为应用程序级组件，容器组件或控制器组件
展示组件：有时也称为纯组件或哑组件

让我们找出这两种组件之间的差异，我们何时应该使用它们以及为什么！

你也可以通过视频学习，它将一个组件重构为两个组件，视频中的示例我们将在下面描述。

将应用程序拆分为不同类型的组件

为了理解两种类型组件之间的区别，让我们从一个简单的应用程序开始，其中尚不存在组件分离。

我们开始构建应用程序的主屏幕，并为单个模板添加了多个功能：

@Component({
  selector: 'app-home',
  template: `
    <h2>All Lessons</h2>
    <h4>Total Lessons: {{lessons?.length}}</h4>
    <div class="lessons-list-container v-h-center-block-parent">
        <table class="table lessons-list card card-strong">
            <tbody>
            <tr *ngFor="let lesson of lessons" (click)="selectLesson(lesson)">
                <td class="lesson-title"> {{lesson.description}} </td>
                <td class="duration">
                    <i class="md-icon duration-icon">access_time</i>
                    <span>{{lesson.duration}}</span>
                </td>
            </tr>
            </tbody>
        </table>
    </div>
`,
  styleUrls: ['./home.component.css']
})
export class HomeComponent implements OnInit {

    lessons: Lesson[];

  constructor(private lessonsService: LessonsService) {
  }

  ngOnInit() {
      this.lessonsService.findAllLessons()
          .do(console.log)
          .subscribe(
              lessons => this.allLessons = lessons
          );
  }

  selectLesson(lesson) {
    ...
  }

}

理解问题

虽然这个主页组件仍然非常简单，但它已经开始具有相当大的尺寸。例如，我们已经实现了一个包含lesson列表的表。

但是应用程序的其他部分可能还需要此功能，例如，假设我们有另一个屏幕显示给定course的目录。

在该屏幕中，我们还希望显示lesson列表，但仅显示属于该course的lesson。在这种情况下，我们需要的东西与我们在主屏幕中实现的内容非常相似。

我们不应该只是跨组件复制粘贴，我们应该创建一个可重用的组件。

让我们创建一个展示组件

在这种情况下我们想要做的是将屏幕的表部分提取到一个单独的组件中，让我们称之为LessonsListComponent：

import {Component, OnInit, Input, EventEmitter, Output} from '@angular/core';
import {Lesson} from "../shared/model/lesson";

@Component({
  selector: 'lessons-list',
  template: `
      <table class="table lessons-list card card-strong">
          <tbody>
          <tr *ngFor="let lesson of lessons" (click)="selectLesson(lesson)">
              <td class="lesson-title"> {{lesson.description}} </td>
              <td class="duration">
                  <i class="md-icon duration-icon">access_time</i>
                  <span>{{lesson.duration}}</span>
              </td>
          </tr>
          </tbody>
      </table>  
  `,
  styleUrls: ['./lessons-list.component.css']
})
export class LessonsListComponent {

  @Input()
  lessons: Lesson[];

  @Output('lesson')
  lessonEmitter = new EventEmitter<Lesson>();

    selectLesson(lesson:Lesson) {
        this.lessonEmitter.emit(lesson);
    }

}

现在让我们仔细看看这个组件：它没有通过构造函数注入lesson服务。相反，它通过@Input接收输入属性中的lessons。

这意味着组件本身不知道lessons的来源：

lessons可能是所有lessons的清单
或者lessons可能是特定course所有lessons的清单
甚至lessons可能是任何给定搜索列表中的页面

我们可以在所有这些场景中重用此组件，因为lesson-list组件不知道数据来自何处。组件的责任纯粹是向用户呈现数据而不是从特定位置获取数据。

这就是我们通常将这种类型的组件称为展示组件的原因。但是Home组件发生了什么？

让我们创建一个智能组件

如果我们回到Home组件，这就是重构后的样子：

import { Component, OnInit } from '@angular/core';
import {LessonsService} from "../shared/model/lessons.service";
import {Lesson} from "../shared/model/lesson";

@Component({
  selector: 'app-home',
  template: `
      <h2>All Lessons</h2>
      <h4>Total Lessons: {{lessons?.length}}</h4>
      <div class="lessons-list-container v-h-center-block-parent">
          <lessons-list [lessons]="lessons" (lesson)="selectLesson($event)"></lessons-list>
      </div>
`,
  styleUrls: ['./home.component.css']
})
export class HomeComponent implements OnInit {

    lessons: Lesson[];

  constructor(private lessonsService: LessonsService) {
  }

  ngOnInit() {
     ...
  }

  selectLesson(lesson) {
    ...
  }

}

我们可以看到，我们已经用新的可重用lessons-list组件替换了主屏幕的列表部分。主组件仍然知道如何从服务中检索lesson列表，以及这是什么类型的列表（如果这些lesson是某个course的lesson等）。

但Home组件不知道如何向用户提供lesson。

Home组件是什么类型的组件？

让我们给这种类型的组件命名，类似于home组件，它是一个特定于应用程序的组件：让我们称之为智能组件。

这种类型的组件固有地绑定到应用程序本身，因此我们可以看到它在构造函数中接收一些特定于应用程序的依赖项，如LessonsService。

在另一个应用程序中使用此组件将非常困难。

我们视图的顶级组件可能永远是智能组件。即使我们将数据加载转移到路由器数据解析器，该组件仍然至少必须将ActivatedRoute服务注入其中。

因此，我们希望通过使用一组展示组件在内部编写来实现顶级智能组件。这就是那么简单。

智能组件和展示组件之间的典型交互

我们在这里看到的示例非常频繁，我们让智能组件通过@Input将数据注入展示组件，并接收展示组件可能通过@Output触发的任何操作。

在这种情况下，我们使用自定义lesson事件来指示我们已在列表中选择了给定lesson。

使用@Output，展示组件通过明确定义的界面与智能组件保持隔离：

lesson-list展示组件只知道它发出了一个事件，但不知道事件的接收者是什么，或接收者为响应事件做了什么
Home智能组件订阅lesson自定义事件并对事件做出反应，但它不知道是什么触发了事件。用户是否双击lesson列表或用户是否单击了视图按钮？这对智能组件是透明的。

所以这一切都清楚简单，这里可能出现什么问题？

拆分智能与展示组件的明确方法？

有了这个，我们可能会在这一点上得出结论，构建我们的应用程序就像使所有顶级组件成为智能组件一样简单，并使用本地展示组件树构建它们。

但问题是，它有时并不那么简单，因为像lesson这样的自定义事件不会冒泡。因此，如果您有一个深层组件，并且您希望上面有多个级别的组件来了解该事件，则该事件不会冒泡。

导致自定义事件不冒泡的问题是什么？

假设lesson列表和Home组件之间只有一层嵌套，我们有几个级别：lesson列表位于选项卡面板内的可折叠面板内。

lesson列表仍然希望通过lesson事件通知Home组件已选择lesson。但是中间TabPanel和CollapsiblePanel中的两个组件是非特定于应用程序的展示组件。

想象它们是Angular Material库的组成部分！

这些展示组件不了解lesson事件，因此无法将其冒泡。那么我们如何实现这一点，以及为什么自定义事件不能简单地冒泡？

为什么自定义事件不会冒泡，就像点击DOM事件一样？

这不是偶然的，它是设计的，可能是为了避免event soup场景，使用类似于AngularJs的$scope.$emit()和$scope.$broadcast()的服务总线的解决方案往往会意外创建。

这些类型的机制往往最终会在应用程序的不同位置之间创建紧密的依赖关系，这些依赖关系不应该彼此意识到，事件最终会被触发多次或依次触发，只看一个文件时就不明显了。

因此，展示组件的自定义事件只能由其父组件可见，而不能在更深的组件树可见。

如果由于某种原因我们确实需要冒泡行为，我们仍然可以使用Javascript原生的element.dispatchEvent()实现它。但大多数情况下，这不是我们想要实施的。

那么我们如何解决选项卡面板场景中可折叠面板内`lesson`列表的情况呢？

我们仍然应该为lesson列表创建一个展示组件。提供lesson的功能可以被隔离，因此LessonsListComponent的版本仍然适用，它只是在应用程序的各个地方使用的东西。但是这个列表如何通知Home组件？

为此，有几种解决方案。我们应该研究的一个解决方案，特别是在构建大规模应用程序时，应该研究像ngrx/store这样的解决方案。

但即使使用store解决方案，我们也可能不希望在展示组件中注入store。因为选择lesson的结果可能并不总是将事件分派给store。

为了简化示例，让我们首先创建一个专门的类似于store的服务来解决这个lesson选择问题：

@Injectable()
export class LessonSelectedService {

    private _selected: BehaviorSubject<Lesson> = new BehaviorSubject(null);

    public selected$ = this._selected.asObservable().filter(lesson => !!lesson);
    
    
    select(lesson:Lesson) {
         this._selected.next(lesson);
    }

}

正如我们所看到的，LessonSelectedService公开了一个可观察的selected$，它将在每次选择新lesson时发出一个值。

请注意，我们在服务内部创建了一个subject，但我们没有将它暴露给外部。这是因为subject本质上是一个事件总线，因此我们希望控制谁可以在服务中发出事件。

如果我们公开subject，我们会给应用程序的任何其他部分代表服务发出事件的能力，这是应该避免的。

那么如何使用这个服务，因为我们不能将它注入LessonsListComponent，对吧？我们将讨论该部分，现在让我们首先看看如何在Home组件中使用这个新服务。

在`Home`组件中使用新服务

Home组件将做的是，它将在其构造函数中注入新组件：

@Component({...})
export class HomeComponent implements OnInit {

    lessons: Lesson[];

  constructor(
        private lessonsService: LessonsService, 
        private lessonSelectedService: LessonSelectedService) {
  }

  ngOnInit() {
      ....
      this.lessonSelectedService.selected$.subscribe(lesson => this.selectLesson(lesson));
  }

  selectLesson(lesson) {
    ...
  }

}

正如我们所看到的，我们订阅了selected$这个Observable，它发出了新的lesson，我们触发了组件的特定逻辑来处理选择。

但请注意，Home组件不知道lesson列表，它只知道应用程序的其他部分触发了lesson选择。应用程序的两个部分仍然是隔离的：

选择的Emitter不知道Home组件
Home组件不知道该lesson
两个角色只知道LessonSelectedService

所以我们已经解决了这个问题吗？还没有，因为我们仍然不想在LessonListComponent中注入新服务，这将使它成为一个智能组件，我们希望将它保持为展示组件。那么如何解决这个问题呢？

如何将`LessonsListComponent`保持为展示组件？

实际上，解决问题的一种方法是使其成为智能组件;-)我们可以得出结论，在该表存在的应用程序的任何地方，我们总是想要触发对LessonSelectedService的调用。

这将使lesson-list组件成为应用程序特定组件，无论如何它可能已经存在。例如，我们可能不会发布此组件并在多个应用程序中使用它。

因此，这将解决问题，这意味着像Home组件这样的顶级应用程序组件可能由不仅仅是展示组件的组件树组成。

智能组件不仅仅是顶级组件

智能组件不必仅是顶级路由器组件。我们可以看到树中可能还有其他组件也会注入像LessonSelectedService这样的服务，并且不一定只从@Input()获取它们的数据。

将`LessonsListComponent`保持为展示组件的另一种解决方案

解决问题的另一种方法是保持lesson-list组件不变，并在需要的地方使用它。但在这种情况下，我们可以将它包装在一个智能组件中，该组件将注入LessonSelectedService：

@Component({
  selector: 'custom-lessons-list',
  template: `
       <lessons-list [lessons]="lessons" (lesson)="selectLesson($event)"></lessons-list>  
  `
})
export class CustomLessonsListComponent {

   constructor(private lessonSelectedService: LessonSelectedService) {

   }

   selectLesson(lesson) {
       this.lessonSelectedService.select(lesson); 
   }

}

在此我们创建了一个包装器智能组件，并将其称为CustomLessonsListComponent。在这种情况下，我们包装了我们自己的展示组件，但我们也可以包装来自第三方库的组件。

想象一下MyCustomCountrySelectDropdown，它包含一个通用下拉列表并使用来自具体服务的数据注入它。

如何确定要构建的组件？

在开始构建我们的应用程序时，并不总是很明显区分什么是智能组件，什么是展示组件。

那么如何在许多组件中拆分应用程序？即使页面的标题只使用一次，它应该是一个组件吗？

组织和可读性是创建组件的唯一原因，即使它仅在一个地方使用。在较小的文件中分隔内容有助于保持代码库的可维护性，并且使用Angular CLI在创建新组件时没有任何开销：使用单个命令，我们有一个工作组件，可以在几秒钟内粘贴标头。

如何进行组件设计

解决这个问题的一种方法是避免从一开始就定义什么是组件以及什么类型：我们可以从仅使用纯HTML和第三方组件构建顶级组件开始。

只有当模板开始变大时，我们才开始将其分解为组件。如果在屏幕的多个部分中使用了某些内容并且总是触发给定的操作（如调用store调度），我们可能会考虑重构为较小的智能组件。

如果稍后我们意识到我们需要呈现与我们刚刚创建的智能组件相同的数据，我们可以将展示部分从它中提取到展示组件中。

获得一组精心设计的组件的最佳方法是通过连续重构，这可以通过使用Angular CLI无负担地完成。

结论

在构建应用程序时，我们可以寻找机会将纯展示逻辑提取到展示组件中：这些只使用@Input和Output，并且在我们需要隔离展示逻辑并重用它时非常有用。

如果我们想要保持两个组件分离并且彼此不知道，则可以使用共享服务或store来完成组件树中的不同级别的智能组件之间或甚至兄弟之间的通信。

但我们可能还希望将组件完全注入到彼此中并创建紧密耦合，有时这是最佳解决方案。在这种情况下，通过例如@ViewChild将组件相互注入可能是最好的方法。

智能与展示组件是有用的区别

一般而言，智能与展示组件之间的区别是非常好记的，但它可能不适用于应用程序的所有组件。

我们可以拥有一个既知道服务又可以在树中更深层次地呈现一些数据的小组件，就像在lesson选择时调用store的lesson列表。

将此组件进一步拆分为智能和展示组件可能并非总是必要的。

智能与展示组件在自我省问时促进我们的思维方式：

这种展示逻辑在应用程序的其他地方是否有用？
将事情进一步分解会有用吗？
我们是否在应用中创建了意外的紧耦合？

我们不一定需要将构建的每个组件的所有渲染逻辑提取到单独的展示组件中。它更多的是在任何给定时间构建对我们的应用程序最有意义的组件，并且如果需要在CLI的简单连续迭代过程中进行重构。

我希望你喜欢这篇文章，并且它有助于开始使用视图层设计。请务必查看上面链接的架构系列上的其他文章！

(译)Angular NgRx Entity完全实用指南

Fri, 12 Oct 2018 14:48:58 +0000

使用 NgRx 构建我们的应用程序时，我们要做的第一件事就是确定在store中存储数据的最佳格式。

我们需要在任何 NgRx 应用程序中处理集中存储中的业务数据，但如果我们必须提出自己的临时解决方案，则该过程可能是重复且耗时的。

我们经常发现自己为不同类型的数据手写完全相同的 reducer 逻辑和 selector，这很容易出错并且会减慢开发过程。

在这篇文章中，我们将了解 NgRx 实体如何真正帮助我们处理store中的业务数据。

我们将详细了解 NgRx 实体及其使用的实体状态格式的价值主张是什么，我们将准确了解 NgRx 实体解决的问题，并知道何时使用它以及为什么使用它。

前言

请注意，这篇文章建立在其他store概念的基础上，例如action，reducers 和 selectors。如果您正在寻找 NgRx store架构的介绍，请看看这篇文章：Angular Service Layers: Redux, RxJs and Ngrx Store - When to Use a Store And Why?。

如果您正在寻找帮助设置 NgRx 开发环境的指南，包括 DevTools，带集成 router 的 time travelling 调试器和 NgRx Store Freeze，请查看：Angular Ngrx DevTools: Important Practical Tips。

所以，不用多说了，让我们开始深入了解我们的 NgRx 实体！让我们从头开始，首先了解什么是实体。

什么是实体(Entity)？

在 NgRx 中，我们在store中存储不同类型的状态，这通常包括：

业务数据，例如在线课程平台的 Course 或 Lesson
一些 UI 状态，例如用户设置 UI

实体代表某种业务数据，因此 Course 和 Lesson 就是实体类型的示例。

在我们的代码中，实体被定义为Typescript类型。例如，在在线课程系统中，最重要的实体是 Course 和 Lesson，使用这两种自定义对象类型定义：

export interface Course {
    id:number;
    description:string;
    iconUrl?: string;
    courseListIcon?: string;
    longDescription?: string;
    categories:string;
    seqNo: number;
    lessonsCount?:number;
    promo?:boolean;
}

export interface Lesson {
    id: number;
    description: string;
    duration: string;
    seqNo: number;
    courseId?: number;
    videoId?: string;
}

实体唯一标识符

我们可以看到，两个实体都有一个名为id的唯一标识符字段，可以是字符串或数字。这是一个技术标识符，对于给定的实体实例是唯一的：例如，没有两个课程具有相同的ID。

我们存储在store中的大多数数据都是实体！

如何在`store`中存储实体集合？

让我们假设我们想在内存store中存储一系列课程：我们将如何做到这一点？一种方法是在 courses 属性下将 courses 存储在一个数组中。

完整的store状态看起来像这样：

{
  courses: [
      {
        id: 0,
        description: "Angular Ngrx Course",
        categories: 'BEGINNER',
        seqNo: 1
    },
    {
        id: 1,
        description: "Angular for Beginners",
        categories: 'BEGINNER',
        seqNo: 2      
    },
    {
        id: 2,
        description: 'Angular Security Course - Web Security Fundamentals',
        categories: 'ADVANCED',
        seqNo: 3      
    },
    ...
  ],
  lessons: [
    {
        id: 1,
        "description": "Angular Tutorial For Beginners - Build Your First App - Hello World Step By Step",
        "duration": "4:17",
        "seqNo": 1,
        courseId: 1
    },
    {
        id: 2,
        "description": "Building Your First  Component - Component Composition",
        "duration": "2:07",
        "seqNo": 2,
        courseId: 1
    },        
     ...
  ]   
}

为什么不在数组中存储相关实体？

我们首先想到的是以数组的形式在store中存储实体，但这种方法可能会导致几个潜在的问题：

如果我们想根据它的已知id查找课程，我们将不得不遍历整个集合，这对于非常大的集合来说可能是低效的
更重要的是，通过使用数组，我们可能会意外地在数组中存储相同课程的不同版本（具有相同的id）
如果我们将所有实体存储为数组，我们的 reducers 对于每个实体看起来几乎相同
例如，假设将新实体添加到集合中的简单情况。我们将重新实现几次完全相同的逻辑，用于向集合中添加新实体并重新排序数组以获取特定的自定义排序顺序

我们可以看到，我们将实体存储在store中的格式对我们的程序有很大影响。

然后让我们试着找出在store中存储实体的理想格式。

设计实体`store`状态：数组或映射？

store的一个角色是充当内存客户端数据库，该数据库包含整个数据库的一部分，我们从客户端通过 selector 派生我们的视图模型。

这与传统的设计相反，后者包括通过 API 调用从服务器引入视图模型。因为存储是内存数据库，所以将业务实体存储在它们自己的内存数据库“表”中是有意义的，并为它们提供类似于主键的唯一标识符。

然后可以将数据扁平化，并使用实体唯一标识符链接在一起，就像在数据库中一样。

一种很好的建模方法是将实体集合存储在 Javascript 对象的形式下，就像映射一样。在此设置中，实体的键将是唯一ID，值将是整个对象。

在这种新格式中，整个store状态的是这样的：

{
    courses: {
        0: {
              id: 0,
              description: "Angular Ngrx Course",
              categories: 'BEGINNER',
              seqNo: 1
           },
        },
        1: {
              id: 1,
              description: "Angular for Beginners",
              categories: 'BEGINNER',
              seqNo: 2                  
        },
        2: {
              id: 2,
              description: "Angular Security Course - Web Security Fundamentals",
              categories: 'BEGINNER',
              seqNo: 3                  
        }
    },
    lessons: {
        1: {
            id: 1,
            "description": "Angular Tutorial For Beginners - Build Your First App - Hello World Step By Step",
            "duration": "4:17",
            "seqNo": 1,
            courseId: 1
        },
        2: {
            id: 2,
            "description": "Building Your First  Component - Component Composition",
            "duration": "2:07",
            "seqNo": 2,
            courseId: 1
        },
        ....
        35: {
            id: 35,
            "description": "Unidirectional Data Flow And The Angular Development Mode",
            "duration": "7:07",
            "seqNo": 6,
            courseId: 0
        }
    }
}

设计id查找的状态

我们可以看到，这种格式使得通过id查找实体非常简单，这是一种非常常见的操作。例如，为了查找id为1的 course，我们只需编写：

`1`	`state.courses[1]`

它还使状态变得扁平化，使得组合多个实体并通过 selector 查询“连接”它们变得更加简单。但是只有一个问题：我们丢失了关于集合顺序的信息！

这是因为与数组不同，Javascript 对象的属性没有关联它们的顺序。是否有任何仍然通过id在映射中存储我们的数据，并仍保留有关顺序信息的方法？

设计保存实体顺序的状态

是的，我们只需要同时使用映射和数组！我们将对象存储在一个映射（称为 entities）中，然后将顺序信息存储在一个数组中（称为 ids）：

{
    courses: {
        ids: [0, 1, 2],
        entities: {
            0: {
                  id: 0,
                  description: "Angular Ngrx Course",
                  categories: 'BEGINNER',
                  seqNo: 1                      
               },
            },
            1: {
                  id: 1,
                  description: "Angular for Beginners",
                  categories: 'BEGINNER',
                  seqNo: 2                                            
            },
            2: {
                  id: 2,
                  description: "Angular Security Course - Web Security Fundamentals",
                  categories: 'BEGINNER',
                  seqNo: 3                                            
            }
        }
    },
    lessons: {
        ids: [1, 2, ... 35],
        entities: {
            1: {
                id: 1,
                "description": "Angular Tutorial For Beginners - Build Your First App - Hello World Step By Step",
                "duration": "4:17",
                "seqNo": 1,
                courseId: 1
            },
            2: {
                id: 2,
                "description": "Building Your First  Component - Component Composition",
                "duration": "2:07",
                "seqNo": 2,
                courseId: 1
            },
            ....
            35: {
                id: 35,
                "description": "Unidirectional Data Flow And The Angular Development Mode",
                "duration": "7:07",
                "seqNo": 6,
                courseId: 0
            }
        }
    }
}

实体状态格式

这种状态格式将实体映射与id数组合在一起称为实体状态格式(Entity State format)。

这是将业务实体存储在集中式存储中的理想格式，但是如果我们必须从头开始手动编写它们，则在编写 reducer 和 selector 时保持此状态会带来额外的负担。

例如，如果我们必须编写一些类型定义来表示完整的存储状态，它们看起来像这样：

export interface StoreState {
    courses: CourseState:
    lessons: LessonsState;
}


export interface CoursesState {
     ids: number[];
     entities: {[key:number]: Course};
} 

export interface LessonsState {
     ids: number[];
     entities: {[key:number]: Lesson};
}

正如我们所看到的，我们已经在这里做了一些重复工作，因为类型 CoursesState 和 LessonsState 几乎相同。更重要的是，这两个实体的所有 reducer 和 selector 代码也非常相似。

编写支持实体状态格式的reducer

例如，一个用于 LoadCourse action 的 reducer，它接受当前的 CoursesState，并为其添加一个新的 course，并根据 seqNo 字段重新排序该集合。

以下就是 LoadCourse action 的 reducer 逻辑：

const initialCoursesState: CoursesState = {
    ids: [],
    entities: {}
}

function sortBySeqNo(e1: Course, e2: Course) {
      return e1.seqNo - e2.seqNo;
}

export function coursesReducer(
   state = initialCoursesState, 
    action: CourseActions): CoursesState {
    switch (action.type) {
        case CourseActionTypes.COURSE_LOADED:
             // push new id to array and re-order
             const ids = state.ids.slice(0);
             ids.push(action.course.id);
             ids.sort(sortBySeqNo);
             // build a new courses state
             return {
                 ids,
                 entities: {
                     ...state.entities, 
                     action.payload.course
                 }
             };
        default: 
            return state;
    }
}

正如我们所看到的，只需在store中添加 course 即可。问题是我们必须为其他常见操作编写类似的代码，例如更新store中的 course 或删除它。

避免重复的 reducer 逻辑

但是比这更大的问题是，将一个 Lesson 加载到 LessonsState 中的等效 LoadLesson 操作的代码几乎相同：

const initialLessonsState: LessonsState = {
    ids: [],
    entities: {}
}

function sortBySeqNo(e1: Lesson, e2: Lesson) {
      return e1.seqNo - e2.seqNo;
}

export function lessonsReducer(
    state = initialLessonsState, 
    action: LessonActions): LessonsState {
    switch (action.type) {
        case CourseActionTypes.LESSON_LOADED:
             // push new id to array and re-order
             const ids = state.ids.slice(0);
             ids.push(action.lesson.id);
             ids.sort(sortBySeqNo);
             return {
                 ids,
                 entities: {
                     ...state.entities, 
                     action.payload.lesson
                 }
             };
        default: 
            return state;
    }
}

除了使用 Lesson 类型而不是 Course 之外，此代码几乎与我们之前编写的 reducer 逻辑完全一样！

我们可以看到，将我们的实体保留在这个双数组和映射场景中会产生大量重复代码。

避免重复的selector逻辑

除了重复的类型定义，重复的初始状态和几乎相同的 reducer 逻辑之外，我们还会有很多几乎相同的 selector 逻辑。

例如，以下是 Course 实体的一些常用selector，它选择store中可用的所有 course：

export const selectCoursesState = 
      createFeatureSelector<CoursesState>("courses");

export const selectAllCourses = createSelector(
    selectCoursesState,
    coursesState => {
        const allCourses = Object.values(coursesState.entities)
        allCourses.sort(sortBySeqNo);
        return allCourses;
    }
);

功能selector的快速说明

注意 selectCoursesState 功能 selector，这是一个辅助 selector，它只接受整个store状态的 courses 属性，如下所示：

`1`	`storeState["courses"]`

使用此实用程序的优点是类型安全，并且可以很容易地定义延迟加载的 selector，这些 selector 无法访问根 store 状态的类型定义。

selector selectAllCourses 获取 store 中的所有 courses 并将它们放入数组中，并根据 seqNo 字段对数组进行排序。

问题是我们需要一些几乎相同的逻辑用于 Lesson 实体：

export const selectLessonsState = 
      createFeatureSelector<LessonsState>("lessons");

export const selectAllLessons = createSelector(
    selectLessonsState,
    lessonsState => {
        const allLessons = Object.values(lessonsState.entities)
        allLessons.sort(sortBySeqNo);
        return allLessons;
    }
);

我们可以看到，这段代码几乎与我们之前为 Course 实体编写的 selector 完全相同。

大量重复代码

让我们总结一下到目前为止我们看到的几乎相同的代码类型：

实体状态定义（如 CoursesState 和 LessonsState）
初始reducer状态（如 initialCoursesState 和 initialLessonsState）
reducer 逻辑
selector 逻辑

大量的重复代码，只是为了将这种采用优化的实体状态格式的数据保存在我们的数据库中。问题是，这是在store中存储相关实体的理想格式，如果我们不使用它，我们可能最终会遇到其他问题。

好消息是我们可以通过利用NgRx实体来避免几乎所有这些重复的代码！

什么是 NgRx 实体，何时使用它？

NgRx 实体是一个小型库，可帮助我们将实体保持在这种理想的实体状态格式（ID数组加上实体映射）。

该库旨在与NgRx Store结合使用，实际上是 NgRx 生态系统的关键部分。从我们的项目开始使用 NgRx 实体，而不是尝试使用我们自己的特殊内存数据库格式，这样做要好得多。

现在让我们学习 NgRx 实体提供给我们编写 NgRx 应用程序的许多方法。

定义实体状态

回到我们的 Course 实体，让我们现在使用 NgRx 实体重新定义实体状态：

1
2
3

export interface CoursesState extends EntityState<Course> {

}

这与我们之前编写的类型定义相同，但我们现在不必为每个单独的实体定义 id 和 entities 属性。相反，我们可以简单地从 EntityState 继承，同时具有相同的类型安全性，以及更少的代码。

NgRx实体适配器(Entity Adapter)

为了能够使用NgRx Entity的其他功能，我们需要首先创建一个实体适配器。适配器是一个实用程序类，它提供了一系列实用程序函数，旨在更简单地操作实体状态。

适配器允许我们以更简单的方式编写所有初始实体状态，reducers 和 selector，同时仍然将我们的实体保持为标准的 EntityState 格式。

以下是 Course 实体的适配器，配置为使用 seqNo 字段对实体进行排序：

export const adapter : EntityAdapter<Course> = 
   createEntityAdapter<Course>({
       sortComparer: sortBySeqNo
   });

定义默认实体排序顺序

请注意，我们使用了可选的 sortComparer 属性，该属性用于设置 Course 实体的排序顺序，这将决定该实体的id数组的顺序。

如果我们不使用此可选属性，则将使用id字段对 Course 进行排序。

使用 NgRx 实体编写更简单的 reducer

现在让我们使用适配器并使用它来定义我们的 Reducer 所需的初始状态。

然后我们将实现与以前相同的 reducer 逻辑：

export const initialCoursesState: CoursesState = 
      adapter.getInitialState();

export function lessonsReducer(
    state = initialLessonsState, 
    action: LessonActions): LessonsState {
    switch (action.type) {
        case LessonActionTypes.LESSON_LOADED:
             return adapter.addOne(action.payload.lesson, state);
        default: 
            return state;
    }
}

注意现在使用适配器编写 reducer 逻辑会更容易。适配器将帮助我们操作现有的 CourseState，方法是在 addOne 中调用我们之前手动执行的所有操作：

addOne 将创建现有状态对象的副本，而不是改变现有状态
然后 addOne 将创建一个 ids 数组的副本，它将在正确的排序位置添加新的 Course
将创建实体对象的副本，该副本指向所有先前的 Course 对象，而无需通过深层副本重新创建这些对象
新实体对象将添加新 Course

使用实体适配器的好处

正如我们所看到的，通过使用适配器编写我们的 reducer，我们可以节省大量的工作并避免常见的 reducer 逻辑错误，因为这种类型的逻辑很容易出错。

偶然地改变存储状态并不常见，这可能会导致问题，特别是如果我们在我们的应用程序中使用OnPush更改检测。

使用适配器可以防止所有这些问题，同时减少编写 reducer 所需的大量代码。

NgRx Entity适配器支持的操作

除了 addOne 之外，NgRx 实体适配器还支持一系列常见的集合修改操作，否则我们必须亲自实现。

以下是所有受支持操作的完整示例：

export function coursesReducer(
    state = initialCoursesState, 
    action: CourseActions): CoursesState {
  switch (action.type) {
    case CourseActions.ADD_COURSE: {
      return adapter.addOne(action.payload.course, state);
    }

    case CourseActions.UPSERT_COURSE: {
      return adapter.upsertOne(action.payload.course, state);
    }

    case CourseActions.ADD_COURSES: {
      return adapter.addMany(action.payload.courses, state);
    }

    case CourseActions.UPSERT_COURSES: {
      return adapter.upsertMany(action.payload.courses, state);
    }

    case CourseActions.UPDATE_COURSE: {
      return adapter.updateOne(action.payload.course, state);
    }

    case CourseActions.UPDATE_COURSES: {
      return adapter.updateMany(action.payload.courses, state);
    }

    case CourseActions.DELETE_COURSE: {
      return adapter.removeOne(action.payload.id, state);
    }

    case CourseActions.DELETE_COURSES: {
      return adapter.removeMany(action.payload.ids, state);
    }

    case CourseActions.LOAD_COURSES: {
      return adapter.addAll(action.payload.courses, state);
    }

    case CourseActions.CLEAR_COURSES: {
      return adapter.removeAll(state);
    }

    default: {
      return state;
    }
  }
}

适配器方法的行为方式如下：

addOne：向集合中添加一个实体
addMany：添加多个实体
addAll：用新的集合替换整个集合
removeOne：删除一个实体
removeMany：删除多个实体
removeAll：清除整个集合
updateOne：更新一个现有实体
updateMany：更新多个现有实体
upsertOne：更新或插入一个实体
upsertMany：更新或插入多个实体

现在想象一下，如果我们必须自己实现所有这些 reducer 逻辑，那会是什么样的！

使用NgRx Entity Selectors

NgRx 实体帮助我们的另一件事是使用常用的 selector，例如 selectAllCourses 和 selectAllLessons。

通过运行以下命令，我们可以随时生成一系列常用的 selector：

export const {
  selectAll,
  selectEntities,
  selectIds,
  selectTotal

} = adapter.getSelectors();

这些 selector 都可以直接在我们的组件中使用，也可以作为构建其他 selector 的起点。

请注意，这些 selector 都以与实体无关的方式命名，因此如果在同一文件中需要多个 selector，建议按以下方式导入它们：

import * as fromCourses from './courses.reducers';

// 这相当于我们之前手动编写的 selectAllCourses
const selectAllCourses = fromCourses.selectAll;

这些 selector 随时可以使用，并且与我们自己手动编写的 selector 一样安全。

NgRx实体的目的不是为了做什么

请注意，尽管 NgRx Entity 使得编写 Course 实体的状态，reducer 和 selector 逻辑变得更加容易，但我们仍然必须编写 reducer 函数本身，尽管这样使用适配器的方式更简单。

使用 NgRx 实体不会避免必须为每个实体编写 reducer 逻辑，尽管这使它更简单。

这意味着对于 Lesson 实体，我们必须做一些非常相似的事情。惯例是将所有这些密切相关的代码直接放在我们定义了实体 reducer 函数的同一文件中。

对于 Lesson 实体，这就是完整的 lesson.reducers.ts 文件的样子：

export interface LessonsState extends EntityState<Lesson> {

}

export const adapter : EntityAdapter<Lesson> =
  createEntityAdapter<Lesson>({sortComparer: sortBySeqNo});


const initialLessonsState = adapter.getInitialState();

export function lessonsReducer(
    state = initialLessonsState,
    action: LessonActions): LessonsState {

  switch(action.type) {
    case CourseActionTypes.LESSON_LOADED:
             return adapter.addOne(action.payload.course, state);
    default:
      return state;
  }
}

export const {
  selectAll,
  selectEntities,
  selectIds,
  selectTotal

} = adapter.getSelectors();

实际上，每个实体的 reducer 逻辑略有不同，因此 reducer 功能之间不会重复代码。

如果您正在寻找更进一步的解决方案，并且无需编写实体特定的 reducer 逻辑，请查看ngrx-data。

配置自定义唯一ID字段

正如我们所提到的，我们程序中的实体都应该有一个名为id的技术标识符字段。但如果由于某种原因，这个领域：

在给定实体中不可用
或者它有不同的名称
或者我们只是想使用恰好是 natural key 的另一个属性

我们仍然可以通过向适配器提供自定义 idselector 功能来实现。这是一个例子：

export const adapter : EntityAdapter<Lesson> = 
      createEntityAdapter<Lesson>({
        sortComparer: sortBySeqNo,
        selectId: lesson => lesson.courseId + '-' + lesson.seqNo
    });

适配器将调用此函数以从给定实体中提取唯一键。

在此示例中，我们通过将 courseId 属性与 Lesson 序号连接来为 Lesson 实体创建唯一标识符，该序号对于给定的 Lesson 是唯一的。

处理自定义状态属性

到目前为止，我们只是通过扩展 EntityState 类型来定义我们的实体状态。但可能我们的实体状态还具有除标准ID和实体之外的其他自定义属性。

假设对于 Course 实体，我们还需要一个额外的标志来指示 courses 是否已经加载。我们可以在 CoursesState 中定义额外的状态属性，然后使用适配器在 reducer 逻辑中更新该属性。

以下是 CoursesState reducer 文件 courses.reducers.ts 的完整示例，现在包括额外的 state 属性：

export interface CoursesState extends EntityState<Course> {
  allCoursesLoaded:boolean;
}

export const adapter : EntityAdapter<Course> =
  createEntityAdapter<Course>();

export const initialCoursesState: CoursesState = 
      adapter.getInitialState({
        allCoursesLoaded: false
    });

export function coursesReducer(
  state = initialCoursesState , 
  action: CourseActions): CoursesState {
  switch(action.type) {
    case CourseActionTypes.COURSE_LOADED:
      return adapter.addOne(action.payload.course, state);
    case CourseActionTypes.ALL_COURSES_LOADED:
      return adapter.addAll(
                action.payload.courses, {
                    ...state, 
                  allCoursesLoaded:true
                });
    default: {
      return state;
    }
  }
}

export const {
  selectAll,
  selectEntities,
  selectIds,
  selectTotal

} = adapter.getSelectors();

以下是我们必须要做的事情，包括这个额外的属性：

首先，我们将 allCoursesLoaded 属性添加到 CoursesState 的类型定义中
接下来，我们需要通过将一个可选对象传递给对 getInitialState() 的调用来在 initialCoursesState 中定义此属性的初始值
我们现在可以在我们的 reducer 逻辑中设置这个属性，就像我们在ALL_COURSES_LOADED reducer中一样。
为此，我们简单地需要使用spread（…运算符）制作 CourseState 的副本，然后我们修改属性并将这个新状态对象传递给适配器调用

使用NgRx Schematics脚手架生成实体

如果您想快速生成我们在本文中展示的 reducer 文件，您可以通过使用NgRx Schematics获得一个非常好的开始。

要使用实体 Schematics，我们需要做的第一件事是设置此CLI属性：

`1`	`ng config cli.defaultCollection @ngrx/schematics`

在此之后，我们可以通过运行以下命令生成一个全新的Lesson reducer文件：

`1`	`ng generate entity --name Lesson --module courses/courses.module.ts`

NgRx实体 Schematics 生成什么？

现在让我们查看上面命令生成的输出。首先，我们有一个空的Entity模型文件：

1
2
3

export interface Lesson {
  id: string;
}

Schematics 命令还将生成一个完整的 Action 文件，每个 Action 对应于实体适配器中的一个状态修改方法：

export enum LessonActionTypes {
  LoadLessons = '[Lesson] Load Lessons',
  AddLesson = '[Lesson] Add Lesson',
  UpsertLesson = '[Lesson] Upsert Lesson',
  AddLessons = '[Lesson] Add Lessons',
  UpsertLessons = '[Lesson] Upsert Lessons',
  UpdateLesson = '[Lesson] Update Lesson',
  UpdateLessons = '[Lesson] Update Lessons',
  DeleteLesson = '[Lesson] Delete Lesson',
  DeleteLessons = '[Lesson] Delete Lessons',
  ClearLessons = '[Lesson] Clear Lessons'
}

export class LoadLessons implements Action {
  readonly type = LessonActionTypes.LoadLessons;

  constructor(public payload: { lessons: Lesson[] }) {}
}

export class AddLesson implements Action {
  readonly type = LessonActionTypes.AddLesson;

  constructor(public payload: { lesson: Lesson }) {}
}

export class UpsertLesson implements Action {
  readonly type = LessonActionTypes.UpsertLesson;

  constructor(public payload: { lesson: Lesson }) {}
}

export class AddLessons implements Action {
  readonly type = LessonActionTypes.AddLessons;

  constructor(public payload: { lessons: Lesson[] }) {}
}

export class UpsertLessons implements Action {
  readonly type = LessonActionTypes.UpsertLessons;

  constructor(public payload: { lessons: Lesson[] }) {}
}

export class UpdateLesson implements Action {
  readonly type = LessonActionTypes.UpdateLesson;

  constructor(public payload: { lesson: Update<Lesson> }) {}
}

export class UpdateLessons implements Action {
  readonly type = LessonActionTypes.UpdateLessons;

  constructor(public payload: { lessons: Update<Lesson>[] }) {}
}

export class DeleteLesson implements Action {
  readonly type = LessonActionTypes.DeleteLesson;

  constructor(public payload: { id: string }) {}
}

export class DeleteLessons implements Action {
  readonly type = LessonActionTypes.DeleteLessons;

  constructor(public payload: { ids: string[] }) {}
}

export class ClearLessons implements Action {
  readonly type = LessonActionTypes.ClearLessons;
}

export type LessonActions =
 LoadLessons
 | AddLesson
 | UpsertLesson
 | AddLessons
 | UpsertLessons
 | UpdateLesson
 | UpdateLessons
 | DeleteLesson
 | DeleteLessons
 | ClearLessons;

查看Actions文件的内容

此文件遵循 Actions 文件的正常建议结构：

一个枚举 LessonActionTypes，每个 Lesson action 一个条目
每个 action 一个类，数据通过 payload 属性传递给 action
底部的一个联合类型 LessonActions，包含此文件的所有 action 类

最后一个联合类型对于编写 reducer 逻辑特别有用。多亏了它，我们可以在 Reducer 的 case 块中进行完整的类型推断和 IDE auto-completion。

NgRx实体 `Update<T>` 类型

另请注意，在某些操作的定义中，我们使用的是Update <Lesson>类型。这是NgRx实体提供的辅助类型，用于帮助模型部分实体更新。

此类型具有标识更新实体的属性标识，以及另一个名为 changes 的属性，该属性指定对实体进行的修改。

以下是 Course 类型的有效更新对象示例：

const update: Update<Course> = {
    id: 1,
    changes: {
        description: "NgRx In Depth",
        categories: 'INTERMEDIATE'
    }
};

查看 reducer 文件的内容

NgRx Entity Schematics 命令还将如期生成Entity reducer文件和 test 文件。以下是reducer文件的内容：

export interface State extends EntityState<Lesson> {

}

export const adapter: EntityAdapter<Lesson> = 
      createEntityAdapter<Lesson>();

export const initialState: State = 
      adapter.getInitialState({});

export function reducer(
  state = initialState,
  action: LessonActions
): State {
  switch (action.type) {
    case LessonActionTypes.AddLesson: {
      return adapter.addOne(action.payload.lesson, state);
    }

    case LessonActionTypes.UpsertLesson: {
      return adapter.upsertOne(action.payload.lesson, state);
    }

    case LessonActionTypes.AddLessons: {
      return adapter.addMany(action.payload.lessons, state);
    }

    case LessonActionTypes.UpsertLessons: {
      return adapter.upsertMany(action.payload.lessons, state);
    }

    case LessonActionTypes.UpdateLesson: {
      return adapter.updateOne(action.payload.lesson, state);
    }

    case LessonActionTypes.UpdateLessons: {
      return adapter.updateMany(action.payload.lessons, state);
    }

    case LessonActionTypes.DeleteLesson: {
      return adapter.removeOne(action.payload.id, state);
    }

    case LessonActionTypes.DeleteLessons: {
      return adapter.removeMany(action.payload.ids, state);
    }

    case LessonActionTypes.LoadLessons: {
      return adapter.addAll(action.payload.lessons, state);
    }

    case LessonActionTypes.ClearLessons: {
      return adapter.removeAll(state);
    }

    default: {
      return state;
    }
  }
}

export const {
  selectIds,
  selectEntities,
  selectAll,
  selectTotal,
} = adapter.getSelectors();

如何最好地使用 Schematics 输出？

请注意生成的 Schematics 文件（与生成CLI的任何其他文件一样）并不意味着保持不变。

实际上，您可能甚至不想使用 actions 文件，而是使用给定的一组约定编写自己的操作，例如本演讲中推荐的约定。

此外，可能并非所有操作都需要在应用程序中进行，因此仅保留我们需要的操作并对其进行调整非常重要。像往常一样，Schematics 生成的文件只是一个有用的开端，需要根据具体情况进行调整。

Github 仓库中可运行的例子

有关如何将 NgRx 实体与我们在示例中使用的两个实体（Course 和 Lesson）一起使用的小型应用程序的完整运行示例，请查看此仓库。

以下是NgRx DevTools，显示了两个实体的store内容：

结论

NgRx 实体是一个非常有用的包，但为了理解它首先要熟悉基本存储概念（如Actions，Reducers 和 Selectors）以及一般的store体系结构。

如果我们已经熟悉这些概念，我们可能已经尝试找到构建store内数据的最佳方法。

NgRx 实体通过为我们的业务实体提供实体状态格式来为此提供答案，该格式针对id进行查找而优化，同时仍保留实体订单信息。

NgRx 实体适配器与 NgRx Schematics 一起使得使用 NgRx 实体来存储我们的数据变得非常简单。

但请注意，并非所有store都需要使用NgRx实体！

NgRx Entity 专门用于处理我们store中的业务实体，使得以方便的方式将它们存储在内存中。

了解有关 NgRx 生态系统的更多信息

我希望这篇文章能帮助您开始使用Ngrx Entity，并且希望您喜欢它！

如果您希望了解如何开始使用NgRx生态系统，您可能需要查看本系列之前的博文：

iptables详解-5-实用匹配扩展iprange,string,time

Wed, 22 Aug 2018 08:59:15 +0000

本章介绍三个实用的规则匹配扩展模块¹：iprange 、string 和 time。

  注意

本系列文章测试环境为 centos 7，iptables 版本 1.4.21。

iprange 扩展

iptables 匹配IP地址时，-s 和 -d 选项只能指定离散的IP地址，不能指定连续的IP地址，这时候就需要 iprange 扩展模块。该模块包含了两个选项：

[!] –src-range from[-to]
[!] –dst-range from[-to]

拒绝来自 10.211.54.111 到 10.211.55.11 范围的IP地址报文

iptables -I INPUT -m iprange --src-range 10.211.55.3-10.211.55.11 -j DROP
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 34 packets, 2308 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            source IP range 10.211.55.3-10.211.55.11

string 扩展

string 扩展可以匹配报文中的字符串或者字节流，是一个比较实用的扩展。该扩展的选项如下：

--algo {bm|kmp} 指定字符串匹配算法，必填选项(算法介绍可以参考这两篇文章bm，kmp)
--from offset 指定在报文中的起始偏移量，默认为0，可选项
--to offset 指定在报文中的结束偏移量，默认是报文大小，可选项
[!] --string pattern 匹配字符串
[!] --hex-string pattern 匹配十六进制字节流

下面让我们实际应用一下该扩展。这里我们在 10.211.55.19 搭建了一个 http 服务，包含两个页面：

curl 10.211.55.19/drop.html -v                      
* About to connect() to 10.211.55.19 port 80 (#0)
*   Trying 10.211.55.19...
* Connected to 10.211.55.19 (10.211.55.19) port 80 (#0)
> GET /drop.html HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.211.55.19
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: openresty/1.13.6.1
< Date: Thu, 23 Aug 2018 00:59:18 GMT
< Content-Type: text/html
< Content-Length: 8
< Last-Modified: Wed, 22 Aug 2018 09:11:45 GMT
< Connection: keep-alive
< ETag: "5b7d28d1-8"
< Accept-Ranges: bytes
<
drop
me
* Connection #0 to host 10.211.55.19 left intact
#####################################################
curl 10.211.55.19/hello.html -v                     
* About to connect() to 10.211.55.19 port 80 (#0)
*   Trying 10.211.55.19...
* Connected to 10.211.55.19 (10.211.55.19) port 80 (#0)
> GET /hello.html HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.211.55.19
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: openresty/1.13.6.1
< Date: Thu, 23 Aug 2018 00:59:52 GMT
< Content-Type: text/html
< Content-Length: 12
< Last-Modified: Wed, 22 Aug 2018 09:11:59 GMT
< Connection: keep-alive
< ETag: "5b7d28df-c"
< Accept-Ranges: bytes
<
hello world
* Connection #0 to host 10.211.55.19 left intact

拒绝包含 world 字符串的报文

iptables -F OUTPUT
iptables -I OUTPUT -m string --algo kmp --string "world" -j REJECT
iptables -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 15 packets, 2432 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "world" ALGO name kmp TO 65535 reject-with icmp-port-unreachable

因为我们要用测试机获取 10.211.55.19 上的页面，所以 iptables 规则要写在 OUTPUT 链上。再使用测试机 curl 一下 hello.html 页面，发现无法获取页面内容：

curl 10.211.55.19/hello.html -v                     
* About to connect() to 10.211.55.19 port 80 (#0)
*   Trying 10.211.55.19...
* Connected to 10.211.55.19 (10.211.55.19) port 80 (#0)
> GET /hello.html HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.211.55.19
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: openresty/1.13.6.1
< Date: Thu, 23 Aug 2018 01:00:03 GMT
< Content-Type: text/html
< Content-Length: 12
< Last-Modified: Wed, 22 Aug 2018 09:11:59 GMT
< Connection: keep-alive
< ETag: "5b7d28df-c"
< Accept-Ranges: bytes
<                       
^C

查看 OUTPUT 链，拦截了96个报文：

iptables -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 220 packets, 15689 bytes)
 pkts bytes target     prot opt in     out     source               destination
   96  7704 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "world" ALGO name kmp TO 65535 reject-with icmp-port-unreachable

拒绝包含 drop\nme 字节流的报文查看 ascii 表，可以知道 \n 的十六进制值为 0A。

iptables -I OUTPUT -m string --algo kmp --hex-string "drop|0A|me" -j REJECT
iptables -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 31 packets, 4008 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|64726f700a6d65|" ALGO name kmp TO 65535 reject-with icmp-port-unreachable
  108  8640 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "world" ALGO name kmp TO 65535 reject-with icmp-port-unreachable

"drop|0A|me" 被转化成了纯字节流字符串 "|64726f700a6d65|"。再使用测试机 curl 一下 drop.html 页面，发现无法获取页面内容：

curl 10.211.55.19/drop.html -v                      
* About to connect() to 10.211.55.19 port 80 (#0)
*   Trying 10.211.55.19...
* Connected to 10.211.55.19 (10.211.55.19) port 80 (#0)
> GET /drop.html HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.211.55.19
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: openresty/1.13.6.1
< Date: Thu, 23 Aug 2018 01:01:43 GMT
< Content-Type: text/html
< Content-Length: 8
< Last-Modified: Wed, 22 Aug 2018 09:11:45 GMT
< Connection: keep-alive
< ETag: "5b7d28d1-8"
< Accept-Ranges: bytes
<                      
^C

查看 OUTPUT 链，拦截了54个报文：

iptables -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 490 packets, 34180 bytes)
 pkts bytes target     prot opt in     out     source               destination
   54  4140 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|64726f700a6d65|" ALGO name kmp TO 65535 reject-with icmp-port-unreachable
  108  8640 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "world" ALGO name kmp TO 65535 reject-with icmp-port-unreachable

  注意

http 协议是基于 tcp 协议的可靠连接，当客户端未得到响应时，会尝试重传，尝试一定次数后才确认请求失败。所以上述两条规则匹配到的报文数最后都会达到108。

iptables -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 2202 packets, 279K bytes)
 pkts bytes target     prot opt in     out     source               destination
  108  8208 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "|64726f700a6d65|" ALGO name kmp TO 65535 reject-with icmp-port-unreachable
  108  8640 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "world" ALGO name kmp TO 65535 reject-with icmp-port-unreachable

  注意

实验过程中，发现使用 bm 算法时，无法匹配目标字符串。

time扩展

time 扩展可以匹配报文到达时间。该扩展的常用选项有：

--datestart YYYY[-MM[-DD[Thh[:mm[:ss]]]]]
--datestop YYYY[-MM[-DD[Thh[:mm[:ss]]]]]
--timestart hh:mm[:ss]
--timestop hh:mm[:ss]
[!] --monthdays day[,day...] 没有31的月份会忽略31，二月份还会忽略29，30
[!] --weekdays day[,day...] 星期选项可以是 1-7 的数字，或者英文缩写 Mon, Tue, Wed, Thu, Fri, Sat, Sun。只使用两个字母也是允许的：Mo, Tu, We, Th, Fr, Sa, Su

周六周日 00:00-00:06, 21:00-23:59 不提供网页服务

iptables -F OUTPUT
iptables -I OUTPUT -p tcp -m multiport --dports 80,443 -m time --weekdays Sa,Su --timestart 21:00  --timestop 06:00 -j REJECT
iptables -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 7 packets, 1272 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 80,443 TIME from 21:00:00 to 06:00:00 on Sat,Sun UTC reject-with icmp-port-unreachable

man iptables-extensions 8 ↩︎

iptables详解-4-规则匹配

Tue, 21 Aug 2018 14:35:08 +0000

本章介绍更多的规则匹配条件。

  注意

本系列文章测试环境为 centos 7，iptables 版本 1.4.21。

源IP地址

指定多个IP地址

iptables -I INPUT -s 10.211.55.9,10.211.55.10 -j DROP
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 40 packets, 2652 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *       10.211.55.10         0.0.0.0/0
    0     0 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0

指定某个网段

iptables -I INPUT -s 10.211.0.0/16 -j ACCEPT
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 27 packets, 2293 bytes)
 pkts bytes target     prot opt in     out     source               destination
   40  2772 ACCEPT     all  --  *      *       10.211.0.0/16        0.0.0.0/0
    0     0 DROP       all  --  *      *       10.211.55.10         0.0.0.0/0
    0     0 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0

对源IP地址取反

iptables -F INPUT
iptables -A INPUT ! -s 10.211.55.9 -j ACCEPT
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
   53  4145 ACCEPT     all  --  *      *      !10.211.55.9          0.0.0.0/0

上述规则的意思为报文的源IP地址不是 10.211.55.9 的，都执行 ACCEPT 操作。让我们使用测试机 ping 一下：

ping 10.211.55.19                                  
PING 10.211.55.19 (10.211.55.19) 56(84) bytes of data.
64 bytes from 10.211.55.19: icmp_seq=1 ttl=64 time=0.401 ms
64 bytes from 10.211.55.19: icmp_seq=2 ttl=64 time=0.261 ms
64 bytes from 10.211.55.19: icmp_seq=3 ttl=64 time=0.258 ms
^C
--- 10.211.55.19 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.258/0.306/0.401/0.069 ms

我们可以看到，测试机仍然可以 ping 通目标机器。这是因为，当所有规则都未匹配时，会使用链的默认策略执行操作，而现在 INPUT 链的默认规则为 ACCEPT。查看 INPUT 链情况：

iptables -nvL INPUT
Chain INPUT (policy ACCEPT 3 packets, 252 bytes)
 pkts bytes target     prot opt in     out     source               destination
  505 41315 ACCEPT     all  --  *      *      !10.211.55.9          0.0.0.0/0

从输出结果可以看到，默认策略接受了3个报文，总大小为252b。

目标IP地址

iptables 使用 -d, --destination 选项指定目标IP地址，表示报文要发到哪里去。查看当前机器的IP地址：

ifconfig | awk '/inet\>/ {print $2}'
10.211.55.19
127.0.0.1
192.168.122.1

拒绝向 192.168.122.1 发送报文

iptables -I INPUT -d 192.168.122.1 -j DROP
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *       0.0.0.0/0            192.168.122.1
 5192  416K ACCEPT     all  --  *      *      !10.211.55.9          0.0.0.0/0

-d 和 -s 选项一样，支持多地址以及网段，也可以取反。

协议

-p, --protocol 选项指定匹配报文的协议。

拒绝来自 10.211.55.9 的 tcp 报文

iptables -F INPUT
iptables -I INPUT -s 10.211.55.9 -d 10.211.55.19 -p tcp -j REJECT
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 32 packets, 2092 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     tcp  --  *      *       10.211.55.9          10.211.55.19         reject-with icmp-port-unreachable

使用测试机 telnet 一下:

1
2
3

telnet 10.211.55.19 22                              
Trying 10.211.55.19...
telnet: connect to address 10.211.55.19: Connection refused

再用测试机 ping 一下:

ping 10.211.55.19                                   
PING 10.211.55.19 (10.211.55.19) 56(84) bytes of data.
64 bytes from 10.211.55.19: icmp_seq=1 ttl=64 time=0.240 ms
64 bytes from 10.211.55.19: icmp_seq=2 ttl=64 time=0.237 ms
64 bytes from 10.211.55.19: icmp_seq=3 ttl=64 time=0.284 ms
^C
--- 10.211.55.19 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.237/0.253/0.284/0.028 ms

这时候查看 INPUT 链:

iptables -nvL INPUT
Chain INPUT (policy ACCEPT 428 packets, 34304 bytes)
 pkts bytes target     prot opt in     out     source               destination
    1    60 REJECT     tcp  --  *      *       10.211.55.9          10.211.55.19         reject-with icmp-port-unreachable

拒绝了一个报文。

-p 选项包含的协议如下：

tcp
udp
icmp
udplite
icmpv6
esp
ah
sctp
mh
all(所有协议)

不指定 -p 选项时，相当于 -p all。

网卡接口

当机器中有多个网卡时，可以使用 -i, --in-interface 选项指定具体的网卡接口。下面是 10.211.55.19 所在网卡的信息:

ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.211.55.19  netmask 255.255.255.0  broadcast 10.211.55.255
        inet6 fe80::21c:42ff:fe14:8ef3  prefixlen 64  scopeid 0x20<link>

拒绝流入 br0 网卡的 ping 报文

iptables -F INPUT
iptables -I INPUT -i br0 -p icmp -j DROP
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 54 packets, 4185 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       icmp --  br0    *       0.0.0.0/0            0.0.0.0/0

使用测试机 ping 一下:

ping 10.211.55.19                                   
PING 10.211.55.19 (10.211.55.19) 56(84) bytes of data.
^C
--- 10.211.55.19 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3000ms

查看 INPUT 链:

iptables -nvL INPUT
Chain INPUT (policy ACCEPT 409 packets, 33105 bytes)
 pkts bytes target     prot opt in     out     source               destination
    4   336 DROP       icmp --  br0    *       0.0.0.0/0            0.0.0.0/0

-i 选项只适用于 PREROUTING、INPUT、FORWARD 这三个链，因为只有它们涉及流入网卡。同理，-o, --out-interface 选项适用 OUTPUT、FORWARD、POSTROUTING 这三个链。

另外，-i 和 -o 都支持取反 ! 操作，而且参数以 + 结尾时，表示以参数开头的网卡都能匹配到。

扩展匹配

除了基本匹配条件以为，还有很多扩展匹配条件。这些匹配条件基于各个匹配模块，使用 -m, --match 选项可以指定模块，然后就可以使用模块中的各种选项。

tcp 模块中包含了端口匹配条件：[!] --source-port,--sport port[:port], [!] --destination-port,--dport port[:port]。

拒绝来自 10.211.55.9 且目标端口为 22 的报文

iptables -F INPUT
iptables -I INPUT -p tcp -m tcp -s 10.211.55.9 --dport 22 -j REJECT
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 28 packets, 1932 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     tcp  --  *      *       10.211.55.9          0.0.0.0/0            tcp dpt:22 reject-with icmp-port-unreachable

使用测试机 ssh 连接:

1
2

ssh root@10.211.55.19                              
ssh: connect to host 10.211.55.19 port 22: Connection refused

查看 INPUT 链:

iptables -nvL INPUT
Chain INPUT (policy ACCEPT 496 packets, 40260 bytes)
 pkts bytes target     prot opt in     out     source               destination
    1    60 REJECT     tcp  --  *      *       10.211.55.9          0.0.0.0/0            tcp dpt:22 reject-with icmp-port-unreachable

当使用 -p 选项时，会默认添加 -m 协议名。比如 -p udp 相当于 -p udp -m udp。

--dport 和 --sport 都支持端口范围。

拒绝来自 10.211.55.9 且源端口范围 30-40 的报文

iptables -I INPUT -p tcp -s 10.211.55.9 --sport 30:40 -j REJECT
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 8 packets, 540 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     tcp  --  *      *       10.211.55.9          0.0.0.0/0            tcp spts:30:40 reject-with icmp-port-unreachable
    1    60 REJECT     tcp  --  *      *       10.211.55.9          0.0.0.0/0            tcp dpt:22 reject-with icmp-port-unreachable

端口范围可以省略数字，比如 8080: 表示 8080:65535， :3306 表示 0:3306。

iptables -I INPUT -p tcp -s 10.211.55.9 --sport 8080: -j REJECT
iptables -I INPUT -p tcp -s 10.211.55.9 --sport :3306 -j REJECT
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 10 packets, 688 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     tcp  --  *      *       10.211.55.9          0.0.0.0/0            tcp spts:0:3306 reject-with icmp-port-unreachable
    0     0 REJECT     tcp  --  *      *       10.211.55.9          0.0.0.0/0            tcp spts:8080:65535 reject-with icmp-port-unreachable
    0     0 REJECT     tcp  --  *      *       10.211.55.9          0.0.0.0/0            tcp spts:30:40 reject-with icmp-port-unreachable
    1    60 REJECT     tcp  --  *      *       10.211.55.9          0.0.0.0/0            tcp dpt:22 reject-with icmp-port-unreachable

multiport模块

--dport 和 --sport 只支持连续的端口范围，但不支持离散的端口范围。这时候需要使用 multiport 模块的

[!] --source-ports,--sports port[,port|,port:port]...
[!] --destination-ports,--dports port[,port|,port:port]...
[!] --ports port[,port|,port:port]...

选项来指定离散端口。其中 --ports 会匹配源端口和目标端口。

iptables -F INPUT
iptables -I INPUT -p tcp -s 10.211.55.9 -m multiport --dports 22,23,80:88,9000 -j REJECT
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 34 packets, 2248 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     tcp  --  *      *       10.211.55.9          0.0.0.0/0            multiport dports 22,23,80:88,9000 reject-with icmp-port-unreachable

  注意

multiport 模块只能结合 tcp 、 udp 、 udplite 、 dccp 和 sctp 协议使用。且最多支持15个离散端口，其中范围端口算作两个端口。

iptables详解-3-规则管理

Wed, 15 Aug 2018 14:19:31 +0000

本章学习如何对 iptables 规则进行管理。

  注意

本系列文章测试环境为 centos 7，iptables 版本 1.4.21。

准备工作

iptables 中最常用的匹配条件就是源ip，源端口，目标ip，目标端口等。最常用的动作有 ACCEPT、DROP、REJECT等。

初始化

让我们先清空系统提供的默认规则，准备一个初始化环境：

iptables -F INPUT
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 298 packets, 30644 bytes)
 pkts bytes target     prot opt in     out     source               destination

因为 filter 表的 INPUT 链默认策略为 ACCEPT ，所以所有到达本机的报文都会通过。

测试机

准备另一台测试机，接下来的规则都会针对这台测试机而做：

ping 10.211.55.19
PING 10.211.55.19 (10.211.55.19) 56(84) bytes of data.
64 bytes from 10.211.55.19: icmp_seq=1 ttl=64 time=0.458 ms
64 bytes from 10.211.55.19: icmp_seq=2 ttl=64 time=0.268 ms
64 bytes from 10.211.55.19: icmp_seq=3 ttl=64 time=0.266 ms
^C
--- 10.211.55.19 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.266/0.330/0.458/0.092 ms

增加规则

-I, --insert 选项可以增加规则。

-j, --jump 接收 target 作为参数。

添加一条规则，拒绝所有来自 10.211.55.9 的报文

iptables -t filter -I INPUT -s 10.211.55.9 -j DROP
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 93 packets, 8970 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0

再使用测试机 ping 一下，会发现不通：

ping 10.211.55.19                                      
PING 10.211.55.19 (10.211.55.19) 56(84) bytes of data.
^C
--- 10.211.55.19 ping statistics ---
11 packets transmitted, 0 received, 100% packet loss, time 10003ms

但是目标机器的报文量会增加(11个报文，总大小924b)：

iptables -nvL INPUT
Chain INPUT (policy ACCEPT 445 packets, 48402 bytes)
 pkts bytes target     prot opt in     out     source               destination
   11   924 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0

-A, --append 选项可以追加规则。

追加一条规则，接受所有来自 10.211.55.9 的报文

iptables -A INPUT -s 10.211.55.9 -j ACCEPT
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 30 packets, 2072 bytes)
 pkts bytes target     prot opt in     out     source               destination
   11   924 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       10.211.55.9          0.0.0.0/0

再次用测试机 ping，还是不通:

ping 10.211.55.19                                      
PING 10.211.55.19 (10.211.55.19) 56(84) bytes of data.
^C
--- 10.211.55.19 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4001ms

查看现在规则情况:

iptables -nvL INPUT
Chain INPUT (policy ACCEPT 904 packets, 100K bytes)
 pkts bytes target     prot opt in     out     source               destination
   16  1344 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       10.211.55.9          0.0.0.0/0

我们可以看到第一条规则报文量更新了，但是第二条规则并未收到任何数据。

-s, --source 选项指定源IP地址。

添加一条规则，接受所有来自 10.211.55.9 的报文

iptables -I INPUT -s 10.211.55.9 -j ACCEPT
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 92 packets, 8870 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       10.211.55.9          0.0.0.0/0
   16  1344 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       10.211.55.9          0.0.0.0/0

现在第一条规则接受所有来自 10.211.55.9 的报文，再使用测试机 ping 一下：

ping 10.211.55.19                                      
PING 10.211.55.19 (10.211.55.19) 56(84) bytes of data.
64 bytes from 10.211.55.19: icmp_seq=1 ttl=64 time=0.367 ms
64 bytes from 10.211.55.19: icmp_seq=2 ttl=64 time=0.296 ms
64 bytes from 10.211.55.19: icmp_seq=3 ttl=64 time=0.278 ms
^C
--- 10.211.55.19 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.278/0.313/0.367/0.043 ms

又可以 ping 通了，而且第一条规则的报文数据也发生了改变：

iptables -nvL INPUT
Chain INPUT (policy ACCEPT 15096 packets, 1693K bytes)
 pkts bytes target     prot opt in     out     source               destination
    3   252 ACCEPT     all  --  *      *       10.211.55.9          0.0.0.0/0
   16  1344 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       10.211.55.9          0.0.0.0/0

从这里，我们可以看出 iptables 的工作机制：只要匹配了一条规则，就不会再去匹配接下来的规则。

在指定顺序规则前添加一条规则

iptables -I INPUT 2 -s 10.211.55.9 -j DROP
iptables -nvL INPUT --line
Chain INPUT (policy ACCEPT 236 packets, 23798 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        3   252 ACCEPT     all  --  *      *       10.211.55.9          0.0.0.0/0
2        0     0 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0
3       16  1344 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0
4        0     0 ACCEPT     all  --  *      *       10.211.55.9          0.0.0.0/0

删除规则

删除规则有两种方式：

根据序号删除
根据匹配条件删除

根据序号删除指定规则

先查看一下目前所有的规则：

iptables -nvL INPUT --line
Chain INPUT (policy ACCEPT 236 packets, 23798 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        3   252 ACCEPT     all  --  *      *       10.211.55.9          0.0.0.0/0
2        0     0 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0
3       16  1344 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0
4        0     0 ACCEPT     all  --  *      *       10.211.55.9          0.0.0.0/0

删除第4条规则，命令如下:

iptables -D INPUT 4
iptables -nvL INPUT --line
Chain INPUT (policy ACCEPT 108 packets, 8771 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        3   252 ACCEPT     all  --  *      *       10.211.55.9          0.0.0.0/0
2        0     0 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0
3       16  1344 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0

根据匹配条件进行删除

我们删除 target 是 ACCEPT 的规则：

iptables -D INPUT -s 10.211.55.9 -j ACCEPT
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 79 packets, 5905 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0
   16  1344 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0

删除所有规则

使用 -F, --flush 选项即可，我们在准备工作中已经操作过。

修改规则

使用 -R, --replace 选项替换指定编号规则内容。

修改规则， target 从 DROP 改为 REJECT，源IP不变

iptables -R INPUT 1 -s 10.211.55.9 -j REJECT
iptables -nvL INPUT
Chain INPUT (policy ACCEPT 282 packets, 24058 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     all  --  *      *       10.211.55.9          0.0.0.0/0            reject-with icmp-port-unreachable
   16  1344 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0

  注意

若不指定 -s 内容，则默认会被设置为 0.0.0.0/0，这可能会导致严重错误（例如 DROP 或者 REJECT 了所有报文，那么当前连接也会断开）。所以使用 -R 命令可以理解为替换当前顺序的规则的所有内容，这些内容必须写全，而不能写一部分；也可以理解为先删除这条指定的规则，再在同一位置插入新规则。

`DROP` 和 `REJECT` 的区别

将 DROP 替换为 REJECT 后，我们使用测试机 ping 一下，看看两者的区别：

ping 10.211.55.19                             
PING 10.211.55.19 (10.211.55.19) 56(84) bytes of data.
From 10.211.55.19 icmp_seq=1 Destination Port Unreachable
From 10.211.55.19 icmp_seq=2 Destination Port Unreachable
From 10.211.55.19 icmp_seq=3 Destination Port Unreachable
^C
--- 10.211.55.19 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2000ms

我们可以看到，REJECT 会给出明确的回应，而不像 DROP 体现为毫无反应。

此时我们再看看规则情况，第一条规则报文量也发生了改变，说明匹配到了这条规则：

iptables -nvL INPUT
Chain INPUT (policy ACCEPT 2844 packets, 248K bytes)
 pkts bytes target     prot opt in     out     source               destination
    3   252 REJECT     all  --  *      *       10.211.55.9          0.0.0.0/0            reject-with icmp-port-unreachable
   16  1344 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0

修改默认策略

使用 -P, --policy 选项修改链的默认策略，当链中没有规则，或者所有规则都未匹配时，则使用默认规则：

iptables -P FORWARD DROP
iptables -nvL
Chain INPUT (policy ACCEPT 112 packets, 8478 bytes)
 pkts bytes target     prot opt in     out     source               destination
    3   252 REJECT     all  --  *      *       10.211.55.9          0.0.0.0/0            reject-with icmp-port-unreachable
   16  1344 DROP       all  --  *      *       10.211.55.9          0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      virbr0  0.0.0.0/0            192.168.122.0/24     ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  virbr0 *       192.168.122.0/24     0.0.0.0/0
    0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0            0.0.0.0/0
    0     0 REJECT     all  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT 80 packets, 7108 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            udp dpt:68

保存规则

通常情况下，我们对 iptables 做的操作都是临时的。就好比在 word 中写了一段话，假如强制关闭了 word 或者重启了电脑，那么刚才所些的那段话也会消失。当我们保存成 word 文件后，那段话就不会丢失。同理，设置 iptables 后也需要保存。

因为在 centos 7 中，默认的防火墙服务是 firewalld ，而不是 iptables 。所以我们需要安装 iptables 服务，替换默认防火墙。

yum install -y iptables-services
# 关闭 firewalld 服务
systemctl stop firewalld
# 禁止 firewalld 服务开机启动
systemctl disable firewalld
# 开启 iptables 服务
systemctl start iptables
# 设置 iptables 服务开机启动
systemctl enable iptables

安装 iptables 服务成功后，即可保存规则：

1
2

service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]

我们可以看到，所有的规则被写入了 /etc/sysconfig/iptables 文件。

这里还有一种手动保存方法，当我们运行 iptables-save 命令时，会有将所有当前的规则输出：

iptables-save
# Generated by iptables-save v1.4.21 on Fri Aug 17 16:51:10 2018
*security
:INPUT ACCEPT [2409:202386]
...
*raw
:PREROUTING ACCEPT [2413:203008]
...
*mangle
:PREROUTING ACCEPT [2413:203008]
...
*nat
:PREROUTING ACCEPT [4:622]
...
*filter
...
-A INPUT -s 10.211.55.9/32 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -s 10.211.55.9/32 -j DROP
...
COMMIT
# Completed on Fri Aug 17 16:51:10 2018

所以只要将输出重定向到 /etc/sysconfig/iptables 文件，也可以完成保存操作:

`1`	`iptables-save > /etc/sysconfig/iptables`

同时可以使用 iptables-restore 命令恢复 iptables 规则，现有规则会被覆盖:

`1`	`iptables-restore < /etc/sysconfig/iptables`

iptables详解-2-查询命令

Wed, 15 Aug 2018 11:37:05 +0000

本章介绍 iptables 常用的查询命令。

  注意

本系列文章测试环境为 centos 7，iptables 版本 1.4.21。

查看表规则

iptables 内置了5张表，分别是 raw、 nat、 mangle、 filter、 security。

我们要查看 filter 表下的所有规则，可以使用如下命令：

iptables -t filter -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             192.168.122.0/24     ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.122.0/24     anywhere
ACCEPT     all  --  anywhere             anywhere
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootpc

其他查看其他表的命令也是类似的。当省略 -t filter 时，默认列出的是 filter 表的规则。

查看表的指定链

参数中可以增加链名，指定查看表的具体链规则：

iptables -nL INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:53
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:53
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:67
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:67

查看规则详情

使用 -v, --verbose 选项列出更详细的信息：

iptables -vL
Chain INPUT (policy ACCEPT 724K packets, 80M bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  virbr0 any     anywhere             anywhere             udp dpt:domain
    0     0 ACCEPT     tcp  --  virbr0 any     anywhere             anywhere             tcp dpt:domain
    0     0 ACCEPT     udp  --  virbr0 any     anywhere             anywhere             udp dpt:bootps
    0     0 ACCEPT     tcp  --  virbr0 any     anywhere             anywhere             tcp dpt:bootps

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  any    virbr0  anywhere             192.168.122.0/24     ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  virbr0 any     192.168.122.0/24     anywhere
    0     0 ACCEPT     all  --  virbr0 virbr0  anywhere             anywhere
    0     0 REJECT     all  --  any    virbr0  anywhere             anywhere             reject-with icmp-port-unreachable
    0     0 REJECT     all  --  virbr0 any     anywhere             anywhere             reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT 710K packets, 74M bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  any    virbr0  anywhere             anywhere             udp dpt:bootpc

字段含义：

pkts: 报文数量
bytes: 报文大小
target: target动作
port: 协议
opt: 选项
in: 入口网卡
out: 出口网卡
source: 源ip/ip段
destination: 目标ip/ip段

链策略 Policy和精确报文数据

表中每个链都包含了策略 Policy，总报文数和总报文大小。policy ACCEPT表示链的默认策略为 ACCEPT。总报文数和总报文大小可以使用 -x, --exact 选项显示精确的数据:

iptables -vnxL -t nat
Chain PREROUTING (policy ACCEPT 6856 packets, 469577 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 6661 packets, 424028 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 97282 packets, 5880717 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 97282 packets, 5880717 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 RETURN     all  --  *      *       192.168.122.0/24     224.0.0.0/24
       0        0 RETURN     all  --  *      *       192.168.122.0/24     255.255.255.255
       0        0 MASQUERADE  tcp  --  *      *       192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
       0        0 MASQUERADE  udp  --  *      *       192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
       0        0 MASQUERADE  all  --  *      *       192.168.122.0/24    !192.168.122.0/24

名称解析

iptables 默认进行了名称解析，这会牺牲效率，可以使用 -n, --numeric 选项直接显示ip。

iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 6854 packets, 469K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 6659 packets, 424K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 96829 packets, 5853K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 96829 packets, 5853K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  *      *       192.168.122.0/24     224.0.0.0/24
    0     0 RETURN     all  --  *      *       192.168.122.0/24     255.255.255.255
    0     0 MASQUERADE  tcp  --  *      *       192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
    0     0 MASQUERADE  udp  --  *      *       192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
    0     0 MASQUERADE  all  --  *      *       192.168.122.0/24    !192.168.122.0/24

显示规则序号

使用 –line[-number] 展示规则行号：

iptables -L --line
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
2    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
3    ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
4    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  anywhere             192.168.122.0/24     ctstate RELATED,ESTABLISHED
2    ACCEPT     all  --  192.168.122.0/24     anywhere
3    ACCEPT     all  --  anywhere             anywhere
4    REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
5    REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootpc

iptables详解-1-简介

Wed, 15 Aug 2018 08:45:33 +0000

iptables 是各种防火墙的基础，需要系统学习。本篇先了解 iptables 的一些基本概念。

  注意

本系列文章测试环境为 centos 7，iptables 版本 1.4.21。

说明

iptables 是用来设置、维护和检查 Linux 内核的 IP 包过滤规则的。用户可以定义不同的表，每个表都包含几个内部的链，也能包含用户定义的链。每个链都是一个规则列表，与对应的包进行匹配：每条规则指定应当如何处理与之相匹配的包，这被称作 target（目标），也可以跳向同一个表内的用户定义的链。¹

一般 iptables 设置都是从 表 出发，到 链 再到 规则。

表

iptables 的核心之一就是 table，它是具有相同功能的规则集合。iptables 提供了5张表：

filter - 主要提供过滤功能，是默认的表。
nat - 主要提供网络地址转换功能，实现数据包转发，修改源地址与端口和目标地址与端口。
mangle - 主要提供修改报文的功能。
raw - 应用在不需要做 nat 的情况下，以提高性能。
security - 主要提供 MAC 网络规则。

链

报文需要经过一系列阶段，每个阶段可以应用各种规则，这样的一个阶段在 iptables 中称为链(chain)。各种阶段串起来就是一条长链。 iptables 中有5条默认的链：

PREROUTING
INPUT
FORWARD
OUTPUT
POSTROUTING

用户也可以创建自定义链，但是只能被默认链调用。

报文生命周期

报文从网卡进入，从网卡流出，会经过5个生命周期，也就是上述的5条默认链。每条链上可以使用相应的表组合起来进行报文处理。当不同表处于同一条链上时，处理报文就会涉及到顺序，执行的优先级如下：

raw -> mangle -> nat -> filter -> security

总结成一张图：

规则

规则包含了匹配条件和 target，用来匹配报文信息。匹配不成功，则进行下一条规则检测；匹配成功后执行规则对应的 target。

target 可以是基本 target，用户自定义链，或者扩展中的 target²。

基本 target 包含：

ACCEPT: 让报文通过。
DROP: 丢弃报文。
RETURN: 停止遍历本链中的规则，将下一条规则置为前一条调用的链。

man iptables 8 ↩︎
man iptables-extensions 8 ↩︎

Tsing Wind - 清风徐来 水波不兴

2021年度计划

golang调度器笔记

CPU寄存器

内存

函数调用栈

汇编指令

常用指令详解

mov指令

add/sub

call/ret指令

jmp/je/jle/jg/jge等等j开头的指令

push/pop

leave指令

go汇编语言

寄存器

FP虚拟寄存器

SB虚拟寄存器

操作数宽度（即操作数的位数）

函数定义

线程本地存储

goroutine调度器概述

goroutine简介

线程模型与调度器

重要的结构体

stack结构体

gobuf结构体

g结构体

m结构体

p结构体

schedt结构体

重要的全局变量

goroutine调度器初始化

初始化g0

主线程与m0绑定

初始化m0

初始化allp

创建main goroutine

GPM 的状态流转

参考资料

英语学习规划

7-9岁全面发展阶段

7岁

精读

习得

8岁

9岁

10岁

学得

习得

11-12

在Golang中轻松使用ipset

前言

功能

常用命令

全类型支持

灵活的选项

示例

快速开始

进阶使用

最后

Fasthttp系列——解析请求头

前言

请求头格式

解析请求头

头字段

处理头字段键值对

Host

UserAgent

ContentType

ContentLength

Connection

TransferEncoding

收尾操作

总结

Fasthttp系列——请求行

第一行

请求方法

请求目标

总结

Tsing Wind - 清风徐来水波不兴

`App`的注册方法

`Group`的`Add`方法

为`Reservation`增加信息

实现`fiber`频率限制中间件

创建新的`angular`项目

`ng-template`指令简介

你会注意到关于`ng-template`的第一件事

`ng-template`指令和`ngIf`

`ng-container`指令

使用`ngTemplateOutlet`指令创建动态模板

具有模板部分`@Inputs`的可配置组件

`Angular`服务层 - `store`架构

为什么`store`在`React`中如此受欢迎？

何时使用`Redux`或`store`？

什么时候建议使用`Flux`或`Redux`？

具有并发更新的`store`和应用程序

`Redux`解决的最常见问题是什么？

`extraneous props`，还有什么意思？

为什么`Redux`在`React`世界中如此受欢迎？

为什么`Redux`在这些情况下运行良好？

`store`如何允许分离的组件交互

这种情况是`store`闪耀的时候

`store`是解决多个问题的复合解决方案，而不仅仅是一个问题

`Redux`是否避免状态相关的问题？

除了`store`之外，`Angular`世界还有替代解决方案吗？

`Angular`和`store`——频繁的选择？

使用`store`有成本

`React`中的单向数据流

`Redux`和单向数据流

`Angular`中的单向数据流

打破`Angular`单向数据流

`store`和性能

`store`和可测试性

`store`和工具

`Redux`的常用替代方案