沙CTO下周请我吃饭吧

github.com/CMGS/Titan .... gist 很简单啊。。当年我写了这个某瓣新 Code 架构的 example 。。里面就自带了 gist 。。

自行开发的应用上 docker 只是一条出路而已……涉及到拆分啊什么的其实最大的问题并非技术问题，而是政治问题。

@Livid 说的并没错，带有状态的服务，最重的那一端如何和业务组织编排才是最核心的问题，docker 带来的应用层收益相比于编排的成本实在太低。从这个角度来看 docker 并没有什么卵用。

所以问题的核心是哪里呢？

编排系统，尤其是对 Nginx MySQL Redis 这样的本身存在的 binary 服务都能做的编排系统，并非简单的只用于自行开发的业务，这才是 Google Borg(Omega) 的核心价值。Docker 只是在这个编排系统中作为一个容器引擎罢了，说白了 Rkt AppC 哪个不能做啊。

因此，我组是自行开发了一套编排系统（http://github.com/HunanTV），目前结合 Redis Cluster 3.0 爽得飞起……开发测试机平台也在上线中，目前基本没跑公司看得见的业务（政治问题），反而在成熟服务编排上下了很多的功夫（Dns体系，Redis，Yarn etc...）

http://v.youku.com/v_show/id_XMTI1NDM1MTIzNg==.html

这个视频就是我们对 Redis 集群控制的界面，恩完全无人值守毫秒级的扩容缩容响应，大概这样吧。

总之我个人认为 Docker 是个 engine，把它看做一个 Platform 实在是高估它了，加之 Docker 实现代码实在是啧啧啧，因此编排和资源控制才是系统工程师应该关注的地方。

可以，git filter 命令……巨复杂。。。

@est 支持4k……这其实是有问题的- -

其实不光是视频质量，还包括音频，以至于我们做直播的转码集群用的都是最好的 SSD，恩 Sandisk Extreme 系列，至尊极速……

当然低质量的，你这样也做不到10s延迟- -

最关键的就是数字信号转码这块，你可以搜一发看到很多广电系统的集成方案，所谓集成方案的意思就是，幺蛾子要烧硬件呐= =

最耗时的一个是转接码（理解为相机的 RAW 转 jpeg）和传输
传输还要上 CDN 神马的，对调度要求非常高

@pagict - -我就是扫地的
@est 这个没问题，但是我觉得作坊级的团队很难做出有意思的直播产品，为什么呢，因为趋势是高清直播，那么首先，对采集设备的要求就很高了。然而你需要做实时直播的话，转码设备的要求也自然而然升高，而这一领域……

完全是……

钱……
钱…
钱

没钱就没法将近实时转码，但是完成转码就没问题了嘛，当然还是有的……

比如你在A地拍摄，如何让B地的机房能把转码后的（H265）的流射到全国各地……

这一领域又是

钱……
钱…
钱

因为，卫星链路好他妈贵啊！

然而 B 地机房接盘之后……
又是新一轮的技术升级了- -
大体上如此

@est 你知道。。。国企最大的问题不是钱。。是脑子。。。。之前有讨论过这个要平台化，把直播技术直接做成产品对外发布会怎样，然后。。。时间会慢慢证明吧- -（话不能说太白。。你懂的）

@est = =我们跨年晚会就是直播这么玩了……这项技术我们说国内第二估计没人敢说国内第一，不过这项技术和我这边没多大关系，主要是信号源处理那块，都是砸钱

海美迪。。。

我厂的内容+直播，其他盒子没牌照可以这么放肆。。。

@Lucups 。。。这。。。你想多了，这里女的有3种，上位的，上位过的，码农。。。
@shyrock = =我组现在就4个人。。。已经累成狗了。。。会慢慢补上吧
@ccseven 好~

@lion9527 = = 作为平台的系统工程师。。。我也木办法啊。。。（我自己看我是歌手都被广告恶心死了……）

@alexwhen 老实讲。。。我们已经。。。系统层面秒他们几条街了。。。只是懒得做 UI……
@7anshuai 谢谢啦~~
@lion9527 。。。你是说坑爹的app嘛，他们外包的- -

@mimzy = =菊。。。。。

恩啊，就是 @Tassel 给的地址~目前主要是我负责的 docker 编排系统和 redis 这块放出来了……目前我们在做比较妖孽的 redis-cluster docker 化自动部署和扩展的工作……生产线跑一段时间后应该也会放出来。文档什么的么……我现在就4个人，2大块完全没精力写了- -

@bizslink = =如。。我。。。然后没了么。。。。

94年大叔……你这叫我88年的怎么活……

@monnand DAE=Douban App Engine, NBE = Nebula Engine，选择 InfluxDB 主要是我并非 SA 出身， Statsd 对我来说部署和维护经验太少，至少目前 influxDB 还比较简单。 Etcd 因为稳定性问题已经被我们放弃，目前第二代 NBE 主要使用的是我们 redis 的解决方案去做 KV 存储。其实选择 Go 主要是因为 docker 相关的库 go 的版本较多较好，不过也有残次品，所以目前我们的 Core 用 Python 重写了。

Pod 这名字其实还是很好理解吧哈哈~除了刚才说的 Cluster，我们还考虑过 Unit 什么的，最后才确定的是 Pod。

@monnand 没参考过 kubernetes 实现，我连它代码都没好好看过，架构是我当时做完 DAE 之后因为 Python runtime 隔离略麻烦，然后在伊朗的时候按照 DAE 架构演进推倒出来的第一版 NBE。另外你说第三方软件主要指？

你指的很像主要是 Pod 吧，我们 Pod 本来是想叫 cluster 的，后面觉得概念冲突，如果说借鉴的话这可以算一点……因为我们一个 Pod 是以业务做隔离的概念。我们和 Kubernetes 的区别主要在于我们第一代的 NBE 是类似于 DAE 那样的纯 web 服务 PaaS，Pod 和 私有 Host 均是后期加入的。第二代的 NBE 是类似于 Docker Swarm 的东西，顺便把 compose 做的编排的事情给做了，并且把可以部署自定义基础服务也纳入了目标中。另外我们这货考虑是对内为主，所以没做得那么的“通用”，和我们有的基础设施和工作流都能很好的接起来。

@dreampuf = = 我在考虑22号干脆去 3W 或者基友公司搞个公开的分享算了……从周一到周五下午2点起已经都被安排好了……

@Actrace openvz 咩- -，这用起来体验还是跟 lxc 之流有差别吧。。
@loddit = =好紧张的样子怎么破