轉：一套大而全的系統架構體系與具體落地方案

原文地址：

https://new.qq.com/omn/20171229/20171229B02VYY.html

 

本文根據DBAplus社羣第131期線上分享整理而成，文末還有好書送哦~

　　講師介紹

　　戰學超

　　青島航空運維經理

　　高級架構師

　　曾任職於NEC軟件、海爾B2B平臺鉅商匯，負責企業數據平臺構建、B2B電商平臺數管理與搭建、企業運維管理平臺搭建；

　　擁有豐富DBA、系統運維架構經驗，熟悉運維管理、數據庫架構、數據平臺搭建、虛擬化、私有云部署、自動化運維等。

　　寫在最前面

　　上次參加DBAplus舉辦的敏捷運維峯會時，一個兄弟的提問一直縈繞耳邊，因爲時間有限沒有進行深刻的交流，甚是遺憾。那個問題是：大家公司的IT系統架構是怎樣的？又如何具體落地？採用了哪些開源或是商業的技術？

　　其實以前也寫過或是作過一些關於系統架構的分享，或多或少的我的或其它限制，總以爲未能盡興，留有遺憾。所以通過最近一個多月的總結和梳理，在這寫出來跟你們作一個分享，這也是對我我的技術生涯中系統架構部分作一個階段性的總結，以便日後可以更好地投入到接下來的雲平臺架構和機器學習，以及企業如何下降IT成本的深刻研究中。

　　系統架構是一個比較大的話題，以一個什麼樣的思路或是方法進行切入很重要。系統架構的脈絡可讓咱們很好地瞭解系統架構的總體概況，也能夠幫助咱們創建有效的我的架構知識體系。

　　本文從系統訪問鏈路爲切入點，圍繞訪問鏈路的方方面面，包括基礎設施、分層架構、分割架構、系統保障、技術平臺生態圈等幾個方面進行展開，力求展示出一套相對比較完整的系統架構體系，同時結合自身經驗，介紹具體落地的方案和技術，但願可以給讀者帶來一些收穫。

　　1、訪問鏈路

　　訪問鏈路表示從用戶訪問請求到最終生產服務器響應，再到反饋給用戶請求的結果信息這一過程。無論是互聯網企業仍是傳統企業，在系統架構中必定要明確本身的訪問鏈路，這對系統優化、系統排故、鏈路監控等相當重要。

　　該圖是一家中小型公司的訪問鏈路圖，系統主要分爲兩大塊：一是對外提供服務的電商平臺；另一塊是企業內部的核心生產系統和企業信息系統等。灰色部分表示正在創建或是規劃創建的部分。

　　該公司訪問鏈路主要有兩條：一條是外部客戶的外網訪問鏈路，另外一條是內部員工的內網訪問鏈路。該公司是有自建的數據中心機房，可能如今不少公司都將對外訪問的系統放到租賃的IDC機房或是雲服務器，其實都是同樣的。根據系統特色劃份內外網訪問鏈路，能夠節省網絡流量，也能夠加強內部系統的安全性等。

　　一、外網訪問鏈路

　　公網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。

　　訪問鏈路要儘量的高效、安全、簡單。每個系統架構師必定要對本身企業或是產品的訪問鏈路瞭然於胸，在系統使用者反饋故障或是性能問題時，深刻分析鏈路中的每個元素找到故障點或是性能瓶頸，進行處理或優化。

　　2、基礎設施

　　基礎設置主要包括網絡、基礎硬件/基礎軟件、數據中心這三部分，以及圍繞基礎設施作的軟件定義網絡(SDN)、虛擬化容器化、雲數據中心等，力求作到上層IT架構能夠不用去過多考慮基礎設施。

　　一、網絡

　　網絡方面包括：網絡接入、網絡規劃、網絡實施、拓撲結構、流量管理、安全監控等幾個方面。

　　首先是網絡接入，因爲中國特殊的網絡環境，對於須要對外提供服務的系統通常都須要考慮多網絡供應商的接入，包括移動、聯通、電信等。不一樣的網絡接入對外提供服務時，會依賴智能DNS等手段，實現不一樣網絡環境鏈接至不一樣公網IP，儘可能避免跨網絡供應商的訪問，提升訪問速度。

　　網絡規劃主要包括局域網的規劃和劃分，通常狀況是須要分隔離區(DMZ)、辦公區、測試區、生產區等幾個區域，不一樣區域之間經過防火牆等安全設備進行有效隔離。另外，廣義上的網絡規劃還包括數據流量及約束條件分析、網絡選型、拓撲結構設計、網絡安全、建設方案等幾個方面。

　　接下來是網絡實施。根據網絡規劃和網絡建設方案，進行網絡的部署和實施。

　　無論傳統企業仍是互聯網公司，必定要有本身的網絡拓撲結構圖，這樣網絡架構清晰明瞭，當網絡故障時，對於故障點、影響範圍等均可以經過網絡拓撲結構圖快速得到。網絡拓撲要實時更新，時刻保持與真實網絡環境一致。

　　要對網絡的流量進行管理和實時監控。根據網絡流量合理調整網絡帶寬等。整個網絡基礎設施中的網絡安全不可或缺。通常經過防火牆、IPS/IDS等軟硬件設備進行網絡安全的防禦或是監控、分析和屏蔽絕大部分的網絡攻擊行爲。

　　網絡做爲重要的基礎設施之一，要根據安全策略和實際業務量、業務狀況等幾個方面進行合理的規劃和實施，完善網絡拓撲結構，經過監控和流量管理等手段，實時瞭解網絡以及網絡設備的運行狀況，當出現故障或是性能問題時，可以快速發現故障源或是性能瓶頸點，以便有重點地進行排故、調優。

　　二、基礎軟硬件

　　1

　　基礎硬件

　　基礎硬件包括服務器、內存、CPU、存儲、電源、防火牆、交換機、路由器、集線器等服務器、網絡及周邊硬件設施。

　　基礎硬件及其備件通常有雙份或是多份，避免硬件單點故障，也就是說通常企業要有本身的備件庫，對服務器、存儲、網絡設備等硬件進行備份，當出現問題時，能夠及時更換。備件庫的信息也要跟隨CMDB一塊兒入庫管理。

　　2

　　基礎軟件

　　基礎軟件包括操做系統ISO文件、數據庫安裝文件、應用服務器安裝文件等基礎軟件，也包括辦公用的Office、瀏覽器等軟件。

　　根據我的經驗，推薦一種相對比較好且易於部署管理的基礎軟件管理方式。根據軟件的性質進行以下分類，請你們參考：

　　三、數據中心

　　現在愈來愈多的公司採用雲服務進行系統部署，省去了自建數據中心機房等比較繁雜的事情。短期來看對企業是很是有利的，由於快且方便，能夠適應企業的快速發展。但隨着企業的規模不斷變大，大量的使用雲服務，IT成本會愈來愈高，自建數據中心可能會逐漸成爲一種比較經濟的方式。自建數據中心和雲服務自己是沒有矛盾且能夠科學組合、相輔相成的。企業哪一階段哪種方式最優，要根據企業的業務實際狀況和進行科學的計算後纔可判斷哪一種方式最經濟。（注：這裏的雲服務是指的公有云）

　　固然也有一些企業由於自身數據的保密性比較高，業務相對比較特殊，因此一開始就自建數據中心機房。

　　通常而言，數據中心機房的建設要按照國家標準和行業標準進行創建，這都有比較明確的標準規範，這裏大概總結了一下：

　　數據中心的創建有自建或是委託專業數據中心設計公司來進行。通常公司能夠經過第二種方式，經過與專業的數據中心設計公司合做，建設安全、可靠、伸縮性強以及節能環保的數據中心。

　　另外數據中心的創建、驗收、等級、災備等都有着明確的國家規範和行業行規，你們在規劃或創建的時候，必定在合規的底線上，進行優化設計，經常使用的數據中心參考文檔有：

　　《數據中心建設與管理指南》

　　《GB50174-2017 數據中心設計規範》

　　《GB50462-2015數據中心基礎設施施工及驗收規範》

　　《GBT22239—2008信息系統安全等級保護基本要求》

　　TIA-942《數據中心電信基礎設施標準》（中文版）等等

　　四、基礎設施管理與優化

　　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基礎雲平臺的糾結。

　　無論系統架構仍是基礎架構，都是一個逐漸演化的過程，適合當下業務架構而且易伸縮的架構纔是最優化的架構。

　　3、分層架構

　　1 、分層架構概述

　　系統在作分層架構候，通常狀況下主要包括：接入層、應用層、公共服務層、數據存儲層等幾個層次，其中接入層還包括DNS轉發、CDN、負載均衡層、靜態資源層等。有CDN的公司會直接將靜態資源放在CDN層中。

　　系統分層架構圖大概以下：

　　二、負載均衡和反向代理

　　負載均衡分爲軟負載和硬負載。其中硬負載包括有F五、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，不少公司在用，但也有一個缺點就是增長維護成本和運維複雜度，雖然這項技術實施起來會比較簡單。

　　三、業務應用層

　　業務應用層比較大的一塊是作服務化，這會在下面的分割架構進行詳細說明。這裏主要說明簡單的業務拆分和應用集羣的部署方式。

　　高內聚、低耦合一直是軟件開發和系統運維所積極追求的。經過實現業務系統的高內聚、低耦合，下降系統依賴，提升系統的可用性，下降故障率，業務拆分是解耦的重要利器之一。通常根據公司業務系統的特色和關聯進行拆分，對公共業務系統進行抽取造成公共業務應用，對全部業務系統進行接口化服務。各個業務系統之間獨立部署，下降耦合度，減小了業務系統之間的依賴和影響，提升整個系統的利用率。

　　由於有前面的負載均衡和反向代理層，全部後端的應用服務器能夠橫向部署多臺，實現高可用也起到用戶訪問分流，增長吞吐、提升併發量。實際應用部署中主要以Java應用居多，且多部署在Tomcat中，以此爲例，在應用服務器部署時，主要考慮如下幾個問題或是建議：

　　統一JDK和Tomcat版本。這很重要，主要是爲了方便管理，另外也方便作自動化運維部署。其中統一部署中的操做系統優化、安全加固，Tomcat優化、安全加固等都要作好，咱們在作Tomcat自動部署的時候，採用的是根據系統配置自動優化的方式和安全加固策略進行。另外就是自動備份和日誌的自動切割，都在統一部署腳本中體現。這樣全部部署下來，安裝位置、部署方式等都是一致的，方便統一管理，統一備份和升級。

　　動態頁面靜態化。這個根據訪問量選擇系統進行，例如公司的B2C官網等能夠採用靜態化的技術，提升頁面的訪問速度。

　　四、公共服務層

　　公共服務層將上層業務層公共用到的一些緩存、消息隊列、session、文件圖片、統一調度、定時任務等抽取出來，做爲單獨的服務進行部署，爲業務層提供緩存、消息隊列以及圖片等服務。

　　緩存主要是指的緩存數據。應用服務器經過緩存服務器查詢經常使用數據，提升系統的查詢速度，對於高併發的寫，經過異步調用消息隊列，進行數據的臨時存儲，提升系統的併發量和系統效率。Session集羣以及文件圖片服務器集羣主要是爲上層業務應用提供統一的session存儲和圖片文件存儲的，避免系統的session失效和單點故障。

　　經常使用的數據緩存以及session存儲主要是Redis。Redis的集羣部署方式在數據存儲層會詳細說明。

　　消息隊列的主要中間件有ActiveMQ和RabbitMQ等，兩者都提供master-slave或是集羣的部署方式。我所經歷的公司中兩者都有生產上的應用。經常使用的還有ZeroMQ、Kafka，但ZeroMQ不能持久化存儲，由於並未在生產使用，因此很差多說。Kafka主要在搭建日誌分析平臺時用到過。對於ActiveMQ和RabbitMQ，兩者並無太大的區別，都在生產用過，也沒遇到太大問題。在技術選擇中，仍是選擇開發和運維最熟悉的爲好，再具體點，建議以開發最熟悉的爲標準。

　　文件圖片服務器，若是公司的數據比較敏感且有較高的保密性，加上核心生產系統只能內部使用的話，建議搭建內部分佈式文件服務器、圖片服務器，我所經歷的公司有使用FastDFS進行構建分佈式集羣文件服務器的，目前比較火的分佈式存儲主要是Ceph吧。若是對外提供服務，建議採用購買雲服務，如阿里雲的OSS等，方便運維管理，並且雲服務自身的特性，也比較容易增長文件或圖片的加載速度。

　　統一調度、統一任務平臺，咱們使用淘寶的TBSchedule，也有一部分使用Spring自帶的定時任務，目前正在作整合。就如今來看，能夠知足咱們的定時任務和統一調度的需求。

　　公共服務層的架構和部署通常來講都提供了主從和集羣兩種高可用方式，而且都實現分佈式部署。因爲公共服務的重要性，全部業務都在調用，因此在實際生產部署的時候，必定要採用高可用的方式進行部署，而且要有可伸縮性和可擴展性。結合咱們公司實際狀況，在進行公共服務部署時，除了採用主從或是Cluster的方式進行部署，還增長了一鍵擴展的腳本，實現對集羣中服務器的快速擴展。分佈式擴展方式中的經常使用算法主要是一致性hash的方式，網上資料不少，這裏不在一一贅述。

　　五、數據存儲層

　　數據存儲層主要分爲關係型數據庫和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端的。

　　看似讀寫分離和分庫分表有點打太極，都先把事情推給開發同窗。實際上從架構的角度來看，數據庫承擔的計算越少越好，數據庫越輕越靈活。通常來說，須要DBA來採用中間件的方式實現讀寫分離和分庫分表時，某種程度上都會下降性能，畢竟加了中間件一層；另外也增長DBA的運維負擔，同時中間件支持的分庫分表對於跨庫查詢和跨庫事務都有必定的限制，須要開發的同窗作一些代碼上的轉變。

　　（3）DMP數據平臺

　　DMP統一數據管理平臺主要用於數據分析和報表展現等功能。經過搭建統一數據管理平臺，減小直接生產庫查詢數據的壓力，減小生產壓力。對於中小企業的數據平臺，我以前寫過一篇介紹，能夠參考：《數據即金錢，中小企業如何搭建數據平臺分得一杯羹？》，比較適合中小企業使用，能夠在這個架構基礎上添加Hadoop集羣等來處理大數據相關的分析，很容易進行擴展。

　　2

　　非關係數據

　　非關係型數據庫主要以Redis爲主。Redis經常使用的高可用方案有哨兵模式和Cluster。使用Redis除了上面講的作共享session存儲以外，最大的應用就是緩存經常使用數據。這兩大應用建議生產環境中分集羣部署。咱們當前或是將來的一個實際狀況：因爲目前正在作服務拆分，更多的服務和應用實現了實現服務無狀態，因此存共享session的需求會愈來愈少。

　　關於非關係型數據庫，除了高可用、監控以外日常工做中還面臨很大的一個工做就是分庫和分片，如何方便快速擴展，這頗有用。對於Redis的使用，我的建議在一開始規劃時就考慮好擴展問題避免之後的遷移或是在線擴展等。這跟關係型數據庫的分庫分表有殊途同歸之妙。Redis的分庫分片和擴展對系統架構來講很重要，尤爲業務的高速發展期，愈來愈多的數據緩存在Redis中，若是沒有作好規劃，將會很被動。具體Redis架構，結合咱們實際生產環境，在之後的文章中在跟你們詳細描述和分享。

　　除Redis以外，不少生產環境也會有MongoDB、HBASE等常見的NoSQL數據庫，不一樣的數據庫有不一樣的應用場景，你們在作系統架構時，根據實際狀況進行審覈。

　　4、分割架構

　　分割架構主要是指業務拆分。根據具體的業務內容和高內聚、低耦合的原則，將複雜的業務進行模塊化的劃分，單獨部署，接口化操做數據，實現業務的橫向分割。細粒度分割複雜的業務系統，能夠下降業務系統的複雜度，按照模塊進行開發和維護，下降總體系統的宕機時間。

　　通常來講，分割架構須要開發、業務爲主，運維、測試爲輔，架構師統一主導進行，共同進行系統劃分工做。

　　業務劃分因公司的業務不一樣而異，支持服務化的開源技術框架也不少，常見的有Dubbo、Dubbox以及比較新的Spring Boot、Spring Cloud等。本人有幸在一家公司以DBA的身份參與到公司的系統重構中去，雖然對服務化的技術框架不是很熟悉，但這個系統劃分及服務化過程，能夠結合以前的經驗給你們作一個簡單的分享，但願讀者可以有所收穫。

　　首先是不可避免。通常系統初期，公司爲了業務儘快上線，大多將業務功能堆加在一塊兒。隨着公司業務發展，系統拆分、系統重構不可避免。

　　成本頗高。系統拆分，系統重構通常帶來的IT高成本，風險相對也較高。該工做通常適合於系統平穩發展時進行，或是單獨的團隊進行並行進行。

　　作好計劃，持久做戰。系統拆分、系統重構時間相對較長，必定要提早作好計劃，避免出現項目持續時間久，項目疲憊的狀況。

　　業務拆分要科學。業務的拆分必定要通過架構、開發、業務、DBA等部門共同討論，共同制定出既適合當下，又可以適合將來一段時間內(2~3年)的業務發展。

　　業務拆分要完全。業務拆分不該該只是系統或是程序工程的拆分，還應該包括數據庫的拆分。咱們以前就是拆分了程序，未完全拆分數據庫，致使程序實現服務化後，後端數據庫的壓力不斷增大。採用數據庫中間件實現後端數據庫的分庫，但由於中間件的一些限制，開發又不得不修改一些跨庫查詢和跨庫事務的狀況。因此業務拆分必定要完全，無論是項目工程，仍是數據庫。

　　拆分取捨有道。拆分取捨有道，既不能將系統拆分得過細，這樣會有不少跨系統的事務或查詢的狀況；但也不能拆分得太粗，隨着時間增加，有面臨着被拆的問題。因此係統的拆分要結合實際狀況進行，既要避免技術潔癖，也要避免粒度太粗。

　　以上幾條，是咱們以前在作系統業務拆分和系統重構時候的一些經驗，至於重構的服務化架構，由於本人以前沒有參與太深，只知其一;不知其二，這裏不便多言。不過目前咱們也在以架構的身份進行系統拆分和服務化的探索，待逐漸完成後，總體的架構會拿出來跟你們分享，目前咱們採用的技術框架主要以Spring Cloud爲主。

　　5、系統保障

　　系統保障主要圍繞基礎運維數據(CMDB)，以監控、災備、安全三大致系保駕護航，運維自動化做爲馬達，保障系統和服務的安全、穩定、高效的運行。關於運維管理體系，運維基礎數據，災備和安全的介紹，我在以前的文章都有介紹，歡迎指正。

　　監控這塊一直沒有下定決心來寫，由於目前咱們監控面臨着監控閥值設置不夠精準致使誤報過多引起告警疲勞，監控因素關聯關係未徹底梳理清楚致使一個問題引起告警風暴的問題。告警疲勞和告警風暴是咱們目前監控面臨的兩大難題。待解決完成後，會進行監控體系的分享。

　　關於告警風暴目前咱們獲得必定程度的環境，主要依賴告警分級和CMDB中的依賴關係來作的，自動判斷故障根源進行告警，多個告警引起候，有限告出根本故障點。目前有必定成效，但還需進一步改進。網上也有一下使用機器學習的方式來準確設置或是動態設置告警閥值的狀況，也值得咱們進一步學習。

　　關於系統保障我已完成的文章和推薦給你們關於監控動態設置閥值的鏈接，整理以下，請參閱指正：

　　6、總結暨技術平臺和技術生態圈

　　寫到這裏，關於系統架構這一塊基本結束。關於系統架構我的建議主要分兩大塊，一個是系統架構，一個是系統運維。首先經過系統架構設計出穩定、高可用、高性能且易擴展的系統來，而後經過系統運維來保障。我的感受這應該是作系統架構應該着重考慮的地方。（這考慮可能跟我目前的工做職責有關係）

　　關於技術平臺和技術生態圈，這是一個很大的話題，跟我的的職業規劃也有必定的關係，我這裏直說一點，就是對於本身所在的公司所用到的技術棧，每一種技術適用的場景以及優缺點要了然於胸，尤爲是對於架構師。對於系統架構的技術生態圈，這裏以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纔是最好的，通常都須要二次開發。

　　直播連接

　　https://m.qlchat.com/topic/details?topicId=2000000501733146&ch=live_tpl_inform