3月12日下午在阿裡巴巴西溪園區，舉行了mongodb杭州使用者交流會。微軟msdn特邀講師徐雷分享《基于mongodb的政府雲平台高并發高可用ha架構實踐 》，從自身實踐出發，講述了政府雲平台分層、技術棧選型、實體架構、api架構及db資料庫架構的設計思路和方法。
以下内容根據現場分享和演講ppt整理而成。
<b>學習mongodb的重要性</b>
<b></b>
目前，幾乎所有國内外的網際網路大公司都在用mongodb，學習企業需要的技術很重要。
<b>mongodb</b><b>優點</b>
相比較關系型資料庫而言，mongdb有兩個明顯的優點：靈活的資料模型和便于橫向擴充。
<b>靈活的資料模型：</b>作為一位網站開發者，最痛苦的就是需求變更，mongdb可以接受字段的不斷修改，非常靈活。
<b>便于橫向擴充： </b>如果有海量資料存儲，這時可以做sharding，非常容易，這個是mongdb本身已經支援的。傳統的關系型資料庫在這一塊比較難實作，因為它會由很多固有的設計缺陷導緻。但傳統關系型資料庫的分片思想和mongdb分片思想其實很像，從算法的角度來說，沒有太大差別，比如基于範圍進行分片，這兩個是通用的。
<b>高并發與高可用架構關鍵點</b>
程式員一般追求高并發，對于高并發這個關鍵詞容易産生興奮點。作為架構師設計一個架構，如果要支援某個級别的并發，一定要注意：不是用redis就是高并發，不是用mongdb就是高并發。<b>高并發高可用架構關鍵點包含：多線程、分布式通信rpc、叢集、負載均衡、網絡與硬體、監控與診斷等。</b>比如java有多線程、高并發的問題，如果涉及到分布式通信rpc 、分布式架構的話，一定會有一些rpc的技術，會有線程通信、程序間的通信出現，這些在不同架構中都有對應的實作。架構師在設計架構時，需要深入研究。
<b>叢集：</b>是不是一定要用叢集？不一定。一般小規模公司才用3-5台伺服器，大規模公司用128g、256g、甚至2t的伺服器記憶體，連資料和索引都進伺服器。mongdb在資料量非常大的時候，比如你有16g記憶體，發現它很慢，有一個很重要的問題，稍微研究下底層的算法，會發現mongdb在使用索引結構進行資料查詢的時候，它需要對索引進行周遊，如果能整體進記憶體最好，如果不能整體進記憶體，它就部分加載，這樣的話就更慢，因為涉及到一個磁盤記憶體問題。
<b>負載均衡：</b>假設用了叢集，比如有10台web伺服器，需要做負載均衡，可以用業内比較成熟的實作方案，比如阿裡雲、微軟雲、亞馬遜雲，直接配置就可以用。如果要建構私有雲，或者資料中心的話，需要想一些負載均衡的方案。比如業内比較流行的，軟負載均衡，反向代理負載均衡。
<b>網絡和硬體：</b>這也是高并發的前提。比如10w并發，平均一個消息多大，估算一下網絡流量，不要說不管帶寬是5m，還是10m，就要10w并發，這需要看硬體的伺服器配置，所有的高并發一定是個完整的體系，不是說在某個點上，寫段代碼就高并發了。是以現在看到的高并發系統，一定是經過無數次的疊代。
<b>監控與維護</b>：這是運維最頭疼的。因為運維每天晚上需要遠端登入看機器正常不正常，影響正常休息，是以現在也提出了自動化運維概念。
<b>政府雲平台背景</b>
政府也需要進行轉變，他們希望把整個政府平台資訊化，建構統一高效的政府雲平台。比如稅務的資訊化、公務人員考核的效率化等。
基于前面說到的，設計的架構一定要微觀上+宏觀上高并發，不能說了搭了幾層就是高并發架構，首先要看寫的代碼，如果在背景就産生了大量問題，大量bug，怎麼能夠高并發，從前端到背景是一條鍊，任何一個節點出問題，都會影響整個系統架構。
<b>政府雲平台分層架構圖</b>
從上圖顯示，這個架構系統不是隻有關系型資料庫，或者nosql資料庫。因為這個場景是比較特殊的。對于政府官員考核的名額比較多，每個名額量化機關不一樣，考核資料模型是會變化的，會導緻資料的不确定性。這個時候比較适合用nosql，如果用傳統關系型資料庫的話，開發就需要天天改資料層的表。
參考上圖，我們做的技術并不僅僅是一種技術，需要考慮傳統pc端，也要考慮移動端的問題。這裡作為服務治理層，或者服務層，這裡服務治理層不僅是服務層，因為希望對服務做一個統一的規劃和安排。另外希望後期加一些自動化運維和監控的知識，包括現在比較新的微服務的概念，這是設計的思路。
協定的話，也沒有固定隻用http這一個，也沒有隻用soap協定。可能大家會說因為你對 soa 架構比較熟，但其實今天所有的系統架構，這個叫soa的概念已經存在。不是說用哪個架構，就一定能解決問題，不推薦這種方式。如果涉及到移動端，可能會用到mqtt協定，如果是頁面應用的話，可能會用到最新的web socket。
業務邏輯層上，分層不是越多越好，而是根據需要分層，分完層之後是否友善後期擴充。比如業務邏輯層，java和.net裡面都有分層的思想，這個部分把業務邏輯獨立出來，不影響其它層。需要注意一下，這裡用到redis，前面講過高并發的系統應用，redis我們推薦。如果公司有能力開發一套緩存系統可以開發，比如阿裡巴巴的rocketmq消息隊列，如果開發不了，就用開源成熟的産品。redis目前是最流行的開源的免費緩存，它屬于nosql的範疇，這兩個結合和mongdb不沖突。mongdb能夠解決10000個并發，一般公司夠用。如果遇到峰值的時候，可以用兔子消息隊列，讓其幫助從中加一層，來緩解資料庫壓力。緩存技術除了加速以外，還可以充當請求緩存池，用于處理一些不太着急的請求。
再說一個問題，這裡不論是java和.net，連接配接資料庫的技術都是差不多的，都有連接配接池，都有多線程，而且垃圾回收的機制也差不多。同樣如果想對傳統型關系資料庫或者nosql資料庫做研究的話，可以看下nosql并發有很重要的問題，傳統關系型資料庫是不強調事務的，但是傳統的nosql資料庫，從誕生之初開始，高并發是它很重要的一個特點。目前nosql也開始支援事務，但是部分事務，不完整。關于mongdb有很多坑，因為它有幾個存儲引擎，這個有點像mysql，mysql也有幾個開源的存儲引擎，每個存儲引擎都不一樣，要用這個資料庫的話，需要注意使用版本、存儲引擎，需要在官方文檔上确認一下。
<b>政府雲平台技術棧選型</b>
java底層和.net底層原理是相通的，資料結構的算法基本上一樣。但為什麼有些是java做的，有些是.net做的，這裡面我們會用到。反向代理考慮到盡量是免費的，節省成本。涉及到一些日志架構，建議用最成熟的架構，這裡沒有平台或者語言系統的偏見。用docker友善運維。
<b>政府雲平台soa架構設計</b>
現在有手機定位，自動駕駛，政府也在考慮這些問題。比如政府希望看到各省縣長的履曆，進行優先提拔；比如要防控房地産的問題，房價波動厲害，需要了解房地産的交易資金，房地産大資料等，任何一個名額政府都希望能看到。soa叫做面向服務的架構，是基于服務來內建現成的系統，這個架構沒有過時。
<b>政府雲平台新soa架構：esb+微服務</b>
這些架構如果開始做的話，兩個系統直接服務內建，後面更複雜的問題來了，像阿裡巴巴自己做了一個服務架構叫dubbo，它裡面有服務治理的事項，也有微服務的特點。作為一名技術人員，一定要注意它的試用場景，如果沒有這些架構，能不能做個類似的功能？
這裡面涉及到一個問題，如果後期系統特别多，最好有一個中間件平台的概念出來。這樣在服務治理的過程中，可以更好的規劃系統架構，而不是所有系統之間随便連接配接。随便連接配接的後果是，後期所有系統接口都是亂的，系統越多，亂的越厲害。比如早期是webservice，有可能後期改成ttp，或者改成http等等一些新型的協定。
<b> </b>
另外，這還涉及到高并發高可用的問題。網站選一個高并發的架構，在網站上要求1w個并發，一台伺服器支援1w/秒的并發，接下來你想要10w的，一定要想辦法進行橫向擴充，當然如果企業特别有錢，可以把伺服器換成1t的記憶體。還有一個高可用名額，比如每秒是1w個并發，更新一下直接挂掉，這是不行的。
<b>省級機關政府雲平台實體架構</b>
實體架構和邏輯架構不同，邏輯架構可以分10層、100層都可以，但不是分層越多越好。分層越多，解耦越厲害，越影響性能。很多人不管設計什麼架構，先分個三層，不管需不需要，直接把接口用webservice包容。這裡一定要根據需要做判斷。
mongdb做叢集，做高可用。首先，保證實體安全，伺服器不要壞掉；然後，mongdb可以支援資料直接加密，金融資料不安全的話，資料永久加密。mongdb3.4版本之後加了金融的資料類型。
mongdb可以做可複制性叢集，這裡可以一對多，但是有個問題，它可以實作自動化過程轉移，如果說資料通路層開發的比較好的話，使用了較新的驅動，無論是java還是c sharp ,它可以自動化來切換。在這個叢集中，它自動會找一台新的節點出現，來替代主節點。這是相對于傳統資料庫mongdb做的好的地方。作為運維隻要把web關系層配好，就不用擔心哪台伺服器在服務，直接可以自動化切換，圖檔伺服器和緩存伺服器，也不是所有的資料都進緩存，有部分資料為了緩解壓力，把使用者資料的資料可以放到緩存裡，這樣可以從緩存裡拉所有資料。
負載均衡的話，用硬體軟體都可以，負載均衡如果隻用一台伺服器，風險較高。cdn從單資料中心擴充到多資料中心也可以，一般公司還用不到多個資料中心。
<b>政府雲平台服務治理api架構設計</b>
所有系統上線之後，不是簡單的開發和釋出，後期系統需要跟其它平台進行對接，會有一個服務元件的中間件平台，可以用開源的，也可以用商用的，比如oracle、sap、微軟、阿裡巴巴的中間件平台。中間內建可能會有不同的協定，這裡面會涉及到很多問題，redis後面可能會換成消息隊列，比如一個5年考核名額，一個月内的資料量比較大，這個時候資料庫肯定要持久化，有些内容放到mongdb，有些會放到傳統的關系型資料庫裡面，需要提前做一些預測。再注意一個問題：這裡的資料web層和通路層，全部都是叢集。redis也是支援叢集。
系統上線之後，要看哪些系統出現異常了，什麼樣的異常是需要馬上解決的，這裡面涉及到服務監控的問題，需要配合專門的運維工程師制定一些規則。
另外，緩存在ui層就有了，api這層也可以有緩存，不是所有的東西放到redis裡面才叫緩存，redis屬于分布式緩存，有些資料可以放到資料持久層，比如關系型資料庫，mongdb也有，伺服器隻要配置夠高，資料直接進資料持久層緩存或者資料通路層緩存也可以。如果單獨加一層緩存也可以。像中間件平台也有獨立的緩存，api層也有。從架構角度來說，要想下緩存放在哪層比較合适，相應的硬體配置要跟的上。當然，越接近用戶端的緩存，效率越高，因為它的實體位置更接近用戶端請求。如果放在最下面，說白了中間要經過很多層才能到資料這一塊。
<b>省級機關政府雲平台db資料庫架構</b>
政府系統，首先實體上保持隔離，再保證安全。要注意的是，峰值出現的時候，需要加一層緩存或者消息隊列。
政府系統的資料量規模是有限的。小規模系統可以用可複制叢集，保證資料庫節點的自動化災備轉化就可以了，這樣的好處是：首先，讀寫分離把壓力分擔了；另外，如果出問題，可以自動化災備、自動化切換，避免手動修複，或者當機帶來的一些問題。
緩存資料伺服器最好用兩台。比如支付寶，新浪微網誌做的比較成功，大量資料放在緩存裡。緩存也有讀寫分離。一些網際網路公司的測試資料顯示，redis的并發能達到每秒11w，是以它很适合做資料持久層的這一套緩存機制，無論是傳統關系型資料庫，還是mongdb，用普通的sshd，每秒隻有1w寫入量的話，可以把資料先寫入redis，這個并發高，基本上10w的并發，能夠滿足絕大多數網際網路公司的需求，如果還不行，可以寫入的資料量少一點，再做讀寫分離。
<b>政府雲平台架構設計考量</b>
<b>推薦閱讀</b>
《mongodb實戰》
《jquery 實戰》