Docker 技術與 Coding.net 技術架構的變遷

Docker 自發布以來，它的影響力不容小覷，目前已經在整個行業甚至於許多大企業都獲得實際的應用案例以及支持。Coding.net 做爲一個創業公司，大量採用了微服務架構解耦系統，在提升開發效率的同時也引入了很多新的問題。今天在這裏跟你們分享一下咱們是如何採用 Docker 技術在內部推行生產環境容器化，代碼化，自動化的。

微服務架構

從2014年上線到現在，Coding.net 已經由早期的一個 Java war 發展成爲一個系統結構複雜，獨立模塊不少的大型分佈式程序。網站的每一個小功能，好比說 GIT 協議處理、Repo 信息讀取（網頁展現）、Push 動態、郵件通知等等都做爲一個個微型服務在雲上運行，互相經過 API / RPC 調用充分解耦，互不侵入，接口明確。 採用微服務架構設計的緣由很簡單：解放生產力。傳統 Java 基於 Application Server 的開發模型下，AS確實提供了不少運行時服務，不少功能均可以在其中實現，可是這也帶來了 AS 負擔太重，組件隔離性不強的問題。AS 運行時服務缺乏標準，各種實現區別很大，調試困難程度不一，集成測試更是難上加難。

在這種環境下，鬆耦合的實際是很是可行的提升團隊生產力的方案。放開手腳讓小朋友們本身選擇合適的程序包裝方式，實現語言。小夥伴們更進一步的互相提供 Mock/Stub 幫助集成測試及單元測試，極大的釋放了團隊生產力。

容器化

經歷了早期野蠻式、爆發式的服務拆分後，Coding.net 不可避免的面臨着生產環境中愈來愈高的複雜度問題。早期 Coding.net 的部署方式簡單，一個 War 包拖入合適位置，網站就徹底更新了。拆分後，變成了三五個小服務跑在十幾臺虛擬機上的問題。同時這三五個小服務又分別使用不一樣技術實現，有的是 Jar 文件運行，有的採用 Jetty+war 或者 Tomcat +war 。一批小夥伴用 Go 重寫了一部分服務，還有幾個小夥伴採用 Ruby 重構了另一個核心功能。如此一來，生產環境的壓力可想而知。每一個組件的編譯方式各不相同，啓動方式和配置方式更是天差地別，甚至有好幾個組件就是源代碼直接運行。運維同窗不光要記住全部組件的運行位置、編譯方法，更要記住配置方式、依賴模型，壓力山大！同時，某一天你們忽然發現，咱們不再能把整個 Coding.net 在機器上跑起來了，由於誰也不知道如何才能正確安裝配置各類依賴服務。

爲了解決這些問題， 咱們最終採用了 Docker container 技術來下降生產環境的複雜度。有個比喻很形象，Docker 把程序裝進了盒子裏，每一個 Docker 鏡像包含了完整的程序代碼，運行時狀態，並且有一個標準的啓動接口。無論小夥伴設計的牛X程序多複雜，一個 docker run 也能把他正常運行起來。同時 Docker 還帶來了版本化的集成，今後告別了不知道運行什麼版本代碼的問題。

代碼化

應用程序裝進盒子後，咱們還面臨着盒子在哪裏運行的問題。很是實在的說十幾個 Container 和十幾臺VM 存在着比較複雜的對應關係，緣由是很現實的：設計之初程序之間的 RPC 是依靠主機 DNS 地址互相通訊的，就算裝進了盒子裏，盒子也不能輕易挪動。若是挪動盒子A，可能涉及到更改盒子B、C、D的配置。因此實際上 Explicit knowledge 在小夥伴的平常工做裏變成了很是嚴重的問題。 這個問題的解決之道就是將依賴關係代碼化。服務之間關聯複雜沒關係，只要咱們把各類依賴關係變成代碼，計算機能夠幫助自動處理至關一部分的工做。

代碼化分爲兩大塊：第一塊是用一個腳本從雲服務提供商那裏抓去了全部機器的 host/IP 配置。 第二塊是定義了一個 protobuf 文件將 Coding.net 生產環境的服務主機的對應關係記錄下來。咱們進一步設計了一個 Service IP 體制，自動爲生產環境中的每一個服務建立一個 DNS CNAME 記錄，指向服務實際使用的機器 DNS A 記錄。因而當有服務挪動操做的時候，DNS記錄會刷新，全部的下游依賴都會從新解析DNS 到新的地址。同時，咱們還本身開發了一個工具，根據記錄的信息檢查生產環境是否與記錄存在差別，進一步能夠將經常使用操做（如啓動中止，更新，移動主機）等等包裝起來，爲操做人員提供一個標準的 CLI 工具，將複雜的生產環境操做變成程序。

一樣道理，咱們也能夠按代碼生成一個開發環境的定義，用一套工具同時操做開發環境和生產環境。小夥伴們一鍵能夠在本身電腦上起停整個 Coding.net 服務雲，也能夠一樣的命令一鍵起停生產環境（前提固然是有足夠權限）。這樣環境的統一所帶來的生產力變革是很是深入的，對公司研發的組織架構也有很深遠的影響，有機會的話能夠在另外一篇文章裏詳細再說。

自動化

裝進盒子，能挪動，只描述了 Coding.net 宏偉藍圖的一小部分，而管理大規模生產環境的關鍵在於自動化。作好代碼化以後，咱們立刻上馬 Continuous Deployment ，讓每一行更改過的代碼一分鐘內進入 Staging， 再結合自動化的 Regresssion testing 工具，自動彙報未預見的錯誤更改。 同時咱們還有一個一鍵發佈和回退服務，讓更新變得更簡單，容易。自動化的服務系統還包括 Log 的轉發存儲，metrics 的自動收集， Application healthcheck 等等，這些都極大的下降了小組件的運維難度，鼓勵你們開發更小更獨立的組件，而不是又笨又大的單體程序。

以上就是 Coding.net 服務架構的演進， 但願能對你們有所啓發。在 4月23 日 QCon 全球軟件開發大會「挑戰全棧開發」專題上，Coding.net 架構師 孫宇聰也將會給你們分享一下如何利用 Docker等的相關技術爲創業公司的全棧開發加分，提升產品質量，創造一個可持續的全棧開發環境。敬請關注4月23日下午 15:50 《Coding.net 全棧開發實踐分享》。歡迎你們交流，郵件 : sunyucong@coding.net。