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