对于 HTTP 协议本身来说是有异步这个响应结果的，它的 202 Accepted 状态码的响应就是告诉客户端请求已经接受了，但还没有处理，并且不保证在处理的过程中是否一定能成功。

从这个角度来说，只用 HTTP 就需要服务端再提供一个查询的接口，客户端在请求结束后不断的查询请求的处理状态。

还有一种情况是你的处理结果可以分批次传输，比如去数据库读取数据需要较长时间，那么就分别读取，分批次交给客户端，这时是可以在一个 HTTP 连接中完成的，通过 chunked 传输编码，让客户端和服务端保持长连接。

有些没太理解，是不是应该用 job ？

深入的理解有没有个方向，比如说你想理解 goroutine，想去写个获取 goroutine ID 的例子，但这需要你先对 goroutine 有着很深的理解，才能做得出来，而不是做着做着就理解了。

@knightdl #3 我还是看了这个剧才知道溜粉这个词，好多人打低分都是因为这个。幸好我看的比较晚，第八集才看，对于联动其他人物或宇宙观没啥期待感。单从剧集本身来讲还是很好的，希望旺达能早点出独立电影。

沈阳也有一些，大连对日的外包多吧

@hwdef #7 《凤凰项目》、《 DevOps 实践指南》、《持续交付》 微信读书上都有。前一本还行，后两本都是大部头

@hwdef #4 通道阻塞没有人唤醒是不会重新运行的，for 被抢占后还是会被切换回来的。select 有 case 才需要 return，没有 case 会阻塞，所以不用 return，编译器的优化

别光收藏啊，聊两句，要不掉出首页没人看，收藏也没用了 https://i.v2ex.co/504J5BO2.png

标记下，中午看。做这个剧的 up 确实挺多，周末刷了一整天。
其实最后俩彩蛋都很清晰，关联后面的电影。倒是这个剧的一些小细节挖出来挺有意思的

@smilingsun #3 之前对容器网络方面感兴趣，有过认真学习。实际上真实的网络环境远不是 flannel 这么简单 https://i.v2ex.co/9kZ3y873.png 还是会碰到很多的坑

@waising #1 knative 我也接触过，后来一直在用 tekton，我觉得算是做得比较好的 kubernetes CI 工具了。istio 和服务网格最开始我以为包含了微服务的所有方面，后来学习后发现只是关注于服务之间的交互和流量治理方面，不过也做的很多了，devops 中提到的几个实践都可以依靠它来实现，金丝雀发布、A/B 测试等等。

复现失败...可能拍的不够快？

正常来讲，虚拟网络设备的 mac 地址可以用 ip command 修改，但是在容器内直接操作是不会被允许的，因为有安全问题，会提示“RTNETLINK answers: Operation not permitted”

所以需要在宿主机上通过 network namespace 来操作。docker 创建的 network namespace 获取比较复杂，不能直接通过 ip netns 获取。

按步骤来获取 netns：

1. 查找 docker container pid
docker inspect -f '{{.State.Pid}}' ${contriner_id}

2. 创建本机的 netns 目录
mkdir /var/run/netns

3. 创建链接
ln -sfT /proc/${pid}/ns/net /var/run/netns/${container_id}

4. 查看 netns
ip netns

然后就可以通过 ip comnad 修改 mac 地址了，但是我不确定修改后会不会导致其他的问题......

ip netns exec ${netns_name} ip link set dev eth0 down
ip netns exec ${netns_name} ip link set dev eth0 address ${new_max_address}
ip netns exec ${netns_name} ip link set dev eth0 up

@CSGO #2 自己做个镜像，把流程放在 Dockerfile 里。容器出问题了也能很快重新起一个，换机器也没问题

你这确实是虚拟机的思路，使用容器的思路应该是直接运行宝塔这个应用的容器。其他的应用也都是直接 pull 对应镜像，而不是自己去安装

花切

同意二楼

一旦你想要吊销 JWT，那么此时 JWT 的作用就不再能提供一个完整的授权，而是仅仅是通过签名成为一段不可伪造的信息，然后使用其他方法鉴权，这个时候它的作用与 session 没有本质区别。