資訊專欄INFORMATION COLUMN
摘要：采用微服務架構設計的原因很簡單解放生產力。運行時服務缺少標準，各類實現區別很大，調試困難程度不一，集成測試更是難上加難。小伙伴們更進一步的互相提供幫助集成測試及單元測試，極大的釋放了團隊生產力。
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。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/26373.html
摘要：說起，必須要介紹是什么東西，為什么中小企業私有云適合使用。看一下現在的架構圖開個玩笑。上面這四點導致我們必須要統一架構，最終把整個業務系統遷移到基于的類似于的私有云的平臺。 本文系 ArchSummit 大會 CODING 工程師王振威演講實錄。 showImg(https://dn-coding-net-production-pp.qbox.me/c2f81423-54b9-4a7b...
摘要：是一個典型的模式架構，用戶通過終端將字符流傳遞給。仿照的工作原理，我們在協議之上設計了，見下圖真實實現中，是應用層的通訊協議。僵尸進程問題我們知道由于缺少而導致僵尸進程無法回收的問題迄今存在。進入構建環境執行命令。 Coding WebIDE 做個國內首個基于 Docker 技術的云端開發平臺于4月1日正式上線。本文主要和大家分享和探討 Docker 在 Web IDE 中運用的一些經...
摘要：期待大家的參與上海站圓滿結束，嘉賓和觀眾熱情不減，現場分享也讓上海觀眾收獲到滿滿的干貨，期望我們未來為大家帶來更多有趣的話題。 SegmentFault D-Day Docker 主題沙龍上海站，在五角場 VMware 上海研發中心完美結束，本次沙龍我們邀請具有實踐經驗的四位嘉賓，分享滿滿的干貨，為開發者們介紹 Docker 技術及其應用。 showImg(https://segmen...
摘要：面對平臺化的競爭，推出了調度引擎，但從未真正流行起來，因為整個行業更傾向于采用，這是第一次死亡它失去了平臺之戰。左耳朵耗子說過一段話，讓人深以為然：我清楚地看到了 Go 和 Docker 這兩種技術的生態圈發展過程。讓我收獲最大的并不是這些技術本身，而是技術的變遷和行業的發展。從中，我看到了非常具體的各種思潮和思路，這些更有價值...... 這些關鍵新技術，可以讓你拿到技術的先機。這些對一個...
摘要：在中采用的共識算法是算法可以在信任程度較低的場景下避免拜占庭問題。但是由于算法本身特性限制，，才能容忍一個拜占庭節點，因此在版本下，節點數量至少是個。 作者: TopJohn原文連接：https://www.xuanzhangjiong.to... Fabric架構演變之路 Hyperledger Fabric是目前主流的開源聯盟鏈產品之一，自2016年5月12日開辟代碼倉庫之日起，...
閱讀 2866·2021-10-08 10:12
閱讀 3966·2021-09-22 15:45
閱讀 2555·2019-08-30 15:52
閱讀 2625·2019-08-29 18:44
閱讀 2644·2019-08-29 12:37
閱讀 1154·2019-08-26 13:36
閱讀 2561·2019-08-26 13:34
閱讀 1473·2019-08-26 12:20
