摘要：數(shù)據(jù)庫無法根據(jù)業(yè)務(wù)分攤壓力，單失效節(jié)點多，事故也頻繁出現(xiàn)。這是智慧摩羯這時簡單的架構(gòu)圖，是單一的節(jié)點庫，增加了很多運維腳本，當時在上就有幾十臺。開發(fā)人員變多，出現(xiàn)的事故概率增大，系統(tǒng)升級的風(fēng)險變高。

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

智慧摩羯數(shù)據(jù)科技有限公司，是一家專注于體育運動大數(shù)據(jù)分析服務(wù)的創(chuàng)新型科技公司，以賽事數(shù)據(jù)為基礎(chǔ)，以大數(shù)據(jù)分析為引擎，運用機器學(xué)習(xí)、深度學(xué)習(xí)等人工智能算法來實現(xiàn)全球體育比賽結(jié)果預(yù)測、體育運動指導(dǎo)、電子競技游戲支持等服務(wù)。

智慧摩羯數(shù)據(jù)科技有限公司聯(lián)合創(chuàng)始人陳健，分享了如何解決隨著業(yè)務(wù)發(fā)展，系統(tǒng)越來越臃腫、應(yīng)用變得越來越不易維護、不易擴展等問題，并分享智慧摩羯在搭建企業(yè)微服務(wù)中的相關(guān)經(jīng)驗。以下為演講正文：

大數(shù)據(jù)分析技術(shù)是企業(yè)的核心競爭力。主要的技術(shù)分為兩部分：

第一部分是大數(shù)據(jù)技術(shù)；

第二部分是應(yīng)用的技術(shù)，即大數(shù)據(jù)服務(wù)和應(yīng)用服務(wù)。

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

正是基于核心技術(shù)，智慧摩羯布局了三條產(chǎn)品線：

一是體育比賽預(yù)測，就是剛跟大家分享的，通過去全網(wǎng)扒數(shù)據(jù)，運用人工智能算法分析進而預(yù)測體育比賽結(jié)果。

二是體育運動指導(dǎo)，通過收集所有運動員及體育愛好者的運動數(shù)據(jù)，對其進行專業(yè)地指導(dǎo)。

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

技術(shù)架構(gòu)

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

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

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

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

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

微服務(wù)解決方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原來數(shù)據(jù)庫阻塞了，然后應(yīng)用層組塞，整個用戶就阻塞了?，F(xiàn)在變成了我們可以逐步降級服務(wù)，給用戶提供更穩(wěn)定可靠的服務(wù)，不至于出問題。

這是我們用青云的 AppCenter 2.0 做的這個事情。在去年青云的 AppCenter 2.0 發(fā)布會上，我覺得能夠幫助智慧摩羯實現(xiàn)業(yè)務(wù)。

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

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

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

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

下一步，原來傳統(tǒng)的部署是程序?qū)淤Y源，資源是指的是什么？比如說 VM，計算資源、存儲資源都算資源，我理解的是，物理設(shè)備這些東西都叫資源。

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

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

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

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

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

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

第一個就是認證授權(quán)，智慧摩羯的微服務(wù)之間現(xiàn)在雖然說是內(nèi)部系統(tǒng)，但是互相之間也應(yīng)該有一個授權(quán)操作，現(xiàn)在是因為公司的業(yè)務(wù)沒有到一定的程度，到一定的程度的話是否允許互相認證訪問是應(yīng)該有授權(quán)的。

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

總結(jié)和反思

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

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

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

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

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

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

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