Nebulium Engine
昨天坐小六子车回家的时候说到拼图只剩下最后一块了，便是现在在做的App引擎——NBE。我从前厂离职之后云游过程之中对之前2年做的DAE想了很多。诚然以前厂Python的实力，2年前的技术团队称之为国内Python界的天团也不为过，但是依托于SDK机制的DAE在很多问题上却还是没有很好的解决方案，其中最大的一个问题就是运行时隔离。为此，DAE做了大量的Black Magic来解决或者说减小这些问题带来的影响，但是同时也限制了DAE多语言异构后端的支持程度。好在豆瓣是一家Python为主的公司，所以也能接受，不然你以为哪有那么容易写Plan ABCDEFG……
不过对于我现在的公司而言，SDK语言绑定机制会带来很大的问题，因为这里并非一门语言独大，因此去SDK化的Engine会是一个比较好的选择，类似于小米的XAE。同时在运行时隔离方面，由于Docker的出现也可以得到很好的解决，整个Engine对于应用而言可以做得很透明，不需要很多Magic很容易部署在物理服务器、AWS、Qingcloud等环境里面。在这个基础上，NBE诞生了。
从我的角度来看，我认为一个好的App Engine应该做到严谨的隔离，无痛的扩展，简单的部署，可靠的支撑等几个方面，同时也不能损耗太多的性能。Docker是个很好的Choice，VM的隔离很严谨，相对性能就很蛋疼了，flex说过隔离和性能就是个天平，Docker这一点上做得比较均衡。但是仅仅是Docker是远远不够的，因此NBE又引入了2层的概念。
Layer 0：资源控制层，包括Containers节点的Agent，控制器，日志收集Agent，服务自发现和配置分发等组建。
Layer 1：应用层，包括部署，维护，监控，扩展等组件。
XTao是不是很熟悉？对，当你给我 http://flynn.io 这货的时候我发现基本上与我设计没太多出入。而且从实现的角度来说，NBE的完成度和集成度都比 Flynn 要高不少，至少我们不需要自己在 PaaS 中实现一个 Gitserver 来满足部署需求，平台本身暴露的均是API，而非 All in One ，要知道我构思这套系统的时候还在阿富汗扛 AK 47……
NBE之中，Layer 0 由三个组件+skydns+etcd组成，后两者对应了 flynn 里面的 discovery 。有G家 CoreOS 背书能省掉不少的维护压力，当然天坑什么的呃就不好说了。前面三个组件按照进击的巨人命名法则分别命名为 Levi，Lenz，Dot。
Levi：矮子兵长一米六，作为 Containers 节点的 Agent，类似于 Flynn 的 Host。不同的在于是协议上我选择通过 Websocket 作为客户端反向连接 Master 。 这样设计是因为 Docker 本身需要 Root 权限，暴露 Docker 的话也就意味着你服务器多了一丢丢的风险， Flynn 的 Host 设计是 RPC 调用，我觉得这样也白搭。同时依靠 WS 的机制，Master 可以实时感知 Agent 的存活，天然的监控手段。
对于 Levi 的职责而言，增/删/查/升 Container 都是应该的，Build 和 Test 同时也支持，某种意义上来说它更像是 drone + host 的并集。虽然目前打包的机制而言没法复用 Docker 自己的 Layer 机制，每一个版本都是一个独立的 Image，不过对于我们的用况已经足够。
Lenz：落魄贵族，日志收集器，我们的日志采用 Logstash + Elasticsearch + Kibnan 的结构。 Logstash 其实呢槽点挺多的，其中一条应该就是内网日志收集还得用SSL。Docker 本身自己的日志方面实现非常弱，一旦服务器上有多个 Container，你会发现磁盘一下就用完了，因为 Docker 本身会把 stdout/err 写入到一个大 json 文件还不分卷……如果要让应用在 Container 内部把日志写入远端的日志服务又造成了线上线下不一致的悖论。我们想要开发者尽量少的做一些 Magic 的事情来实现开发部署的一致，因此在 Logspout 的基础上，我写了它。https://github.com/progrium/logspout/pull/15
最后则是Dot：军团长，Master。其核心目标是单点支持上千 Levi 的直连，并且把任务分发下去。Go 语言的 Goroutine 机制很好的满足了这一需求。同时暴露的 API 可以从上一级进行资源调控。从职责上来说，更像是以前DAE的Deploy，不过远比Deploy复杂……
至于流量的动态路由（基于nginx的dyups模块），测试反馈，打包方案等，这里就不多说了。最后愿意来湖南一月两平买房子的小伙伴们心动不如行动，赶紧来个简历吧……
P.S. 以上项目均在github上可以找到，我的风格一律不写文档，所以凑合看吧。
不过对于我现在的公司而言，SDK语言绑定机制会带来很大的问题，因为这里并非一门语言独大，因此去SDK化的Engine会是一个比较好的选择，类似于小米的XAE。同时在运行时隔离方面，由于Docker的出现也可以得到很好的解决，整个Engine对于应用而言可以做得很透明，不需要很多Magic很容易部署在物理服务器、AWS、Qingcloud等环境里面。在这个基础上，NBE诞生了。
从我的角度来看，我认为一个好的App Engine应该做到严谨的隔离，无痛的扩展，简单的部署，可靠的支撑等几个方面，同时也不能损耗太多的性能。Docker是个很好的Choice，VM的隔离很严谨，相对性能就很蛋疼了，flex说过隔离和性能就是个天平，Docker这一点上做得比较均衡。但是仅仅是Docker是远远不够的，因此NBE又引入了2层的概念。
Layer 0：资源控制层，包括Containers节点的Agent，控制器，日志收集Agent，服务自发现和配置分发等组建。
Layer 1：应用层，包括部署，维护，监控，扩展等组件。
XTao是不是很熟悉？对，当你给我 http://flynn.io 这货的时候我发现基本上与我设计没太多出入。而且从实现的角度来说，NBE的完成度和集成度都比 Flynn 要高不少，至少我们不需要自己在 PaaS 中实现一个 Gitserver 来满足部署需求，平台本身暴露的均是API，而非 All in One ，要知道我构思这套系统的时候还在阿富汗扛 AK 47……
NBE之中，Layer 0 由三个组件+skydns+etcd组成，后两者对应了 flynn 里面的 discovery 。有G家 CoreOS 背书能省掉不少的维护压力，当然天坑什么的呃就不好说了。前面三个组件按照进击的巨人命名法则分别命名为 Levi，Lenz，Dot。
Levi：矮子兵长一米六，作为 Containers 节点的 Agent，类似于 Flynn 的 Host。不同的在于是协议上我选择通过 Websocket 作为客户端反向连接 Master 。 这样设计是因为 Docker 本身需要 Root 权限，暴露 Docker 的话也就意味着你服务器多了一丢丢的风险， Flynn 的 Host 设计是 RPC 调用，我觉得这样也白搭。同时依靠 WS 的机制，Master 可以实时感知 Agent 的存活，天然的监控手段。
对于 Levi 的职责而言，增/删/查/升 Container 都是应该的，Build 和 Test 同时也支持，某种意义上来说它更像是 drone + host 的并集。虽然目前打包的机制而言没法复用 Docker 自己的 Layer 机制，每一个版本都是一个独立的 Image，不过对于我们的用况已经足够。
Lenz：落魄贵族，日志收集器，我们的日志采用 Logstash + Elasticsearch + Kibnan 的结构。 Logstash 其实呢槽点挺多的，其中一条应该就是内网日志收集还得用SSL。Docker 本身自己的日志方面实现非常弱，一旦服务器上有多个 Container，你会发现磁盘一下就用完了，因为 Docker 本身会把 stdout/err 写入到一个大 json 文件还不分卷……如果要让应用在 Container 内部把日志写入远端的日志服务又造成了线上线下不一致的悖论。我们想要开发者尽量少的做一些 Magic 的事情来实现开发部署的一致，因此在 Logspout 的基础上，我写了它。https://github.com/progrium/logspout/pull/15
最后则是Dot：军团长，Master。其核心目标是单点支持上千 Levi 的直连，并且把任务分发下去。Go 语言的 Goroutine 机制很好的满足了这一需求。同时暴露的 API 可以从上一级进行资源调控。从职责上来说，更像是以前DAE的Deploy，不过远比Deploy复杂……
至于流量的动态路由（基于nginx的dyups模块），测试反馈，打包方案等，这里就不多说了。最后愿意来湖南一月两平买房子的小伙伴们心动不如行动，赶紧来个简历吧……
P.S. 以上项目均在github上可以找到，我的风格一律不写文档，所以凑合看吧。
