在公有云被广泛接纳的今天，数据传输安全问题日益凸显，因为在公有云提供商的经典网络（二层互通）中，即便是内部网络通信也要考虑网络嗅探等hack手段，这也是公有云主推所谓“专用网络（二层隔离）”的原因之一。从应用的角度，我们应该尽量通过技术手段保证数据通信的安全性。而目前最常用的方式就是基于SSL/TLS的安全通信方式了，在七层，对应的就是https了。

这样，下面的仅在负载均衡/反向代理入口做加密通信的传统模型越来越无法满足数据安全性的需要了(nginx与backend service之间是基于明文的http通信)：

传统安全通信模型：

client --- (via https) ---> nginx ---- (via http) ----> upstream backend services

我们需要下面的模型：

更为安全的通信模型：

client --- (via https) ---> nginx ---- (via https) ----> upstream backend services

在Kubernetes集群中，这种情况稍好些，首先，业务负载运行在集群的“虚拟网络”中，其次，一些K8s的网络插件实现是支持跨节点网络加密的（有一定的网络性能损耗），比如weave。但永远没有绝对的安全，作为业务应用的设计和实现人员，我们要尽可能的保证数据的通信安全，因此在面向七层的应用中，要尽可能的使用基于HTTPS的通信模型。本篇就来实践一下如何为Kubernetes集群内的HTTPS服务进行ingress的配置。

一. 例子概述与环境准备

在《实践kubernetes ingress controller的四个例子》一文中，我讲解了四种基本的kubernetes ingress配置方式。在这些例子中，有些例子的ingress controller(nginx)与backend service之间使用的是https，但client到ingress controller之间的通信却一直是基于http的。在本文中，我们的目标就是上面提到的那个更为安全的通信模型，即client与ingress controller(nginx)、nginx与backend service之间均使用的是https通信。这里在《实践kubernetes ingress controller的四个例子》一文例子的基础上，我们创建一个新的nginx ingress controller: nginx-ingress-controller-ic3，并将后端的svc7~svc9三个不同类型的服务暴露给client，如下图所示：

• svc7: 是对传统通信模型的“复现”，即client与ingress controller(nginx)间采用https加密通信，但ingress controller(nginx)与svc7间则是明文的http通信；
• svc8: 是ssl-termination的安全配置模型，即client与svc8的https通信分为“两段”，client与nginx建立https连接后，nginx将client提交的加密请求解密后，再向svc8发起https请求，并重新加密请求数据。这种client端ssl的过程在反向代理或负载均衡器终结的https通信方式被称为“ssl-termination”。
• svc9: 是ssl-passthrough的安全配置模型，即nginx不会对client的https request进行解密，而是直接转发给backend的svc9服务，client端的ssl过程不会终结于nginx，而是在svc9对应的pod中终结。这种https通信方式被称为”ssl-passthrough”。这种配置模型尤其适合backend service对client端进行client certificate验证的情况，同时也降低了nginx加解密的性能负担。

本文基于下面环境进行实验：kubernetes 1.10.3、weave networks 2.3.0、nginx-ingress-controller:0.15.0。关于本文涉及的例子的源码、chart包以及ingress controllers的yaml源文件可以在这里下载到。

二. 建立新的ingress-nginx-controller：nginx-ingress-controller-ic3

为了更好地进行例子说明，我们建立一个新的ingress-nginx-controller：nginx-ingress-controller-ic3，svc7~svc9都通过该ingress controller进行服务入口的暴露管理。要创建nginx-ingress-controller-ic3，我们首先需要在ic-common.yaml中为Role: nginx-ingress-role添加一个resourceName： “ingress-controller-leader-ic3″，并apply生效：

// ic-common.yaml
... ...
    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"
      - "ingress-controller-leader-ic3"
... ...

# kubectl apply -f ic-common.yaml

我们为nginx-ingress-controller-ic3创建nodeport service，新nodeport为：30092：

// ic3-service-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-ic3
  namespace: ingress-nginx-demo
spec:
  type: NodePort
  ports:
  - name: https
    port: 443
    targetPort: 443
    nodePort: 30092
    protocol: TCP
  selector:
    app: ingress-nginx-ic3

注意：ingress-nginx-ic3 service的nodeport映射到ic3 ingress controller的443端口，也就是支持安全通信的端口，而不是明文的80端口。

最后创建nginx-ingress-controller-ic3 pod，可以复制一份ic2-mandatory.yaml，然后将内容中的ic2全部修改为ic3即可：

# kubectl apply -f ic3-mandatory.yaml

如无意外，nginx-ingress-controller-ic3应该已经正常地运行在你的k8s cluster中了。

三. svc7: 使用ssl termination，但nginx与backend服务之间采用明文传输（http)

加密Web流量有两个主要配置方案：SSL termination和SSL passthrough。

使用SSL termination时，客户端的SSL请求在负载均衡器/反向代理中解密，解密操作将增加负载均衡器的工作负担，较为耗费CPU，但简化了SSL证书的管理。至于负载均衡器和后端之间的流量是否加密，需要nginx另行配置。

SSL Passthrough，意味着client端将直接将SSL连接发送到后端(backend)。与SSL termination不同，请求始终保持加密，并且解密负载分布在后端服务器上。但是，这种情况的SSL证书管理略复杂，证书必须在每台服务器上自行管理。另外，在这种方式下可能无法添加或修改HTTP header，可能会丢失X-forwarded-* header中包含的客户端的IP地址，端口和其他信息。

我们先来看一种并不那么“安全”的“传统模型”：在nginx上暴露https，但nginx到backend service(svc7)采用http。

我们先来创建相关的密钥和公钥证书，并以一个Secret：ingress-controller-demo-tls-secret存储密钥和证书数据：

// ingress-controller-demo/manifests下面

# openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ic3.key -out ic3.crt -subj "/CN=*.tonybai.com/O=tonybai.com"
# kubectl create secret tls ingress-controller-demo-tls-secret --key  ic3.key --cert ic3.crt

svc7几乎是和svc1一样的程序（输出的字符串标识不同），但svc7的ingress与svc1大不相同，因为我们需要通过https访问svc7的ingress：

// svc7的values.yaml
... ...
replicaCount: 1

image:
  repository: bigwhite/ingress-controller-demo-svc7
  tag: v0.1
  pullPolicy: Always

service:
  type: ClusterIP
  port: 443

ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: ic3
  path: /
  hosts:
    - svc7.tonybai.com
  tls:
    - secretName: ingress-controller-demo-tls-secret
      hosts:
        - svc7.tonybai.com
... ...

与svc1的values.yaml不同的是，我们使用的ingress controller是ic3，我们开启了tls，secret用的就是我们上面创建的那个secret：ingress-controller-demo-tls-secret。创建ic3-svc7后，我们看到ingress controller内部的nginx.conf中有关svc7的配置输出如下：

# kubectl exec nginx-ingress-controller-ic3-67f7cf7845-2tnc9 -n ingress-nginx-demo -- cat /etc/nginx/nginx.conf

        # map port 442 to 443 for header X-Forwarded-Port
        map $pass_server_port $pass_port {
                442              443;
                default          $pass_server_port;
        }

        upstream default-ic3-svc7-http {
                least_conn;

                keepalive 32;

                server 192.168.28.13:8080 max_fails=0 fail_timeout=0;

        }

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

                listen 80;

                listen [::]:80;

                set $proxy_upstream_name "-";

                listen 442 proxy_protocol   ssl http2;

                listen [::]:442 proxy_protocol  ssl http2;

                # PEM sha: 248951b75535e0824c1a7f74dc382be3447057b7
                ssl_certificate                         /ingress-controller/ssl/default-ingress-controller-demo-tls-secret.pem;
                ssl_certificate_key                     /ingress-controller/ssl/default-ingress-controller-demo-tls-secret.pem;

                ssl_trusted_certificate                 /ingress-controller/ssl/default-ingress-controller-demo-tls-secret-full-chain.pem;
                ssl_stapling                            on;
                ssl_stapling_verify                     on;

                location / {
                        ... ...
                        proxy_pass http://default-ic3-svc7-http;

                        proxy_redirect                          off;

                }
           ... ...
        }
        ## end server svc7.tonybai.com

可以看到30092(nodeport) 映射的ingress controller的443端口在svc7.tonybai.com这个server域名下已经有了ssl标识，并且ssl_certificate和ssl_certificate_key对应的值就是我们之前创建的ingress-controller-demo-tls-secret。

我们通过curl访问以下svc7服务：

# curl -k https://svc7.tonybai.com:30092
Hello, I am svc7 for ingress-controller demo!

此时，如果再用http方式去访问svc7，你会得到下面错误结果：

# curl http://svc7.tonybai.com:30092
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx/1.13.12</center>
</body>
</html>

四. svc8: 使用ssl termination，但nginx与backend服务之间采用加密传输(https)

前面说过，SSL termination配置场景中，负载均衡器和后端之间的流量是否加密，需要nginx另行配置。svc7采用了未加密的方式，nginx -> backend service存在安全风险，我们要将其改造为也通过https进行数据加密传输，于是有了svc8这个例子。

svc8对应的程序本身其实是上一篇文章《实践kubernetes ingress controller的四个例子》中的svc2的clone（唯一修改就是输出的log中的标识)。

在svc8对应的chart中，我们将values.yaml改为：

// ingress-controller-demo/charts/svc8/values.yaml

replicaCount: 1

image:
  repository: bigwhite/ingress-controller-demo-svc8
  tag: v0.1
  pullPolicy: Always

service:
  type: ClusterIP
  port: 443

ingress:
  enabled: true
  annotations:
    # kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/secure-backends: "true"
    kubernetes.io/ingress.class: ic3
  path: /
  hosts:
    - svc8.tonybai.com
  tls:
    - secretName: ingress-controller-demo-tls-secret
      hosts:
        - svc8.tonybai.com

... ...

与svc7不同点在于values.yaml中的新annotation： nginx.ingress.kubernetes.io/secure-backends: “true”。这个annotation让nginx以https的方式去访问backend service: svc8。安装svc8 chart后，ingress nginx controller为svc8生成的配置如下：

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

                listen 80;

                listen [::]:80;

                set $proxy_upstream_name "-";

                listen 442 proxy_protocol   ssl http2;

                listen [::]:442 proxy_protocol  ssl http2;

                # PEM sha: 248951b75535e0824c1a7f74dc382be3447057b7
                ssl_certificate                         /ingress-controller/ssl/default-ingress-controller-demo-tls-secret.pem;
                ssl_certificate_key                     /ingress-controller/ssl/default-ingress-controller-demo-tls-secret.pem;

                ssl_trusted_certificate                 /ingress-controller/ssl/default-ingress-controller-demo-tls-secret-full-chain.pem;
                ssl_stapling                            on;
                ssl_stapling_verify                     on;

                location / {
                     ... ...
                        proxy_pass https://default-ic3-svc8-https;

                        proxy_redirect                          off;

                }

        }
        ## end server svc8.tonybai.com

        upstream default-ic3-svc8-https {
                least_conn;

                keepalive 32;

                server 192.168.28.14:8080 max_fails=0 fail_timeout=0;

        }

使用curl访问svc8服务（-k: 忽略对server端证书的校验)：

# curl -k https://svc8.tonybai.com:30092
Hello, I am svc8 for ingress-controller demo!

五. svc9: 使用ssl passthrough, termination at pod

某些服务需要通过对client端的证书进行校验的方式，进行身份验证和授权，svc9就是这样一个对client certification进行校验的双向https校验的service。针对这种情况，ssl termination的配置方法无法满足需求，我们需要使用ssl passthrough的方案。

在ingress nginx controller开启ssl passthrough方案需要在ingress controller和ingress中都做一些改动。

首先我们需要为nginx-ingress-controller-ic3添加一个新的命令行参数：–enable-ssl-passthrough，并重新apply生效：

// ic3-mandatory.yaml
... ...
spec:
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller-ic3
          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-ic3
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services-ic3
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services-ic3
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx-ic3
            - --annotations-prefix=nginx.ingress.kubernetes.io
            - --enable-ssl-passthrough
            - --ingress-class=ic3
... ...

然后在svc9的chart中，为ingress添加新的annotation nginx.ingress.kubernetes.io/ssl-passthrough: “true”

// ingress-controller-demo/charts/svc9/values.yaml

replicaCount: 1

image:
  repository: bigwhite/ingress-controller-demo-svc9
  tag: v0.1
  pullPolicy: Always

service:
  type: ClusterIP
  port: 443

ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: ic3
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"

  path: /
  hosts:
    - svc9.tonybai.com
  tls:
    - secretName: ingress-controller-demo-tls-secret
      hosts:
        - svc9.tonybai.com
... ...

isntall svc9 chart之后，我们用curl来访问以下svc9：

# curl -k  https://svc9.tonybai.com:30092
curl: (35) gnutls_handshake() failed: Certificate is bad

由于svc9程序对client端的certificate进行验证，没有提供client certificate的curl请求被拒绝了！svc9 pod的日志也证实了这一点：

2018/06/25 05:36:29 http: TLS handshake error from 192.168.31.10:38634: tls: client didn't provide a certificate

我们进入到ingress-controller-demo/src/svc9/client路径下，执行：

# curl -k --key ./client.key --cert ./client.crt https://svc9.tonybai.com:30092
Hello, I am svc9 for ingress-controller demo!

带上client.crt后，svc9通过了验证，返回了正确的应答。

client路径下是一个svc9专用的客户端，我们也可以执行该程序去访问svc9:

# go run client.go
Hello, I am svc9 for ingress-controller demo!

我们再看看采用ssl-passthrough方式下ingress-nginx controller的访问日志，当curl请求发出时，ingress-nginx controller并未有日志输出，因为没有在nginx处ssl termnination，从此也可以证实：nginx将client的ssl过程转发到pod中去了，即passthrough了。

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

微信赞赏：

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

本文是首发于个人微信公众号的文章“TB一周萃选[第8期]”的归档。

再看看那个光点，它就在这里。那是我们的家园，我们的一切。你所爱的每一个人，你认识的每一个人，你听说过的每一个人，曾经有过的每一个人，都在它上面度过他们的一生。我们的欢乐与痛苦聚集在一起，数以千计的自以为是的宗教、意识形态和经济学说，所有的猎人与强盗、英雄与懦夫、文明的缔造者与毁灭者、国王与农夫、年轻的情侣、母亲与父亲、满怀希望的孩子、发明家和探险家、德高望重的教师、腐败的政客、超级明星、最高领袖、人类历史上的每一个圣人与罪犯，都住在这里——一粒悬浮在阳光中的微尘。

但在浩瀚的宇宙剧场里，地球只是一个极小的舞台。

——卡尔·萨根 《暗淡蓝点》

笔者注：那个光点所指的是1990年旅行者1号于距地球64亿公里处最后一次回望母星的照片中的地球，它只是一个占用2-3个像素的光点。

这一周，我们被“超级月亮”、“红月亮”、“月全食”等关键字刷屏了。月全食并不是稀罕物，据说一般2年就会有一次，而且由于是体格巨大的地球遮住月球，因此可观赏的地域也是很广阔的，与稀罕的日全食有大不同。这次月全食的特殊之处在于月亮恰位于公转的近地点，看起来大一些罢了。即便大，也有很多人不屑去看，但更多的人选择关注这个事件，并抽空儿抬头瞄上两眼，还有一部分更为执着的天文爱好者们冒着严寒，移步到远离市区的户外，就为了能最大程度降低城市光污染对观赏的影响。

对地外星体或天文现象的关注，古人早已有之。只是古代人不明其理，以神秘或神灵释之。究其深层原因？人类为何从古自今保持对地外事物的关注，仅仅是看客？仅仅是好奇么？从每个个体的角度来看也许是这样，但从人类文明整体的角度来说，这是根植于我们人类古老的基因所决定的：人类社会终极目标就是要不断的生存和繁衍下去，世世代代，子子孙孙无穷尽也。古时人类即是如此，但苦于能力不足，无法将手臂伸到地球之外。但随着人类文明演化和发展，尤其是当人类科技发展突飞猛进之后，人类逐渐意识到：“地球也许是我们的第一个家，但可能不是我们唯一的家”。“人类生存和繁衍”的使命促使着人们不断地走出地球，其第一要务就是找到合适人类生存的第二家园或更多家园，附带的任务可能是为人类在茫茫的宇宙星海中找到其他“邻居”。

只是和科幻片中的宇宙探索进展相比，现实中的我们的进展还是太缓慢了。

一、一周文章精粹

1. 写Go代码时遇到的那些问题[第2期]

年前开启写的一个Go coding系列，这里广告一下。第2期内容关注了dep的日常工作流、“超时等待退出”框架的一种实现以及Go testing中的fixture的setUp和tearDown，欢迎交流。

文章链接：“写Go代码时遇到的那些问题[第2期]“

2. 使用不到200行Go代码实现你的区块链

2017年以来，随着比特币价格的爆发，区块链技术热度也逐渐走强。对于技术人来说，区块链是什么不能仅停留在口头上，Show your code更重要。这篇文章旨在以Go代码从头开始实现一个简易区块链的demo，目的是帮助你理解区块链背后的原理。

文章链接：“Code your own blockchain in less than 200 lines of Go!”

3. “The Good Way to REST”系列

自从Roy Thomas Fielding在他2000年的博士论文中提出了REST(REpresentational State Transfer)设计原则后，RESTful架构一度在Web Service的领域占据了大片领地，直到近几年RPC的兴起，RESTful才有了一副“过气网红”的样子。总体来说，RESTful已是一门成熟的设计技术原则。REFINERI咨询师Berat Daglar撰写了三篇文章，对REST的概念、原理机制以及发展过程进行了介绍和总结：

文章链接：
* “The Good Way to REST: Introduction”
* “The Good Way to REST: Core Values And Mechanics”
* “The Good Way To REST: Road to Maturity”

4. Apollo 2.0框架和源码分析(一)

Baidu的Apollo自动驾驶平台一经发布就受到了广泛的关注。其最新Apollo 2.0更是具备了实现简单城市道路自动驾驶的能力。

知乎专栏上的这篇“”文章为大家详细介绍了Apollo 2.0软硬件框架结构。但源码分析还要等后续部分出炉。

文章链接： Apollo 2.0框架和源码分析(一)

5. Go package import全面总结

Go基础知识范畴，该文对Go中各种形式的import用法进行了梳理，初学者可以看看。

文章链接：“Go tips and tricks: almost everything about imports”

二、一周资料分享

1.远程工作指南

在这个网络时代，远程工作的方式越来越多的被很多个人和公司所青睐，其尤其适合程序猿、撰稿人等以计算机为工具进行“创作”的键盘族，一台电脑+一根网线（一个无线路由）足矣。remote working形式还尤其适合“松耦合”、初期无固定办公场所的初创公司。

但对于一个公司或组织而言，采用远程工作的方式还是有一定挑战的：比如：如何招聘到正确的人、高效沟通、有效管理、远程工作文化的建立等。这些都可以从下面这份远程工作指南的资料中找到。

资料链接：“远程工作指南”

2. Hacker 101指南

“安全”永远是影响广泛但从业人员又相对小众的领域。对于一般开发者而言，“安全”永远是被最后考虑的topic，而所谓的安全问题又都是开发者“一手造就”的，这似乎是一个死结。

hacker101.com网站推出了free的web安全视频课程，从名字中的“101”我们也可以知道这是一个入门课程，课程包括会话安全和漏洞两大主题，值得一看。

资料链接：“Hacker 101 Guide”

三、一周工具推荐

1. vscode+vscode-go+vscodevim组合

再吹一波vscode!

之前曾写过一篇文章《使用Visual Studio Code辅助Go源码编写》，那个时候我依然以Vim为主，vscode为辅。不过当时在文章中我就提到过vim结合vim-go在我的机器上存在的一些问题：比如save文件时非常慢、光标移动后光标下的字符显示异常等。这些问题我个人猜测与vim-go使用的相关插件的性能有关，也许也和我的单一GOPATH目录下go packages过多有关。不过，无论怎样，vim下写Go代码的体验日益糟糕。

因此在这两个月编码较多、task较为急迫的情况，我切换到了“vscode+vscode-go+vscodevim”组合，这以后除了因gocode偶尔崩溃导致的自动补齐失效(可以重启gocode解决：gocode close;gocode)之外，基本没有遇到什么较大问题。

可以说vscode为多种编程语言的程序员之间提供了一种通用的“工具”语言。可惜在android mobile或pad上无法使用vscode。

工具链接：vscode

四、一周图书推荐

1.《Designing Distributed Systems – Patterns and Paradigms for Scalable, Reliable Services》

Brendan Burns目前是微软azure的技术工程总监，但其更响亮的title是之前在Google Cloud Platform工作时和Joe Beda、Craig McLuckie一起发起了Kubernetes开源项目，开启了分布式计算的新时代。

近期Brendan Burns刚刚发布了自己的新书《Designing Distributed Systems – Patterns and Paradigms for Scalable, Reliable Services》。在书中，Brendan Burns借用软件设计模式的概念阐述和总结了构建一个可靠、可扩展的分布式系统时可能使用到的一些“模式”：

• 单机模式(Single-Node Patterns)
  • 边车模式 (Sidecar Pattern)
  • 大使模式 (Ambassador Pattern)
  • 适配器模式(Adapter Pattern)
• 服务模式(Serving Patterns)
  • 带负载均衡的多副本无状态服务(Replicated Load-Balanced Services)
  • 分片服务(Sharded Services)
  • 分散/聚集(Scatter/Gather)
  • 函数即服务和事件驱动处理(Functions and Event-Driven Processing)
  • 分布式选主(Ownership Election)
• 批处理计算模式(Batch Computational Patterns)
  • 工作队列系统(Work Queue Systems)
  • 事件驱动批处理(Event-Driven Batch Processing)
  • 协作批处理(Coordinated Batch Processing)

该书完全面对基于容器以及容器调度管理平台的构建的分布式系统，是云原生时代不可多得的技术参考书。该书由O’Reilly出版，目前在azure的站点上可以免费下载。

图书链接：《Designing Distributed Systems 》

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

我的联系方式：

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

微信赞赏：

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