專訪阿里陳康賢：我所理解的網站架構

陳康賢（花名龍隆，博客），淘寶技術部技術專家，著有《大型分佈式網站架構設計與實踐》一書，在分佈式系統架構設計、高併發系統設計、系統穩定性保障等領域積累了較爲豐富的實踐經驗，對新技術有濃厚的興趣,目前負責阿里直播平臺的建設，新一年的校招及社招也已經開始，有興趣加入阿里直播平臺的朋友，歡迎發送簡歷至longlong@taobao.com ，有不少崗位能夠選擇，期待與你們有更多的交流。

避免失敗是全部工程技術的核心

CSDN：你我的對架構/軟件架構的理解是？

陳康賢：如下僅是我的的一些理解，架構不只僅融合了思想，融合了技術，同時也融合了藝術，好的架構並不只僅是停留在技術文檔裏，而是在實踐的過程當中不斷地修正和調整的，這對架構師也提出了更高的要求，僅僅是停留在抽象和概念階段是沒有太大價值的，細節是魔鬼，一些從抽象層面看起來比較簡單的架構，實際上最大的挑戰每每來自於細節，這些細節既包含產品視覺交互功能的實現，也包含業務規則、風險等種種邏輯的處理，還包括技術上的一些難以預知的「坑」，具體的技術方案在實施的過程當中，可能須要花費大量的時間跟精力去解決和避免那些極端狀況下可能出現的問題。

架構應該知足一段時間內的業務發展，可是這一段時間到底有多長，有說三個月，有說半年，有說一年，也有說三年，不一樣的人不一樣的環境對於這個問題的理解可能不一樣，創業型公司，或者是嘗試型的業務，搖搖欲墜九死一輩子，優先考慮的是業務模式而非技術架構，所以，此時的架構應該儘量簡單儘量容易實現，三個月以後業務變成什麼樣子甚至是否存在，還很難說，這個時候去想三年以後的架構，基本上也是天馬行空，對於比較成熟的業務，或者是對以前穩定的業務系統進行重構，則須要將眼光放長遠些，避免一些在中長期可能面臨的問題，好比數據庫的分庫分表數量，ID的長度，分庫分表的維度等。

另外就是系統須要可擴展，在設計時要留有必定的擴展點，避免稍有變動就須要整個系統重構的狀況出現，對擴展開放，對修改封閉，實際上這很好理解，修改原有的系統而不是擴展原有的系統，更容易引入新的問題，也會帶來更大的測試工做量。一段時間以內架構的演變，經常會經歷從清晰，再到模糊混亂，再重構，再清晰，而後又變得模糊的過程，市場環境老是瞬息萬變的，所以，系統的設計要遵循對擴展開放，對修改封閉的原則，作到這點便可方便及時的接入新流程，又可以不影響既有的流程。

從宏觀來看，各個系統間的關係必定不該該是煙囪與煙囪的關係，而是猶如城市裏的高樓大廈，經過公路鏈接起來，所以，要提升建房子的速度，就要充分利用已有的基礎設施，已有的中間件，來下降系統構建的成本和風險。

架構設計的幾個層次，沒有架構也是架構，專一於解決現有問題也能稱爲架構，而好的架構應該是即可以約束開發者又可以解放開發者使其專一於功能的設計。儘可能將複雜的事情變的簡單，而不要將簡單的事情變的複雜，技術歷來都不是用來炫的，而是用來解決實際問題的。避免失敗是全部工程技術的核心，架構也是技術，要運用架構技術去緩解風險。

分佈式架構 VS. 集中式架構系統，以及思考

CSDN：分佈式系統架構是一個很是廣發的概念，他有着怎樣的特色，以及在網站什麼時候要用分佈式？另外它有哪些的場景？

陳康賢：分佈式架構其實是解決了集中式架構系統能力進一步向上擴展的所面臨的瓶頸，這些瓶頸包括資源、運維、開發維護等，由於單機的硬件受到技術條件的限制，越往上擴展，成本可能並不是是線性的而是指數級的，分佈式架構經過大量廉價的PC Server集羣，使得能力的擴展與經濟成本的關係再次迴歸線性，另外當開發團隊的規模愈來愈大，業務愈來愈複雜，分佈式及服務化也使得系統可以更好的進行拆解，讓更多的團隊可以更高效率的在一塊兒協做。

可是，從另外一個角度來看，分佈式架構也是一種複雜的架構，不少傳統架構下面能夠弱化的問題，在分佈式環境下變得凸顯，甚至是成爲相當重要的問題，好比數據一致性問題，好比網絡通訊、序列化、延時問題，好比如何應對失敗的問題，傳統環境下數據一致性經過數據庫事務在至關程度下被弱化了，而分佈式環境下將成爲一個很是複雜的問題，另外就是分佈式架構使得集羣內部的網絡通訊變得更加頻繁，通訊協議、序列化方式、通訊延遲、容錯、性能這些都會變得複雜化，分佈式環境下的失敗將成爲常態，如何處理這些失敗也會變得一個很是複雜的問題，一個成熟的分佈式架構體系所依賴的基礎設施不少，從各類中間件，到自動化運維體系，監控體系，容災體系，這些都須要一段時間的積累，而且持續投入和付出，所以，在考慮分佈式架構的同時，也須要從投入產出以及回報角度綜合考慮，對於創業公司來講，須要想清楚優先要解決的問題是什麼，再來思考企業須要什麼樣的架構，一味地參考大公司的架構，可能會提早讓系統變得過於複雜，失去響應靈活的特色，從而失去競爭力。

我所理解的網站架構

CSDN：大型網站架構設計的思想與原則是什麼？

陳康賢：實際上很難說有個一個統一的思想和設計原則，可以放之四海而皆準，由於每一個人對於設計的理解和理念是不一樣的，我的以爲設計一個複雜的大型網站，其實是一個分而治之的過程：

首先得充分的理解業務，理解需求，理解當下須要解決的首要問題，以及可能的風險有哪些，再將目標進行分解，進行具體的技術選型、模型設計、架構設計。若是須要解決的核心問題是併發，則能夠經過各類緩存手段（本地緩存、分佈式緩存），來提升查詢的吞吐，這樣雖然會必定程度上須要在數據一致性上作出犧牲，由強一致性變爲最終一致性，可是，若是數據一致性不是核心須要解決的問題，那麼，此問題的優先級則能夠先放一放，反過來若是核心問題變爲數據的一致性，如交易系統，那麼再怎麼強調數據的一致性都不爲過，因爲分佈式環境下爲了應對高併發的寫入以及海量數據的存儲，一般須要對關係型數據庫進行分庫分表擴展，這也給數據一致性帶來了很大的挑戰，本來的單庫事務的強一致性保障，在這個時候升級爲跨庫的分佈式事務，而經過二階段或者三階段提交所保障的分佈式事務，因爲分佈式事務管理器與資源管理器之間的屢次網絡通訊成本，吞吐及效率上很難知足高併發場景下的要求，而這實際上對於交易系統來講，又是一個很難迴避的問題，所以，你們又想出不少的招來解決這個問題，經過可靠消息系統來保障不失爲一種方式，變同步爲異步，可是，又引入新的問題，消息系統爲保證不丟消息，則很難保證消息的順序性以及是否重複投遞，這樣做爲消息的接收方，則須要保障消息處理的冪等性，以及對消息去重。

我的比較推崇洛克希德·馬丁公司的著名飛機設計師凱利·約翰遜所提出的KISS原則，架構設計能簡單毫不復雜，堅定砍掉任何華而不實的設計，不要由於3年後可能怎樣甚至是一些現實中根本沒法出現的場景，加入到當下的架構設計中，致使系統無比複雜。有時候看似引入的是一個很簡單很容易解決的問題，可能在具體的執行過程當中，會所以帶來一系列沒必要要的麻煩，按下葫蘆起來瓢。

另一點就是對於未經驗證的新技術、新理念的引入必定要慎重，必定要在全方位的驗證事後，再大規模的使用，新技術、新理念的出現，天然有它的誘惑，慎重並不表明保守，技術老是在不斷前進，擁抱變化自己沒有問題，可是引入不成熟的技術看似能帶來短時間的收益，可是它的風險或者是後期的成本可能遠遠大於收益。

CSDN：設計一個大型網站架構時，一般須要從哪些層面去考慮？服務器/存儲部署方面須要注意哪些問題？

陳康賢：大型網站的設計是一個很是複雜的問題，須要考慮的問題不少，好比海量數據的存儲，存儲又分爲在線存儲與離線存儲，在線又有關係型數據庫存儲和非關係型數據庫存儲，持久化存儲和內存存儲，這些都須要架構師根據具體的場景進行選型。

高併發且容許數據丟失的狀況下，能夠採用內存存儲，而查詢條件單一，只須要根據主鍵進行查詢，則能夠選擇key-value型的存儲，對於海量的文檔及圖片內容，則可藉助分佈式文件系統以及CDN邊緣節點，即解決了存儲的問題，又可以將冷熱數據分離，而且經過邊緣節點提升用戶訪問的效率，若是是須要多維度的複雜查詢，則須要使用關係型數據庫。當數據量大，併發寫入請求多的時候，又須要進行分庫分表，因爲分庫分表會限制數據的查詢維度，查詢條件必須得帶上分庫分表的鍵，若是須要多個查詢維度，則須要使用數據同步工具同步出另外一維度的數據結構，或者是搭建垂直搜索引擎，以提供多維度的數據查詢，不少狀況下難以經過一種存儲工具解決全部問題，所以須要多種存儲複合使用，以提升效率及用戶的使用體驗。

再又如應用的部署，從集中式架構到分佈式架構，SOA服務化，再到時下流行的微服務架構，接入層的負載均衡設備解決了無狀態WEB應用的擴展問題，而軟負載中心則解決了服務發現和服務路由的問題，輕量虛擬化及docker的出現使得Martin Fowler所提出的微服務理念可以更容易成爲現實，固然，大型網站還須要考慮好比某個地域出現不可抗力因素時，如何保障整站的可用性以及數據完整性，諸如同城容災，異地容災（如兩地三中心），以及時下正處於風口浪尖的異地雙活、異地多活架構。

大型網站的架構每每不是一蹴而就的，而是經過需求的推進通過多年演變一步步造成的，不一樣的時期不一樣的階段不一樣的規模，所面臨的業務不一樣、需求不一樣、須要解決的核心問題也不一樣，這就致使不一樣的階段不一樣的架構，而且架構也是不斷演進與發展的。

CSND：大型網站有哪些典型的故障以及一般有哪些解決之道或相應的優化建議呢？

陳康賢：一個成規模的網站可能天天都在經歷故障，只不過故障可能在絕大部分人感知到以前就已經修復了，致使故障的緣由不少，有多是業務邏輯的變動對於依賴的測試不充分，或者是不兼容的版本升級致使的序列化錯誤，又或者是測試用例未覆蓋到的程序bug，又或者是不一樣版本jar包的同名類衝突問題等等，也有多是訪問量過高致使日誌將磁盤打爆，又或者是機器負載太高致使大量線程阻塞，又或者是鎖競爭過於激烈致使進程僵死，或者是數據庫鏈接池用完，JVM頻繁GC等等。

另外也有多是因爲物理環境問題，好比網線被拔掉，光纖被挖斷，機房停電，硬件設備損壞等等，致使故障的緣由可能千奇百怪，很難一一枚舉，對於變動所致使的故障，能作的是讓測試用例儘量全面的覆蓋到每個細節，包括依賴項，項目設計階段多考慮風險，按照流程來發布，可是也不能因噎廢食，使得發佈流程沉重僵化，對新的業務需求響應緩慢，實際上這也是一個很難拿捏的度。

此外就是要創建起完善的監控系統，包括異常日誌收集分析，業務流程全鏈路校驗，機器運行狀態檢測（負載、qps、磁盤、內存、網絡、運行水位），歷史數據的分析，異常報警等，對於服務化的架構，還須要完善服務治理，包括強弱依賴管理，調用關係（誰調用了誰，誰被誰調用了），調用頻次，異常情況等，這其實是一個體系化的工做，也是一個比較基礎的工做，有了這些以後，你纔可以及時的感知到系統的異常情況，及時定位問題，修復問題。

CSDN：構建一個網站時，能夠選擇開源或自主研發，前者因萬一選用的開源方案在未來才發現某一些特性不知足，就得推倒重來，然後者則彷佛有重複造輪子的嫌疑，對此你怎麼看？

陳康賢：這個問題得辯證來看，使用開源可以下降很大的工做量，可是也會存在潛在的風險，特別是一些未獲得普遍驗證的技術，即使是使用的十分普遍的如Struts、SSL，也時不時會爆出一些驚人的漏洞，對於小公司來講，使用開源的技術可以快速的構建出一個勘用的網站，即使是在使用開源軟件的過程當中遇到問題，切換的成本可能也不會很高，可是對於大公司而言，切換的成本可能會變得很是的高，由於業務和依賴關係實在是太複雜，一旦大規模使用，影響的範圍可能很是廣，所以在作選擇以前不得不很是之慎重，固然，咱們也會有一些比較特殊的需求，開源軟件沒法知足，或者說是走在了開源的前面，這些工具、中間件就須要本身動手開發了。

另外就是開源的軟件有些特性實際上與咱們的指望有很大的差距，而他們自己的架構可能又不是那麼方便擴展，可是這些特性對於咱們來講又十分的關鍵，好比Hadoop，它的MapReduce、HDFS、Hive提供一整套海量數據的分析解決方案，可是底層的權限控制作的很弱，所以咱們不得不花了很大的精力開發出一套替代方案，又花費很大的精力將原來Hadoop上的數據和Job遷移到新平臺。對於開源技術的選擇，咱們更傾向於選擇一些社區比較活躍比較成熟的軟件，最好是有一些比較成規模的成功案例的，這樣的風險會小一些，畢竟對於一家成熟的電商網站來講，穩定大於一切，系統的不可用時間是跟成交金額直接關聯的，分分秒秒過去的時間，就是實實在在的金錢。

對於較爲核心的應用所引入的開源技術，咱們也會花費較大的精力深刻地去了解，作一些bugfix，避免踩到一些坑。

另一點就是大公司的不少場景多是很是特殊的，好比高併發場景下的MySAL數據庫行鎖，大對象常駐內存時的JVM的內存回收，一些軟件可能爲了知足通用的需求，犧牲了一些特殊場景下的性能。所以，對於咱們來講，瞭解這些後，也是有必定的優化空間的，包括從實現上去規避，或者是去改造開源軟件，而作這些的前提就是對開源軟件的瞭解。

CSDN：通常網站面臨的問題就是負載的問題，當人數多，致使速度慢是主要解決的問題，對此你有什麼建議？

陳康賢：相較於傳統企業來講，大部分互聯網企業都會面臨的一個很大的挑戰，隨着用戶規模的不斷擴大，系統的壓力會愈來愈大，而在創業初期，系統的架構設計每每是一切從簡甚至根本沒有架構，快速迭代，優先知足業務，而受市場環境的影響業務每每是多變的，所以每每會背下「技術債」，業務邏輯高度耦合，系統不可擴展，代碼結構臃腫，此時不得不進行重構。

「分佈式」是應對大流量核心思想，首先，系統得作好準備，支持擴展，尤爲是在數據、模型層面，由於數據的拆分、擴容、數據遷移最麻煩最費時間，稍有不慎，還可能致使數據不一致，形成的損失也有多是沒法挽回的，方案設計必須得慎之又慎，在數據拆分遷移的同時，新的數據正在源源不斷的寫入，老的數據也經常會面臨高併發的更新，所以，業界常常將數據拆分擴容比喻成是在給一架高速飛行的飛機換引擎，這也是整個擴容過程當中，最複雜，技術含量最高，最有挑戰的任務。

再就是集中式應用的業務邏輯拆分，原先團隊規模小，業務量也小，可能會在少數幾個應用上堆了不少代碼和業務邏輯，而隨着公司規模的增加，業務迅速發展，團隊規模愈來愈大，集中式的應用維護將會變得十分困難，這既包括開發部署，筆者曾經開發過一個應用，改幾行代碼，本地編譯打包須要10幾分鐘，本地部署又須要十幾分鍾，這極大的下降了開發的效率，另外這樣的巨無霸工程也會佔用不少服務器資源，而單機的硬件資源又不可能無限升級，這也會是一個問題，再者就是耦合的業務邏輯也不便於複用，得四處重複造輪子，浪費資源，這又引伸出另外一塊，也就是企業內部的服務化。

SOA架構包括時下流行的微服務理念，解決的是企業內部資源複用的問題，避免信息孤島和重複造輪子，提升系統可維護性，下降業務試錯以及系統構建成本，提高企業競爭力。通用的統一的SOA通訊標準，包括通訊協議、序列化反序列化方式，可以簡化SOA架構的實現，服務的自動註冊、路由、軟負載能下降運維成本，隨着服務的增長，單靠人工來進行服務治理愈來愈困難，又衍生了服務治理系統，對服務的調用，依賴，異常等信息進行統一的管理。當應用變得無狀態以後，擴容就很是方便了，經過負載均衡軟硬件設施，或者是SOA的軟負載機制，能夠根據須要十分方便的增減機器擴充容量，而這種能力幾乎是線性的(在必定規模下)。固然，大部分的場景以及技術解決方案，國外的Yahoo、Google、Facebook、Linkin 、Twitter…，國內的BAT，這些知名的互聯網企業，實際上很大程度上已經充當先驅，後來的追隨者，只須要緊隨前人的腳步，驀直前行，架構的風險已經被大大的下降。

架構師的技能或素養，架構師到底要不要寫代碼？

CSDN：成爲一名架構師須要哪些的技能或素養？

陳康賢：如下僅表明我的觀點，設計符合要求的系統是架構師的基本技能，功能、可用性、可擴展性，以及團隊能力、項目執行風險、運行環境都須要綜合考慮，架構師的功力更多體如今技術的綜合運用上，所以對於項目所須要的技術細節的瞭解必須是全面的，這樣纔可以將最合適的技術用在最須要的地方，而且還須要有技術的前瞻性，經過經驗以及積累發現可能潛在的風險，對於問題的理解，不可以僅停留在表面，邏輯思惟和抽象思惟能力是一個架構師的重要素質。

固然，做爲架構師還須要一個很是重要的技能，就是充分的溝通，完成系統的設計只是萬里長征的第一步，設計思想須要充分的傳達給團隊中，而且從團隊中獲得相應的反饋，對方案進行調整，不斷完善，只有在團隊中全部人都瞭解領悟了你的設計以後，後續的推動包括項目的實施纔可以變得順暢，細節是魔鬼，在後續的執行過程當中，可能會面臨各類問題，涉及到的方案調整，溝通協調是不可避免的，做爲架構師來講，須要有充分的準備，好的架構師可以帶領團隊高歌猛進，而不稱職的架構師最終會致使矛盾重重，對於合做的團隊來講，須要確承認能的風險，包括接口，時間節點，兼容性，對接可能遇到的技術問題，對於可能遇到的風險，架構師必須瞭然於胸，提早準備，從容應對。

Linus Torvalds說，

Talk is cheap, show me the code.

可是我想說的是，

Talk is not cheap, talk is important too!

不少人會問，架構師到底要不要寫代碼，首先，我的認爲，架構師是須要寫代碼的，無奈時間是有限的，項目的規模越大，所須要思考的細節點越多，天然而然花費的時間越多；除此以外，做爲架構師的你還須要傳播佈道，告訴全部人你理解的架構是什麼樣子，告訴你們怎麼作如何作，核心的目標是什麼，核心的風險是什麼；架構師還須要協調各個依賴的關聯繫統，告訴其餘人你要作一件什麼事情，須要其餘人怎麼配合，作這件事的價值以及其餘人爲什麼要配合你，這一樣須要花費大量的時間，那麼，在剩下很少的時間裏，架構師能寫的代碼可能很少，可是，爲了讓你設計的系統不脫離現實，你必須寫代碼，必須Review核心關鍵代碼，確保總體架構的思路獲得貫徹，確保你的設計是易於實施的，確保潛在的風險獲得妥善的控制，特別是在有新技術引入的狀況下，原型驗證是必不可少的步驟。有種觀點認爲，架構師必須是代碼貢獻最多的，一我的寫代碼，天然不需統一思想，可是實際上這很難作到，做爲架構師你得記住，不是你一我的在奮鬥，不要讓本身成爲團隊的瓶頸，可是，我一樣也不同意架構師徹底不編碼，不親身體驗過，有的風險是很難事先作出判斷的，況且技術自己也在發展，今天的經驗放在明天不必定有效，做爲程序員的最基本技能，編碼是你學習和積累的最直接的方式。

架構師也是一個普通人，一天只有24小時，須要花費不少時間進行方案設計，技術合理性思考，原型驗證，還須要花費大量的時間給團隊傳達設計思想和目標，爲什麼這樣設計，這樣設計有什麼好處，不這樣設計會有什麼樣的問題，人是最複雜的生物，程序員都是很是有個性而且很是聰明的，統一思想統一目標是一個很是艱鉅的任務，一千我的心中有一千個哈姆雷特，一樣，作一件事情可能也有不一樣的方法，方法太多有時候並非好事，做爲架構師，須要找出最合適的方法，並讓它獲得你們承認，這並不是是把我的目標轉化爲團隊目標的過程，而是不斷地溝通不斷的改進演化以後，在你們充分參與的前提下找到的最適合當前業務場景的方案。

CSND：對將來你有着怎樣的規劃和期許？

陳康賢：技術這條路註定不是坦途，碼農大多數時候的生活是枯燥無味的，而且這又是一個學無止境的行業，技術的更新換代很是快，失敗的糾結，苦思冥想的無奈，成功的喜悅，其中的酸甜苦辣，我想只有真正的碼農才能體會。

近期來看，應該會繼續專一於直播，阿里在電商領域積累了豐富的經驗，可是對於直播來講還屬於一個有待成熟的領域，還有很大的提高空間，技術挑戰也是比較大的，後續但願可以作一些事情，下降直播的門檻，下降資源的消耗，提升服務的穩定性。 就跟《戰爭之王》這部電影裏尤里·奧洛夫（Yuri Orlov）的經典臺詞所說的同樣，人總想在有生之年作件大事，只是暫時還沒想好要作什麼，誠然，我不會跟尤里同樣去販賣軍火，社會的發展和變化太快，很難預料本身五年以後會專一於什麼，從事哪方面的工做，可是，做爲一個熱愛技術，喜歡專研的人，應該仍是會是作跟技術、跟工程能扯上點關係的事情。

CSDN：最後，想給看這篇文章的讀者說些什麼？

陳康賢：當初畢業找工做的時候，說實話也沒想過說一份工做會幹這麼長時間，並且後面可能還要繼續作下去很長時間，實際上畢業的第一份工做很是重要，由於當你開始工做以後，你將再也不是一張白紙，而你後續再去找工做的時候，前面的工做經歷將會是很重要的參考，第一份工做將很大程度影響你後續工做的大方向，後續再想要轉型，可所付出的努力和冒的風險可能更大。

選擇有時候很重要，首先得清楚本身喜歡作什麼樣的工做，由於作本身喜歡作的事情，你更願意付出，不會以爲辛苦，更不會以爲痛苦，而是樂在其中，工做是一件長期的事情，所以，值得你好好想一想本身到底喜歡作什麼。

另外就是看後續的成長空間，一滴水到了一杯奶中，水就變成了奶，一滴奶到了一杯水中，奶就變成了水，有可能某個公司A給你的offer多了1-2K，而公司B卻可以提供給你一個更大的舞臺去發揮，去成長，給你提供一套系統的培訓和成長體系，而且周圍都是業界大牛，此時的選擇，考驗着你的智慧。

短時間的1-2K，從長遠來看，實際上真的不算什麼，可是損失多是長期的發展空間，那有人說，工資給的高不說明更重視麼，話雖沒錯，可是去到一個沒有發展空間的公司，或者已是夕陽產業，也許你確實很優秀，可能你的高度就表明了公司最高的高度，那麼你的空間在哪，這其實是一個雞頭鳳尾的抉擇問題，選擇一個更有空間更有潛力的公司，可能剛開始你在團隊中並非那麼出色，可是，認真工做幾年後，你再出去跟同齡人比，區別仍是蠻大的，而且，優秀、成熟的公司會有一套相對公平的評價機制，總的來說，會讓足夠優秀而且給公司創造更多價值的人，獲得相應的回報，因此也不用擔憂回報的問題。實際上HR也不傻，你獲得的回報多是經濟上的回報+成長空間的總和，而兩部分加起來，大部分公司給出的價位應該是差很少的。

機會是老是留給有準備的人，選擇很重要，堅持有時候也很重要，作事情得要能沉的下心，不要怕困難，人生就像騎單車，想保持平衡就得往前走。

但願前面所說的內容可以對你們有所幫助，也歡迎你們跟我交流。

陳康賢的聯繫方式：

Email: longlong@taobao.com

sina微博: 淘寶龍隆

（責編/錢曙光，關注架構和算法領域，尋求報道或者投稿請發郵件qianshg@csdn.net，交流探討可加微信qshuguang2008，備註姓名+公司+職位）

「CSDN 高級架構師羣」，內有諸多知名互聯網公司的大牛架構師，歡迎架構師加微信qshuguang2008入羣，備註姓名+公司+職位。

2016年3月18日-19日，由CSDN重磅打造的數據庫核心技術與實戰應用峯會、互聯網應用架構實戰峯會將在上海舉行。這兩場峯會將邀請業內頂尖的架構師和技術專家，共同探討高可用/高併發系統架構設計、新技術應用、移動應用架構、微服務、智能硬件架構、雲數據庫實戰、新一代數據庫平臺、產品選型、性能調優、大數據應用實戰等領域的熱點話題與技術。