上次參加DBAplus舉辦的敏捷運(yùn)維峰會(huì)時(shí)，一個(gè)兄弟的提問一直縈繞耳邊，由于時(shí)間有限沒有進(jìn)行深入的交流，甚是遺憾。那個(gè)問題是：你們公司的IT系統(tǒng)架構(gòu)是怎樣的？又如何具體落地？采用了哪些開源或是商業(yè)的技術(shù)？

其實(shí)之前也寫過或是做過一些關(guān)于系統(tǒng)架構(gòu)的分享，或多或少的個(gè)人或其它限制，總覺得未能盡興，留有遺憾。因此經(jīng)過最近一個(gè)多月的總結(jié)和梳理，在這寫出來跟大家做一個(gè)分享，這也是對(duì)我個(gè)人技術(shù)生涯中系統(tǒng)架構(gòu)部分做一個(gè)階段性的總結(jié)，以便往后能夠更好地投入到接下來的云平臺(tái)架構(gòu)和機(jī)器學(xué)習(xí)，以及企業(yè)如何降低IT成本的深入研究中。

系統(tǒng)架構(gòu)是一個(gè)比較大的話題，以一個(gè)什么樣的思路或是方法進(jìn)行切入很重要。系統(tǒng)架構(gòu)的脈絡(luò)可以讓我們很好地了解系統(tǒng)架構(gòu)的整體概況，也可以幫助我們建立有效的個(gè)人架構(gòu)知識(shí)體系。

本文從系統(tǒng)訪問鏈路為切入點(diǎn)，圍繞訪問鏈路的方方面面，包括基礎(chǔ)設(shè)施、分層架構(gòu)、分割架構(gòu)、系統(tǒng)保障、技術(shù)平臺(tái)生態(tài)圈等幾個(gè)方面進(jìn)行展開，力求展現(xiàn)出一套相對(duì)比較完整的系統(tǒng)架構(gòu)體系，同時(shí)結(jié)合自身經(jīng)驗(yàn)，介紹具體落地的方案和技術(shù)，希望能夠給讀者帶來一些收獲。

訪問鏈路表示從用戶訪問請(qǐng)求到最終生產(chǎn)服務(wù)器響應(yīng)，再到反饋給用戶請(qǐng)求的結(jié)果信息這一過程。不管是互聯(lián)網(wǎng)企業(yè)還是傳統(tǒng)企業(yè)，在系統(tǒng)架構(gòu)中一定要明確自己的訪問鏈路，這對(duì)系統(tǒng)優(yōu)化、系統(tǒng)排故、鏈路監(jiān)控等至關(guān)重要。

該圖是一家中小型公司的訪問鏈路圖，系統(tǒng)主要分為兩大塊：一是對(duì)外提供服務(wù)的電商平臺(tái)；另外一塊是企業(yè)內(nèi)部的核心生產(chǎn)系統(tǒng)和企業(yè)信息系統(tǒng)等?；疑糠直硎菊诮⒒蚴且?guī)劃建立的部分。

該公司訪問鏈路主要有兩條：一條是外部客戶的外網(wǎng)訪問鏈路，另一條是內(nèi)部員工的內(nèi)網(wǎng)訪問鏈路。該公司是有自建的數(shù)據(jù)中心機(jī)房，可能現(xiàn)在很多公司都將對(duì)外訪問的系統(tǒng)放到租賃的IDC機(jī)房或是云服務(wù)器，其實(shí)都是一樣的。根據(jù)系統(tǒng)特點(diǎn)劃分內(nèi)外網(wǎng)訪問鏈路，可以節(jié)省網(wǎng)絡(luò)流量，也可以增強(qiáng)內(nèi)部系統(tǒng)的安全性等。

1、外網(wǎng)訪問鏈路

外網(wǎng)訪問鏈路從公網(wǎng)DNS開始，按照用戶訪問請(qǐng)求的全鏈路，完整的DNS解析過程應(yīng)該是這樣的：

用戶本地Host->用戶DNS緩存->LocalServer(本地DNS電信、聯(lián)通等)->Root服務(wù)器->權(quán)威服務(wù)器->LocalServer->用戶得到DNS解析結(jié)果->請(qǐng)求等。

2 、內(nèi)外訪問鏈路

圖中數(shù)據(jù)中心B暫時(shí)為備份機(jī)房，提供實(shí)時(shí)同步和延遲同步兩種備份方式。有一些大型集團(tuán)公司可能多個(gè)數(shù)據(jù)中心同時(shí)在用，這個(gè)時(shí)候有的是采用專線的方式，也有的是采用服務(wù)器直接部署在云中，這個(gè)需要根據(jù)專線和云服務(wù)的成本(其實(shí)云服務(wù)的價(jià)格不一定低)，以及數(shù)據(jù)的保密性等進(jìn)行選擇。

其實(shí)上面的訪問鏈路也有一定的潛在問題：

1. 當(dāng)外網(wǎng)訪問量大的時(shí)候，硬件防火墻和WAF將會(huì)成為一定的瓶頸，需要進(jìn)行優(yōu)化、限流或是直接摘除，轉(zhuǎn)為在軟防火墻或是應(yīng)用WAF進(jìn)行分布式防護(hù)；還有一點(diǎn)就是對(duì)防火墻和WAF的策略要求較高，要避免漏殺或是誤殺的情況出現(xiàn)。

2. 內(nèi)網(wǎng)的安全性問題。內(nèi)網(wǎng)的DNS和軟負(fù)載沒有有效地提供內(nèi)網(wǎng)對(duì)生產(chǎn)服務(wù)器的保護(hù)。這個(gè)需要從兩方面加強(qiáng)：

1. 一是對(duì)辦公區(qū)PC機(jī)的防病毒客戶端安裝并及時(shí)更新策略；

2. 二是在軟負(fù)載層增加安全策略，一般兩種方式：

• 調(diào)整WAF的策略或是網(wǎng)絡(luò)位置，對(duì)內(nèi)網(wǎng)進(jìn)行安全防護(hù)；

• 直接購(gòu)買新的WAF放在內(nèi)網(wǎng)區(qū)，但這會(huì)增加成本，同時(shí)讓訪問鏈路更復(fù)雜。

基礎(chǔ)設(shè)置主要包括網(wǎng)絡(luò)、基礎(chǔ)硬件/基礎(chǔ)軟件、數(shù)據(jù)中心這三部分，以及圍繞基礎(chǔ)設(shè)施做的軟件定義網(wǎng)絡(luò)(SDN)、虛擬化容器化、云數(shù)據(jù)中心等，力求做到上層IT架構(gòu)可以不用去過多考慮基礎(chǔ)設(shè)施。

網(wǎng)絡(luò)方面包括：網(wǎng)絡(luò)接入、網(wǎng)絡(luò)規(guī)劃、網(wǎng)絡(luò)實(shí)施、拓?fù)浣Y(jié)構(gòu)、流量管理、安全監(jiān)控等幾個(gè)方面。

首先是網(wǎng)絡(luò)接入，由于中國(guó)特殊的網(wǎng)絡(luò)環(huán)境，對(duì)于需要對(duì)外提供服務(wù)的系統(tǒng)一般都需要考慮多網(wǎng)絡(luò)供應(yīng)商的接入，包括移動(dòng)、聯(lián)通、電信等。不同的網(wǎng)絡(luò)接入對(duì)外提供服務(wù)時(shí)，會(huì)依賴智能DNS等手段，實(shí)現(xiàn)不同網(wǎng)絡(luò)環(huán)境連接至不同公網(wǎng)IP，盡量避免跨網(wǎng)絡(luò)供應(yīng)商的訪問，提高訪問速度。

網(wǎng)絡(luò)規(guī)劃主要包括局域網(wǎng)的規(guī)劃和劃分，一般情況是需要分隔離區(qū)(DMZ)、辦公區(qū)、測(cè)試區(qū)、生產(chǎn)區(qū)等幾個(gè)區(qū)域，不同區(qū)域之間通過防火墻等安全設(shè)備進(jìn)行有效隔離。另外，廣義上的網(wǎng)絡(luò)規(guī)劃還包括數(shù)據(jù)流量及約束條件分析、網(wǎng)絡(luò)選型、拓?fù)浣Y(jié)構(gòu)設(shè)計(jì)、網(wǎng)絡(luò)安全、建設(shè)方案等幾個(gè)方面。

接下來是網(wǎng)絡(luò)實(shí)施。根據(jù)網(wǎng)絡(luò)規(guī)劃和網(wǎng)絡(luò)建設(shè)方案，進(jìn)行網(wǎng)絡(luò)的部署和實(shí)施。

不管傳統(tǒng)企業(yè)還是互聯(lián)網(wǎng)公司，一定要有自己的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)圖，這樣網(wǎng)絡(luò)架構(gòu)清晰明了，當(dāng)網(wǎng)絡(luò)故障時(shí)，對(duì)于故障點(diǎn)、影響范圍等都可以通過網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)圖快速獲得。網(wǎng)絡(luò)拓?fù)湟獙?shí)時(shí)更新，時(shí)刻保持與真實(shí)網(wǎng)絡(luò)環(huán)境一致。

要對(duì)網(wǎng)絡(luò)的流量進(jìn)行管理和實(shí)時(shí)監(jiān)控。根據(jù)網(wǎng)絡(luò)流量合理調(diào)整網(wǎng)絡(luò)帶寬等。整個(gè)網(wǎng)絡(luò)基礎(chǔ)設(shè)施中的網(wǎng)絡(luò)安全不可或缺。一般通過防火墻、IPS/IDS等軟硬件設(shè)備進(jìn)行網(wǎng)絡(luò)安全的防護(hù)或是監(jiān)控、分析和屏蔽絕大部分的網(wǎng)絡(luò)攻擊行為。

網(wǎng)絡(luò)作為重要的基礎(chǔ)設(shè)施之一，要根據(jù)安全策略和實(shí)際業(yè)務(wù)量、業(yè)務(wù)情況等幾個(gè)方面進(jìn)行合理的規(guī)劃和實(shí)施，完善網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，通過監(jiān)控和流量管理等手段，實(shí)時(shí)了解網(wǎng)絡(luò)以及網(wǎng)絡(luò)設(shè)備的運(yùn)行情況，當(dāng)出現(xiàn)故障或是性能問題時(shí)，能夠快速發(fā)現(xiàn)故障源或是性能瓶頸點(diǎn)，以便有重點(diǎn)地進(jìn)行排故、調(diào)優(yōu)。

2、基礎(chǔ)軟硬件

基礎(chǔ)硬件包括服務(wù)器、內(nèi)存、CPU、存儲(chǔ)、電源、防火墻、交換機(jī)、路由器、集線器等服務(wù)器、網(wǎng)絡(luò)及周邊硬件設(shè)施。

基礎(chǔ)硬件及其備件一般有雙份或是多份，避免硬件單點(diǎn)故障，也就是說一般企業(yè)要有自己的備件庫(kù)，對(duì)服務(wù)器、存儲(chǔ)、網(wǎng)絡(luò)設(shè)備等硬件進(jìn)行備份，當(dāng)出現(xiàn)問題時(shí)，可以及時(shí)更換。備件庫(kù)的信息也要跟隨CMDB一起入庫(kù)管理。

基礎(chǔ)軟件包括操作系統(tǒng)ISO文件、數(shù)據(jù)庫(kù)安裝文件、應(yīng)用服務(wù)器安裝文件等基礎(chǔ)軟件，也包括辦公用的Office、瀏覽器等軟件。

根據(jù)個(gè)人經(jīng)驗(yàn)，推薦一種相對(duì)比較好且易于部署管理的基礎(chǔ)軟件管理方式。根據(jù)軟件的性質(zhì)進(jìn)行如下分類，請(qǐng)大家參考：

將上述軟件進(jìn)行統(tǒng)一整理，部署到一臺(tái)Nginx服務(wù)器上作為靜態(tài)資源，并建立二級(jí)域名如soft.xxx.com。這樣局域網(wǎng)內(nèi)用戶在使用軟件時(shí)，直接通過訪問soft.xxx.com進(jìn)行下載安裝即可。這樣做的一個(gè)好處是可以管理公司的基礎(chǔ)軟件，并且規(guī)范版本號(hào)，避免多種版本的存在。以下是使用Nginx搭建的一個(gè)軟件庫(kù)，僅用來說明。

3、數(shù)據(jù)中心

如今越來越多的公司采用云服務(wù)進(jìn)行系統(tǒng)部署，省去了自建數(shù)據(jù)中心機(jī)房等比較繁雜的事情。短時(shí)間來看對(duì)企業(yè)是非常有利的，因?yàn)榭烨曳奖?，可以適應(yīng)企業(yè)的快速發(fā)展。但隨著企業(yè)的規(guī)模不斷變大，大量的使用云服務(wù)，IT成本會(huì)越來越高，自建數(shù)據(jù)中心可能會(huì)逐漸成為一種比較經(jīng)濟(jì)的方式。自建數(shù)據(jù)中心和云服務(wù)本身是沒有矛盾且可以科學(xué)組合、相輔相成的。企業(yè)哪一階段哪一種方式最優(yōu)，要根據(jù)企業(yè)的業(yè)務(wù)實(shí)際情況和進(jìn)行科學(xué)的計(jì)算后才可判斷哪種方式最經(jīng)濟(jì)。（注：這里的云服務(wù)是指的公有云）

當(dāng)然也有一些企業(yè)因?yàn)樽陨頂?shù)據(jù)的保密性比較高，業(yè)務(wù)相對(duì)比較特殊，所以一開始就自建數(shù)據(jù)中心機(jī)房。

一般而言，數(shù)據(jù)中心機(jī)房的建設(shè)要按照國(guó)家標(biāo)準(zhǔn)和行業(yè)標(biāo)準(zhǔn)進(jìn)行建立，這都有比較明確的標(biāo)準(zhǔn)規(guī)范，這里大概總結(jié)了一下：

數(shù)據(jù)中心的建立有自建或是委托專業(yè)數(shù)據(jù)中心設(shè)計(jì)公司來進(jìn)行。一般公司可以通過第二種方式，通過與專業(yè)的數(shù)據(jù)中心設(shè)計(jì)公司合作，建設(shè)安全、可靠、伸縮性強(qiáng)以及節(jié)能環(huán)保的數(shù)據(jù)中心。

另外數(shù)據(jù)中心的建立、驗(yàn)收、等級(jí)、災(zāi)備等都有著明確的國(guó)家規(guī)范和行業(yè)行規(guī)，大家在規(guī)劃或建立的時(shí)候，一定在合規(guī)的底線上，進(jìn)行優(yōu)化設(shè)計(jì)，常用的數(shù)據(jù)中心參考文檔有：

• 《數(shù)據(jù)中心建設(shè)與管理指南》

• 《GB50174-2017 數(shù)據(jù)中心設(shè)計(jì)規(guī)范》

• 《GB50462-2015數(shù)據(jù)中心基礎(chǔ)設(shè)施施工及驗(yàn)收規(guī)范》

• 《GBT22239—2008信息系統(tǒng)安全等級(jí)保護(hù)基本要求》

• TIA-942《數(shù)據(jù)中心電信基礎(chǔ)設(shè)施標(biāo)準(zhǔn)》（中文版）等等

【提示】由于文檔打包較大，感興趣的同學(xué)可點(diǎn)擊鏈接https://pan.baidu.com/s/1eR7RyPO或點(diǎn)擊文末【閱讀原文】進(jìn)行下載。

4、基礎(chǔ)設(shè)施管理與優(yōu)化

對(duì)于基礎(chǔ)設(shè)施的管理，需要CMDB結(jié)合資產(chǎn)管理系統(tǒng)對(duì)基礎(chǔ)設(shè)施進(jìn)行統(tǒng)一錄入、上架、管理、下架、報(bào)廢等全生命周期進(jìn)行管理。通過IT系統(tǒng)進(jìn)行基礎(chǔ)設(shè)施管理，可以提高管理效率，降低故障率等。CMDB作為運(yùn)維管理體系中的基礎(chǔ)一環(huán)，至關(guān)重要。一些中小型企業(yè)可能暫時(shí)沒有能力建立或是購(gòu)買CMDB，這時(shí)可以通過采用構(gòu)建開源CMDB或是直接用最簡(jiǎn)單有效的Excel進(jìn)行管理，總之，不管哪種方式，基礎(chǔ)設(shè)施的集中管理不可或缺。CMDB中的數(shù)據(jù)一定要與實(shí)際環(huán)境實(shí)時(shí)對(duì)應(yīng)，確保準(zhǔn)確無延遲。

為了更高效地利用基礎(chǔ)設(shè)施的資源，虛擬化、容器化正在不同的公司中逐漸實(shí)行。本文以一些中小公司(包括我們公司)常見的基礎(chǔ)架構(gòu)演變路線進(jìn)行介紹。

很多公司遵循著多臺(tái)物理機(jī)到虛擬化再到容器化或是虛擬化容器化并存，最終實(shí)現(xiàn)到云服務(wù)的這一演變過程。首先是初始階段的多臺(tái)物理機(jī)部署服務(wù)，資源利用率比較粗，相對(duì)比較浪費(fèi)，于是通過虛擬化提高資源的利用率和管理效率。我所經(jīng)歷的一家公司正處在虛擬化階段，通過購(gòu)買fc-san存儲(chǔ)，構(gòu)建虛擬化集群，實(shí)現(xiàn)服務(wù)器的高效利用、集群高可用并且便于備份。但在虛擬化的過程中，也經(jīng)歷著虛擬化的以下問題：

1. 搭建成本太高，需要購(gòu)買專業(yè)存儲(chǔ)以及網(wǎng)絡(luò)設(shè)備等。(當(dāng)然也可以直接在物理機(jī)上部署exsi，但是高可用不是很好實(shí)現(xiàn)，例如VMare自帶的高可用組件)

2. 虛擬機(jī)備份比較笨重，需要結(jié)合BE或是自帶的備份工具，耗時(shí)較長(zhǎng)，備份粒度不夠細(xì)。

3. 服務(wù)宕機(jī)后虛擬機(jī)漂移時(shí)間相對(duì)較長(zhǎng)，大概5分鐘左右(跟硬件和技術(shù)有關(guān)系，有的公司可能時(shí)間很短)。漂移后虛擬機(jī)自動(dòng)重啟，如果部署在虛擬機(jī)上的服務(wù)未開機(jī)自啟，將比較頭疼。

4. 部署虛擬機(jī)時(shí)間較長(zhǎng)，雖然采用Cobbler等方式實(shí)現(xiàn)自動(dòng)安裝，但部署一套虛擬機(jī)，大概在10~20分鐘左右。

以上四點(diǎn)是我們?cè)谧鎏摂M化時(shí)，面臨著比較突出的問題，當(dāng)然這也許跟我們虛擬化工程師的技術(shù)水平有一定的關(guān)系。為了解決虛擬化的問題，提高運(yùn)維效率，我們現(xiàn)在正進(jìn)行虛擬化+容器化并存的架構(gòu)改進(jìn)和優(yōu)化，當(dāng)前架構(gòu)如下：

注：基礎(chǔ)設(shè)施架構(gòu)這一塊，目前我們面臨這1~2年后的數(shù)據(jù)中心遷移以及新數(shù)據(jù)中心規(guī)劃，后續(xù)我們的規(guī)范方案和遷移方案定稿后，會(huì)繼續(xù)跟大家分享、探討。

可以看出，當(dāng)前基礎(chǔ)資源架構(gòu)是虛擬化和容器化并存，二者相互隔離又在應(yīng)用層面相互聯(lián)系，共同組成集群，為上層應(yīng)用提供服務(wù)。

相比虛擬化以及物理機(jī)，單純?nèi)萜骰幸韵聨讉€(gè)難點(diǎn)不太好實(shí)現(xiàn)：

1. Windows服務(wù)器在Docker容器不能或是不容易部署。(據(jù)稱Docker已經(jīng)開始支持win，但未研究測(cè)試)

2. Oracle數(shù)據(jù)庫(kù)在Docker部署缺少大規(guī)模生產(chǎn)經(jīng)驗(yàn)，不敢貿(mào)然直接在容器部署Oracle服務(wù)器。尤其是RAC+DG這樣的高可用集群，在容器部署也不太現(xiàn)實(shí)。

3. 就目前我們技術(shù)現(xiàn)狀來說，單純?nèi)萜骰幸欢ǖ娘L(fēng)險(xiǎn)，需要一個(gè)摸索階段，雖然有很多成熟的經(jīng)驗(yàn)可以借鑒，但畢竟適合自己的架構(gòu)才是最好的。

基于容器的便利性以及高效快捷，未來會(huì)逐漸以容器化為主，但數(shù)據(jù)庫(kù)和Window服務(wù)相關(guān)的部署以虛擬化為主，二者互補(bǔ)，為以后實(shí)現(xiàn)云服務(wù)提供基礎(chǔ)鋪墊。

容器化管理計(jì)劃以K8s為主進(jìn)行編排和調(diào)度，K8s目前正在技術(shù)調(diào)研和測(cè)試中，待成熟后會(huì)為大家繼續(xù)進(jìn)行分享。當(dāng)然我們也面臨著是否需要采用OpenStack或是其它技術(shù)搭建IaaS基礎(chǔ)云平臺(tái)的糾結(jié)。

不管系統(tǒng)架構(gòu)還是基礎(chǔ)架構(gòu)，都是一個(gè)逐漸演化的過程，適合當(dāng)下業(yè)務(wù)架構(gòu)并且易伸縮的架構(gòu)才是最優(yōu)化的架構(gòu)。

1 、分層架構(gòu)概述

系統(tǒng)在做分層架構(gòu)候，一般情況下主要包括：接入層、應(yīng)用層、公共服務(wù)層、數(shù)據(jù)存儲(chǔ)層等幾個(gè)層次，其中接入層還包括DNS轉(zhuǎn)發(fā)、CDN、負(fù)載均衡層、靜態(tài)資源層等。有CDN的公司會(huì)直接將靜態(tài)資源放在CDN層中。

系統(tǒng)分層架構(gòu)圖大概如下：

2、負(fù)載均衡和反向代理

負(fù)載均衡分為軟負(fù)載和硬負(fù)載。其中硬負(fù)載包括有F5、A10等不同品牌的硬件負(fù)載均衡器，軟負(fù)載包括LVS、Nginx、HAproxy等開源軟負(fù)載均衡軟件。硬負(fù)載相對(duì)比較貴，成本較高。中小企業(yè)可以選擇開源的軟負(fù)載實(shí)現(xiàn)負(fù)載均衡和反向代理，通過負(fù)載均衡提高系統(tǒng)的吞吐從而提高性能，反向代理增加內(nèi)部系統(tǒng)的安全性。負(fù)載均衡服務(wù)器一般是部署在DMZ區(qū)域與內(nèi)網(wǎng)通過防火墻進(jìn)行端口映射，提高內(nèi)網(wǎng)服務(wù)器的安全。

軟負(fù)載的選擇上一般從LVS、Nginx、HAproxy三者中進(jìn)行選擇或是組合選擇。其中LVS相比Nginx、HAproxy、LVS工作在網(wǎng)絡(luò)四層，僅做請(qǐng)求轉(zhuǎn)發(fā)，性能效率比較高。Nginx和HAproxy工作在網(wǎng)絡(luò)七層之上，較LVS性能差一些，但二者之間，并沒有特別大的差別。

使用負(fù)載均衡和反向代理一般要著重考慮以下三個(gè)問題：

• 高可用問題 

• 負(fù)載策略 

• 有狀態(tài)服務(wù)的session保存

（1）實(shí)現(xiàn)負(fù)載均衡服務(wù)器的高可用一般通過虛擬IP的方式，將虛擬IP通過防火墻與公網(wǎng)IP端口轉(zhuǎn)換，對(duì)外提供服務(wù)，常用的開源組件有keepalived。但在使用開源組件進(jìn)行虛擬IP配置時(shí)，一般都要去積極主動(dòng)地進(jìn)行腦裂檢測(cè)和避免腦裂問題的產(chǎn)生。通常用檢測(cè)腦裂問題的辦法進(jìn)行仲裁，通過多個(gè)節(jié)點(diǎn)進(jìn)行仲裁選舉出問題節(jié)點(diǎn)，踢出集群，我們?cè)谧瞿X裂仲裁時(shí)除了其它節(jié)點(diǎn)選舉之外，還添加本節(jié)點(diǎn)的自動(dòng)檢測(cè)，避免本節(jié)點(diǎn)故障假死的情況下，選舉不準(zhǔn)確。關(guān)于腦裂仲裁算法網(wǎng)上都有實(shí)現(xiàn)方法，大伙可以參照，結(jié)合實(shí)際情況進(jìn)行改良。

（2）使用負(fù)載均衡和反向代理有一個(gè)比較重要的問題就是負(fù)載策略的選擇。以Nginx為例，常用的有Round-robin（輪循）、Weight-round-robin（帶權(quán)輪循）、Ip-hash（Ip哈希），其中HAproxy還支持動(dòng)態(tài)加權(quán)輪循(Dynamic Round Robin)，加權(quán)源地址哈希(Weighted Source Hash)，加權(quán)URL哈希和加權(quán)參數(shù)哈希(Weighted Parameter Hash)等。但是我們生產(chǎn)環(huán)境中用的最多的還是輪詢和iphash這兩種方式。如果后端應(yīng)用是有狀態(tài)的，且未實(shí)現(xiàn)session共享，一般使用ip-hash的方式。

（3）對(duì)于有狀態(tài)的后端應(yīng)用，如果采用輪詢的策略會(huì)有問題。但是采用ip-hash的方式也會(huì)有一定的問題，首先是后端服務(wù)器的訪問負(fù)載不均衡，會(huì)有較大的偏差，其次是未實(shí)現(xiàn)真正的應(yīng)用高可用，當(dāng)連接到的后端服務(wù)器宕機(jī)，session丟失，需要重新進(jìn)行業(yè)務(wù)登錄或操作等。解決這一問題一般常用的方法有三種：

1. 應(yīng)用服務(wù)器共享session

2. cookie存session

3. session服務(wù)器存session

應(yīng)用服務(wù)器共享session，這個(gè)Tomcat是支持的，只需要配置即可，但對(duì)應(yīng)用的性能有比較大的影響，尤其是應(yīng)用節(jié)點(diǎn)比較多的情況；cookie存session是一個(gè)方法，但cookie的大小有限，不適合存較多的session；session服務(wù)器存session應(yīng)該算是最佳的辦法，例如使用Redis存共享session，很多公司在用，但也有一個(gè)缺點(diǎn)就是增加維護(hù)成本和運(yùn)維復(fù)雜度，雖然這項(xiàng)技術(shù)實(shí)施起來會(huì)比較簡(jiǎn)單。

3、業(yè)務(wù)應(yīng)用層

業(yè)務(wù)應(yīng)用層比較大的一塊是做服務(wù)化，這會(huì)在下面的分割架構(gòu)進(jìn)行詳細(xì)說明。這里主要說明簡(jiǎn)單的業(yè)務(wù)拆分和應(yīng)用集群的部署方式。

高內(nèi)聚、低耦合一直是軟件開發(fā)和系統(tǒng)運(yùn)維所積極追求的。通過實(shí)現(xiàn)業(yè)務(wù)系統(tǒng)的高內(nèi)聚、低耦合，降低系統(tǒng)依賴，提高系統(tǒng)的可用性，降低故障率，業(yè)務(wù)拆分是解耦的重要利器之一。一般根據(jù)公司業(yè)務(wù)系統(tǒng)的特點(diǎn)和關(guān)聯(lián)進(jìn)行拆分，對(duì)公共業(yè)務(wù)系統(tǒng)進(jìn)行抽取形成公共業(yè)務(wù)應(yīng)用，對(duì)所有業(yè)務(wù)系統(tǒng)進(jìn)行接口化服務(wù)。各個(gè)業(yè)務(wù)系統(tǒng)之間獨(dú)立部署，降低耦合度，減少了業(yè)務(wù)系統(tǒng)之間的依賴和影響，提高整個(gè)系統(tǒng)的利用率。

因?yàn)橛星懊娴呢?fù)載均衡和反向代理層，所有后端的應(yīng)用服務(wù)器可以橫向部署多臺(tái)，實(shí)現(xiàn)高可用也起到用戶訪問分流，增加吞吐、提高并發(fā)量。實(shí)際應(yīng)用部署中主要以Java應(yīng)用居多，且多部署在Tomcat中，以此為例，在應(yīng)用服務(wù)器部署時(shí)，主要考慮以下幾個(gè)問題或是建議：

• 統(tǒng)一JDK和Tomcat版本。這很重要，主要是為了方便管理，另外也方便做自動(dòng)化運(yùn)維部署。其中統(tǒng)一部署中的操作系統(tǒng)優(yōu)化、安全加固，Tomcat優(yōu)化、安全加固等都要做好，我們?cè)谧鯰omcat自動(dòng)部署的時(shí)候，采用的是根據(jù)系統(tǒng)配置自動(dòng)優(yōu)化的方式和安全加固策略進(jìn)行。另外就是自動(dòng)備份和日志的自動(dòng)切割，都在統(tǒng)一部署腳本中體現(xiàn)。這樣所有部署下來，安裝位置、部署方式等都是一致的，方便統(tǒng)一管理，統(tǒng)一備份和升級(jí)。

• 動(dòng)態(tài)頁(yè)面靜態(tài)化。這個(gè)根據(jù)訪問量選擇系統(tǒng)進(jìn)行，例如公司的B2C官網(wǎng)等可以采用靜態(tài)化的技術(shù)，提高頁(yè)面的訪問速度。

4、公共服務(wù)層

公共服務(wù)層將上層業(yè)務(wù)層公共用到的一些緩存、消息隊(duì)列、session、文件圖片、統(tǒng)一調(diào)度、定時(shí)任務(wù)等抽取出來，作為單獨(dú)的服務(wù)進(jìn)行部署，為業(yè)務(wù)層提供緩存、消息隊(duì)列以及圖片等服務(wù)。

緩存主要是指的緩存數(shù)據(jù)。應(yīng)用服務(wù)器通過緩存服務(wù)器查詢常用數(shù)據(jù)，提高系統(tǒng)的查詢速度，對(duì)于高并發(fā)的寫，通過異步調(diào)用消息隊(duì)列，進(jìn)行數(shù)據(jù)的臨時(shí)存儲(chǔ)，提高系統(tǒng)的并發(fā)量和系統(tǒng)效率。Session集群以及文件圖片服務(wù)器集群主要是為上層業(yè)務(wù)應(yīng)用提供統(tǒng)一的session存儲(chǔ)和圖片文件存儲(chǔ)的，避免系統(tǒng)的session失效和單點(diǎn)故障。

常用的數(shù)據(jù)緩存以及session存儲(chǔ)主要是Redis。Redis的集群部署方式在數(shù)據(jù)存儲(chǔ)層會(huì)詳細(xì)說明。

消息隊(duì)列的主要中間件有ActiveMQ和RabbitMQ等，二者都提供master-slave或是集群的部署方式。我所經(jīng)歷的公司中二者都有生產(chǎn)上的應(yīng)用。常用的還有ZeroMQ、Kafka，但ZeroMQ不能持久化存儲(chǔ)，因?yàn)椴⑽丛谏a(chǎn)使用，所以不好多說。Kafka主要在搭建日志分析平臺(tái)時(shí)用到過。對(duì)于ActiveMQ和RabbitMQ，二者并沒有太大的區(qū)別，都在生產(chǎn)用過，也沒遇到太大問題。在技術(shù)選擇中，還是選擇開發(fā)和運(yùn)維最熟悉的為好，再具體點(diǎn)，建議以開發(fā)最熟悉的為標(biāo)準(zhǔn)。

文件圖片服務(wù)器，如果公司的數(shù)據(jù)比較敏感且有較高的保密性，加上核心生產(chǎn)系統(tǒng)只能內(nèi)部使用的話，建議搭建內(nèi)部分布式文件服務(wù)器、圖片服務(wù)器，我所經(jīng)歷的公司有使用FastDFS進(jìn)行構(gòu)建分布式集群文件服務(wù)器的，目前比較火的分布式存儲(chǔ)主要是Ceph吧。如果對(duì)外提供服務(wù)，建議采用購(gòu)買云服務(wù)，如阿里云的OSS等，方便運(yùn)維管理，而且云服務(wù)自身的特性，也比較容易增加文件或圖片的加載速度。

統(tǒng)一調(diào)度、統(tǒng)一任務(wù)平臺(tái)，我們使用淘寶的TBSchedule，也有一部分使用Spring自帶的定時(shí)任務(wù)，目前正在做整合。就現(xiàn)在來看，可以滿足我們的定時(shí)任務(wù)和統(tǒng)一調(diào)度的需求。

公共服務(wù)層的架構(gòu)和部署一般來說都提供了主從和集群兩種高可用方式，并且都實(shí)現(xiàn)分布式部署。由于公共服務(wù)的重要性，所有業(yè)務(wù)都在調(diào)用，所以在實(shí)際生產(chǎn)部署的時(shí)候，一定要采用高可用的方式進(jìn)行部署，并且要有可伸縮性和可擴(kuò)展性。結(jié)合我們公司實(shí)際情況，在進(jìn)行公共服務(wù)部署時(shí)，除了采用主從或是Cluster的方式進(jìn)行部署，還增加了一鍵擴(kuò)展的腳本，實(shí)現(xiàn)對(duì)集群中服務(wù)器的快速擴(kuò)展。分布式擴(kuò)展方式中的常用算法主要是一致性hash的方式，網(wǎng)上資料很多，這里不在一一贅述。

5、數(shù)據(jù)存儲(chǔ)層

數(shù)據(jù)存儲(chǔ)層主要分為關(guān)系型數(shù)據(jù)庫(kù)和NoSQL數(shù)據(jù)庫(kù)。主要從高可用集群包括負(fù)載均衡、讀寫分離、分庫(kù)分表等幾個(gè)方面，結(jié)合自身實(shí)際應(yīng)用經(jīng)驗(yàn)進(jìn)行分析。 

目前用得比較多的數(shù)據(jù)庫(kù)主要Oracle和MySQL兩種，我之前所經(jīng)歷的生產(chǎn)系統(tǒng)，做如下架構(gòu)，請(qǐng)參考：

（1）Oracle

首先是Oracle數(shù)據(jù)庫(kù)，為了避免單點(diǎn)故障，一般數(shù)據(jù)庫(kù)都進(jìn)行集群部署，一方面實(shí)現(xiàn)高可用，另一方面實(shí)現(xiàn)負(fù)載均衡提高業(yè)務(wù)數(shù)據(jù)處理能力等。

Oracle常用的比較經(jīng)典的高可用方案主要是RAC+DataGuard，其中RAC負(fù)責(zé)負(fù)載均衡，對(duì)應(yīng)用的數(shù)據(jù)庫(kù)請(qǐng)求分布在不同的節(jié)點(diǎn)進(jìn)行。DataGuard作為RAC的Standby，平常以readonly模式打開，為應(yīng)用提供讀的服務(wù)，實(shí)現(xiàn)讀寫分離的功能。

Oracle整體的集群架構(gòu)成本較高，除了專用的license，還需共享存儲(chǔ)等，且搭建比較復(fù)雜，運(yùn)維成本較高。

很多人感覺RAC并不是Oracle高可用架構(gòu)的原因可能有以下場(chǎng)景：當(dāng)節(jié)點(diǎn)負(fù)載很高，壓力很大的時(shí)候，如果一個(gè)節(jié)點(diǎn)突然宕掉，相應(yīng)該節(jié)點(diǎn)的請(qǐng)求會(huì)飄到另一個(gè)節(jié)點(diǎn)上，另一個(gè)節(jié)點(diǎn)也很快會(huì)因?yàn)樨?fù)載過高而宕機(jī)，進(jìn)而整個(gè)集群不可用。

關(guān)于Oracle分庫(kù)分表。平常用得比較多的是Oracle的分表，將一些大表通過hash或日期等方式拆分成多個(gè)表，實(shí)現(xiàn)大表數(shù)據(jù)分散化，提高大表的性能。但對(duì)于Oracle的分庫(kù)，本人并沒有找到好的方式或是中間件，用的比較多的主要是DBLINK+Synonym的方式，相比性能有不小的下降。不知大家是否有關(guān)于Oracle分布更好的方案或是中間件，可留言一起探討。

（2）MySQL

MySQL的高可用架構(gòu)相對(duì)會(huì)更靈活一些，成本會(huì)較低。目前生產(chǎn)MySQL高可用架構(gòu)主要以主從同步、主主同步+Keepalived、MHA等為主。關(guān)于MHA，不管是楊建榮老師還是賀春旸老師都做過深入的解析和結(jié)合自編腳本做了一些改進(jìn)，生產(chǎn)系統(tǒng)使用MHA，除了了解MHA的原理以及管理腳本，二位老師的解析和自編腳本，推薦大家做深入研究。

除了基于主從復(fù)制的高可用方案，不同的MySQL分支也提供了相應(yīng)的Cluster的服務(wù)，我們生產(chǎn)中并未使用MySQL的Cluster，所以不做過多介紹。

對(duì)于MySQL的分庫(kù)分表、讀寫分離等功能的實(shí)現(xiàn)，我們更多的是依賴于MySQL中間件。常用的MySQL中間件也非常多。

上圖摘自14年8月份在做分庫(kù)分表技術(shù)調(diào)研時(shí)在網(wǎng)上找的一個(gè)圖。截止到目前，我經(jīng)歷過生產(chǎn)使用較多的分庫(kù)分表和讀寫分離中間件的主要有Maxscale(實(shí)現(xiàn)讀寫分離)，Spider(分庫(kù)分表)，OneProxy以及MyCat。下面是之前我們電商平臺(tái)使用MyCat實(shí)現(xiàn)讀寫分離和分庫(kù)分表的架構(gòu)，希望能夠給各位帶來一些收獲：

該架構(gòu)分為四個(gè)大的數(shù)據(jù)庫(kù)集群：交易平臺(tái)、會(huì)員中心、金融平臺(tái)、物流平臺(tái)，每個(gè)集群內(nèi)部讀寫分離。四個(gè)集群之上采用OneProxy做數(shù)據(jù)庫(kù)路由，實(shí)現(xiàn)對(duì)開發(fā)來說后臺(tái)只是一個(gè)數(shù)據(jù)庫(kù)。

采用數(shù)據(jù)庫(kù)中間件，或多或少的都有一些限制，例如跨庫(kù)查詢、跨庫(kù)事務(wù)等，各位在進(jìn)行改造的時(shí)候，一定要結(jié)合開發(fā)、測(cè)試，共同進(jìn)行分庫(kù)分表后的測(cè)試，確保無誤。關(guān)于讀寫分離和分庫(kù)分表，這里將個(gè)人的感悟分享一下：

• 關(guān)于MySQL讀寫分離

讀寫分離通過分解數(shù)據(jù)庫(kù)讀寫操作，減緩寫的壓力。尤其是在未實(shí)現(xiàn)分庫(kù)的情況下，采用maste-slave模式的master節(jié)點(diǎn)面臨著巨大的讀寫壓力。采用讀寫分離的好處不言而喻，但也有苦惱。假如讀寫落在的庫(kù)上數(shù)據(jù)有延遲導(dǎo)致不一致，也是個(gè)很痛苦的事情。

提供讀寫分離的中間件也很多，Maxscale首薦，Amoeba比較經(jīng)典，歲數(shù)也比較大，另外下面的MySQL分庫(kù)分表的中間件也大多支持讀寫分離。對(duì)于讀寫分離的訴求一般都是寫庫(kù)壓力大。對(duì)于這種情況，3種建議方式：

1. 數(shù)據(jù)庫(kù)之上添加消息隊(duì)列，減輕直接寫數(shù)據(jù)庫(kù)的壓力；

2. 使用緩存服務(wù)器例如Redis，將常用數(shù)據(jù)緩存在緩存服務(wù)器中；

3. 讀寫分離，同時(shí)加強(qiáng)主從同步速度，盡量避免屬于延遲的情況。

1~2步需要開發(fā)的同學(xué)參與進(jìn)來由架構(gòu)師主導(dǎo)完成，進(jìn)行這3步的同時(shí)還要不斷優(yōu)化慢查詢。

• 關(guān)于MySQL分庫(kù)分表

首先強(qiáng)烈建議業(yè)務(wù)層面拆分，微服務(wù)的同時(shí)數(shù)據(jù)庫(kù)也完成拆分，通過開發(fā)手段避免跨庫(kù)查詢和跨庫(kù)事務(wù)。減少使用數(shù)據(jù)庫(kù)中間件實(shí)現(xiàn)MySQL的分庫(kù)操作，當(dāng)然單表過大是需要DBA介入進(jìn)行分表優(yōu)化的。

分庫(kù)分表常用的中間件也較多：MariaDB的Spider、OneProxy、360的Atlas、MyCat、Cobar等。

• Spider

  https:///kb/en/library/spider-storage-engine-overview/

• OneProxy

  http://www./proxy.html

• Atlas：目前應(yīng)該已經(jīng)停更了。

  https://github.com/Qihoo360/Atlas/blob/master/README_ZH.md 

• MyCat：功能比較全，而且比較火。

  http://www./ mycat

• Cobar：目前也已經(jīng)停更，記得MyCat早期就是繼續(xù)Cobar而逐漸演化的

  https://github.com/alibaba/cobar?spm=0.0.0.0.arolKs 

• PS：阿里關(guān)于數(shù)據(jù)庫(kù)開源了很多不錯(cuò)的產(chǎn)品

  https://yq.aliyun.com/opensource

大家可以看出，對(duì)于讀寫分離和分庫(kù)分表我都是優(yōu)先推薦的MariaDB系的產(chǎn)品。因?yàn)楣竞蛡€(gè)人原因吧，我只有在之前的公司研究過一段時(shí)間MySQL的讀寫分離和分庫(kù)分表，在測(cè)試環(huán)境做了大量的測(cè)試，但最終沒上到生產(chǎn)中，反而是隨著公司的業(yè)務(wù)重組，IT順勢(shì)做了服務(wù)化，將原來的一套B2B平臺(tái)拆分成多個(gè)模塊，實(shí)現(xiàn)了解耦，數(shù)據(jù)庫(kù)也順勢(shì)拆分了出來，所以就單個(gè)模塊，讀寫壓力少了很多。算是業(yè)務(wù)重組和系統(tǒng)重構(gòu)讓我們暫時(shí)沒用中間件來實(shí)現(xiàn)讀寫分離和分庫(kù)分表。但報(bào)表類型的查詢我們還是讓開發(fā)直接查詢的slave端的。

之所以推薦MariaDB系，是因?yàn)橹昂唾R春旸老師(http://blog.51cto.com/hcymysql)聊天的時(shí)候，得知他們有一些采用的Maxscale和Spider，他本身也做了大量的測(cè)試，也有生產(chǎn)經(jīng)驗(yàn)，所以在這里給大家做推薦。當(dāng)時(shí)我們公司測(cè)試的主要以O(shè)neProxy為主，但其是收費(fèi)產(chǎn)品。

看似讀寫分離和分庫(kù)分表有點(diǎn)打太極，都先把事情推給開發(fā)同學(xué)。實(shí)際上從架構(gòu)的角度來看，數(shù)據(jù)庫(kù)承擔(dān)的計(jì)算越少越好，數(shù)據(jù)庫(kù)越輕越靈活。一般來講，需要DBA來采用中間件的方式實(shí)現(xiàn)讀寫分離和分庫(kù)分表時(shí)，某種程度上都會(huì)降低性能，畢竟加了中間件一層；另外也增加DBA的運(yùn)維負(fù)擔(dān)，同時(shí)中間件支持的分庫(kù)分表對(duì)于跨庫(kù)查詢和跨庫(kù)事務(wù)都有一定的限制，需要開發(fā)的同學(xué)做一些代碼上的轉(zhuǎn)變。

（3）DMP數(shù)據(jù)平臺(tái)

DMP統(tǒng)一數(shù)據(jù)管理平臺(tái)主要用于數(shù)據(jù)分析和報(bào)表展示等功能。通過搭建統(tǒng)一數(shù)據(jù)管理平臺(tái)，減少直接生產(chǎn)庫(kù)查詢數(shù)據(jù)的壓力，減少生產(chǎn)壓力。對(duì)于中小企業(yè)的數(shù)據(jù)平臺(tái)，我之前寫過一篇介紹，可以參考：《數(shù)據(jù)即金錢，中小企業(yè)如何搭建數(shù)據(jù)平臺(tái)分得一杯羹？》，比較適合中小企業(yè)使用，可以在這個(gè)架構(gòu)基礎(chǔ)上添加Hadoop集群等來處理大數(shù)據(jù)相關(guān)的分析，很容易進(jìn)行擴(kuò)展。

非關(guān)系型數(shù)據(jù)庫(kù)主要以Redis為主。Redis常用的高可用方案有哨兵模式和Cluster。使用Redis除了上面講的做共享session存儲(chǔ)之外，最大的應(yīng)用就是緩存常用數(shù)據(jù)。這兩大應(yīng)用建議生產(chǎn)環(huán)境中分集群部署。我們當(dāng)前或是未來的一個(gè)實(shí)際情況：由于目前正在做服務(wù)拆分，更多的服務(wù)和應(yīng)用實(shí)現(xiàn)了實(shí)現(xiàn)服務(wù)無狀態(tài)，所以存共享session的需求會(huì)越來越少。

關(guān)于非關(guān)系型數(shù)據(jù)庫(kù)，除了高可用、監(jiān)控之外平常工作中還面臨很大的一個(gè)工作就是分庫(kù)和分片，如何方便快速擴(kuò)展，這很有用。對(duì)于Redis的使用，個(gè)人建議在一開始規(guī)劃時(shí)就考慮好擴(kuò)展問題避免以后的遷移或是在線擴(kuò)展等。這跟關(guān)系型數(shù)據(jù)庫(kù)的分庫(kù)分表有異曲同工之妙。Redis的分庫(kù)分片和擴(kuò)展對(duì)系統(tǒng)架構(gòu)來說很重要，尤其業(yè)務(wù)的高速發(fā)展期，越來越多的數(shù)據(jù)緩存在Redis中，如果沒有做好規(guī)劃，將會(huì)很被動(dòng)。具體Redis架構(gòu)，結(jié)合我們實(shí)際生產(chǎn)環(huán)境，在以后的文章中在跟大家詳細(xì)描述和分享。

除Redis之外，很多生產(chǎn)環(huán)境也會(huì)有MongoDB、HBASE等常見的NoSQL數(shù)據(jù)庫(kù)，不同的數(shù)據(jù)庫(kù)有不同的應(yīng)用場(chǎng)景，大家在做系統(tǒng)架構(gòu)時(shí)，根據(jù)實(shí)際情況進(jìn)行審核。

分割架構(gòu)主要是指業(yè)務(wù)拆分。根據(jù)具體的業(yè)務(wù)內(nèi)容和高內(nèi)聚、低耦合的原則，將復(fù)雜的業(yè)務(wù)進(jìn)行模塊化的劃分，單獨(dú)部署，接口化操作數(shù)據(jù)，實(shí)現(xiàn)業(yè)務(wù)的橫向分割。細(xì)粒度分割復(fù)雜的業(yè)務(wù)系統(tǒng)，可以降低業(yè)務(wù)系統(tǒng)的復(fù)雜度，按照模塊進(jìn)行開發(fā)和維護(hù)，降低整體系統(tǒng)的宕機(jī)時(shí)間。

一般來說，分割架構(gòu)需要開發(fā)、業(yè)務(wù)為主，運(yùn)維、測(cè)試為輔，架構(gòu)師統(tǒng)一主導(dǎo)進(jìn)行，共同進(jìn)行系統(tǒng)劃分工作。

業(yè)務(wù)劃分因公司的業(yè)務(wù)不同而異，支持服務(wù)化的開源技術(shù)框架也很多，常見的有Dubbo、Dubbox以及比較新的Spring Boot、Spring Cloud等。本人有幸在一家公司以DBA的身份參與到公司的系統(tǒng)重構(gòu)中去，雖然對(duì)服務(wù)化的技術(shù)框架不是很熟悉，但這個(gè)系統(tǒng)劃分及服務(wù)化過程，可以結(jié)合之前的經(jīng)驗(yàn)給大家做一個(gè)簡(jiǎn)單的分享，希望讀者能夠有所收獲。

1. 首先是不可避免。一般系統(tǒng)初期，公司為了業(yè)務(wù)盡快上線，大多將業(yè)務(wù)功能堆加在一起。隨著公司業(yè)務(wù)發(fā)展，系統(tǒng)拆分、系統(tǒng)重構(gòu)不可避免。

2. 成本頗高。系統(tǒng)拆分，系統(tǒng)重構(gòu)一般帶來的IT高成本，風(fēng)險(xiǎn)相對(duì)也較高。該工作一般適合于系統(tǒng)平穩(wěn)發(fā)展時(shí)進(jìn)行，或是單獨(dú)的團(tuán)隊(duì)進(jìn)行并行進(jìn)行。

3. 做好計(jì)劃，持久作戰(zhàn)。系統(tǒng)拆分、系統(tǒng)重構(gòu)時(shí)間相對(duì)較長(zhǎng)，一定要提前做好計(jì)劃，避免出現(xiàn)項(xiàng)目持續(xù)時(shí)間久，項(xiàng)目疲憊的情況。

4. 業(yè)務(wù)拆分要科學(xué)。業(yè)務(wù)的拆分一定要經(jīng)過架構(gòu)、開發(fā)、業(yè)務(wù)、DBA等部門共同討論，共同制定出既適合當(dāng)下，又能夠適合未來一段時(shí)間內(nèi)(2~3年)的業(yè)務(wù)發(fā)展。

5. 業(yè)務(wù)拆分要徹底。業(yè)務(wù)拆分不應(yīng)該只是系統(tǒng)或是程序工程的拆分，還應(yīng)該包括數(shù)據(jù)庫(kù)的拆分。我們之前就是拆分了程序，未徹底拆分?jǐn)?shù)據(jù)庫(kù)，導(dǎo)致程序?qū)崿F(xiàn)服務(wù)化后，后端數(shù)據(jù)庫(kù)的壓力不斷增大。采用數(shù)據(jù)庫(kù)中間件實(shí)現(xiàn)后端數(shù)據(jù)庫(kù)的分庫(kù)，但因?yàn)橹虚g件的一些限制，開發(fā)又不得不修改一些跨庫(kù)查詢和跨庫(kù)事務(wù)的情況。所以業(yè)務(wù)拆分一定要徹底，不管是項(xiàng)目工程，還是數(shù)據(jù)庫(kù)。

6. 拆分取舍有道。拆分取舍有道，既不能將系統(tǒng)拆分得過細(xì)，這樣會(huì)有很多跨系統(tǒng)的事務(wù)或查詢的情況；但也不能拆分得太粗，隨著時(shí)間增長(zhǎng)，有面臨著被拆的問題。所以系統(tǒng)的拆分要結(jié)合實(shí)際情況進(jìn)行，既要避免技術(shù)潔癖，也要避免粒度太粗。

以上幾條，是我們之前在做系統(tǒng)業(yè)務(wù)拆分和系統(tǒng)重構(gòu)時(shí)候的一些經(jīng)驗(yàn)，至于重構(gòu)的服務(wù)化架構(gòu)，因?yàn)楸救酥皼]有參與太深，一知半解，這里不便多言。不過目前我們也在以架構(gòu)的身份進(jìn)行系統(tǒng)拆分和服務(wù)化的探索，待逐漸完成后，整體的架構(gòu)會(huì)拿出來跟大家分享，目前我們采用的技術(shù)框架主要以Spring Cloud為主。

系統(tǒng)保障主要圍繞基礎(chǔ)運(yùn)維數(shù)據(jù)(CMDB)，以監(jiān)控、災(zāi)備、安全三大體系保駕護(hù)航，運(yùn)維自動(dòng)化作為馬達(dá)，保障系統(tǒng)和服務(wù)的安全、穩(wěn)定、高效的運(yùn)行。關(guān)于運(yùn)維管理體系，運(yùn)維基礎(chǔ)數(shù)據(jù)，災(zāi)備和安全的介紹，我在之前的文章都有介紹，歡迎指正。

監(jiān)控這塊一直沒有下定決心來寫，因?yàn)槟壳拔覀儽O(jiān)控面臨著監(jiān)控閥值設(shè)置不夠精準(zhǔn)導(dǎo)致誤報(bào)過多引發(fā)告警疲勞，監(jiān)控因素關(guān)聯(lián)關(guān)系未完全梳理清楚導(dǎo)致一個(gè)問題引發(fā)告警風(fēng)暴的問題。告警疲勞和告警風(fēng)暴是我們目前監(jiān)控面臨的兩大難題。待解決完成后，會(huì)進(jìn)行監(jiān)控體系的分享。

關(guān)于告警風(fēng)暴目前我們得到一定程度的環(huán)境，主要依賴告警分級(jí)和CMDB中的依賴關(guān)系來做的，自動(dòng)判斷故障根源進(jìn)行告警，多個(gè)告警引發(fā)候，有限告出根本故障點(diǎn)。目前有一定成效，但還需進(jìn)一步改進(jìn)。網(wǎng)上也有一下使用機(jī)器學(xué)習(xí)的方式來準(zhǔn)確設(shè)置或是動(dòng)態(tài)設(shè)置告警閥值的情況，也值得我們進(jìn)一步學(xué)習(xí)。

寫到這里，關(guān)于系統(tǒng)架構(gòu)這一塊基本結(jié)束。關(guān)于系統(tǒng)架構(gòu)個(gè)人建議主要分兩大塊，一個(gè)是系統(tǒng)架構(gòu)，一個(gè)是系統(tǒng)運(yùn)維。首先通過系統(tǒng)架構(gòu)設(shè)計(jì)出穩(wěn)定、高可用、高性能且易擴(kuò)展的系統(tǒng)來，然后通過系統(tǒng)運(yùn)維來保障。個(gè)人感覺這應(yīng)該是做系統(tǒng)架構(gòu)應(yīng)該著重考慮的地方。（這考慮可能跟我目前的工作職責(zé)有關(guān)系）

關(guān)于技術(shù)平臺(tái)和技術(shù)生態(tài)圈，這是一個(gè)很大的話題，跟個(gè)人的職業(yè)規(guī)劃也有一定的關(guān)系，我這里直說一點(diǎn)，就是對(duì)于自己所在的公司所用到的技術(shù)棧，每一種技術(shù)適用的場(chǎng)景以及優(yōu)缺點(diǎn)要了然于胸，尤其是對(duì)于架構(gòu)師。對(duì)于系統(tǒng)架構(gòu)的技術(shù)生態(tài)圈，這里以StuQ中各種技能圖譜來表述技術(shù)生態(tài)圈。常見的IT技能圖譜可以參考：https://github.com/TeamStuQ/skill-map 每一種腦圖代表了這一IT領(lǐng)域可能用到的技術(shù)知識(shí)，各位可以在此基礎(chǔ)上，結(jié)合自身情況，建立起自己的技術(shù)體系，并且在日常工作和學(xué)習(xí)中不斷得完善。

最后，圍繞系統(tǒng)架構(gòu)，再重復(fù)一句經(jīng)久不變的哲理：系統(tǒng)架構(gòu)不是一開始就架構(gòu)出來的，是通過不斷的演變而來的。做系統(tǒng)架構(gòu)一定要符合公司的實(shí)際情況，采用最熟悉的技術(shù)進(jìn)行架構(gòu)，同時(shí)要做好技術(shù)儲(chǔ)備，以便應(yīng)對(duì)瞬息萬變的技術(shù)革新。