我之前并未使用过标准的Kubernetes ingress，而是自己实现了一个基于nginx的、类似ingress controller的服务入口管理程序nginx-kit。这个程序会部署到Kubernetes集群中，以Pod形式运行。该Pod由两个Container组成，一个Container放置了一个由脚本启动的nginx；另外一个Container中放置的是一个conf generator程序，它监听Kubernetes集群service对象的变更，并根据变更情况动态生成nginx的配置文件。第一个Container中的脚本会监听配置文件目录的变化，并reload配置文件信息实现Kubernetes内部服务对外暴露入口的动态管理。关于这个程序的详情可以参考我之前写的两篇文章：《Kubernetes集群中的Nginx配置热更新方案》和《为Kubernetes集群中服务部署Nginx入口服务》。

近期在使用ingress controller对内部服务入口的暴露进行动态管理，使用后发现我之前实现的nginx kit与ingress controller的实现之一: ingress-nginx简直是异曲同工。只是当时对Kubernetes理解还不够深入，在设计nginx-kit时格局“太小了”，只实现了一个满足内部需求的”ingress controller”，而不是一个通用的、可扩展的ingress controller:(。

好了！言归正传，这篇文章是ingress的入门文章，将通过四个例子来说明一下ingress controller的实现之一： ingress-nginx在不同服务暴露场景下的使用和配置方法。

一. 例子概述与环境准备

我们有四个例子，见下图中的a) ~ d)：

• 例子a): 单ingress-nginx controller。通过ingress-svc1将内部服务svc1的http服务端口暴露到集群外，通过访问http://svc1.tonybai.com:30090即可访问svc1服务。
• 例子b)：单ingress-nginx controller。通过ingress-svc1将内部服务svc1的http服务端口暴露到集群外，通过访问http://svc1.tonybai.com:30090即可访问svc1服务；通过ingress-svc2将内部服务svc2的https服务端口暴露到集群外，通过访问http://svc2.tonybai.com:30090即可访问svc2服务。
• 例子c)：单ingress-nginx controller。除了暴露svc1和svc2之外，还暴露了集群内部的一个tcp(四层)服务：svc3，通过tcp连接svc3.tonybai.com:30070即可访问svc3服务。
• 例子d): 多ingress-nginx controllers。其中nginx-ingress-controller-ic1负责暴露svc1、svc2和svc3服务（访问方式如上面所描述的）；nginx-ingress-controller-ic2负责暴露svc4、svc5和svc6，其中svc4是一个http服务；svc5是https服务，svc6是一个tcp（四层)服务。

这里我们使用一个Kubernetes 1.10.3的集群来循序渐进地实践一下这四个例子。关于这四个例子的源码、chart包以及ingress controllers的yaml源文件在这里可以下载到：

$tree -L 2 ingress-controller-demo
ingress-controller-demo
├── charts
│   ├── svc1
│   ├── svc2
│   ├── svc3
│   ├── svc4
│   ├── svc5
│   └── svc6
├── manifests
│   ├── ic-common.yaml
│   ├── ic1-mandatory.yaml
│   ├── ic1-service-nodeport.yaml
│   ├── ic2-mandatory.yaml
│   └── ic2-service-nodeport.yaml
└── src
    ├── svc1
    ├── svc2
    ├── svc3
    ├── svc4
    ├── svc5
    └── svc6

其中:

• src下面存放着svc1~svc6的源码（包括Dockerfile）；
• manifests下面存放的是ingress controllers的yaml源文件；
• charts下面存放的是svc1~svc6的helm chart安装包源文件。

二. 创建第一个ingress-nginx controller

ingress controller有多种实现，其中应用较广的是kubernetes官方仓库中的ingress-nginx。在bare metal上安装ingress-nginx controller十分方便，只需执行下面命令即可：

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/mandatory.yaml

不过，考虑到我后续在环境中会安装多个ingress-nginx controller，我们需要对mandatory.yaml中的内容做些调整：

• 首先明确多个ingress-nginx controller及其相关kubernetes object所在的namespace，默认为ingress-nginx，这里统一改为ingress-nginx-demo，yaml描述文件中所有的object的namespace也都改为ingress-nginx-demo，clusterrole、clusterrolebinding对象不归属于任何namespace，因此无需修改；

• 接下来，将多个ingress-nginx controller能共用的kubernetes object的描述数据从mandatory.yaml中提取出来，放入ic-common.yaml中，包括：namespace: ingress-nginx-demo、deployment: default-http-backend、service: default-http-backend、serviceaccount: nginx-ingress-serviceaccount、clusterrole: nginx-ingress-demo-clusterrole、role: nginx-ingress-role、rolebinding: nginx-ingress-role-nisa-binding以及clusterrolebinding: nginx-ingress-demo-clusterrole-nisa-binding;

• 将“缩水”后的mandatory.yaml改名为ic1-mandatory.yaml，并将其内容中的kubernetes object的name添加上“-ic1″后缀。

• 在ic1-mandatory.yaml中nginx-ingress-controller的启动参数列表尾部添加“–ingress-class=ic1”:

// ic1-mandatory.yaml
... ...
    spec:
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller-ic1
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.15.0
          args:
            - /nginx-ingress-controller
            - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
            - --configmap=$(POD_NAMESPACE)/nginx-configuration-ic1
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services-ic1
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services-ic1
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx-ic1
            - --annotations-prefix=nginx.ingress.kubernetes.io
            - --ingress-class=ic1
... ...

• ic-common.yaml中的nginx-ingress-role中的resourceNames列表中需添加两项：”ingress-controller-leader-ic1″和”ingress-controller-leader-ic2″：

// ic-common.yaml
... ...
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx-demo
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-ic1"
      - "ingress-controller-leader-ic2"
... ...

这两个resouceName分别给两个ingress-controller使用，当每个ingress-controller存在多副本(replicas > 1)时，多副本会通过ingress-controller-leader-icX这个configmap资源来进行leader election（选主)。以ingress-controller-ic1为例，当存在多副本时，ingress-controller-ic1的启动日志：

I0621 09:13:20.646426       7 stat_collector.go:34] changing prometheus collector from  to default
I0621 09:13:20.648198       7 status.go:196] new leader elected: nginx-ingress-controller-ic1-7c9bc49cbb-kgjvz
I0621 09:13:20.752485       7 controller.go:177] ingress backend successfully reloaded...

不过，虽然存在leader，但业务流量却是负载分担的。

• 为ingress-nginx controller pod创建nodeport类型service

如果只是部署了ingress controller，那么外部依然无法连上ingress controller，因为ingress controller自身还没有对应的service将自己暴露到集群外部。官方文档推荐使用NodePort方式，于是我们创建了ic1-service-nodeport.yaml，让流入host:30090的流量进入ingress controller service。

总结一下ingress-controller-ic1这个ingress controller的完整创建步骤：

kubectl apply -f ic-common.yaml
kubectl apply -f ic1-service-nodeport.yaml
kubectl apply -f ic1-mandatory.yaml

三. 创建例子a)

svc1是一个在容器8080端口提供http服务的服务程序。在例子a)中，我们在k8s集群中创建svc1，并创建ic1-svc1 ingress将svc1暴露在集群外面，外部请求通过svc1.tonybai.com:30090可以访问到svc1。而做到这一点，我们仅需要使用helm install一下svc1这个chart：

# helm install --name ic1-svc1 ./svc1
NAME:   ic1-svc1
LAST DEPLOYED: Thu Jun 21 20:39:25 2018
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Service
NAME      TYPE       CLUSTER-IP      EXTERNAL-IP  PORT(S)  AGE
ic1-svc1  ClusterIP  10.103.210.182  <none>       80/TCP   0s

==> v1beta2/Deployment
NAME      DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
ic1-svc1  1        0        0           0          0s

==> v1beta1/Ingress
NAME      HOSTS             ADDRESS  PORTS  AGE
ic1-svc1  svc1.tonybai.com  80       0s

==> v1/Pod(related)
NAME                       READY  STATUS             RESTARTS  AGE
ic1-svc1-5ff84d7bff-5j7tb  0/1    ContainerCreating  0         0s

NOTES:
1. Get the application URL by running these commands:

http://svc1.tonybai.com/

svc1服务以及对应的ic1-svc1 ingress创建后，我们来测试一下：

# curl svc1.tonybai.com:30090
Hello, I am svc1 for ingress-controller demo!

结果符合预期。而这一切实现的关键在于ingress-controller-demo/charts/svc1/values.yaml:

... ...
ingress:
  enabled: true
  annotations:
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
    kubernetes.io/ingress.class: ic1
  path: /
  hosts:
    - svc1.tonybai.com
... ...

ingress的enabled改为true，helm才会创建svc1对应的ingress。annotations中的kubernetes.io/ingress.class: ic1很关键，设定ingress的这个annotation，可以使得该ingress归属于我们上面创建的nginx-ingress-controller-ic1 ingress controller，而其他ingress controller会忽略这个ingress。

我们再来看看 ingress-controller-ic1的后台日志，当添加svc1时，日志输出：

I0621 12:39:25.406331       7 event.go:218] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"default", Name:"ic1-svc1", UID:"2176416f-7550-11e8-a0e8-00163e0cd764", APIVersion:"extensions", ResourceVersion:"1877656", FieldPath:""}): type: 'Normal' reason: 'CREATE' Ingress default/ic1-svc1
I0621 12:39:25.517915       7 controller.go:177] ingress backend successfully reloaded...
W0621 12:39:28.739708       7 controller.go:773] service default/ic1-svc1 does not have any active endpoints
I0621 12:39:34.262824       7 controller.go:168] backend reload required
I0621 12:39:34.371479       7 controller.go:177] ingress backend successfully reloaded...

nginx-ingress-controller-ic1会监听到service变化，并reload nginx。

我们可以通过下面命令查看nginx-ingress-controller-ic1内部的nginx的配置文件内容：

# kubectl exec nginx-ingress-controller-ic1-7c9bc49cbb-kgjvz -n ingress-nginx-demo -- cat /etc/nginx/nginx.conf

我们可以看到有关svc1的相关内容如下：

        upstream default-ic1-svc1-http {
                least_conn;

                keepalive 32;

                server 192.168.31.9:8080 max_fails=0 fail_timeout=0;

        }

        ## start server svc1.tonybai.com
        server {
                server_name svc1.tonybai.com ;

                listen 80;

                listen [::]:80;

                set $proxy_upstream_name "-";

                location / {

                       ... ...

                        set $proxy_upstream_name "default-ic1-svc1-http";

                        set $namespace      "default";
                        set $ingress_name   "ic1-svc1";
                        set $service_name   "ic1-svc1";

                       ... ...

                        proxy_pass http://default-ic1-svc1-http;

                        proxy_redirect                          off;

                }

        }
        ## end server svc1.tonybai.com

可一看出外部到svc1.tonybai.com:30090的流量被转到service ingress-nginx-ic1:80上，进而到达nginx pod的targetPort(80)上。

四. 创建例子b)

有了例子a)作为基础，理解接下来的例子就相对简单了。例子b)与a)最大的不同是svc2是一个https服务。外部通过http协议访问：svc2.tonybai.com:30090后，nginx-ingress-controller-ic1内部的nginx需要以https的方式去访问svc2。ingress-nginx ingress controller支持这种情况，仅需要在svcb的ingress annotations加上下面这个annotation：nginx.ingress.kubernetes.io/secure-backends: “true”：

// ingress-controller-demo/charts/svc2/values.yaml
... ...
ingress:
  enabled: true
  annotations:
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
    nginx.ingress.kubernetes.io/secure-backends: "true"
    kubernetes.io/ingress.class: ic1
  path: /
  hosts:
    - svc2.tonybai.com
 ... ...

和例子a)一样，使用helm安装svc2这个chart后，svc2这个服务就暴露出来了：

# helm install --name ic1-svc2 ./svc2

# curl http://svc2.tonybai.com:30090
Hello, I am svc2 for ingress-controller demo!

五. 创建例子c)

svc3与前面两个服务均不同，因为它直接暴露的是四层的tcp服务。kubernetes ingress无法直接支持四层的服务端口暴露，我们需要在ingress controller上“动手脚”。

首先，四层的暴露的端口不能与之前的七层端口30090重叠(因为不是通过ingress来暴露svc3服务的)，我们需要一个新端口：30070，我们需要在ic1-service-nodeport.yaml中增加一组nodeport：

//ingress-controller-demo/manifests/ic1-service-nodeport.yaml

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-ic1
  namespace: ingress-nginx-demo
spec:
  type: NodePort
  ports:
  - name: http
    port: 80
    targetPort: 80
    nodePort: 30090
    protocol: TCP
  - name: tcp
    port: 30070
    targetPort: 30070
    nodePort: 30070
    protocol: TCP
  selector:
    app: ingress-nginx-ic1

注意这里两组nodeport中的port不能一样，否则kubernetes会用下面的一组覆盖上面的那组。这里我们暴露30070这个nodeport，service的集群内port也是30070，后面的endpoint中的容器（即nginx-ingress-controller-ic1 pod）监听的也是30070。

接下来，要让nginx-ingress-controller-ic1 pod也监听30070，我们没法用ingress实现，但是ingress-nginx ingress controller支持通过一个名为：tcp-services-ic1的configmap来配置：

//ingress-controller-demo/manifests/ic1-mandatory.yaml
.... ...
spec:
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller-ic1
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.15.0
          args:
            - /nginx-ingress-controller
            - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
            - --configmap=$(POD_NAMESPACE)/nginx-configuration-ic1
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services-ic1
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services-ic1
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx-ic1
            - --annotations-prefix=nginx.ingress.kubernetes.io
... ...

在ic1-mandatory.yaml中，我们这样更新tcp-services-ic1 configmap的配置：

kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services-ic1
  namespace: ingress-nginx-demo
data:
  30070: "default/ic1-svc3:8080"

大家可以看到，在configmap的data中，我们用了一个key:value的格式行，其中key就是nginx要暴露的端口：30070，value则为

<namespace/service name>:<service port>

格式的值，这里我们使用default名字空间下的ic1-svc3服务，服务端口8080。

重新apply ic1-mandatory.yaml和ic1-service-nodeport.yaml后，我们测试一下svc3服务：

# telnet svc3.tonybai.com 30070
Trying 127.0.0.1...
Connected to svc3.tonybai.com.
Escape character is '^]'.
hello
hello
world
world

svc3是一个echo服务，我们看到svc3 echo了我们输入的内容。

在nginx内部，30070是这样被暴露的：

stream {
        log_format log_stream [$time_local] $protocol $status $bytes_sent $bytes_received $session_time;

        access_log /var/log/nginx/access.log log_stream;

        error_log  /var/log/nginx/error.log;

        # TCP services

        upstream tcp-30070-default-ic1-svc3-8080 {

                server                  192.168.28.13:8080;

        }
        server {

                listen                  30070;

                listen                  [::]:30070;

                proxy_timeout           600s;
                proxy_pass              tcp-30070-default-ic1-svc3-8080;

        }

        # UDP services
}

六. 创建例子d)

在例子d)对应的图示中，我们建立了另外一个ingress-nginx ingress controller: nginx-ingress-controller-ic2，与nginx-ingress-controller-ic1 不同的是， nginx-ingress-controller-ic2的启动参数中含：

            - --ingress-class=ic2

用以区分ic1。ic2-mandatory.yaml和ic1-mandatory.yaml相比，就是将“rc1”字样整体替换为”ic2″即可。除此之外，有了ic1-service-nodeport.yaml的基础，ic2-service-nodeport.yaml内容也是“雷同”的。建立 nginx-ingress-controller-ic2步骤如下：

# kubectl apply -f ic2-service-nodeport.yaml
# kubectl apply -f ic2-mandatory.yaml

归属于nginx-ingress-controller-ic2的三个服务svc4、svc5和svc6等价于nginx-ingress-controller-ic1的svc1、svc2和svc3，这里就不赘述了。

# curl svc4.tonybai.com:30091
Hello, I am svc4 for ingress-controller demo!
# curl svc5.tonybai.com:30091
Hello, I am svc5 for ingress-controller demo!
# telnet  svc6.tonybai.com 30071
Trying 127.0.0.1...
Connected to svc6.tonybai.com.
Escape character is '^]'.
hello
hello
tony
tony

如果想使得ingress-nginx controller高可用，只需将其pod副本数量调大即可。

51短信平台：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

我有一个习惯，那就是随时记录下编程过程中遇到的问题（包括问题现场、问题起因以及对问题的分析），并喜欢阶段性的对一段时间内的编码过程的得与失进行回顾和总结。内容可以包括：对编程语法的新认知、遇坑填坑的经历、一些让自己豁然开朗的小tip/小实践等。记录和总结的多了，感觉有价值的，就成文发在博客上的；一些小的点，或是还没有想清楚的事情，或思路没法结构化统一的，就放在资料库里备用。“写Go代码时遇到的那些问题”这个系列也是基于这个思路做的。

在这一篇中，我把“所遇到的问题”划分为三类：语言类、库与工具类、实践类，这样应该更便于大家分类阅读和理解。另外借这篇文章，我们先来看一下Go语言当前的State，资料来自于twitter、reddit、golang-dev forum、github上golang项目的issue/cl以及各种gophercon的talk资料。

零. Go语言当前状态

1. vgo

Go 1.10在中国农历春节期间正式发布。随后Go team进入了Go 1.11的开发周期。

在2017年的Go语言用户调查报告结果中，缺少良好的包管理工具以及Generics依然是Gopher面临的最为棘手的挑战和难题的Top2，Go team也终于开始认真对待这两个问题了，尤其是包依赖管理的问题。在今年2月末，Russ Cox在自己的博客上连续发表了七篇博文，详细阐述了vgo – 带版本感知和支持的Go命令行工具的设计思路和实现方案，并在3月末正式提交了”versioned-go proposal“。

目前相对成熟的包管理方案是:

"语义化版本"
+manifest文件(手工维护的依赖约束描述文件)
+lock文件(工具自动生成的传递依赖描述文件)
+版本选择引擎工具（比如dep中的gps - Go Packaging Solver）

与之相比，vgo既有继承，更有创新。继承的是对语义化版本的支持，创新的则是semantic import versioning、最小版本选择minimal version selection等新机制，不变的则是对Go1语法的兼容。按照Russ Cox的计划，Go 1.11很可能会提供一个试验性的vgo实现（当然vgo所呈现的形式估计是merge到go tools中），让广大gopher试用和反馈，然后会像vendor机制那样，在后续Go版本中逐渐成为默认选项。

2. wasm porting

知名开源项目gopherjs的作者Richard Musiol上个月提交了一个proposal: WebAssembly architecture for Go，主旨在于让Gopher也可以用Go编写前端代码，让Go编写的代码可以在浏览器中运行。当然这并不是真的让Go能像js那样直接运行于浏览器或nodejs上，而是将Go编译为WebAssembly，wasm中间字节码，再在浏览器或nodejs初始化的运行环境中运行。这里根据自己的理解粗略画了一幅二进制机器码的go app与中间码的wasm的运行层次对比图，希望对大家有用：

wasm porting已经完成了第一次commit ，很大可能会随着go1.11一并发布第一个版本。

3. 非协作式的goroutine抢占式调度

当前goroutine的“抢占式”调度依靠的是compiler在函数中自动插入的“cooperative preemption point”来实现的，但这种方式在使用过程中依然有各种各样的问题，比如：检查点的性能损耗、诡异的全面延迟问题以及调试上的困难。近期负责go runtime gc设计与实现的Austin Clements提出了一个proposal：non-cooperative goroutine preemption ，该proposal将去除cooperative preemption point，而改为利用构建和记录每条指令的stack和register map的方式实现goroutine的抢占， 该proposal预计将在go 1.12中实现。

4. Go的历史与未来

在GopherConRu 2018大会上，来自Go team的核心成员Brad Fitzpatrick做了“Go的历史与未来”的主题演讲 ，Bradfitz“爆料”了关于Go2的几个可能，考虑到Bradfitz在Go team中的位置，这些可能性还是具有很大可信度的：

1). 绝不像Perl6和Python3那样分裂社区
2). Go1的包可以import Go2的package
3). Go2很可能加入Generics，Ian Lance Taylor应该在主导该Proposal
4). Go2在error handling方面会有改进，但不会是try--catch那种形式
5). 相比于Go1，Go2仅会在1-3个方面做出重大变化
6). Go2可能会有一个新的标准库，并且该标准库会比现有的标准库更小，很多功能放到标准库外面
7). 但Go2会在标准库外面给出最流行、推荐的、可能认证的常用包列表，这些在标准库外面的包可以持续更新，而不像那些在标准库中的包，只能半年更新一次。

一. 语言篇

1. len(channel)的使用

len是Go语言的一个built-in函数，它支持接受array、slice、map、string、channel类型的参数，并返回对应类型的”长度” – 一个整型值：

len(s)   

如果s是string，len(s)返回字符串中的字节个数
如何s是[n]T, *[n]T的数组类型，len(s)返回数组的长度n
如果s是[]T的Slice类型，len(s)返回slice的当前长度
如果s是map[K]T的map类型，len(s)返回map中的已定义的key的个数
如果s是chan T类型，那么len(s)返回当前在buffered channel中排队（尚未读取）的元素个数

不过我们在代码经常见到的是len函数针对数组、slice、string类型的调用，而len与channel的联合使用却很少。那是不是说len(channel)就不可用了呢？我们先来看看len(channel)的语义。

• 当channel为unbuffered channel时，len(channel)总是返回0；
• 当channel为buffered channel时，len(channel)返回当前channel中尚未被读取的元素个数。

这样一来，所谓len(channel)中的channel就是针对buffered channel。len(channel)从语义上来说一般会被用来做“判满”、”判有”和”判空”逻辑：

// 判空

if len(channel) == 0 {
    // 这时：channel 空了 ?
}

// 判有

if len(channel) > 0 {
    // 这时：channel 有数据了 ?
}

// 判满
if len(channel) == cap(channel) {
    // 这时:   channel 满了 ?
}

大家看到了，我在上面代码中注释：“空了”、“有数据了”和“满了”的后面打上了问号！channel多用于多个goroutine间的通讯，一旦多个goroutine共同读写channel，len(channel)就会在多个goroutine间形成”竞态条件”，单存的依靠len(channel)来判断队列状态，不能保证在后续真正读写channel的时候channel状态是不变的。以判空为例：

从上图可以看到，当goroutine1使用len(channel)判空后，便尝试从channel中读取数据。但在真正从Channel读数据前，另外一个goroutine2已经将数据读了出去，goroutine1后面的读取将阻塞在channel上，导致后面逻辑的失效。因此，为了不阻塞在channel上，常见的方法是将“判空与读取”放在一起做、将”判满与写入”一起做，通过select实现操作的“事务性”：

//writing-go-code-issues/3rd-issue/channel_len.go/channel_len.go.go
func readFromChan(ch <-chan int) (int, bool) {
    select {
    case i := <-ch:
        return i, true
    default:
        return 0, false // channel is empty
    }
}

func writeToChan(ch chan<- int, i int) bool {
    select {
    case ch <- i:
        return true
    default:
        return false // channel is full
    }
}

我们看到由于用到了Select-default的trick，当channel空的时候，readFromChan不会阻塞；当channel满的时候，writeToChan也不会阻塞。这种方法也许适合大多数的场合，但是这种方法有一个“问题”，那就是“改变了channel的状态”：读出了一个元素或写入了一个元素。有些时候，我们不想这么做，我们想在不改变channel状态下单纯地侦测channel状态！很遗憾，目前没有哪种方法可以适用于所有场合。但是在特定的场景下，我们可以用len(channel)实现。比如下面这个场景：

这是一个“多producer + 1 consumer”的场景。controller是一个总控协程，初始情况下，它来判断channel中是否有消息。如果有消息，它本身不消费“消息”，而是创建一个consumer来消费消息，直到consumer因某种情况退出，控制权再回到controller，controller不会立即创建new consumer，而是等待channel下一次有消息时才创建。在这样一个场景中，我们就可以使用len(channel)来判断是否有消息。

2. 时间的格式化输出

时间的格式化输出是日常编程中经常遇到的“题目”。以前使用C语言编程时，用的是strftime。我们来回忆一下c的代码：

// writing-go-code-issues/3rd-issue/time-format/strftime_in_c.c
#include <stdio.h>
#include <time.h>

int main() {
        time_t now = time(NULL);

        struct tm *localTm;
        localTm = localtime(&now);

        char strTime[100];
        strftime(strTime, sizeof(strTime),  "%Y-%m-%d %H:%M:%S", localTm);
        printf("%s\n", strTime);

        return 0;
}

这段c代码输出结果是：

2018-04-04 16:07:00

我们看到strftime采用“字符化”的占位符(诸如：%Y、%m等)“拼”出时间的目标输出格式布局（如：”%Y-%m-%d %H:%M:%S”），这种方式不仅在C中采用，很多其他主流编程语言也采用了该方案，比如:shell、python、ruby、java等，这似乎已经成为了各种编程语言在时间格式化输出的标准。这些占位符对应的字符（比如Y、M、H）是对应英文单词的头母，因此相对来说较为容易记忆。

但是如果你在Go中使用strftime的这套“标准”，看到输出结果的那一刻，你肯定要“骂娘”！

// writing-go-code-issues/3rd-issue/time-format/timeformat_in_c_way.go
package main

import (
    "fmt"
    "time"
)

func main() {
    fmt.Println(time.Now().Format("%Y-%m-%d %H:%M:%S"))
}

上述go代码输出结果如下：

%Y-%m-%d %H:%M:%S

Go居然将“时间格式占位符字符串”原封不动的输出了!

这是因为Go另辟了蹊径，采用了不同于strftime的时间格式化输出的方案。Go的设计者主要出于这样的考虑：虽然strftime的单个占位符使用了对应单词的首字母的形式，但是但真正写起代码来，不打开strftime函数的manual或查看网页版的strftime助记符说明，很难真的拼出一个复杂的时间格式。并且对于一个”%Y-%m-%d %H:%M:%S”的格式串，不对照文档，很难在大脑中准确给出格式化后的时间结果，比如%Y和%y有何不同、%M和%m又有何差别呢？

Go语言采用了更为直观的“参考时间(reference time)”替代strftime的各种标准占位符，使用“参考时间”构造出来的“时间格式串”与最终输出串是“一模一样”的，这就省去了程序员再次在大脑中对格式串进行解析的过程：

格式串："2006年01月02日 15时04分05秒"

=>

输出结果：2018年04月04日 18时13分08秒

标准的参考时间如下：

2006-01-02 15:04:05 PM -07:00 Jan Mon MST

这个绝对时间本身并没有什么实际意义，仅是出于“好记”的考虑，我们将这个参考时间换为另外一种时间输出格式：

01/02 03:04:05PM '06 -0700

我们看出Go设计者的“用心良苦”，这个时间其实恰好是将助记符从小到大排序(从01到07)的结果，可以理解为：01对应的是%M, 02对应的是%d等等。下面这幅图形象地展示了“参考时间”、“格式串”与最终格式化的输出结果之间的关系：

就我个人使用go的经历来看，我在做时间格式化输出时，尤其是构建略微复杂的时间格式输出时，也还是要go doc time包或打开time包的web手册的。从社区的反馈来看，很多Gopher也都有类似经历，尤其是那些已经用惯了strftime格式的gopher。甚至有人专门做了“Fucking Go Date Format”页面，来帮助自动将strftime使用的格式转换为go time的格式。

下面这幅cheatsheet也能提供一些帮助(由writing-go-code-issues/3rd-issue/time-format/timeformat_cheatsheet.go输出生成)：

二. 库与工具篇

1. golang.org/x/text/encoding/unicode遇坑一则

在gocmpp这个项目中，我用到了unicode字符集转换：将utf8转换为ucs2(utf16)、ucs2转换为utf8、utf8转为GB18030等。这些转换功能，我是借助golang.org/x/text这个项目下的encoding/unicode和transform实现的。x/text是golang官方维护的text处理的工具包，其中包含了对unicode字符集的相关操作。

要实现一个utf8到ucs2(utf16)的字符集转换，只需像如下这样实现即可（这也是我的最初实现）：

func Utf8ToUcs2(in string) (string, error) {
    if !utf8.ValidString(in) {
        return "", ErrInvalidUtf8Rune
    }

    r := bytes.NewReader([]byte(in))

    //UTF-16 bigendian, no-bom
    t := transform.NewReader(r, unicode.All[1].NewEncoder())
    out, err := ioutil.ReadAll(t)
    if err != nil {
        return "", err
    }
    return string(out), nil
}

这里要注意是unicode.All这个切片保存着UTF-16的所有格式：

var All = []encoding.Encoding{
    UTF16(BigEndian, UseBOM),
    UTF16(BigEndian, IgnoreBOM),
    UTF16(LittleEndian, IgnoreBOM),
}

这里我最初我用的是All[1]，即UTF16(BigEndian, IgnoreBOM)，一切都是正常的。

但就在年前，我将text项目更新到最新版本，然后发现单元测试无法通过：

--- FAIL: TestUtf8ToUcs2 (0.00s)
    utils_test.go:58: The first char is fe, not equal to expected 6c
FAIL
FAIL    github.com/bigwhite/gocmpp/utils    0.008s

经查找发现：text项目的golang.org/x/text/encoding/unicode包做了不兼容的修改，上面那个unicode.All切片变成了下面这个样子：

// All lists a configuration for each IANA-defined UTF-16 variant.
var All = []encoding.Encoding{
    UTF8,
    UTF16(BigEndian, UseBOM),
    UTF16(BigEndian, IgnoreBOM),
    UTF16(LittleEndian, IgnoreBOM),
}

All切片在最前面插入了一个UTF8元素，这样导致我的代码中原本使用的 UTF16(BigEndian, IgnoreBOM)变成了UTF16(BigEndian, UseBOM)，test不过也就情有可原了。

如何改呢？这回儿我直接使用UTF16(BigEndian, IgnoreBOM)，而不再使用All切片了：

func Utf8ToUcs2(in string) (string, error) {
    if !utf8.ValidString(in) {
        return "", ErrInvalidUtf8Rune
    }

    r := bytes.NewReader([]byte(in))
    //UTF-16 bigendian, no-bom
    t := transform.NewReader(r,
            unicode.UTF16(unicode.BigEndian, unicode.IgnoreBOM).NewEncoder())
    out, err := ioutil.ReadAll(t)
    if err != nil {
        return "", err
    }
    return string(out), nil
}

这样即便All切片再有什么变动，我的代码也不会受到什么影响了。

2. logrus的非结构化日志定制输出

在该系列的第一篇文章中，我提到过使用logrus+lumberjack来实现支持rotate的logging。

默认情况下日志的输出格式是这样的（writing-go-code-issues/3rd-issue/logrus/logrus2lumberjack_default.go）：

time="2018-04-05T06:08:53+08:00" level=info msg="logrus log to lumberjack in normal text formatter"

这样相对结构化的日志比较适合后续的集中日志分析。但是日志携带的“元信息(time、level、msg)”过多，并不是所有场合都倾向于这种日志，于是我们期望以普通的非结构化的日志输出，我们定制formatter：

// writing-go-code-issues/3rd-issue/logrus/logrus2lumberjack.go
func main() {
    customFormatter := &logrus.TextFormatter{
        FullTimestamp:   true,
        TimestampFormat: "2006-01-02 15:04:05",
    }
    logger := logrus.New()
    logger.Formatter = customFormatter

    rotateLogger := &lumberjack.Logger{
        Filename: "./foo.log",
    }
    logger.Out = rotateLogger
    logger.Info("logrus log to lumberjack in normal text formatter")
}

我们使用textformatter，并定制了时间戳的格式，输出结果如下：

time="2018-04-05 06:22:57" level=info msg="logrus log to lumberjack in normal text formatter"

日志仍然不是我们想要的那种。但同样的customFormatter如果输出到terminal，结果却是我们想要的：

//writing-go-code-issues/3rd-issue/logrus/logrus2tty.go

INFO[2018-04-05 06:26:16] logrus log to tty in normal text formatter

到底如何设置TextFormatter的属性才能让我们输出到lumberjack中的日志格式是我们想要的这种呢？无奈下只能挖logrus的源码了，我们找到了这段代码：

//github.com/sirupsen/logrus/text_formatter.go

// Format renders a single log entry
func (f *TextFormatter) Format(entry *Entry) ([]byte, error) {
    ... ...
    isColored := (f.ForceColors || f.isTerminal) && !f.DisableColors

    timestampFormat := f.TimestampFormat
    if timestampFormat == "" {
        timestampFormat = defaultTimestampFormat
    }
    if isColored {
        f.printColored(b, entry, keys, timestampFormat)
    } else {
        if !f.DisableTimestamp {
            f.appendKeyValue(b, "time", entry.Time.Format(timestampFormat))
        }
        f.appendKeyValue(b, "level", entry.Level.String())
        if entry.Message != "" {
            f.appendKeyValue(b, "msg", entry.Message)
        }
        for _, key := range keys {
            f.appendKeyValue(b, key, entry.Data[key])
        }
    }

    b.WriteByte('\n')
    return b.Bytes(), nil
}

我们看到如果isColored为false，输出的就是带有time, msg, level的结构化日志；只有isColored为true才能输出我们想要的普通日志。isColored的值与三个属性有关：ForceColors 、isTerminal和DisableColors。我们按照让isColored为true的条件组合重新设置一下这三个属性，因为输出到file，因此isTerminal自动为false。

//writing-go-code-issues/3rd-issue/logrus/logrus2lumberjack_normal.go
func main() {
    //    isColored := (f.ForceColors || f.isTerminal) && !f.DisableColors
    customFormatter := &logrus.TextFormatter{
        FullTimestamp:   true,
        TimestampFormat: "2006-01-02 15:04:05",
        ForceColors:     true,
    }
    logger := logrus.New()
    logger.Formatter = customFormatter

    rotateLogger := &lumberjack.Logger{
        Filename: "./foo.log",
    }
    logger.Out = rotateLogger
    logger.Info("logrus log to lumberjack in normal text formatter")
}

我们设置ForceColors为true后，在foo.log中得到了我们期望的输出结果：

INFO[2018-04-05 06:33:22] logrus log to lumberjack in normal text formatter

三. 实践篇

1. 说说网络数据读取timeout的处理 – 以SetReadDeadline为例

Go天生适合于网络编程，但网络编程的复杂性也是有目共睹的、要写出稳定、高效的网络端程序，需要的考虑的因素有很多。比如其中之一的：从socket读取数据超时的问题。

Go语言标准网络库并没有实现epoll实现的那样的“idle timeout”，而是提供了Deadline机制，我们用一副图来对比一下两个机制的不同：

看上图a)和b)展示了”idle timeout”机制，所谓idle timeout就是指这个timeout是真正在没有data ready的情况的timeout（如图中a)，如果有数据ready可读(如图中b)，那么timeout机制暂停，直到数据读完后，再次进入数据等待的时候，idle timeout再次启动。

而deadline(以read deadline为例)机制，则是无论是否有数据ready以及数据读取活动，都会在到达时间（deadline）后的再次read时返回timeout error，并且后续的所有network read operation也都会返回timeout（如图中d），除非重新调用SetReadDeadline(time.Time{})取消Deadline或在再次读取动作前重新重新设定deadline实现续时的目的。Go网络编程一般是“阻塞模型”，那为什么还要有SetReadDeadline呢，这是因为有时候，我们要给调用者“感知”其他“异常情况”的机会，比如是否收到了main goroutine发送过来的退出通知信息。

Deadline机制在使用起来很容易出错，这里列举两个曾经遇到的出错状况：

a) 以为SetReadDeadline后，后续每次Read都可能实现idle timeout

在上图中，我们看到这个流程是读取一个完整业务包的过程，业务包的读取使用了三次Read调用，但是只在第一次Read前调用了SetReadDeadline。这种使用方式仅仅在Read A时实现了足额的“idle timeout”，且仅当A数据始终未ready时会timeout；一旦A数据ready并已经被Read，当Read B和Read C时，如果还期望足额的“idle timeout”那就误解了SetReadDeadline的真正含义了。因此要想在每次Read时都实现“足额的idle timeout”，需要在每次Read前都重新设定deadline。

b) 一个完整“业务包”分多次读取的异常情况的处理

在这幅图中，每个Read前都重新设定了deadline，那么这样就一定ok了么？对于在一个过程中读取一个“完整业务包”的业务逻辑来说，我们还要考虑对每次读取异常情况的处理，尤其是timeout发生。在该例子中，有三个Read位置需要考虑异常处理。

如果Read A始终没有读到数据，deadline到期，返回timeout，这里是最容易处理的，因为此时前一个完整数据包已经被读完，新的完整数据包还没有到来，外层控制逻辑收到timeout后，重启再次启动该读流程即可。

如果Read B或Read C处没有读到数据，deadline到期，这时异常处理就棘手一些，因为一个完整数据包的部分数据（A）已经从流中被读出，剩余的数据并不是一个完整的业务数据包，不能简单地再在外层控制逻辑中重新启动该过程。我们要么在Read B或Read C处尝试多次重读，直到将完整数据包读取完整后返回；要么认为在B或C处出现timeout是不合理的，返回区别于A处的错误码给外层控制逻辑，让外层逻辑决定是否是连接存在异常。

注：本文所涉及的示例代码，请到这里下载。

微博：@tonybai_cn
微信公众号：iamtonybai
github.com: https://github.com/bigwhite

微信赞赏：