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