摘要：數據庫無法根據業務分攤壓力，單失效節點多，事故也頻繁出現。這是智慧摩羯這時簡單的架構圖，是單一的節點庫，增加了很多運維腳本，當時在上就有幾十臺。開發人員變多，出現的事故概率增大，系統升級的風險變高。

2010 年南非世界杯，「預言帝」章魚保羅搶走了原本屬于球星的風頭，它精準的預測了德國國家隊的比賽結果；現實中，我們每個人也會對比賽結果進行娛樂性的預測，關注自己喜歡的球隊，而有這么一家專業的公司，卻利用著大數據、人工智能、神經算法來給體育比賽結果預測，對體育進行服務 —— 智慧摩羯數據科技有限公司。

智慧摩羯數據科技有限公司，是一家專注于體育運動大數據分析服務的創新型科技公司，以賽事數據為基礎，以大數據分析為引擎，運用機器學習、深度學習等人工智能算法來實現全球體育比賽結果預測、體育運動指導、電子競技游戲支持等服務。

智慧摩羯數據科技有限公司聯合創始人陳健，分享了如何解決隨著業務發展，系統越來越臃腫、應用變得越來越不易維護、不易擴展等問題，并分享智慧摩羯在搭建企業微服務中的相關經驗。以下為演講正文：

大數據分析技術是企業的核心競爭力。主要的技術分為兩部分：

第一部分是大數據技術；

第二部分是應用的技術，即大數據服務和應用服務。

大數據服務跟絕大多數公司差不多，首先是數據采集，我們有很多爬蟲，可以直接在公網爬取全網數據，爬取到全網的體育數據后，我們對數據進行分析，然后就是數據處理和建模。早期我們通過大數據分析技術把這些數據跑出來，進行建模，進行結果預測。現在我們開始進行一些更深入地研究，像機器學習、深度學習，還有神經網絡等相關算法都已經引進并運用。希望通過這些人工智能算法更智能、更科學地預測一場比賽，或者對體育進行服務。

正是基于核心技術，智慧摩羯布局了三條產品線：

一是體育比賽預測，就是剛跟大家分享的，通過去全網扒數據，運用人工智能算法分析進而預測體育比賽結果。

二是體育運動指導，通過收集所有運動員及體育愛好者的運動數據，對其進行專業地指導。

三是電競游戲支持，我們發現電競其實也可以進行各種各樣的數據收集、分析和預測，智慧摩羯可以為電子競技類游戲提供專業的數據支持，讓游戲更加專業、真實和有趣。

技術架構

第一部分是技術的演化過程，主要講種子期和成長期。

早期是把代碼放在 GitHub 上，為了把業務拆得足夠細，所以創建了很多代碼庫，但智慧摩羯當時只有一兩個后臺工程師，很快就拆出超過 10 個庫。這樣維護起來成本太高，代碼重復，且沒有精力合到公共的代碼庫里，我們發現這條路走不通。

這就是智慧摩羯早期的架構，特點是代碼庫特別多，我們有前端負載均衡，有 API 服務，有消息隊列服務，定時任務服務，這時候 Redis 是單節點的，MySQL 也是單節點的，是很簡單的架構。實際上代碼庫多對我們來講是比較重的事情，然后我們就把多個代碼庫合成一個，解決公共庫的問題，代碼的冗余度降低了。雖然單個數據庫根據業務劃分多個 schema，但是還是在一個數據庫里面，然后單個 Redis 節點，存放所有的緩存數據，這樣也可以降低成本。

問題就是單體工程越來越龐大，一年我們就做了幾十萬行代碼的量級，還是一個工程代碼庫。還有一個特點就是文檔少，重復代碼多。由于開發人員增加了，從兩三個人變成了十幾個人，導致重復代碼越來越多，因為不是每個人都對代碼理解，文檔少，必然就會理解少，重復的代碼多。數據庫無法根據業務分攤壓力，單失效節點多，事故也頻繁出現。

這是智慧摩羯這時簡單的架構圖，GitHub 是單一的節點庫，增加了很多運維腳本，當時 VM 在 QingCloud 上就有幾十臺。

微服務解決方案

沒有問題就沒有動力去改變這個事情，所以我們先來看下有哪些問題。

第一個特點是單個節點的數據庫承受所有的應用層壓力，沒有進行拆分。這時候數據庫其實是最大的瓶頸，一旦它發生阻塞，整個服務就癱瘓了。因為所有的連接一直在那兒阻塞，沒辦法接新的連接，整個服務就是完全阻塞的狀態。

第二個特點，單個 Redis 承受所有的緩存的數據，服務癱瘓，恢復時間慢。單體工程代碼量非常龐大，新人頭疼，無從下手。開發人員變多，出現的事故概率增大，系統升級的風險變高。

代碼的沖突也頻繁發生，這時由于每個人不太了解，合并的時候頻繁出現代碼被覆蓋的情況，我們的開發分支跟線上穩定分支總會出現各種各樣的問題，升級的風險非常高。應用層都部署在 VM 上，上百節點的 VM 沒有分開，這是我們的問題。

針對以上問題，兩個核心的解決方案：第一個是隔離，第二個是解耦。一部分是靜態的部分，就是代碼的部分。然后動態的部分就是運維，如果不談運維、不談代碼就有點空。首先是隔離，工程代碼要隔離，然后代碼跟代碼之間不要互相干擾。第二個是運維事故要隔離。然后是解耦，代碼要解耦，系統升級要解耦。

一個目標就是要放權，我對微服務的理解就是產生很多的子服務以后，首先你的代碼庫拆掉，之前代碼庫的管理權限是給到整個研發部，很多事情需要統一的授權。但是代碼庫拆掉后你就可以把權力下放到各個業務小組，由他們來決定代碼的合并和代碼的系統升級，這樣的話就等于把這個權力下發下去了。整個微服務實施的步驟是數據庫的 schema 拆分，接口流量拆分，微服務的注冊發現，管理服務的生命周期。

首先是代碼庫，我們先把 GitHub 的代碼庫由一個工程 fork 出來很多子工程，其實都是一樣的，因為短時間內如果想以最快的速度把工程拆掉，這是最簡單的辦法。

這是第一點，然后把一些公共的合起來，剩下的全部拆掉。拆掉的過程中肯定會有一些跟這個業務不相關的代碼，但是至少保證了每一個工程可以獨立的進行分支合并。

第二點是我們的數據庫進行了比較大的改動，原來可能是單個數據庫，就只有多 schema 的架構，現在我們把原來的數據庫拆成八個，這些都是做事務的數據庫，然后用 MariaDB，因為 MariaDB 支持多元復制，把這些子數據庫，這些不同的 schema 合到一個數據庫里面，這樣可以把數據庫分開。

另外就是分表的問題，我們通過阿里開源的 Otter 來解決，實際上是偽裝成了一個 MySQL 的 Slave，不停地從 Master 里面同步數據。然后可以建立多張表跟一張表的映射關系，建立完畢以后把多張表合成一張，這樣我們有分有合，用戶查的是分表數據，但是我們后臺統計的是合表數據，合表數據可以提供給管理后臺的人員用，給做運營、做分析的人用，這樣也能把數據庫壓力分散掉，線上就是線上，我們自己后臺的分析就是后臺的分析，把 OLTP 和 OLAP 分離。

我們規范了合并流程，原來只有兩個分支，一個是 Master 分支，一個是 Develop 分支。相信大家比較了解，Develop 分支就是開發分支，主要開發新的 features，比如說我們要開發新版本，所有的 features 開發完畢以后，就會進入集成測試的分支。但是開發人員在測試階段還可以改代碼，這個事情如果沒有規范好，會導致測試人員做很多無用功。最后我們覺得需要給測試人員足夠的權限，他們來管理一個多帶帶的分支。

這樣的話所有的開發人員往這個分支合并代碼的時候必須經過測試人員的同意，測試再去測這個獨立分支的時候，如果測完沒有問題，再往 Master 合并，能保證測的代碼就是要升級的代碼。同時為了保證流程，如果線上發現了一個 bug，應該以 M 打頭，通過它 fork 出來一個子分支，然后往三個分支同時進行合并，依次合并。這個代碼的分支合并的規范流程，其實對我們來講還是很重要的。這里面解決了很多開發人員不規范，亂提交代碼的問題。這個很有用，能保證代碼的質量。

接著我們對線上所有的服務進行拆分，拆分之前我們就是一個單體服務，很麻煩。如圖：

最前面是負載均衡器，這個就不用說了，用的是青云的負載均衡器。在負載均衡器后面，我們自己加了一層是 API gateway，我們把接口、定時任務、消息隊列等這些模塊按照功能為單位，依次進行劃分，劃分成幾百個服務。

這幾百個服務沒必要每個服務一臺機器。對哪些服務需要訪問哪些資源連接進行整理歸類，比如有的是訪問用戶的數據庫，有的是訪問訂單數據庫，但是他們訪問的時候也會分讀寫，到底是讀數據還是寫數據。

然后我們再把所有的這些幾百個服務、接口，每一個都仔細過了一遍，然后把哪個該走讀，哪個該走寫，全部歸好類，把所有的配置配好，然后由 API gateway 轉到不同的機型，可能配的是讀庫或者寫庫，把線上的幾百個接口拆成幾百個服務，每一個服務能做到對其他的服務最小力度地干擾。

原來數據庫阻塞了，然后應用層組塞，整個用戶就阻塞了。現在變成了我們可以逐步降級服務，給用戶提供更穩定可靠的服務，不至于出問題。

這是我們用青云的 AppCenter 2.0 做的這個事情。在去年青云的 AppCenter 2.0 發布會上，我覺得能夠幫助智慧摩羯實現業務。

我對它的理解就是，它在定義角色，定義生命周期。里面包含了存儲的角色，計算的角色，包含 RDB、包含 Redis、包含 Zookeeper，可以包含很多的角色。然后這一個角色可以定義很多參數，因為這些參數就是配置參數，原來的配置參數可能不統一，比如說 Redis有 Redis 的配置參數、Zookeeper 有 Zookeeper 的配置參數。

整體的把所有的配置參數都抽象出來，然后生命周期里比如說服務的創建、服務的銷毀、服務的啟動、服務的關閉、服務的 Scale In&Scale Out，還有監控，健康檢查，每一個過程定義好以后，這些過程都能夠觸發我們提前定義好的腳本，這個腳本能夠在生命周期里做它該做的工作。

然后我們把我們的服務注冊在青云的 AppCenter 2.0 里面，當服務啟動以后我們的服務之間怎么訪問呢，這是依賴于我們用的 consul 的框架，每一個節點啟動以后會有一個 consul 的 Agent，Agent 用來獲取其它服務的地址，完成微服務之間的訪問。

同時服務的注冊和發現，還有健康檢查，也依賴于 consul 的 sever，例如，我要注冊一個服務，我的 IP 是什么，我的信息是什么，放到哪里，其他的服務就能同步下來，并且找到這個服務。

下一步，原來傳統的部署是程序對接資源，資源是指的是什么？比如說 VM，計算資源、存儲資源都算資源，我理解的是，物理設備這些東西都叫資源。

然后程序直接對接資源，這會導致我們有很多的配置文件，由于存在不同的環境，可能不同的環境只是配置文件不同，那么這個配置文件不同就導致了多一個環境就多一套配置文件，所以需要對配置文件進行管理，配置文件發生變化以后需要對相應的服務進行更新和同步。比如說經常出現配置文件和實際部署的服務發生不一致，如果是不一致的話就會出問題。

而現在還有一個特點，當你管理幾百個節點的時候會很痛苦，它們到底是屬于哪一個服務的，你不清楚，因為對你而言它就是一大堆幾百個節點的資源，都在青云的管理后臺里，只能通過標簽分類。但這并不準確，如果有人粗心把標簽打錯了，你就會誤判，而且可能只有運維人員最了解，其他人都不懂。

中間經過 AppCenter 2.0 以后，我們做的微服務，相當于隔一層，程序直接不去對接資源，而是對接 AppCenter 2.0 里面的一個微服務。

這個微服務里面定義了需要的參數，這些參數不是配置文件，而是在服務啟動的時候才會真正有這么一個東西，這是在微服務啟動的時候，比如說我需要一個 MySQL，它是哪一個 IP 地址，主從是什么樣的結構，我需要一個集群，它是什么樣的配置參數，你在創建的時候再填寫，這樣的話由 AppCenter 2.0 去創建資源、創建服務，把這些資源提起來，并且管理服務的生命周期。

通過這些我們把幾百個節點，完全按照以服務為角度進行歸攏和聚類，方便我們的管理。

接下來談談還有哪些工作我們沒有做，其實我們剛才說的這些工作都是比較初級的，是能幫助我們的最快的手段。開發人員沒有投入太多的代碼的改動，我們就把整個服務拆掉，拆成十幾個微服務。我認為智慧摩羯接下來要做的事情，或者說智慧摩羯還沒有完成的工作。

第一個就是認證授權，智慧摩羯的微服務之間現在雖然說是內部系統，但是互相之間也應該有一個授權操作，現在是因為公司的業務沒有到一定的程度，到一定的程度的話是否允許互相認證訪問是應該有授權的。

還有性能監控，拆掉之后每一個服務的性能，延遲還沒有加監控。再就是流量控制，假如說某一個服務知道它大概能承受多少量級的壓力，如果這個壓力過線，我們就能自動進行熔斷，而這個還沒有做。

總結和反思

通過以上這些操作，我們消滅了單失效節點。MySQL 的每一個服務都有主從，可以把壓力分擔。應用層都解決了。解耦單體工程，每個微服務的代碼庫由每個小組進行維護，原來每一次升級都是一次大動作，所有的研發工程師都比較緊張，需要一起溝通交流，然后盯著升級，擔心其是否會出現問題。

現在通過這種方式避免了各個模塊之間的代碼干擾，解決了之前有可能你改了這個代碼卻引起了另外一個你根本不知道的地方出現問題。各個代碼庫的合并授權下發給相關的組長，這樣就解決了放權的問題，我們可以把研發部拆成很多的小組，他們可以獨立進行自己的工作，不再受整個研發部統一的授權。

規范了代碼的合并流程，這實際上解決了開發階段的代碼污染問題，包括開發階段的代碼污染、測試階段的代碼污染、以及線上的代碼污染。

對上百個資源節點以微服務為單位進行分組管理，減少了各個模塊之間的運維干擾，運維也可以以微服務為單位進行拆分放權，包括進行升級。

部署就可以以接口為單位，用接口隨意切流量，雖然做不到智能的流量控制，但是如果線上某一個接口造成特別大的壓力，可以讓接口先返回一些友好的報送信息，從而解決線上某一個接口壓力過大的問題。

第一，系統在不斷地進步，每一個公司的系統都有不同的階段，要針對現階段找到最佳的解決方案。

第二，所有的道理大家都懂，每個人心中也都有解決方案，當你遇到問題的時候肯定有自己的想法，但是最核心的、最重要的事情就是干！