【開源訪談】厲華：寫一個開源容器引擎會是什麼樣的體驗？

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、僞終端等組合一下：

Cocker整體架構圖

Cocker對象狀態遷徙圖

分層文件系統

網絡模型Bridge原理圖

cgroup系統資源管制

僞終端建立過程

若是必定要總結技術實現最難啃的骨頭，恐怕是容器啓動時對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、iLOG三、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