2013年，Docker.Inc 开源了一款应用容器引擎 Docker。开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到相同内核的任何Linux 机器上部署运行。这种集装箱式的应用开发和部署方式降低了开发人员在开发、测试和部署软件时的压力。Docker 自2013年推出以来，深受开发者喜爱。
今天我们请到的嘉宾，是一位容器核心技术专家，他独立自研了国产开源应用容器引擎 —— Cocker，今天我们就来听一听他与 Cocker 的故事。
先向开发者介绍一下自己
大家好，我叫厉华（calvinwilliams、betonarmee、pizazzrain都是我的网名^_^），目前在杭州银行信息技术部负责基础架构。
我出生在杭州，上学在杭州，工作在杭州。我从初中开始在小霸王学习机上鼓捣 GW-BASIC，高中拿到年级前三名后父亲信守承诺买了人生中第一台电脑（联想品牌机，1998年要一万五千块钱），沉迷于 Q-BASIC导致成绩一蹶不振。
1999年高考前努力了一把，我考进了浙江工业大学机械工程及自动化专业，2000年计算机二级考了全院第一，也是从那时起与 C 语言结下了缘分。大学期间获得的最高荣誉是2001年全国大学生数据建模国家二等奖。
我特喜欢折腾，2002年用家里的废旧 PC 安装红帽子Linux搞过网站，提供免费Web空间、论坛服务（用 PHP+MySQL 自研）。
2003年大学毕业后凭着开发能力和建模奖项进入银行系统从事技术研发至今，写了快15年的 C 语言，完全独立自研了银行核心系统联机交易平台 IB2（日均600万笔交易）、批量交易平台 HZBAT、前置框架 HB（实施了100多个前置系统），生产稳定运行至今，曾经也写了半年的 JAVA 语言，还有一年的小型机 AS400 RPGLE 语言，很喜欢 C 的简洁、强掌控力和高效性能，深度代码洁癖。
您是什么时候开始接触容器技术的？
我接触容器技术比较晚，在2018年初行里做容器云 POC 时自学了 Docker，因为有多年 Linux 环境研发经验，学起来比较快。不得不说容器技术是革命性的软件部署方式，它比虚机轻量的多、秒级的启动速度、易于打包部署、强大的弹性伸缩能力。我在这里找了一篇文章，可以让你更好的了解容器技术 。
是什么样的机遇促使你产生了编写 Cocker 的想法？
每次行里大项目后我都不能马上闲下来，得找个小项目过渡一下工作节奏，2012年杭州银行新核心系统投产后我就意识到今后前置系统会越来越多，就接着花了半年时间完全自研了前置框架HB，完全通过配置方式开发前置。2018年核心系统服务分布式改造后，我继续学习容器技术。在查阅了容器技术的资料后，我发现实现容器引擎并不是很难，再加上自己有一些独特的思路，于是自己就有了写一个容器引擎的想法。
在编写 Cocker 的过程中，遇到过最大的困难是在写哪部分的时候？
实现一个容器引擎的核心功能并不难，在 Linux 上实现一个容器引擎无非就是使用内核提供的 chroot、namespaces、CGROUP、分层文件系统、iptables、伪终端等组合一下：
如果一定要总结技术实现最难啃的骨头，恐怕是容器启动时对chroot、名字空间、分层文件系统、系统资源管制、网络环境等的有序准确设置吧，但我觉得研发容器引擎更难的是，麻雀虽小五脏俱全，写一个完整的容器引擎产品比粗糙的实现一个容器启动器要考虑更多的东西，例如：目录文件结构规范、镜像和容器对象的操作原语、怎样才能更加的方便用户使用等等，这些都是构造一个产品所面临的大量设计和细节考量。实施最终产出落地，往往比只是脑袋里想一遍，组合哪些底层接口要付出更多的精力时间（创造的乐趣也在此过程中），这样说吧，调用内核提供的接口粗糙的实现一个可以跑起来的容器启动器我只花了一周时间（每天晚上孩子睡觉后），但把它打磨成完整管理能力的产品，我又花了两个月左右（每天晚上孩子睡觉后）。
有人可能会说，完全抄 Docker 不就得了，我的回答是那还不如不写，就像我的其它开源项目一样，每一个都要有自己的特色，要么有更强劲的性能（fasterjson、fasterxml、fasterhttp 等可以比肩世界上最快的函数库），要么有更简单的结构实现便于别人修改和扩展（吐槽一下一般开源项目都喜欢把自己实现的很复杂）。
开发者怎样编写出一个自己的小框架或者像您这样的引擎？
我认为一方面要熟悉不用框架或引擎如何写，比如写一个通讯框架，只有写过通讯程序的人，有过底层接口的使用经验，才能抽象出框架设计，框架原本就是为了以后更方便的重复开发软件而总结出来的封装，底层接口趟坑越多，上层用户需求经历越多，框架越强大。
另一方面，要明确自己研发的框架或引擎所适合的规模场景和领域优势。框架或引擎没有万金油，不同规模场景适配不同的框架引擎。产品通用性好适配面就广，但在追求某一方面极致的场景中更适合适配该场景特色的框架或引擎。
最后，作为一个框架或引擎的维护者，需要长年累月不断迭代修补的毅力和精力时间，尤其是纯粹个人推动，在国内技术人生存环境里尤为可贵。
Cocker 与 Docker 相比，有什么优势。
我当初学习 Docker 时，发现 Docker 强调的一个容器一个进程，这可以瘦化容器引擎的设计，如果要支持多进程则要借助其它技术，行里核心体系都是用 C 语言搭建的，多个进程协同成一个系统很常见，阿里显然也发现了这个问题，Pouch 的一个宣传理念就是“富容器”。所以Cocker的第一个优势是原生支持多进程模式（当然也支持单一进程），自研了 cockerinit 进程模仿 Linux init 负责回收孤儿进程，也负责 attach 时创建伪终端，K8S可以省却Pod了。
Cocker 的第二个优势，虚机管理方式，更通用更灵活。既然 cockerinit 能为每一个 attach 创建一个伪终端，那么自然而然容器就变成了虚拟机管理模式，容器管理原语新增启动boot，停止shutdown，镜像的构建可以不用强制批处理式的Dockerfile 方式，而可以登进去交互式的慢慢鼓捣。
Cocker 的第三个优势是原生支持容器内应用配置文件的实例化。由镜像创建容器后，容器内应用配置文件实例化，往往借助容器调度引擎或其它第三方工具实现，Cocker 有一个管理指令指定外部的一个键值映射文件和容器内变量化的配置文件，即可快速替换出一个可实际使用的实例化的配置文件。原生支持意味着依赖更少，性能和使用更优。
Docker 是用 go 语言写的，Cocker是用C语言写的，个人认为只要有足够的技术能力，一般底层系统软件最好用不带gc的语言编写为宜，尤其在Linux平台，用C语言更贴近内核。
有人可能注意到，Cocker 的优势其实都不是什么大的革新，从管理功能角度来讲 Docker 已经相当成熟了，Cocker 只不过把 Docker 不屑于做或不适应我们环境的地方做了改善，目前来看是这样的，但未来不排除有大的革新。
现在 Cocker 的进度是什么样的？
目前Cocker已经相对完整的实现了一个容器引擎该有的核心功能，但还有改造空间，比如有待研发自有镜像库（我先基于ssh实现了一个）、容器根进程要合并成一个统一的服务（否则容器一多，进程数量对系统有压力）、对底层接口的调用方式要改造成函数方式（现在有一些处理是很粗糙的直接调用外部命令）等等，后面会择机启动二期，研发调度引擎（对标Kubernetes）。大的路线图是先把核心功能做全，再迭代完善。
如果有朋友想要加入进来一起做，我大力欢迎。社区化团队化发展一个产品，我愿意倾听大家的意见，民主、有序的推进Cocker发展。联系方式我会让小编放到文章末尾，需要的小伙伴请到文末自取。
Cocker 现在是否已经有生产环境在使用？
我的很多开源项目（logpipe、fasterjson、fasterhttp、tcpdaemon、iLOG3、G6等）都是经历行里生产环境的历练迅速成熟起来的。Cocker 现在还没有实际项目在用，这也是我最担心的。
已经有几家公司在询问 Cocker 商业化推动可能性，还有行业组织来电探讨 Cocker 未来发展方向，本人在金融系统深有感触国家监管机构近年来对核心技术自主可控的强烈要求，银行业都对去 IOE 呼声很高，国内也没有本土的容器引擎（除了阿里 Pouch），国内容器云厂商几乎都是 fork 国外产品提供服务为主，我觉得可以以国产自主作为特色作为起点，当然产品必须要稳定可靠。
像 Vue.js 在国内外都有很好的开发者生态，是否计划建立 Cocker 相关的开发者生态的计划，还是说打算自己一个人奋战下去。
前面说了，我想先把二期调度引擎做出来，等核心主干大致完整后再邀请大家参与进来一起迭代完善，否则协调难度会比较大。
Cocker 会坚持走开源和社区化路线，这恰好是国内社区推动开源容器技术空白的地方，阿里Pouch 是商业公司推动的开源路线。
Cocker 2019 年的开发计划是什么？
2019年计划三个目标：完整核心功能、完成个人推动向社区进化过程、经历首个实际项目。
至于Cocker Store，等经历过实际项目肯定后，肯定会搭建，因为它是促进大家交流和推广很重要的一环。
从你个人角度讲，怎样看待中国的开源生态？
对于开源人，绕不过去国内技术人生存环境，现在国内坚持搞开源，可以为了技术可以放弃很多重要的东西。但理想归理想，真正通过开源能达成自己“目标”的少之又少，所以还是奉劝各位不要疏忽了本职工作，有了一定收入和职位才能更好的从事开源、帮助别人。毕竟国内的环境还不足以支撑起技术人的开源理想。
对于国产开源项目，国内技术环境似乎对国产开源项目很有成见：一来国内大多倾向于见效快、收益高的应用开发，能专研核心技术的人才寥寥，自然也就少有原创优秀作品出现；二来技术生存环境原因，个人无法支撑起持久的精力和资金投入，小公司忙着存活，大公司没有真心实意的开源分享理念，自然最后烂尾是常态。这种成见一旦形成氛围，严重压制了中国原创开源的生命力。我记得某位阿里大牛写的书里描述到：“国内开源项目一出来，大家冷嘲热讽，最多精神鼓励一下，国外开源项目一出来，不管好不好，先跪舔起来”。随着近年来开源中国对国产开源的大力支持，还是涌现除了不少优秀的作品，今年的国产开源项目评选影响面广反馈热烈的大作越来越多，希望随着中国技术环境逐渐改善，能改变这类风气。
对于架构师，有一部分人其实只是国外主流软件的熟练使用者而已，谈必称熟练使用 Docker、熟练使用 K8S，一有交流活动谈必称熟练掌握 Spring Cloud 为荣，最近又出了 Fink 我会用我骄傲，鲜有人真正愿意深入探究软件实现原理，鲜有人出于好奇心去造个更好的“轮子”（创新的开端），请描述一下分布式架构的基础 Raft、Paxos 算法过程而不是每次都讲到名字为止，请描述一下设计开发高性能日志库背后所蕴含的计算机体系架构知识，有些架构问题可以用技术来解决，有些技术问题用架构来解决更好，搞技术不是请客吃饭，还是要实实在在静下心来去除浮躁，那些真正的大师，都是十年如一日的深耕在某一领域，低调的你都不知道他的名字，但你的日常工作生活却离不开他的有思想的代码。
对于开源成本，有些公司以为使用开源项目就能大幅削减版权支出，这是一种不够深度的想法，如果技术管理者踩过开源的坑，一定会明白自主可控的重要性，如果公司要掌控使用开源软件带来的风险，还是要组建长期的开源支持团队，否则如果不出问题还好，一旦出了生产问题，没有熟悉掌控开源代码的团队处置就只能听天由命了，开源支持团队还负责审计恶意代码，防止圣诞雪事件发生。
对于创业和投资，资本者精明的比技术人还了解技术收益，人家追求的投资周期，而不是你的项目最终能否成功，不多说。
最后感谢开源中国给了我一个自我介绍的机会，感谢开源中国给国内技术人一个学习交流的互动平台，感谢开源中国提供强大、免费的源码托管服务（我有40多个开源项目在上面），祝愿开源中国越来越好。坚信真正的好产品都应该给每个用户一个吐槽按钮。喜欢开源的味道，喜欢分享的喜悦，喜欢以己能力帮助他人的成就。
在专访即将结束的时候，厉华告诉我，杭州银行2019年春季社招现在已经开始了，信息技术部基础架构团队急缺 C/JAVA 技术专家和架构师，如果你正在考虑年后换工作的事情，可以在杭州银行招聘的官网了解到更多信息，岗位搜索关键词“软件开发岗（架构设计方向）”。基础架构团队是一支热爱技术的大牛团队，希望能和优秀的您一起共筑金融科技未来。
本次专访到此结束，有相关问题或者想讨论的问题可以在评论区留言。
- 码云地址：gitee.com/calvinwilli…
- Github：github.com/calvinwilli…
- Email：calvinwilliams@163.com
