作者簡介： 章燁明，杏仁醫生CTO。中年程序員，關注各種技術和團隊管理。本文首發杏仁醫生技術站

1. 創業公司的技術挑戰

托爾斯泰說：“幸福的家庭都是相同的，不幸的家庭各有各的不幸。”互聯網創業公司也一樣。大部分互聯網創業公司，都會碰到以下幾個技術挑戰。

• 如何快速、低成本的搭建系統，同時確保安全穩定？
• 如何快速的構建和發布應用，滿足業務需求？
• 如何提高團隊開發效率，確保開發質量？

這個列表肯定不完整，但這三個應該是創業公司技術團隊都會面臨的共通的問題。當然杏仁不能說完全解決了這幾個問題，但還是取得了一些進展。我們接下來簡單介紹下，我們杏仁是怎么應對這些挑戰的，以及容器又可以帶來什么？

該系列文章會分為三篇。第一篇介紹容器化之前，杏仁技術架構的發展歷史。第二篇介紹容器以及杏仁的容器化方案。第三篇最后總結為什么我們認為創業公司應該用容器，以及為什么容器可以幫助我們應對這三個挑戰。

2. 杏仁早期

在 2012 年以前，大部分互聯網公司包括創業公司，都是直接購買服務器，租用 IDC 機房的機架部署的。應用是直接運行在物理機上的，要擴展必須購買新服務器。IDC 經常出各種故障，如果碰到 IDC 遷移的話，就更痛苦，必須半夜搬機器，天亮前上線。總之對創業公司的成本、服務穩定性、工作效率都是有很大的消耗。

不過杏仁醫生很幸運，正好趕上了公有云的成熟，所以一開始就是基于公有云搭建的。杏仁醫生最早期的架構如下：

這個架構非常簡單，其中負載平衡、數據庫都是基于騰訊云的。然后騰訊云也提供了一些基礎的監控、告警和安全服務。然后就是兩個應用，一個移動后端 API，一個運營平臺，都是基于 Play 的 Scala 應用。

很多人可能會好奇為什么選擇 Scala／Play 進行開發，畢竟 Scala 在國內應該用的不多。這里一方面因為杏仁醫生是繼承了看處方的架構，當初看處方就是基于 Scala／Play 開發的， 團隊對這一套方案比較熟悉。我們需要快速的構建杏仁醫生，自然就會選擇最熟悉的語言和框架。而且對于中小規模的應用，Scala／Play 的開發效率的確非常高。Scala 本身的表達能力非常強，是一門很有意思的語言。很多好學的工程師，也會對新的語言也會比較感興趣。

3. 應用拆分和CI／CD

經過一年多快速演進，整個應用越來越龐雜。所以我們對應用進行了拆分，并且隨著業務擴張，應用也越來越多，例如 HIS、CRM 等。所以我們的架構變成了這個樣子。

這時 Scala 最大的問題開始體現出來了，那就是編譯速度的問題。那時候我們的應用部署方式也很原始，必須登陸服務器運行一個 Shell 腳本，它會拉取代碼，然后編譯、打包、運行，整個過程需要耗費5～10分鐘。而我們 API 應用的節點后來增加到 5、6 臺，即使兩臺同時發布，也需要 20 分鐘才能全部發布完成。如果發布后出了問題，那就吐血了，因為回滾也是一樣的流程，又需要 20 分鐘。

有一次我們做了一個送 Apple Watch 的活動，半夜 12 點開始。我們出了個很低級的 BUG，活動一開始就蹭蹭蹭的一分鐘送好幾個 Apple Watch。我們創業公司也沒多少錢，每一個都是白花花的銀子，心痛啊。修復很簡單，但發布或者回滾都得先編譯，太慢了，于是我們一狠心把服務器給停了，幾分鐘后才部署上了新的代碼。

這是我們覺得必須要有一個自動化的發布系統了。其實在幾年以前，發布都是需要運維執行的，研發提交給運維，運維手動部署。那自然發布不可能很頻繁，并且對開發和運維都是很大的負擔。但漸漸的敏捷和 Devops 的文化成為主流，持續集成和發布（CI/CD）成為一項基礎設施。

我們第一版 CI/CD 很簡單，是基于 Jenkins 的，通過腳本進行編譯、打包，然后拷貝到服務器上發布。因為只要打包一次即可，緩解了部署慢的問題。但還是存在幾個問題。

• 首先，沒有應用倉庫。打包是一次性的，部署的時候會備份當前應用目錄，用于回滾，所以只能回滾到上一個版本。
• 其次，健康檢比較簡單，只能檢測應用是否啟動。我們遇到過應用啟動了，測活也沒問題，但服務還是有嚴重問題、基本不可用的情況。
• 最后，不支持灰度發布，出問題只能回滾。

期間我們有一次較大的故障，也是因為這幾個因素，花了很長時間才恢復。痛定思痛，于是我們又開發了 Frigate 發布系統，它的架構大致如下圖。

• Frigate 有一個應用倉庫，即 App Repository。應用倉庫會保存發布的應用版本，回滾的時候可以指定版本。

• Watcher 組建實現了比較強大的應用檢測功能。除了一般的 HTTP 檢測，還可以從日志、監控里獲取數據，可以根據異常數、錯誤率等進行進一步的健康檢測。

• Frigate 支持分組和分階段發布。例如現發布2臺機器，然后健康檢查，或者中間可以有一些人工檢查，然后再發布剩余的機器。

后來回頭看，Frigate 雖然沒有使用容器，但其實是實現了容器編排的很多功能。Frigate 發布的截圖如下，這是基于 Jenkins Pipeline 的。

4. 微服務化

系統多了，依賴復雜、數據沒有隔離、邏輯重復，接下來一個必然的方向就是微服務。關于微服務，我們公眾號有兩篇文章（樂高式微服務化改造（上）、樂高式微服務化改造（下））對此有比較詳細的分析說明，這里就簡單介紹一下。

我們的服務注冊和發現是基于 Consul 的，負載平衡是通過 Nginx 實現的。下圖是整個服務注冊和發現的過程：

有幾點是值得一提的。

首先，我們的微服務是基于 HTTP 和 Json 的，沒有采用二進制的協議如 Protobuf、Thrift 等。其實 HTTP 和二進制協議的性能差別，并沒有很多人想的那么大，一般也就2、3倍的差距（沒有親測）。對大部分企業，這個差別根本就不是瓶頸，特別是現在還有 HTTP2。如果真的有需要，還可以在 HTTP2 上跑二進制協議，通過框架在服務端和客戶端加一層就可以實現。

其次，我們的微服務對應用是無侵入的。我們沒有采用常見的 Dubbo、SpringCloud 框架。一方面我們服務調用方有 Java 應用也有 Scala 應用，要接入還是要花點功夫。另一方面，我們認為微服務框架發展的未來方向是非侵入性的獨立的微服務基礎設施層。其實這和容器編排的理念是一致的，并且最近提出的 Service Mesh 概念，就是進一步的延伸，我們認為這才是微服務的未來。

最后，我們每個微服務都會生成一個 SDK，便于調用方調用。SDK 集成了熔斷、異步、分布式追逐（開發中）等功能。

搭建了微服務基礎框架后，我們開發了好幾個微服務，有業務的例如訂單、預約等，有基礎設施的例如推送、短信等。當然其實有些并不算“微”。

但是我們發現，整個體系依然存在不少問題

• 基于云服務，成本低了，效率高了。但運維還是面向資源的，并且資源利用率不高。

• 有了持續集成和部署的能力。但新增節點、新建服務等，依然需要大量人工運維，并且擴展并不方便。

• 實踐微服務，改進了應用架構。但依賴管理、監控等尚未完善，穩定性仍然不夠。

5. 容器是什么？

上面我們簡單說明了杏仁容器化之前的架構發展。下面我們就來談談容器。

2013 年 Docker 橫空出世，到 2015 年已經漸漸進入大家的視野。容器當然不一定是 Docker，而且容器現在也是有標準的。但一說容器大家肯定會想到 Docker。所以我們這里說的容器，主要就是指 Docker。

容器到底是什么呢？顧名思義，容器就是用來裝東西的。在這里它用來裝的就是應用程序。容器的特點簡單說就那么四點：

• 容器是自包含的，它打包了應用程序及其所有依賴，可以直接運行。以前應用程序的依賴管理一直是個大問題，即使像 RPM 、Maven、Ansible 等都能解決一部分問題，但并沒有一個所有應用程序通用的標準機制，直到容器出現。

• 容器是可移植的，可以在幾乎任何地方以相同的方式運行。這就可以確保應用在開發環境、測試環境、生產環境等都有完全一樣的運行環境。

• 容器是互相隔離的，同一主機上運行的多個容器，不會互相影響。即一個容器中運行的應用程序，是訪問不到其他容器的資源的（進程、網絡、文件、用戶等），除非配置為共享的資源。

• 容器是輕量級的，體現在容器的秒級啟動，并且占用資源很少。

容器能做的很多事情，虛擬機也能做，那它們有什么區別呢？下面這張圖是 Docker 官網的截圖，很好的說明了兩者的區別。

但最根本的差別，其實就是最后一點：輕量。很多人可能覺得這只是一個簡單的差別，但其實不是。因為就是這一點使得容器可以成為一種 標準化的應用發布方式。

上個世紀 5、60 年代集裝箱剛出現，看上去也只是簡單的差別，也沒有什么技術含量。但集裝箱提供了一個標準化的物流方式，全球的海陸空運輸、碼頭裝卸等圍繞集裝箱形成了整個一個高效的物流體系。最終改變了世界貿易，促成了全球化。

所以容器這個標準化的應用發布方式，最終會影響上層的整個應用架構。最終圍繞容器，會建立一套完整應用架構體系，帶來革命性的改變。現在其實已經可以看到一點端倪了，Kubernetes 基本已經成為標準，不久前 Google 還發布了 Istio 這個 Service Mesh 工具，進一步把微服務的基礎架構也抽象了出來。

6. 容器編排是什么？

光有能裝應用的容器還不夠，如果還是人工管理那么多容器，那也發揮不出容器的優勢。所以我們需要一個容器編排系統。容器編排能提供以下功能：

• 應用調度：應用部署、無縫升級、彈性擴展、自愈等。
• 資源管理：內存、CPU、存儲空間、網絡等。
• 服務管理：命名空間、負載均衡、健康檢查等。
• 以及很多其他功能，如日志、監控、認證、授權等。

容器編排領域最主要的三個系統是 Docker Swarm、Kubernetes 以及 Marathon/Mesos。

Swarm 是 Docker 官方的方案，優點就是簡單，缺點是太簡單了。

然后是 Google 的 Kubernetes，也叫 K8s。Kubernetes 最近一年大放光彩，幾乎統治了容器編排領域，就連 Docker 官方不久前也宣布了支持 Kubernetes 。它的優勢就是有大廠支持，而且 Google 是把它作為戰略來布局的，你可以把它想象成當年的 Android；它的社區也非常火爆。

技術上，Kubernetes 是一個集成的方案，設計非常優秀，可以說是分布式系統的設計典范，Google 在這方面畢竟有很深入的經驗。缺點就是有點復雜，而且在今年之前它還是存在不少問題，包括性能問題、大版本的兼容性、部署復雜等，當然現在已經基本解決了。

Mesos 在 Docker 之前就有了，本身做的是分布式系統的資源管理，Mesos 很靈活，上面可以支持各種系統，包括 Spark 等。Marathon 則是基于 Mesos 實現了編排的功能。

我們是去年年中考慮容器化的，我們最后選擇的方案是 Marathon/Mesos。原因一方面是之前 Jenkins 容器化已經用到了 Marathon/Mesos，有些經驗。另一方面是該方案便于和當前的架構整合。Kubernetes 太過復雜，遷移的話，對架構改動太大。

7. 杏仁的容器化

我們容器化之后的架構是這樣的：

所有的應用都以容器的方式運行在 Mesos Slave 上，Mesos Master 統一管理 Mesos Slave 服務器。Marathon 通過 Mesos 調度容器，進行發布、升級、擴容等。Calico 是 Docker 的網絡解決方案，實現了一個容器一個 IP 以及容器之間的互聯。而右上角部分，我們基本保留了我們之前的微服務架構，只是用于服務發現和注冊的 Consul Agent 替換成了 Registrator。

同時我們的 CI/CD 也相應的做了調整。

Jenkins 自身現在也是基于容器的，會在 Mesos Slave 的容器里進行編譯和打包。應用會被打包成的 Docker 鏡像，上傳到我們的鏡像倉庫 Harbor 里。部署時，Jenkins 調用 Marathon 的接口進行部署，Marathon 則從 Mesos 申請資源。部署時 Mesos 會從 Harbor 下載相應的應用鏡像并根據配置運行。

有了這套系統，我們創建應用、擴展應用就很簡單了。創建應用時首先通過 Dockerfile 和 Jenkins 創建鏡像，然后在 Marathon 界面上，只需要準備一個 Json 配置（也可以通過 Form 配置），指定資源、實例數、鏡像、網絡、健康檢查、環境變量等，就可以很快上線一個新應用。

有時候我們要準備一個秒殺活動或者推送幾百萬用戶，需要增加應用實例，也只要在 Marathon 界面調整一個數字就可以了。

除了容器編排和 CI/CD，還有兩個很基礎的東西，一個是基于 ELK 的統一日志平臺、另一個是基于 Open-Falcon、StatsD、Graphite、Grafana 的 監控告警平臺。大致結構如下，具體實現以后有機會再專門寫文章介紹，這里就不詳述了。

最終，我們的整個平臺的組成是這樣的：

8. 容器化總結

到這里為止，這些就是杏仁目前的基礎平臺的架構。通過這套系統，我們提升了資源利用率，剛剛遷移到容器化環境的時候，我們只用了原來大約 6、70% 的云服務器。并且我們大大加強了我們的自動化運維的能力，完善了服務監控。

但是這套系統也存在不少問題。

• 新增服務器節點還是需要一些手工操作。
• 容器、環境等的配置都是分散在各處，缺乏有效的管理。
• 對有狀態應用支持不好。
• 系統存在一些冗余，例如有 Zookeeper、有 Etcd 還有 Consul。
• 不支持自動擴容。
• 部分基礎設施沒有容器化。

未來我們會繼續進化，也許等時機成熟了，也不排除會遷移到公有云的容器服務，或者自建 Kubernetes 集群。

總結

以上是生活随笔為你收集整理的创业公司的容器化之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。