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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

問(wèn)題就是單體工程越來(lái)越龐大，一年我們就做了幾十萬(wàn)行代碼的量級(jí)，還是一個(gè)工程代碼庫(kù)。還有一個(gè)特點(diǎn)就是文檔少，重復(fù)代碼多。由于開(kāi)發(fā)人員增加了，從兩三個(gè)人變成了十幾個(gè)人，導(dǎo)致重復(fù)代碼越來(lái)越多，因?yàn)椴皇敲總€(gè)人都對(duì)代碼理解，文檔少，必然就會(huì)理解少，重復(fù)的代碼多。數(shù)據(jù)庫(kù)無(wú)法根據(jù)業(yè)務(wù)分?jǐn)倝毫Γ瑔问Ч?jié)點(diǎn)多，事故也頻繁出現(xiàn)。

這是智慧摩羯這時(shí)簡(jiǎn)單的架構(gòu)圖，GitHub 是單一的節(jié)點(diǎn)庫(kù)，增加了很多運(yùn)維腳本，當(dāng)時(shí) VM 在 QingCloud 上就有幾十臺(tái)。

微服務(wù)解決方案

沒(méi)有問(wèn)題就沒(méi)有動(dòng)力去改變這個(gè)事情，所以我們先來(lái)看下有哪些問(wèn)題。

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

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

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

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

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

首先是代碼庫(kù)，我們先把 GitHub 的代碼庫(kù)由一個(gè)工程 fork 出來(lái)很多子工程，其實(shí)都是一樣的，因?yàn)槎虝r(shí)間內(nèi)如果想以最快的速度把工程拆掉，這是最簡(jiǎn)單的辦法。

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

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

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

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

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

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

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

這幾百個(gè)服務(wù)沒(méi)必要每個(gè)服務(wù)一臺(tái)機(jī)器。對(duì)哪些服務(wù)需要訪問(wèn)哪些資源連接進(jìn)行整理歸類，比如有的是訪問(wèn)用戶的數(shù)據(jù)庫(kù)，有的是訪問(wèn)訂單數(shù)據(jù)庫(kù)，但是他們?cè)L問(wèn)的時(shí)候也會(huì)分讀寫(xiě)，到底是讀數(shù)據(jù)還是寫(xiě)數(shù)據(jù)。

然后我們?cè)侔阉械倪@些幾百個(gè)服務(wù)、接口，每一個(gè)都仔細(xì)過(guò)了一遍，然后把哪個(gè)該走讀，哪個(gè)該走寫(xiě)，全部歸好類，把所有的配置配好，然后由 API gateway 轉(zhuǎn)到不同的機(jī)型，可能配的是讀庫(kù)或者寫(xiě)庫(kù)，把線上的幾百個(gè)接口拆成幾百個(gè)服務(wù)，每一個(gè)服務(wù)能做到對(duì)其他的服務(wù)最小力度地干擾。

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

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

我對(duì)它的理解就是，它在定義角色，定義生命周期。里面包含了存儲(chǔ)的角色，計(jì)算的角色，包含 RDB、包含 Redis、包含 Zookeeper，可以包含很多的角色。然后這一個(gè)角色可以定義很多參數(shù)，因?yàn)檫@些參數(shù)就是配置參數(shù)，原來(lái)的配置參數(shù)可能不統(tǒng)一，比如說(shuō) Redis有 Redis 的配置參數(shù)、Zookeeper 有 Zookeeper 的配置參數(shù)。

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

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

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

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

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

而現(xiàn)在還有一個(gè)特點(diǎn)，當(dāng)你管理幾百個(gè)節(jié)點(diǎn)的時(shí)候會(huì)很痛苦，它們到底是屬于哪一個(gè)服務(wù)的，你不清楚，因?yàn)閷?duì)你而言它就是一大堆幾百個(gè)節(jié)點(diǎn)的資源，都在青云的管理后臺(tái)里，只能通過(guò)標(biāo)簽分類。但這并不準(zhǔn)確，如果有人粗心把標(biāo)簽打錯(cuò)了，你就會(huì)誤判，而且可能只有運(yùn)維人員最了解，其他人都不懂。

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

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

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

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

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

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

總結(jié)和反思

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

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

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

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

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

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

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