支持容器的 paas 平台应该都可以，比如 heroku： https://devcenter.heroku.com/articles/build-docker-images-heroku-yml

参加过 Go 夜读的读书会，可惜愿意一起讨论分享的人不多。

@iannil #8 完全不吃肉吗？会不会有些肉类中的微量元素没有摄取到，有点像素食者。

@czfy #6 哦哦，明白了。游戏引擎在做这方面的模块，他们提供周边的服务模块。所以以后游戏开发确实会越来越简单。

@czfy #4 他们（ TDS ）现在抽象出了社区、好友、成就、存储、数据分析、广告这几个模块。并没有涉及到游戏根本的内容上。我想以后会不会出现根据游戏类型的相关模块化。比如 FPS 游戏提供枪支模型动作，赛车游戏提供车辆模型碰撞什么的。

加入了“ TapTap 的开发者服务（ TDS ）”，搜了一下是那种模块化的游戏开发工具。有没有相关从业人士讲讲这种东西好用吗？以后做游戏真的能拖拖模块组合起来就可以吗

这也太按照字面的意思来理解了。

我理解的 devops 是一套由各种原则、方法组成的工作体系，由此来达成提高产品质量、保证安全性、快速交付等目的。

看过一个 TEDx 的演讲，是关于努力的，演讲者有一句话我认为讲得很好，一直牢牢记着。

《我们这一代人的困惑--于宙》
“这些年我一直提醒自己一件事情，千万不要自己感动自己。大部分人看似的努力，不过是愚蠢导致的。什么熬夜看书到天亮，连续几天只睡几小时，多久没放假了，如果这些东西也值得夸耀，那么富士康流水线上任何一个人都比你努力多了。人难免天生有自怜的情绪，唯有时刻保持清醒，才能看清真正的价值在哪里”

努力是为了实现梦想，或是达成目的。向着错误方向的努力，也是努力，只不过是愚蠢导致的，这种努力也是没有价值的。

以此来看 A 和 B ； A 如果是向着错误的方向努力，其实不过是自我安慰罢了。B 的问题我觉得在于应该要求自己，而不是要求别人，如果以是否成功来否定别人的努力，对于别人来说，未免太过残忍。毕竟成功不仅仅只能靠努力，就算向着正确的方向努力，也不一定能成功。

可以看一看心理学相关的书，它们可以帮助你更好的接受、更有勇气改变。

别看精神分析学这种治病的，要看更“鸡汤”一点的个体心理学和积极心理学。上面也有人提到过的《被讨厌的勇气》和《哈佛幸福课》。

Go 由于有自己的调度模型，所以它的 channel 阻塞不是依赖于线程的。而是由 Go 自己的运行时来保存 goroutine 的上下文，然后等待唤醒。

线程的并发可以看看 CSAPP 的第十二章 并发编程

@monsterxx03 #8 我觉得 Go 的运行时调度模型实现的挺好的，一个 go 关键字就能用。但毕竟没有暴露底层的线程操作，所以碰到这种情况只能通过 cgo 实现。

@zhoudaiyu #5 可以学一学容器原理，挺有意思的。我也是之前对容器网络感兴趣，才学习的这方面知识。

@zhoudaiyu #3 应该说 nsenter 是超权限的 docker exec，在大部分的时候首先要考虑的都是使用 docker exec 命令。

因为容器是由一系列的的技术组合而成，nsenter 或是 ip netns 这样的命令仅仅只是进入 namespace，没考虑到容器其他的内容，这样操作有可能会导致对容器造成损坏的。

损坏这个描述可能不特别恰当，应该说你的操作可能超出了 docker 的管理，以至于后续 docker 可能无法正常管理容器。

本质上都是进入到容器所在的 namespace 上执行命令，但 docker exec 可能会有其他的处理，安全等方面的。

默认情况下推荐使用 docker exec 。除非想突破 exec 中运行命令的限制，比如说 https://www.v2ex.com/t/758750 这个帖子的楼主想改容器的 mac 地址，通过 exec 进入是不能改的。只有通过其他手段进入 namespace 才能改。

TLS 协议握手的内容是不加密的，包括上面提到的 SNI，但是 SNI 是扩展协议，理论上没有需求是可以不用发的。

这家的东西都很有特色，就是价格有点贵

将 HTTP 作为传输协议的 RPC，只能说没有通用性，不能说不规范。