講師介紹
戰(zhàn)學(xué)超
青島航空運維經(jīng)理
高級架構(gòu)師
曾任職于NEC軟件、海爾B2B平臺巨商匯，負(fù)責(zé)企業(yè)數(shù)據(jù)平臺構(gòu)建、B2B電商平臺數(shù)管理與搭建、企業(yè)運維管理平臺搭建；
擁有豐富DBA、系統(tǒng)運維架構(gòu)經(jīng)驗，熟悉運維管理、數(shù)據(jù)庫架構(gòu)、數(shù)據(jù)平臺搭建、虛擬化、私有云部署、自動化運維等。
寫在最前面
上次參加DBAplus舉辦的敏捷運維峰會時，一個兄弟的提問一直縈繞耳邊，由于時間有限沒有進行深入的交流，甚是遺憾。那個問題是：你們公司的IT系統(tǒng)架構(gòu)是怎樣的？又如何具體落地？采用了哪些開源或是商業(yè)的技術(shù)？
其實之前也寫過或是做過一些關(guān)于系統(tǒng)架構(gòu)的分享，或多或少的個人或其它限制，總覺得未能盡興，留有遺憾。因此經(jīng)過最近一個多月的總結(jié)和梳理，在這寫出來跟大家做一個分享，這也是對我個人技術(shù)生涯中系統(tǒng)架構(gòu)部分做一個階段性的總結(jié)，以便往后能夠更好地投入到接下來的云平臺架構(gòu)和機器學(xué)習(xí)，以及企業(yè)如何降低IT成本的深入研究中。
系統(tǒng)架構(gòu)是一個比較大的話題，以一個什么樣的思路或是方法進行切入很重要。系統(tǒng)架構(gòu)的脈絡(luò)可以讓我們很好地了解系統(tǒng)架構(gòu)的整體概況，也可以幫助我們建立有效的個人架構(gòu)知識體系。
本文從系統(tǒng)訪問鏈路為切入點，圍繞訪問鏈路的方方面面，包括基礎(chǔ)設(shè)施、分層架構(gòu)、分割架構(gòu)、系統(tǒng)保障、技術(shù)平臺生態(tài)圈等幾個方面進行展開，力求展現(xiàn)出一套相對比較完整的系統(tǒng)架構(gòu)體系，同時結(jié)合自身經(jīng)驗，介紹具體落地的方案和技術(shù)，希望能夠給讀者帶來一些收獲。
一、訪問鏈路
訪問鏈路表示從用戶訪問請求到最終生產(chǎn)服務(wù)器響應(yīng)，再到反饋給用戶請求的結(jié)果信息這一過程。不管是互聯(lián)網(wǎng)企業(yè)還是傳統(tǒng)企業(yè)，在系統(tǒng)架構(gòu)中一定要明確自己的訪問鏈路，這對系統(tǒng)優(yōu)化、系統(tǒng)排故、鏈路監(jiān)控等至關(guān)重要。
該圖是一家中小型公司的訪問鏈路圖，系統(tǒng)主要分為兩大塊：一是對外提供服務(wù)的電商平臺；另外一塊是企業(yè)內(nèi)部的核心生產(chǎn)系統(tǒng)和企業(yè)信息系統(tǒng)等。灰色部分表示正在建立或是規(guī)劃建立的部分。
該公司訪問鏈路主要有兩條：一條是外部客戶的外網(wǎng)訪問鏈路，另一條是內(nèi)部員工的內(nèi)網(wǎng)訪問鏈路。該公司是有自建的數(shù)據(jù)中心機房，可能現(xiàn)在很多公司都將對外訪問的系統(tǒng)放到租賃的IDC機房或是云服務(wù)器，其實都是一樣的。根據(jù)系統(tǒng)特點劃分內(nèi)外網(wǎng)訪問鏈路，可以節(jié)省網(wǎng)絡(luò)流量，也可以增強內(nèi)部系統(tǒng)的安全性等。
1、外網(wǎng)訪問鏈路
公網(wǎng)DNS->GSLB->CDN->防火墻/IPS->WAF->軟負(fù)載->生產(chǎn)服務(wù)器。
外網(wǎng)訪問鏈路從公網(wǎng)DNS開始，按照用戶訪問請求的全鏈路，完整的DNS解析過程應(yīng)該是這樣的：
用戶本地Host->用戶DNS緩存->LocalServer(本地DNS電信、聯(lián)通等)->Root服務(wù)器->權(quán)威服務(wù)器->LocalServer->用戶得到DNS解析結(jié)果->請求等。
2 、內(nèi)外訪問鏈路
內(nèi)外DNS->軟負(fù)載->生產(chǎn)服務(wù)器
圖中數(shù)據(jù)中心B暫時為備份機房，提供實時同步和延遲同步兩種備份方式。有一些大型集團公司可能多個數(shù)據(jù)中心同時在用，這個時候有的是采用專線的方式，也有的是采用服務(wù)器直接部署在云中，這個需要根據(jù)專線和云服務(wù)的成本(其實云服務(wù)的價格不一定低)，以及數(shù)據(jù)的保密性等進行選擇。
其實上面的訪問鏈路也有一定的潛在問題：
當(dāng)外網(wǎng)訪問量大的時候，硬件防火墻和WAF將會成為一定的瓶頸，需要進行優(yōu)化、限流或是直接摘除，轉(zhuǎn)為在軟防火墻或是應(yīng)用WAF進行分布式防護；還有一點就是對防火墻和WAF的策略要求較高，要避免漏殺或是誤殺的情況出現(xiàn)。
內(nèi)網(wǎng)的安全性問題。內(nèi)網(wǎng)的DNS和軟負(fù)載沒有有效地提供內(nèi)網(wǎng)對生產(chǎn)服務(wù)器的保護。這個需要從兩方面加強：
一是對辦公區(qū)PC機的防病毒客戶端安裝并及時更新策略；
二是在軟負(fù)載層增加安全策略，一般兩種方式：
調(diào)整WAF的策略或是網(wǎng)絡(luò)位置，對內(nèi)網(wǎng)進行安全防護；
直接購買新的WAF放在內(nèi)網(wǎng)區(qū)，但這會增加成本，同時讓訪問鏈路更復(fù)雜。
其實可以在內(nèi)網(wǎng)部署開源WAF或是結(jié)合Nginx做安全防護，這里推薦一款Nginx+Lua做的安全防護模塊：https：//github.com/loveshell/ngx_lua_waf。
訪問鏈路要盡可能的高效、安全、簡單。每一個系統(tǒng)架構(gòu)師一定要對自己企業(yè)或是產(chǎn)品的訪問鏈路了然于胸，在系統(tǒng)使用者反饋故障或是性能問題時，深入分析鏈路中的每一個元素找到故障點或是性能瓶頸，進行處理或優(yōu)化。
二、基礎(chǔ)設(shè)施
基礎(chǔ)設(shè)置主要包括網(wǎng)絡(luò)、基礎(chǔ)硬件/基礎(chǔ)軟件、數(shù)據(jù)中心這三部分，以及圍繞基礎(chǔ)設(shè)施做的軟件定義網(wǎng)絡(luò)(SDN)、虛擬化容器化、云數(shù)據(jù)中心等，力求做到上層IT架構(gòu)可以不用去過多考慮基礎(chǔ)設(shè)施。
1、網(wǎng)絡(luò)
網(wǎng)絡(luò)方面包括：網(wǎng)絡(luò)接入、網(wǎng)絡(luò)規(guī)劃、網(wǎng)絡(luò)實施、拓?fù)浣Y(jié)構(gòu)、流量管理、安全監(jiān)控等幾個方面。
首先是網(wǎng)絡(luò)接入，由于中國特殊的網(wǎng)絡(luò)環(huán)境，對于需要對外提供服務(wù)的系統(tǒng)一般都需要考慮多網(wǎng)絡(luò)供應(yīng)商的接入，包括移動、聯(lián)通、電信等。不同的網(wǎng)絡(luò)接入對外提供服務(wù)時，會依賴智能DNS等手段，實現(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ū)、測試區(qū)、生產(chǎn)區(qū)等幾個區(qū)域，不同區(qū)域之間通過防火墻等安全設(shè)備進行有效隔離。另外，廣義上的網(wǎng)絡(luò)規(guī)劃還包括數(shù)據(jù)流量及約束條件分析、網(wǎng)絡(luò)選型、拓?fù)浣Y(jié)構(gòu)設(shè)計、網(wǎng)絡(luò)安全、建設(shè)方案等幾個方面。
接下來是網(wǎng)絡(luò)實施。根據(jù)網(wǎng)絡(luò)規(guī)劃和網(wǎng)絡(luò)建設(shè)方案，進行網(wǎng)絡(luò)的部署和實施。
不管傳統(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ò)故障時，對于故障點、影響范圍等都可以通過網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)圖快速獲得。網(wǎng)絡(luò)拓?fù)湟獙崟r更新，時刻保持與真實網(wǎng)絡(luò)環(huán)境一致。
要對網(wǎng)絡(luò)的流量進行管理和實時監(jiān)控。根據(jù)網(wǎng)絡(luò)流量合理調(diào)整網(wǎng)絡(luò)帶寬等。整個網(wǎng)絡(luò)基礎(chǔ)設(shè)施中的網(wǎng)絡(luò)安全不可或缺。一般通過防火墻、IPS/IDS等軟硬件設(shè)備進行網(wǎng)絡(luò)安全的防護或是監(jiān)控、分析和屏蔽絕大部分的網(wǎng)絡(luò)攻擊行為。
網(wǎng)絡(luò)作為重要的基礎(chǔ)設(shè)施之一，要根據(jù)安全策略和實際業(yè)務(wù)量、業(yè)務(wù)情況等幾個方面進行合理的規(guī)劃和實施，完善網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，通過監(jiān)控和流量管理等手段，實時了解網(wǎng)絡(luò)以及網(wǎng)絡(luò)設(shè)備的運行情況，當(dāng)出現(xiàn)故障或是性能問題時，能夠快速發(fā)現(xiàn)故障源或是性能瓶頸點，以便有重點地進行排故、調(diào)優(yōu)。
2、基礎(chǔ)軟硬件
1基礎(chǔ)硬件
基礎(chǔ)硬件包括服務(wù)器、內(nèi)存、CPU、存儲、電源、防火墻、交換機、路由器、集線器等服務(wù)器、網(wǎng)絡(luò)及周邊硬件設(shè)施。
基礎(chǔ)硬件及其備件一般有雙份或是多份，避免硬件單點故障，也就是說一般企業(yè)要有自己的備件庫，對服務(wù)器、存儲、網(wǎng)絡(luò)設(shè)備等硬件進行備份，當(dāng)出現(xiàn)問題時，可以及時更換。備件庫的信息也要跟隨CMDB一起入庫管理。
2基礎(chǔ)軟件
基礎(chǔ)軟件包括操作系統(tǒng)ISO文件、數(shù)據(jù)庫安裝文件、應(yīng)用服務(wù)器安裝文件等基礎(chǔ)軟件，也包括辦公用的Office、瀏覽器等軟件。
根據(jù)個人經(jīng)驗，推薦一種相對比較好且易于部署管理的基礎(chǔ)軟件管理方式。根據(jù)軟件的性質(zhì)進行如下分類，請大家參考：
將上述軟件進行統(tǒng)一整理，部署到一臺Nginx服務(wù)器上作為靜態(tài)資源，并建立二級域名如soft.xxx.com。這樣局域網(wǎng)內(nèi)用戶在使用軟件時，直接通過訪問soft.xxx.com進行下載安裝即可。這樣做的一個好處是可以管理公司的基礎(chǔ)軟件，并且規(guī)范版本號，避免多種版本的存在。以下是使用Nginx搭建的一個軟件庫，僅用來說明。
3、數(shù)據(jù)中心
如今越來越多的公司采用云服務(wù)進行系統(tǒng)部署，省去了自建數(shù)據(jù)中心機房等比較繁雜的事情。短時間來看對企業(yè)是非常有利的，因為快且方便，可以適應(yīng)企業(yè)的快速發(fā)展。但隨著企業(yè)的規(guī)模不斷變大，大量的使用云服務(wù)，IT成本會越來越高，自建數(shù)據(jù)中心可能會逐漸成為一種比較經(jīng)濟的方式。自建數(shù)據(jù)中心和云服務(wù)本身是沒有矛盾且可以科學(xué)組合、相輔相成的。企業(yè)哪一階段哪一種方式最優(yōu)，要根據(jù)企業(yè)的業(yè)務(wù)實際情況和進行科學(xué)的計算后才可判斷哪種方式最經(jīng)濟。（注：這里的云服務(wù)是指的公有云）
當(dāng)然也有一些企業(yè)因為自身數(shù)據(jù)的保密性比較高，業(yè)務(wù)相對比較特殊，所以一開始就自建數(shù)據(jù)中心機房。
一般而言，數(shù)據(jù)中心機房的建設(shè)要按照國家標(biāo)準(zhǔn)和行業(yè)標(biāo)準(zhǔn)進行建立，這都有比較明確的標(biāo)準(zhǔn)規(guī)范，這里大概總結(jié)了一下：
數(shù)據(jù)中心的建立有自建或是委托專業(yè)數(shù)據(jù)中心設(shè)計公司來進行。一般公司可以通過第二種方式，通過與專業(yè)的數(shù)據(jù)中心設(shè)計公司合作，建設(shè)安全、可靠、伸縮性強以及節(jié)能環(huán)保的數(shù)據(jù)中心。
另外數(shù)據(jù)中心的建立、驗收、等級、災(zāi)備等都有著明確的國家規(guī)范和行業(yè)行規(guī)，大家在規(guī)劃或建立的時候，一定在合規(guī)的底線上，進行優(yōu)化設(shè)計，常用的數(shù)據(jù)中心參考文檔有：
《數(shù)據(jù)中心建設(shè)與管理指南》
《GB50174-2017 數(shù)據(jù)中心設(shè)計規(guī)范》
《GB50462-2015數(shù)據(jù)中心基礎(chǔ)設(shè)施施工及驗收規(guī)范》
《GBT22239—2008信息系統(tǒng)安全等級保護基本要求》
TIA-942《數(shù)據(jù)中心電信基礎(chǔ)設(shè)施標(biāo)準(zhǔn)》（中文版）等等
【提示】由于文檔打包較大，感興趣的同學(xué)可點擊鏈接https：//pan.baidu.com/s/1eR7RyPO或點擊文末【鏈接】進行下載。
4、基礎(chǔ)設(shè)施管理與優(yōu)化
1基礎(chǔ)設(shè)施管理
對于基礎(chǔ)設(shè)施的管理，需要CMDB結(jié)合資產(chǎn)管理系統(tǒng)對基礎(chǔ)設(shè)施進行統(tǒng)一錄入、上架、管理、下架、報廢等全生命周期進行管理。通過IT系統(tǒng)進行基礎(chǔ)設(shè)施管理，可以提高管理效率，降低故障率等。CMDB作為運維管理體系中的基礎(chǔ)一環(huán)，至關(guān)重要。一些中小型企業(yè)可能暫時沒有能力建立或是購買CMDB，這時可以通過采用構(gòu)建開源CMDB或是直接用最簡單有效的Excel進行管理，總之，不管哪種方式，基礎(chǔ)設(shè)施的集中管理不可或缺。CMDB中的數(shù)據(jù)一定要與實際環(huán)境實時對應(yīng)，確保準(zhǔn)確無延遲。
2基礎(chǔ)設(shè)施優(yōu)化
為了更高效地利用基礎(chǔ)設(shè)施的資源，虛擬化、容器化正在不同的公司中逐漸實行。本文以一些中小公司(包括我們公司)常見的基礎(chǔ)架構(gòu)演變路線進行介紹。
很多公司遵循著多臺物理機到虛擬化再到容器化或是虛擬化容器化并存，最終實現(xiàn)到云服務(wù)的這一演變過程。首先是初始階段的多臺物理機部署服務(wù)，資源利用率比較粗，相對比較浪費，于是通過虛擬化提高資源的利用率和管理效率。我所經(jīng)歷的一家公司正處在虛擬化階段，通過購買fc-san存儲，構(gòu)建虛擬化集群，實現(xiàn)服務(wù)器的高效利用、集群高可用并且便于備份。但在虛擬化的過程中，也經(jīng)歷著虛擬化的以下問題：
搭建成本太高，需要購買專業(yè)存儲以及網(wǎng)絡(luò)設(shè)備等。(當(dāng)然也可以直接在物理機上部署exsi，但是高可用不是很好實現(xiàn)，例如VMare自帶的高可用組件)
虛擬機備份比較笨重，需要結(jié)合BE或是自帶的備份工具，耗時較長，備份粒度不夠細(xì)。
服務(wù)宕機后虛擬機漂移時間相對較長，大概5分鐘左右(跟硬件和技術(shù)有關(guān)系，有的公司可能時間很短)。漂移后虛擬機自動重啟，如果部署在虛擬機上的服務(wù)未開機自啟，將比較頭疼。
部署虛擬機時間較長，雖然采用Cobbler等方式實現(xiàn)自動安裝，但部署一套虛擬機，大概在10~20分鐘左右。
以上四點是我們在做虛擬化時，面臨著比較突出的問題，當(dāng)然這也許跟我們虛擬化工程師的技術(shù)水平有一定的關(guān)系。為了解決虛擬化的問題，提高運維效率，我們現(xiàn)在正進行虛擬化+容器化并存的架構(gòu)改進和優(yōu)化，當(dāng)前架構(gòu)如下：
注：基礎(chǔ)設(shè)施架構(gòu)這一塊，目前我們面臨這1~2年后的數(shù)據(jù)中心遷移以及新數(shù)據(jù)中心規(guī)劃，后續(xù)我們的規(guī)范方案和遷移方案定稿后，會繼續(xù)跟大家分享、探討。
可以看出，當(dāng)前基礎(chǔ)資源架構(gòu)是虛擬化和容器化并存，二者相互隔離又在應(yīng)用層面相互聯(lián)系，共同組成集群，為上層應(yīng)用提供服務(wù)。
相比虛擬化以及物理機，單純?nèi)萜骰幸韵聨讉�難點不太好實現(xiàn)：
Windows服務(wù)器在Docker容器不能或是不容易部署。(據(jù)稱Docker已經(jīng)開始支持win，但未研究測試)
Oracle數(shù)據(jù)庫在Docker部署缺少大規(guī)模生產(chǎn)經(jīng)驗，不敢貿(mào)然直接在容器部署Oracle服務(wù)器。尤其是RAC+DG這樣的高可用集群，在容器部署也不太現(xiàn)實。
就目前我們技術(shù)現(xiàn)狀來說，單純?nèi)萜骰幸欢ǖ娘L(fēng)險，需要一個摸索階段，雖然有很多成熟的經(jīng)驗可以借鑒，但畢竟適合自己的架構(gòu)才是最好的。
基于容器的便利性以及高效快捷，未來會逐漸以容器化為主，但數(shù)據(jù)庫和Window服務(wù)相關(guān)的部署以虛擬化為主，二者互補，為以后實現(xiàn)云服務(wù)提供基礎(chǔ)鋪墊。
容器化管理計劃以K8s為主進行編排和調(diào)度，K8s目前正在技術(shù)調(diào)研和測試中，待成熟后會為大家繼續(xù)進行分享。當(dāng)然我們也面臨著是否需要采用OpenStack或是其它技術(shù)搭建IaaS基礎(chǔ)云平臺的糾結(jié)。
不管系統(tǒng)架構(gòu)還是基礎(chǔ)架構(gòu)，都是一個逐漸演化的過程，適合當(dāng)下業(yè)務(wù)架構(gòu)并且易伸縮的架構(gòu)才是最優(yōu)化的架構(gòu)。
三、分層架構(gòu)
1 、分層架構(gòu)概述
系統(tǒng)在做分層架構(gòu)候，一般情況下主要包括：接入層、應(yīng)用層、公共服務(wù)層、數(shù)據(jù)存儲層等幾個層次，其中接入層還包括DNS轉(zhuǎn)發(fā)、CDN、負(fù)載均衡層、靜態(tài)資源層等。有CDN的公司會直接將靜態(tài)資源放在CDN層中。
系統(tǒng)分層架構(gòu)圖大概如下：
2、負(fù)載均衡和反向代理
負(fù)載均衡分為軟負(fù)載和硬負(fù)載。其中硬負(fù)載包括有F5、A10等不同品牌的硬件負(fù)載均衡器，軟負(fù)載包括LVS、Nginx、HAproxy等開源軟負(fù)載均衡軟件。硬負(fù)載相對比較貴，成本較高。中小企業(yè)可以選擇開源的軟負(fù)載實現(xiàn)負(fù)載均衡和反向代理，通過負(fù)載均衡提高系統(tǒng)的吞吐從而提高性能，反向代理增加內(nèi)部系統(tǒng)的安全性。負(fù)載均衡服務(wù)器一般是部署在DMZ區(qū)域與內(nèi)網(wǎng)通過防火墻進行端口映射，提高內(nèi)網(wǎng)服務(wù)器的安全。
軟負(fù)載的選擇上一般從LVS、Nginx、HAproxy三者中進行選擇或是組合選擇。其中LVS相比Nginx、HAproxy、LVS工作在網(wǎng)絡(luò)四層，僅做請求轉(zhuǎn)發(fā)，性能效率比較高。Nginx和HAproxy工作在網(wǎng)絡(luò)七層之上，較LVS性能差一些，但二者之間，并沒有特別大的差別。
使用負(fù)載均衡和反向代理一般要著重考慮以下三個問題：
高可用問題
負(fù)載策略
有狀態(tài)服務(wù)的session保存
（1）實現(xiàn)負(fù)載均衡服務(wù)器的高可用一般通過虛擬IP的方式，將虛擬IP通過防火墻與公網(wǎng)IP端口轉(zhuǎn)換，對外提供服務(wù)，常用的開源組件有keepalived。但在使用開源組件進行虛擬IP配置時，一般都要去積極主動地進行腦裂檢測和避免腦裂問題的產(chǎn)生。通常用檢測腦裂問題的辦法進行仲裁，通過多個節(jié)點進行仲裁選舉出問題節(jié)點，踢出集群，我們在做腦裂仲裁時除了其它節(jié)點選舉之外，還添加本節(jié)點的自動檢測，避免本節(jié)點故障假死的情況下，選舉不準(zhǔn)確。關(guān)于腦裂仲裁算法網(wǎng)上都有實現(xiàn)方法，大伙可以參照，結(jié)合實際情況進行改良。
（2）使用負(fù)載均衡和反向代理有一個比較重要的問題就是負(fù)載策略的選擇。以Nginx為例，常用的有Round-robin（輪循）、Weight-round-robin（帶權(quán)輪循）、Ip-hash（Ip哈希），其中HAproxy還支持動態(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)的，且未實現(xiàn)session共享，一般使用ip-hash的方式。
（3）對于有狀態(tài)的后端應(yīng)用，如果采用輪詢的策略會有問題。但是采用ip-hash的方式也會有一定的問題，首先是后端服務(wù)器的訪問負(fù)載不均衡，會有較大的偏差，其次是未實現(xiàn)真正的應(yīng)用高可用，當(dāng)連接到的后端服務(wù)器宕機，session丟失，需要重新進行業(yè)務(wù)登錄或操作等。解決這一問題一般常用的方法有三種：
應(yīng)用服務(wù)器共享session
cookie存session
session服務(wù)器存session
應(yīng)用服務(wù)器共享session，這個Tomcat是支持的，只需要配置即可，但對應(yīng)用的性能有比較大的影響，尤其是應(yīng)用節(jié)點比較多的情況；cookie存session是一個方法，但cookie的大小有限，不適合存較多的session；session服務(wù)器存session應(yīng)該算是最佳的辦法，例如使用Redis存共享session，很多公司在用，但也有一個缺點就是增加維護成本和運維復(fù)雜度，雖然這項技術(shù)實施起來會比較簡單。
3、業(yè)務(wù)應(yīng)用層
業(yè)務(wù)應(yīng)用層比較大的一塊是做服務(wù)化，這會在下面的分割架構(gòu)進行詳細(xì)說明。這里主要說明簡單的業(yè)務(wù)拆分和應(yīng)用集群的部署方式。
高內(nèi)聚、低耦合一直是軟件開發(fā)和系統(tǒng)運維所積極追求的。通過實現(xiàn)業(yè)務(wù)系統(tǒng)的高內(nèi)聚、低耦合，降低系統(tǒng)依賴，提高系統(tǒng)的可用性，降低故障率，業(yè)務(wù)拆分是解耦的重要利器之一。一般根據(jù)公司業(yè)務(wù)系統(tǒng)的特點和關(guān)聯(lián)進行拆分，對公共業(yè)務(wù)系統(tǒng)進行抽取形成公共業(yè)務(wù)應(yīng)用，對所有業(yè)務(wù)系統(tǒng)進行接口化服務(wù)。各個業(yè)務(wù)系統(tǒng)之間獨立部署，降低耦合度，減少了業(yè)務(wù)系統(tǒng)之間的依賴和影響，提高整個系統(tǒng)的利用率。
因為有前面的負(fù)載均衡和反向代理層，所有后端的應(yīng)用服務(wù)器可以橫向部署多臺，實現(xiàn)高可用也起到用戶訪問分流，增加吞吐、提高并發(fā)量。實際應(yīng)用部署中主要以Java應(yīng)用居多，且多部署在Tomcat中，以此為例，在應(yīng)用服務(wù)器部署時，主要考慮以下幾個問題或是建議：
統(tǒng)一JDK和Tomcat版本。這很重要，主要是為了方便管理，另外也方便做自動化運維部署。其中統(tǒng)一部署中的操作系統(tǒng)優(yōu)化、安全加固，Tomcat優(yōu)化、安全加固等都要做好，我們在做Tomcat自動部署的時候，采用的是根據(jù)系統(tǒng)配置自動優(yōu)化的方式和安全加固策略進行。另外就是自動備份和日志的自動切割，都在統(tǒng)一部署腳本中體現(xiàn)。這樣所有部署下來，安裝位置、部署方式等都是一致的，方便統(tǒng)一管理，統(tǒng)一備份和升級。
動態(tài)頁面靜態(tài)化。這個根據(jù)訪問量選擇系統(tǒng)進行，例如公司的B2C官網(wǎng)等可以采用靜態(tài)化的技術(shù)，提高頁面的訪問速度。
4、公共服務(wù)層
公共服務(wù)層將上層業(yè)務(wù)層公共用到的一些緩存、消息隊列、session、文件圖片、統(tǒng)一調(diào)度、定時任務(wù)等抽取出來，作為單獨的服務(wù)進行部署，為業(yè)務(wù)層提供緩存、消息隊列以及圖片等服務(wù)。
緩存主要是指的緩存數(shù)據(jù)。應(yīng)用服務(wù)器通過緩存服務(wù)器查詢常用數(shù)據(jù)，提高系統(tǒng)的查詢速度，對于高并發(fā)的寫，通過異步調(diào)用消息隊列，進行數(shù)據(jù)的臨時存儲，提高系統(tǒng)的并發(fā)量和系統(tǒng)效率。Session集群以及文件圖片服務(wù)器集群主要是為上層業(yè)務(wù)應(yīng)用提供統(tǒng)一的session存儲和圖片文件存儲的，避免系統(tǒng)的session失效和單點故障。
常用的數(shù)據(jù)緩存以及session存儲主要是Redis。Redis的集群部署方式在數(shù)據(jù)存儲層會詳細(xì)說明。
消息隊列的主要中間件有ActiveMQ和RabbitMQ等，二者都提供master-slave或是集群的部署方式。我所經(jīng)歷的公司中二者都有生產(chǎn)上的應(yīng)用。常用的還有ZeroMQ、Kafka，但ZeroMQ不能持久化存儲，因為并未在生產(chǎn)使用，所以不好多說。Kafka主要在搭建日志分析平臺時用到過。對于ActiveMQ和RabbitMQ，二者并沒有太大的區(qū)別，都在生產(chǎn)用過，也沒遇到太大問題。在技術(shù)選擇中，還是選擇開發(fā)和運維最熟悉的為好，再具體點，建議以開發(fā)最熟悉的為標(biāo)準(zhǔn)。
文件圖片服務(wù)器，如果公司的數(shù)據(jù)比較敏感且有較高的保密性，加上核心生產(chǎn)系統(tǒng)只能內(nèi)部使用的話，建議搭建內(nèi)部分布式文件服務(wù)器、圖片服務(wù)器，我所經(jīng)歷的公司有使用FastDFS進行構(gòu)建分布式集群文件服務(wù)器的，目前比較火的分布式存儲主要是Ceph吧。如果對外提供服務(wù)，建議采用購買云服務(wù)，如阿里云的OSS等，方便運維管理，而且云服務(wù)自身的特性，也比較容易增加文件或圖片的加載速度。
統(tǒng)一調(diào)度、統(tǒng)一任務(wù)平臺，我們使用淘寶的TBSchedule，也有一部分使用Spring自帶的定時任務(wù)，目前正在做整合。就現(xiàn)在來看，可以滿足我們的定時任務(wù)和統(tǒng)一調(diào)度的需求。
公共服務(wù)層的架構(gòu)和部署一般來說都提供了主從和集群兩種高可用方式，并且都實現(xiàn)分布式部署。由于公共服務(wù)的重要性，所有業(yè)務(wù)都在調(diào)用，所以在實際生產(chǎn)部署的時候，一定要采用高可用的方式進行部署，并且要有可伸縮性和可擴展性。結(jié)合我們公司實際情況，在進行公共服務(wù)部署時，除了采用主從或是Cluster的方式進行部署，還增加了一鍵擴展的腳本，實現(xiàn)對集群中服務(wù)器的快速擴展。分布式擴展方式中的常用算法主要是一致性hash的方式，網(wǎng)上資料很多，這里不在一一贅述。
5、數(shù)據(jù)存儲層
數(shù)據(jù)存儲層主要分為關(guān)系型數(shù)據(jù)庫和NoSQL數(shù)據(jù)庫。主要從高可用集群包括負(fù)載均衡、讀寫分離、分庫分表等幾個方面，結(jié)合自身實際應(yīng)用經(jīng)驗進行分析。
1關(guān)系型數(shù)據(jù)庫
目前用得比較多的數(shù)據(jù)庫主要Oracle和MySQL兩種，我之前所經(jīng)歷的生產(chǎn)系統(tǒng)，做如下架構(gòu)，請參考：
（1）Oracle
首先是Oracle數(shù)據(jù)庫，為了避免單點故障，一般數(shù)據(jù)庫都進行集群部署，一方面實現(xiàn)高可用，另一方面實現(xiàn)負(fù)載均衡提高業(yè)務(wù)數(shù)據(jù)處理能力等。
Oracle常用的比較經(jīng)典的高可用方案主要是RAC+DataGuard，其中RAC負(fù)責(zé)負(fù)載均衡，對應(yīng)用的數(shù)據(jù)庫請求分布在不同的節(jié)點進行。DataGuard作為RAC的Standby，平常以readonly模式打開，為應(yīng)用提供讀的服務(wù)，實現(xiàn)讀寫分離的功能。
Oracle整體的集群架構(gòu)成本較高，除了專用的license，還需共享存儲等，且搭建比較復(fù)雜，運維成本較高。
很多人感覺RAC并不是Oracle高可用架構(gòu)的原因可能有以下場景：當(dāng)節(jié)點負(fù)載很高，壓力很大的時候，如果一個節(jié)點突然宕掉，相應(yīng)該節(jié)點的請求會飄到另一個節(jié)點上，另一個節(jié)點也很快會因為負(fù)載過高而宕機，進而整個集群不可用。
關(guān)于Oracle分庫分表。平常用得比較多的是Oracle的分表，將一些大表通過hash或日期等方式拆分成多個表，實現(xiàn)大表數(shù)據(jù)分散化，提高大表的性能。但對于Oracle的分庫，本人并沒有找到好的方式或是中間件，用的比較多的主要是DBLINK+Synonym的方式，相比性能有不小的下降。不知大家是否有關(guān)于Oracle分布更好的方案或是中間件，可留言一起探討。
（2）MySQL
MySQL的高可用架構(gòu)相對會更靈活一些，成本會較低。目前生產(chǎn)MySQL高可用架構(gòu)主要以主從同步、主主同步+Keepalived、MHA等為主。關(guān)于MHA，不管是楊建榮老師還是賀春旸老師都做過深入的解析和結(jié)合自編腳本做了一些改進，生產(chǎn)系統(tǒng)使用MHA，除了了解MHA的原理以及管理腳本，二位老師的解析和自編腳本，推薦大家做深入研究。
除了基于主從復(fù)制的高可用方案，不同的MySQL分支也提供了相應(yīng)的Cluster的服務(wù)，我們生產(chǎn)中并未使用MySQL的Cluster，所以不做過多介紹。
對于MySQL的分庫分表、讀寫分離等功能的實現(xiàn)，我們更多的是依賴于MySQL中間件。常用的MySQL中間件也非常多。
上圖摘自14年8月份在做分庫分表技術(shù)調(diào)研時在網(wǎng)上找的一個圖。截止到目前，我經(jīng)歷過生產(chǎn)使用較多的分庫分表和讀寫分離中間件的主要有Maxscale(實現(xiàn)讀寫分離)，Spider(分庫分表)，OneProxy以及MyCat。下面是之前我們電商平臺使用MyCat實現(xiàn)讀寫分離和分庫分表的架構(gòu)，希望能夠給各位帶來一些收獲：
該架構(gòu)分為四個大的數(shù)據(jù)庫集群：交易平臺、會員中心、金融平臺、物流平臺，每個集群內(nèi)部讀寫分離。四個集群之上采用OneProxy做數(shù)據(jù)庫路由，實現(xiàn)對開發(fā)來說后臺只是一個數(shù)據(jù)庫。
采用數(shù)據(jù)庫中間件，或多或少的都有一些限制，例如跨庫查詢、跨庫事務(wù)等，各位在進行改造的時候，一定要結(jié)合開發(fā)、測試，共同進行分庫分表后的測試，確保無誤。關(guān)于讀寫分離和分庫分表，這里將個人的感悟分享一下：
關(guān)于MySQL讀寫分離
讀寫分離通過分解數(shù)據(jù)庫讀寫操作，減緩寫的壓力。尤其是在未實現(xiàn)分庫的情況下，采用maste-slave模式的master節(jié)點面臨著巨大的讀寫壓力。采用讀寫分離的好處不言而喻，但也有苦惱。假如讀寫落在的庫上數(shù)據(jù)有延遲導(dǎo)致不一致，也是個很痛苦的事情。
提供讀寫分離的中間件也很多，Maxscale首薦，Amoeba比較經(jīng)典，歲數(shù)也比較大，另外下面的MySQL分庫分表的中間件也大多支持讀寫分離。對于讀寫分離的訴求一般都是寫庫壓力大。對于這種情況，3種建議方式：
數(shù)據(jù)庫之上添加消息隊列，減輕直接寫數(shù)據(jù)庫的壓力；
使用緩存服務(wù)器例如Redis，將常用數(shù)據(jù)緩存在緩存服務(wù)器中；
讀寫分離，同時加強主從同步速度，盡量避免屬于延遲的情況。
1~2步需要開發(fā)的同學(xué)參與進來由架構(gòu)師主導(dǎo)完成，進行這3步的同時還要不斷優(yōu)化慢查詢。
關(guān)于MySQL分庫分表
首先強烈建議業(yè)務(wù)層面拆分，微服務(wù)的同時數(shù)據(jù)庫也完成拆分，通過開發(fā)手段避免跨庫查詢和跨庫事務(wù)。減少使用數(shù)據(jù)庫中間件實現(xiàn)MySQL的分庫操作，當(dāng)然單表過大是需要DBA介入進行分表優(yōu)化的。
分庫分表常用的中間件也較多：MariaDB的Spider、OneProxy、360的Atlas、MyCat、Cobar等。
Spider
https：//mariadb.com/kb/en/library/spider-storage-engine-overview/
OneProxy
http：//www.onexsoft.com/proxy.html
Atlas：目前應(yīng)該已經(jīng)停更了。
https：//github.com/Qihoo360/Atlas/blob/master/README_ZH.md
MyCat：功能比較全，而且比較火。
http：//www.mycat.io/ mycat
Cobar：目前也已經(jīng)停更，記得MyCat早期就是繼續(xù)Cobar而逐漸演化的
https：//github.com/alibaba/cobar？spm=0.0.0.0.arolKs
PS：阿里關(guān)于數(shù)據(jù)庫開源了很多不錯的產(chǎn)品
https：//yq.aliyun.com/opensource
大家可以看出，對于讀寫分離和分庫分表我都是優(yōu)先推薦的MariaDB系的產(chǎn)品。因為公司和個人原因吧，我只有在之前的公司研究過一段時間MySQL的讀寫分離和分庫分表，在測試環(huán)境做了大量的測試，但最終沒上到生產(chǎn)中，反而是隨著公司的業(yè)務(wù)重組，IT順勢做了服務(wù)化，將原來的一套B2B平臺拆分成多個模塊，實現(xiàn)了解耦，數(shù)據(jù)庫也順勢拆分了出來，所以就單個模塊，讀寫壓力少了很多。算是業(yè)務(wù)重組和系統(tǒng)重構(gòu)讓我們暫時沒用中間件來實現(xiàn)讀寫分離和分庫分表。但報表類型的查詢我們還是讓開發(fā)直接查詢的slave端的。
之所以推薦MariaDB系，是因為之前和賀春旸老師(http：//blog.51cto.com/hcymysql)聊天的時候，得知他們有一些采用的Maxscale和Spider，他本身也做了大量的測試，也有生產(chǎn)經(jīng)驗，所以在這里給大家做推薦。當(dāng)時我們公司測試的主要以O(shè)neProxy為主，但其是收費產(chǎn)品。
看似讀寫分離和分庫分表有點打太極，都先把事情推給開發(fā)同學(xué)。實際上從架構(gòu)的角度來看，數(shù)據(jù)庫承擔(dān)的計算越少越好，數(shù)據(jù)庫越輕越靈活。一般來講，需要DBA來采用中間件的方式實現(xiàn)讀寫分離和分庫分表時，某種程度上都會降低性能，畢竟加了中間件一層；另外也增加DBA的運維負(fù)擔(dān)，同時中間件支持的分庫分表對于跨庫查詢和跨庫事務(wù)都有一定的限制，需要開發(fā)的同學(xué)做一些代碼上的轉(zhuǎn)變。
（3）DMP數(shù)據(jù)平臺
DMP統(tǒng)一數(shù)據(jù)管理平臺主要用于數(shù)據(jù)分析和報表展示等功能。通過搭建統(tǒng)一數(shù)據(jù)管理平臺，減少直接生產(chǎn)庫查詢數(shù)據(jù)的壓力，減少生產(chǎn)壓力。對于中小企業(yè)的數(shù)據(jù)平臺，我之前寫過一篇介紹，可以參考：《數(shù)據(jù)即金錢，中小企業(yè)如何搭建數(shù)據(jù)平臺分得一杯羹？》，比較適合中小企業(yè)使用，可以在這個架構(gòu)基礎(chǔ)上添加Hadoop集群等來處理大數(shù)據(jù)相關(guān)的分析，很容易進行擴展。
2非關(guān)系數(shù)據(jù)
非關(guān)系型數(shù)據(jù)庫主要以Redis為主。Redis常用的高可用方案有哨兵模式和Cluster。使用Redis除了上面講的做共享session存儲之外，最大的應(yīng)用就是緩存常用數(shù)據(jù)。這兩大應(yīng)用建議生產(chǎn)環(huán)境中分集群部署。我們當(dāng)前或是未來的一個實際情況：由于目前正在做服務(wù)拆分，更多的服務(wù)和應(yīng)用實現(xiàn)了實現(xiàn)服務(wù)無狀態(tài)，所以存共享session的需求會越來越少。
關(guān)于非關(guān)系型數(shù)據(jù)庫，除了高可用、監(jiān)控之外平常工作中還面臨很大的一個工作就是分庫和分片，如何方便快速擴展，這很有用。對于Redis的使用，個人建議在一開始規(guī)劃時就考慮好擴展問題避免以后的遷移或是在線擴展等。這跟關(guān)系型數(shù)據(jù)庫的分庫分表有異曲同工之妙。Redis的分庫分片和擴展對系統(tǒng)架構(gòu)來說很重要，尤其業(yè)務(wù)的高速發(fā)展期，越來越多的數(shù)據(jù)緩存在Redis中，如果沒有做好規(guī)劃，將會很被動。具體Redis架構(gòu)，結(jié)合我們實際生產(chǎn)環(huán)境，在以后的文章中在跟大家詳細(xì)描述和分享。
除Redis之外，很多生產(chǎn)環(huán)境也會有MongoDB、HBASE等常見的NoSQL數(shù)據(jù)庫，不同的數(shù)據(jù)庫有不同的應(yīng)用場景，大家在做系統(tǒng)架構(gòu)時，根據(jù)實際情況進行審核。
四、分割架構(gòu)
分割架構(gòu)主要是指業(yè)務(wù)拆分。根據(jù)具體的業(yè)務(wù)內(nèi)容和高內(nèi)聚、低耦合的原則，將復(fù)雜的業(yè)務(wù)進行模塊化的劃分，單獨部署，接口化操作數(shù)據(jù)，實現(xiàn)業(yè)務(wù)的橫向分割。細(xì)粒度分割復(fù)雜的業(yè)務(wù)系統(tǒng)，可以降低業(yè)務(wù)系統(tǒng)的復(fù)雜度，按照模塊進行開發(fā)和維護，降低整體系統(tǒng)的宕機時間。
一般來說，分割架構(gòu)需要開發(fā)、業(yè)務(wù)為主，運維、測試為輔，架構(gòu)師統(tǒng)一主導(dǎo)進行，共同進行系統(tǒng)劃分工作。
業(yè)務(wù)劃分因公司的業(yè)務(wù)不同而異，支持服務(wù)化的開源技術(shù)框架也很多，常見的有Dubbo、Dubbox以及比較新的Spring Boot、Spring Cloud等。本人有幸在一家公司以DBA的身份參與到公司的系統(tǒng)重構(gòu)中去，雖然對服務(wù)化的技術(shù)框架不是很熟悉，但這個系統(tǒng)劃分及服務(wù)化過程，可以結(jié)合之前的經(jīng)驗給大家做一個簡單的分享，希望讀者能夠有所收獲。
首先是不可避免。一般系統(tǒng)初期，公司為了業(yè)務(wù)盡快上線，大多將業(yè)務(wù)功能堆加在一起。隨著公司業(yè)務(wù)發(fā)展，系統(tǒng)拆分、系統(tǒng)重構(gòu)不可避免。
成本頗高。系統(tǒng)拆分，系統(tǒng)重構(gòu)一般帶來的IT高成本，風(fēng)險相對也較高。該工作一般適合于系統(tǒng)平穩(wěn)發(fā)展時進行，或是單獨的團隊進行并行進行。
做好計劃，持久作戰(zhàn)。系統(tǒng)拆分、系統(tǒng)重構(gòu)時間相對較長，一定要提前做好計劃，避免出現(xiàn)項目持續(xù)時間久，項目疲憊的情況。
業(yè)務(wù)拆分要科學(xué)。業(yè)務(wù)的拆分一定要經(jīng)過架構(gòu)、開發(fā)、業(yè)務(wù)、DBA等部門共同討論，共同制定出既適合當(dāng)下，又能夠適合未來一段時間內(nèi)(2~3年)的業(yè)務(wù)發(fā)展。
業(yè)務(wù)拆分要徹底。業(yè)務(wù)拆分不應(yīng)該只是系統(tǒng)或是程序工程的拆分，還應(yīng)該包括數(shù)據(jù)庫的拆分。我們之前就是拆分了程序，未徹底拆分?jǐn)?shù)據(jù)庫，導(dǎo)致程序?qū)崿F(xiàn)服務(wù)化后，后端數(shù)據(jù)庫的壓力不斷增大。采用數(shù)據(jù)庫中間件實現(xiàn)后端數(shù)據(jù)庫的分庫，但因為中間件的一些限制，開發(fā)又不得不修改一些跨庫查詢和跨庫事務(wù)的情況。所以業(yè)務(wù)拆分一定要徹底，不管是項目工程，還是數(shù)據(jù)庫。
拆分取舍有道。拆分取舍有道，既不能將系統(tǒng)拆分得過細(xì)，這樣會有很多跨系統(tǒng)的事務(wù)或查詢的情況；但也不能拆分得太粗，隨著時間增長，有面臨著被拆的問題。所以系統(tǒng)的拆分要結(jié)合實際情況進行，既要避免技術(shù)潔癖，也要避免粒度太粗。
以上幾條，是我們之前在做系統(tǒng)業(yè)務(wù)拆分和系統(tǒng)重構(gòu)時候的一些經(jīng)驗，至于重構(gòu)的服務(wù)化架構(gòu)，因為本人之前沒有參與太深，一知半解，這里不便多言。不過目前我們也在以架構(gòu)的身份進行系統(tǒng)拆分和服務(wù)化的探索，待逐漸完成后，整體的架構(gòu)會拿出來跟大家分享，目前我們采用的技術(shù)框架主要以Spring Cloud為主。
五、系統(tǒng)保障
系統(tǒng)保障主要圍繞基礎(chǔ)運維數(shù)據(jù)(CMDB)，以監(jiān)控、災(zāi)備、安全三大體系保駕護航，運維自動化作為馬達(dá)，保障系統(tǒng)和服務(wù)的安全、穩(wěn)定、高效的運行。關(guān)于運維管理體系，運維基礎(chǔ)數(shù)據(jù)，災(zāi)備和安全的介紹，我在之前的文章都有介紹，歡迎指正。
監(jiān)控這塊一直沒有下定決心來寫，因為目前我們監(jiān)控面臨著監(jiān)控閥值設(shè)置不夠精準(zhǔn)導(dǎo)致誤報過多引發(fā)告警疲勞，監(jiān)控因素關(guān)聯(lián)關(guān)系未完全梳理清楚導(dǎo)致一個問題引發(fā)告警風(fēng)暴的問題。告警疲勞和告警風(fēng)暴是我們目前監(jiān)控面臨的兩大難題。待解決完成后，會進行監(jiān)控體系的分享。
關(guān)于告警風(fēng)暴目前我們得到一定程度的環(huán)境，主要依賴告警分級和CMDB中的依賴關(guān)系來做的，自動判斷故障根源進行告警，多個告警引發(fā)候，有限告出根本故障點。目前有一定成效，但還需進一步改進。網(wǎng)上也有一下使用機器學(xué)習(xí)的方式來準(zhǔn)確設(shè)置或是動態(tài)設(shè)置告警閥值的情況，也值得我們進一步學(xué)習(xí)。
關(guān)于系統(tǒng)保障我已完成的文章和推薦給大家關(guān)于監(jiān)控動態(tài)設(shè)置閥值的連接，整理如下，請參閱指正：
《一個可供借鑒的中小企業(yè)運維管理平臺架構(gòu)樣本》
《干貨！談自動化運維平臺的地基如何打牢》
《從安全、監(jiān)控與災(zāi)備說開去，談運維管理防線建設(shè)》
《做好災(zāi)備平臺，打造自動化運維管理的最后堡壘》
《解放運維的雙手，談自動化運維管理平臺設(shè)計》
阿里的Goldeneye
http：//www.infoq.com/cn/articles/alibaba-goldeneye-four-links
智能運維里的時間序列：預(yù)測、異常檢測和根源分析
http：//www.infoq.com/cn/presentations/time-series-in-intelligent-operation-and-maintenanc
六、總結(jié)暨技術(shù)平臺和技術(shù)生態(tài)圈
寫到這里，關(guān)于系統(tǒng)架構(gòu)這一塊基本結(jié)束。關(guān)于系統(tǒng)架構(gòu)個人建議主要分兩大塊，一個是系統(tǒng)架構(gòu)，一個是系統(tǒng)運維。首先通過系統(tǒng)架構(gòu)設(shè)計出穩(wěn)定、高可用、高性能且易擴展的系統(tǒng)來，然后通過系統(tǒng)運維來保障。個人感覺這應(yīng)該是做系統(tǒng)架構(gòu)應(yīng)該著重考慮的地方。（這考慮可能跟我目前的工作職責(zé)有關(guān)系）
關(guān)于技術(shù)平臺和技術(shù)生態(tài)圈，這是一個很大的話題，跟個人的職業(yè)規(guī)劃也有一定的關(guān)系，我這里直說一點，就是對于自己所在的公司所用到的技術(shù)棧，每一種技術(shù)適用的場景以及優(yōu)缺點要了然于胸，尤其是對于架構(gòu)師。對于系統(tǒng)架構(gòu)的技術(shù)生態(tài)圈，這里以StuQ中各種技能圖譜來表述技術(shù)生態(tài)圈。常見的IT技能圖譜可以參考：https：//github.com/TeamStuQ/skill-map 每一種腦圖代表了這一IT領(lǐng)域可能用到的技術(shù)知識，各位可以在此基礎(chǔ)上，結(jié)合自身情況，建立起自己的技術(shù)體系，并且在日常工作和學(xué)習(xí)中不斷得完善。
最后，圍繞系統(tǒng)架構(gòu)，再重復(fù)一句經(jīng)久不變的哲理：系統(tǒng)架構(gòu)不是一開始就架構(gòu)出來的，是通過不斷的演變而來的。做系統(tǒng)架構(gòu)一定要符合公司的實際情況，采用最熟悉的技術(shù)進行架構(gòu)，同時要做好技術(shù)儲備，以便應(yīng)對瞬息萬變的技術(shù)革新。
Q&A
Q：問CMDB有什么開源產(chǎn)品推薦的？謝謝！
A：關(guān)于CMDB開源的產(chǎn)品還是蠻多的，懂Python的話，推薦這幾個開源開源資產(chǎn)管理系統(tǒng)：
https：//github.com/hequan2017/autoops
https：//github.com/pengzihe/cmdb
https：//github.com/welliamcao/OpsManage
https：//github.com/hgz6536/opman-django
https：//github.com/voilet/cmdb
https：//github.com/roncoo/roncoo-cmdb
如果直接可用的話，ITOP還不錯。不過適合自己的CMDB才是最好的，一般都需要二次開發(fā)。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標(biāo)題：一套大而全的系統(tǒng)架構(gòu)體系與具體落地方案
本文網(wǎng)址：http://www.ezxoed.cn/html/solutions/14019324475.html
相關(guān)文章
