數據中心內部去堆疊架構

❶ 07 數據中心供配電系統架構

數據中心供配電系統是從電源線路進用戶起經過高/低壓供配電設備到負載止的整個電路系統，主要包括：高壓變配電系統、柴油發電機系統、自動轉換開關系統（ATSE，Automatic Transfer Switching Equipment）、輸入低壓配電系統、不間斷電源系統（UPS，Uninterruptible Power System）系統、UPS列頭配電系統和機架配電系統、電氣照明、防雷及接地系統。

❷ 數據中心網路架構扁平化到兩層的方式有何弊端

我是學信息管理與信息系統的。

首先說一下什麼是數據中心網路架構。顧名思義，不論是在酒店的管理系統中掌握的顧客信息、學校的學生教務系統中掌握的成績信息、還是醫院的醫療系統中掌握的病人信息，在管理系統中都稱之為數據。隨著網路技術以及管理系統的不斷演進和發展，利用網路平台管理信息數據的管理系統通常是以數據中心網路架構作為基礎，從而一步一步實現的。

數據中心網路架構扁平化設置主要是基於數據傳輸效率和容錯能力，存在不少缺點。默認的聚合設備導致埠號增多，對設備本身進行轉發，計算處理能力，甚至對產品架構提出更高的要求，設備損耗很快。

❸ 數據中心整合IT基礎架構 我們需要考慮什麼

互用性是個老大難的問題，供應廠常常把責任推給其他製造商。對於多種產品構成的系統來說，以上問題使得管理更加復雜化，關鍵產品的支持也不得不延期。在過去幾年，我們看到更多的數據中心採用了整合方法——由一個供應商直接提供歐諾個整套數據中心硬體——來解決這些問題。 本文中，TechTarget數據中心的Nick Martin連線MTM Technologies Inc.的虛擬化架構師Bill Kleyman，為讀者挖掘出更多關於整合基礎架構平台的信息，以及IT人員對此需要考慮的關注點。 Nick Martin：對於整合基礎架構平台，我們需要權衡什麼？比如，刀片還是機架硬體？ Bill Kleyman：一個公司，不管要選擇哪種數據中心基礎架構平台，都得考量其優缺點，其關鍵是公司的明確業務驅動是什麼。機架硬體環境和刀片機箱解決方案都可以做得很好。 HP ProLiant機架伺服器定位就很精確，它們能夠用大量內核處理上百個gigabyte的RAM，就依賴於你的處理器。這些機器可以處理虛擬化、應用託管和普遍的伺服器需求。要點在於明白這個硬體在公司的短期目標和長期目標中扮演了什麼角色。 最好結合實例來理解，假如一個公司正在急速擴張，他們已經購買了在XenServer或者VMware的虛擬化平台。從那裡，他們計劃把全部台式電腦作為「使用各自設備工作」方針的一部分。這個環境將一直擴張成長，那最佳的解決方案是什麼呢？ 如果他們購買獨立伺服器，管理員就得個別地管理每個箱子，或者通過一些第三方管理工具。他們還需要管理工作負載、硬體配置和網路，確保所有的獨立伺服器工作運行良好。 另一方面，如果有了一個整合的基礎架構。就可以解決問題。思科UCS（統一計算系統）是個不錯的例子。使用這個解決方案之後，公司就能在一片屋檐下擁有所有數據中心基礎架構的元件。網路和交換，刀片管理和機箱控制都在一個GUI（圖形用戶界面）中。管理員可以復制整個硬體配置，然後載入到休眠中的伺服器，以便快速配置。管理和發展都成了比較輕松的工作。 如今，如果同樣的公司仍然想要虛擬化，但是自知計算需求有限，那選擇機架伺服器可能才是最好的。 Martin：那麼整合基礎架構有那些優缺點呢？ Kleyman：可管理性和發展潛力的難度降低，這是我們最容易想到的好處。周圍建設的管理工具控制並修改刀片機箱的工作呈極度粒狀。 管理者能夠登入，並馬上看到他們需要了解的環境信息。以UCS GUI為例，工程師可以登入查看環境中是否有關鍵性錯誤。如果發現問題，他們可以深入到問題所在確切位置的刀片，並下至DIMM slot的層面解決問題。管理硬體配置也變簡單了，把新的刀片放進機箱，你可以從一個刀片把屬性復制到另一個刀片，花不了多久就能將其就位。這意味著配置整個機架所有的刀片不需幾天，只需幾分鍾。 但是缺點也很明顯。使用整合基礎架構最大的好處之一是「一步到位」，但是這某種意義上也是缺點。記住，整合基礎架構的管理是為在已有環境中特定分析和觀察而設計的。所以，你放置任何東西若是超過了該環境，就得用另一種方式重新監測。不要忘了hyperviser層面、後備和快照的工作負載管理，以及一切需要企業應用管理的東西。這些將會變得獨立，而且需要監控和管理。】

❹ 數據中心是什麼其系統結構和工作原理是怎樣的呢

一直想整理一下這塊內容，既然是漫談，就想起什麼說什麼吧。我一直是在互聯網行業，就以互聯網行業來說。
先大概列一下互聯網行業數據倉庫、數據平台的用途：

• 整合公司所有業務數據，建立統一的數據中心；

• 提供各種報表，有給高層的，有給各個業務的；

• 為網站運營提供運營上的數據支持，就是通過數據，讓運營及時了解網站和產品的運營效果；

• 為各個業務提供線上或線下的數據支持，成為公司統一的數據交換與提供平台；

• 分析用戶行為數據，通過數據挖掘來降低投入成本，提高投入效果；比如廣告定向精準投放、用戶個性化推薦等；

• 開發數據產品，直接或間接為公司盈利；

• 建設開放數據平台，開放公司數據；

• 。。。。。。



• 上面列出的內容看上去和傳統行業數據倉庫用途差不多，並且都要求數據倉庫/數據平台有很好的穩定性、可靠性；但在互聯網行業，除了數據量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 ，另外，互聯網行業的業務變化非常快，不可能像傳統行業一樣，可以使用自頂向下的方法建立數據倉庫，一勞永逸，它要求新的業務很快能融入數據倉庫中來，老的下線的業務，能很方便的從現有的數據倉庫中下線；


• 其實，互聯網行業的數據倉庫就是所謂的敏捷數據倉庫，不但要求能快速的響應數據，也要求能快速的響應業務；


• 建設敏捷數據倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數據建模，如果一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模（比如：基於網站日誌建立的網站統計分析模型和用戶瀏覽軌跡模型；基於公司核心用戶數據建立的用戶模型），其它的業務一般都採用維度+寬表的方式來建立數據模型。這塊是後話。


• 整體架構下面的圖是我們目前使用的數據平台架構圖，其實大多公司應該都差不多：


• 邏輯上，一般都有數據採集層、數據存儲與分析層、數據共享層、數據應用層。可能叫法有所不同，本質上的角色都大同小異。


• 我們從下往上看：


• 數據採集數據採集層的任務就是把數據從各種數據源中採集和存儲到數據存儲上，期間有可能會做一些簡單的清洗。



• 數據源的種類比較多：



• 網站日誌：



• 作為互聯網行業，網站日誌占的份額最大，網站日誌存儲在多台網站日誌伺服器上，


• 一般是在每台網站日誌伺服器上部署flume agent，實時的收集網站日誌並存儲到HDFS上；



• 業務資料庫：



• 業務資料庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，我們迫切的需要一種能從各種資料庫中將數據同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管數據量大小，都需要啟動MapRece來執行，而且需要Hadoop集群的每台機器都能訪問業務資料庫；應對此場景，淘寶開源的DataX，是一個很好的解決方案（可參考文章 《異構數據源海量數據交換工具-Taobao DataX 下載和使用》），有資源的話，可以基於DataX之上做二次開發，就能非常好的解決，我們目前使用的DataHub也是。


• 當然，Flume通過配置與開發，也可以實時的從資料庫中同步數據到HDFS。



• 來自於Ftp/Http的數據源：



• 有可能一些合作夥伴提供的數據，需要通過Ftp/Http等定時獲取，DataX也可以滿足該需求；



• 其他數據源：



• 比如一些手工錄入的數據，只需要提供一個介面或小程序，即可完成；



• 數據存儲與分析毋庸置疑，HDFS是大數據環境下數據倉庫/數據平台最完美的數據存儲解決方案。



• 離線數據分析與計算，也就是對實時性要求不高的部分，在我看來，Hive還是首當其沖的選擇，豐富的數據類型、內置函數；壓縮比非常高的ORC文件存儲格式；非常方便的SQL支持，使得Hive在基於結構化數據上的統計分析遠遠比MapRece要高效的多，一句SQL可以完成的需求，開發MR可能需要上百行代碼；


• 當然，使用Hadoop框架自然而然也提供了MapRece介面，如果真的很樂意開發Java，或者對SQL不熟，那麼也可以使用MapRece來做分析與計算；Spark是這兩年非常火的，經過實踐，它的性能的確比MapRece要好很多，而且和Hive、Yarn結合的越來越好，因此，必須支持使用Spark和SparkSQL來做分析和計算。因為已經有Hadoop Yarn，使用Spark其實是非常容易的，不用單獨部署Spark集群，關於Spark On Yarn的相關文章，可參考：《Spark On Yarn系列文章》


• 實時計算部分，後面單獨說。


• 數據共享這里的數據共享，其實指的是前面數據分析與計算後的結果存放的地方，其實就是關系型資料庫和NOSQL資料庫；



• 前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取數據，那麼就需要一個數據共享的地方，使得各業務和產品能方便的獲取數據；和數據採集層到HDFS剛好相反，這里需要一個從HDFS將數據同步至其他目標數據源的工具，同樣，DataX也可以滿足。


• 另外，一些實時計算的結果數據可能由實時計算模塊直接寫入數據共享。



• 數據應用

• 業務產品
  



• 業務產品所使用的數據，已經存在於數據共享層，他們直接從數據共享層訪問即可；



• 報表



• 同業務產品，報表所使用的數據，一般也是已經統計匯總好的，存放於數據共享層；



• 即席查詢



• 即席查詢的用戶有很多，有可能是數據開發人員、網站和產品運營人員、數據分析人員、甚至是部門老大，他們都有即席查詢數據的需求；


• 這種即席查詢通常是現有的報表和數據共享層的數據並不能滿足他們的需求，需要從數據存儲層直接查詢。


• 即席查詢一般是通過SQL完成，最大的難度在於響應速度上，使用Hive有點慢，目前我的解決方案是SparkSQL，它的響應速度較Hive快很多，而且能很好的與Hive兼容。


• 當然，你也可以使用Impala，如果不在乎平台中再多一個框架的話。



• OLAP



• 目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數據，都是通過將需要的數據同步到關系型資料庫中做OLAP，但如果數據量巨大的話，關系型資料庫顯然不行；


• 這時候，需要做相應的開發，從HDFS或者HBase中獲取數據，完成OLAP的功能；


• 比如：根據用戶在界面上選擇的不定的維度和指標，通過開發介面，從HBase中獲取數據來展示。



• 其它數據介面
  



• 這種介面有通用的，有定製的。比如：一個從Redis中獲取用戶屬性的介面是通用的，所有的業務都可以調用這個介面來獲取用戶屬性。



• 實時計算現在業務對數據倉庫實時性的需求越來越多，比如：實時的了解網站的整體流量；實時的獲取一個廣告的曝光和點擊；在海量數據下，依靠傳統資料庫和傳統實現方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時低的、高可靠的實時計算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡單，不想多引入一個框架到平台中，另外，Spark Streaming比Storm延時性高那麼一點點，那對於我們的需要可以忽略。


• 我們目前使用Spark Streaming實現了實時的網站流量統計、實時的廣告效果統計兩塊功能。


• 做法也很簡單，由Flume在前端日誌伺服器上收集網站日誌和廣告日誌，實時的發送給Spark Streaming，由Spark Streaming完成統計，將數據存儲至Redis，業務通過訪問Redis實時獲取。


• 任務調度與監控在數據倉庫/數據平台中，有各種各樣非常多的程序和任務，比如：數據採集任務、數據同步任務、數據分析任務等；



• 這些任務除了定時調度，還存在非常復雜的任務依賴關系，比如：數據分析任務必須等相應的數據採集任務完成後才能開始；數據同步任務需要等數據分析任務完成後才能開始；這就需要一個非常完善的任務調度與監控系統，它作為數據倉庫/數據平台的中樞，負責調度和監控所有任務的分配與運行。


• 前面有寫過文章，《大數據平台中的任務調度與監控》,這里不再累贅。


• 總結在我看來架構並不是技術越多越新越好，而是在可以滿足需求的情況下，越簡單越穩定越好。目前在我們的數據平台中，開發更多的是關注業務，而不是技術，他們把業務和需求搞清楚了，基本上只需要做簡單的SQL開發，然後配置到調度系統就可以了，如果任務異常，會收到告警。這樣，可以使更多的資源專注於業務之上。

❺ 如何看待數據中心網路架構變化

隨著雲計算、虛擬化、SDN等技術在數據中心持續落地，數據中心網路到了不得不改變的時候了。為了滿足這些新的技術需求，數據中心網路架構也從傳統的三層網路向大二層網路架構轉變，也就是新一代的數據中心將採用二層的網路架構，所有的接入設備都連接到核心網路設備上，然後通過核心設備路由轉發出去。在數據中心內部完全是一個二層網路，而且為了實現跨數據中心的VM遷移，數據中心之間也可以跑二層，當前是虛擬的二層網路，基於物理三層網路來跑二層。數據中心內部網路架構向大二層轉變的趨勢已經無法更改，將會有越來越多的數據中心網路架構向這個方向發展。數據中心內部網路建設成為一個大的二層網路，雖然架構上清晰了，簡單了，但是卻帶來不少的現實難題。下面就來說一說，新一代數據中心網路架構變革所遇到的難題。

大二層MAC容量問題

數據中心網路架構向著大二層方向演變，首先帶來的就是MAC容量的難題。二層網路根據MAC地址來完成點到點的轉發，在數據中心裡擁有數千台伺服器是再普通不過的了，而如今跨數據中心之間也要實現二層轉發，這樣就要求數據中心的核心設備MAC容量超大才行。比如一個中等城市寬頻網路至少要擁有100萬個家庭，要實現所有的家庭寬頻上網，若都採用二層的數據中心網路，則需要核心網路設備可以處理1M的MAC容量，這對網路設備提出了很高的要求。目前能夠達到1M的MAC容量的網路設備的確有，但是應用並不普遍，32K~256K是最常用的容量規格。採用1M的MAC容量設備，這樣的設備往往價格很高，會給數據中心帶來沉重的負擔，而且這樣大規格的設備使用並不普及，設備的穩定性低。很多能夠達到1M的MAC容量的設備採用的都是晶元外掛TCAM來實現的，這種方式由於是通過PCI匯流排來訪問外掛器件，訪問速度自然沒有晶元內快，所以這種方式的MAC學習速度並不是線速的。在一些網路環路、震盪中，這些設備就會表現出MAC學習不穩定，流量有丟包，顯示有問題等一系列待解決的問題。所以在大二層的數據中心網路中，如何提升網路設備的MAC容量，是當前網路技術中急需解決的問題。如今通過技術手段達到1M以上MAC容量並不是難事，但在這種網路環境下，要保證網路運行的穩定性，還有很多的技術難題要解決。

環路問題

二層網路最常見的網路故障就是環路問題，在網路規模比較小的情況下，可以通過部署STP/MSTP這些環路協議避免環路的產生。當然STP/MSTP協議有天生的缺陷，阻塞了備用鏈路，造成網路帶寬的嚴重浪費，後來又出現了TRILL新的二層網路環路協議。TRILL協議可以保證所有的鏈路都處於轉發狀態，避免了網路帶寬的浪費。不過我們知道TRILL實際上要靠ISIS協議來維持TRILL協議的狀態，當網路規模很大的時候，網路設備要處理大量的ISIS協議，這對網路設備是一個不小的沖擊。能夠擁有1M的MAC容量的網路設備，埠數量要數百個，要保證所有這些的埠的TRILL狀態計算準備，並且在有網路震盪的情況下，TRILL協議仍能正確切換，這對網路設備要求很高，尤其要保證 TRILL協議的切換速度。比如像STP協議，在正常切換的情況下，速度都要30秒，而若網路規模比較大，則所花費的時間會更長，達到分鍾級別都是有可能的。TRILL協議也是如此，ISIS協議並不是快速收斂的協議，超時時間，切換速度都不比STP協議快，所以在TRILL的二層環路網路中，一旦發生網路切換，那麼收斂速度是個問題。數據中心很多業務是非常敏感的，在網路出現丟包或者震盪數秒鍾，都會影響到業務，所以當數據中心二層網路規模擴大以後，環路協議的收斂問題突顯。有人建議將TRILL的ISIS協議處理提升優先順序，比如放到一個單核上處理，通過軟體中斷的方式處理響應，這樣能夠大大提升切換的速度，避免受到其它協議的影響，當然這樣自然會佔用更多的設備資源，而且效果也未知。

廣播域過大的問題

大二層還會遇到一個問題就是廣播域過大。因為整個數據中心，甚至多個數據中心之間都是二層的，那麼一個廣播報文會在整個數據中心的設備上進行廣播的，顯然會佔用大量的網路帶寬，如果廣播流量比較多，可能會造成個別的埠出現擁塞，從而影響業務。在正常的網路中，肯定是廣播流量越小越好。對於大二層網路廣播域過大的問題，還好有一些解決的方法，而且這些方法目前看是比較符合實際的。比如：默認情況下，禁止廣播報文的轉發，讓廣播報文和組播報文一樣，通過協議控制轉發，只有協議狀態計算好之後，才允許廣播報文轉發，而且是像組播一樣，只轉發給請求接收的埠，也就是在未來的數據中心裡將沒有廣播的概念，只有單播和組播的概念。對於跨數據中心的二層，這種二層轉發實際上是一種邏輯上的二層轉發，要通過物理三層轉發，是一種封裝技術，這樣就可以通過軟體控制這種情況下，廣播報文要不要轉發。在默認情況下，跨數據中心的二層廣播報文是不轉發的，可以通過軟體設置讓特定的廣播報文轉發。還有就是對廣播報文設置廣播抑制比，當埠上的廣播流量達到一定比例時，對廣播報文進行丟棄。顯然，對於大二層廣播域過大的問題，目前已經有了一些比較好的解決方法，可以很好地解決這一問題。

盡管數據中心網路架構的演變面臨著各種各樣的問題，但是向大二層轉變的趨勢已經無法改變。縱然這樣的架構給數據中心帶來了新的問題，但是正是有了這些缺陷，也給了網路設備商機會，誰能很好地解決這些問題，誰就能在未來的網路市場上戰勝對手，贏得市場。

❻ 在大型的雲計算數據中心，一般採用哪些架構

建立數據中心需要相關資質及建設標准，國內服務商有自建數據中心的不多，像BAT、小鳥雲等

大致來說有一下四個方面：

機房建設：強電，空調，弱電，安防，消防，裝修等
基礎設施：柴油發電機，不間斷電源，冷水機組，精密空調，視屏門禁等
機房設備：伺服器，存儲器，路由器，交換機，防火牆，負載均衡，監控設備等
網路接入：專線，裸纖，英特網，電話線，BGP接入，室內綜合布線等

❼ 數據中心架構圖怎麼畫

看了 很多下面這個應該是最標準的，參照畫就可以了額。工具嘛viso 即可

❽ 數據中心的架構展望

以Web為中心的計算技術的興起意味著關注IT資產的角度從物理轉向了邏輯。
德國哲學家尼采說過：「那些未能摧毀我的，使我更強大。」是的，如果你能在這一度繁榮又一度蕭條的IT輪回中活下來而不會感到焦頭爛額，那麼你一定覺得自己真的很強大。不過且慢，還不到松一口氣的時候，現在你需要利用已經積聚起的每一分力量，去和面前那些動搖IT業的變革做一番爭斗。
主要的技術供應商和向前看的網路及IT經理人都認為，一個以Web為中心的嶄新計算模型正在孕育成形，但是對於這個計算模型最終的形態以及該如何命名，他們卻莫衷一是。會象IBM鼓吹的那樣成為按需計算嗎？會是Oracle、Sun和其他廠商力推的網格技術熱嗎？還是完全朝著公用計算、自動計算、虛擬化或其它方向前進呢？
諸如Cisco、EMC、HP和微軟等技術巨擘都在為爭取你的歡心而激烈較量，而設計上的勝利者將在未來十年收益頗豐。（證據何在？只要看看現在Wintel陣營的統治地位和客戶機/伺服器領域。）
你不得不對這些高高在上的理念進行一番甄選，研究研究你的關鍵技術供應商的發展路線，與此同時，針對你的基礎架構的每一層及其上面的應用努力做出最佳選擇。
不用擔心，讓我們來為你了解眼前的變革助上一臂之力。我們將在本文探索一種我們稱之為新數據中心的概念。新數據中心的出現代表著IT業內一場靜悄悄的革命，一場既有風險又能為你和你的戰略供應商帶來回報的革命。
業界能否最終把未來數年稱之為「新數據中心時代」，只有時間知道。我們在此提出這一概念僅供你在設計新的網路化IT環境時參考之用。 然後，你就得為各種相互競爭的操作系統（Unix、Linux和Windows）決定它們的最佳作用，每一種操作系統都經歷著不同的成功道路。在Windows領域，你正在關注操作系統和微軟其它核心軟體組件的多種升級技術，以便支持更強有力的合作和應用集成。
另外，你還要為新一代的Web應用挑選開發平台。如果你對圍繞這些新應用的各種標准、安全和管理問題尚不了解，那麼很快你就會變得內行。 你的網路基礎架構必須能夠滿足合作新需求以及Web應用的爆炸性增長。為VoIP和新興的會話初始化協議（Session Initiation Protocol）應用提供高質量支持做好准備，這有可能意味著將中樞和數據中心交換機升級至10Gb/秒乙太網，以及將配線室升級至1G。
許多公司還部署了一大批新設備，以解決具體的高容量、高交易量Web站點和Web新應用的問題－－比方說，第4層至第7層交換機、安全套接字層加速和負載平衡等。在整個Web基礎架構生態系統中，各廠商相互競爭的領域不僅在產品性能上，也在將更多功能合並至一台設備的能力上。不過最終你希望構建一個單一的網路基礎架構，而不必繼續為每一次網路新挑戰急急惶惶。這將導致Web和傳統基礎架構廠商之間在控制能夠支持現有和分布式新應用的統一網路時發生沖突。 牢固的安全措施是新數據中心所必需的，但目前仍然很難描述。各種威脅不斷變化而且攻擊越來越密集，但是各公司卻想方設法讓應用更加分散、信息更容易訪問，這兩者結合是很危險的。
在未來幾年，你必須選擇如何以最佳方式在整個新數據中心部署安全技術：應該安裝什麼硬體、軟體和網路基礎架構安全工具？管理化安全服務應該起到什麼作用（如果能起作用的話）？你如何使用越來越多的安全工具管理數據大潮？還有令人頭疼的是，不斷打補丁的軟體和無線技術安全難題，這些可真夠你受的。 隨新數據中心而來的是系統和網路管理的新需求。主要廠商必須超越設備管理層面，讓用戶對應用性能有清晰了解－－然後提供各種工具確保這些性能的發揮。還有，你需要更好地支持移動設備、網路和安全管理集成，並且了解和熱衷於IBM、HP和微軟等主要廠商的自動化（即自我恢復）管理戰略。

❾ 騰訊的內部組織架構是怎樣的

騰訊的內部組織架構於2005年升級為BU（Business Unit）事業部制；2012年升級為BG（Business Group）事業群制。2018年9月30日，騰訊公布了組織架構調整方案：在原有七大事業群（BG）的基礎上，保留原有的六大架構體系：

1、企業發展事業群（CDG）：為公司新業務孵化和新業態探索的平台，推動包括基礎支付、金融應用在內的金融科技業務、廣告營銷服務和國際業務等領域的發展和創新。同時作為專業支持平台，為公司及各事業群提供戰略規劃、投資並購、投資者關系及國際傳訊、市場公關等專業支持。

2、互動娛樂事業群（IEG）：發展網路游戲、電競等互動娛樂業務，打造一個從策劃、研發、發行，運營及營銷的垂直生態鏈。致力為中國以及全球游戲用戶創造高品質產品，並通過在線游戲，直播和線下電競賽事聯動用戶，提升總體游戲體驗。

3、技術工程事業群（TEG）：為公司及各事業群提供技術及運營平台支持、研發管理、數據中心的建設與運營，並為用戶提供全線產品的客戶服務。作為運營著亞洲最大網路、伺服器集群和數據中心的事業群，並牽頭騰訊技術委員會，通過內部分布式開源協同，加強基礎研發，建設技術中台等措施，支持業務創新。

4、微信事業群（WXG）：搭建和運營微信生態體系，依託微信基礎平台，以及微信公眾號、小程序、微信支付、企業微信、微信搜索等開放平台，為各行各業的智慧化升級提供解決方案和連接能力。同時開發和運營包括郵箱、通訊錄、微信讀書等產品。

5、雲與智慧產業事業群（CSIG）：推進雲與產業互聯網戰略，依託雲、安全、人工智慧等技術創新，打造智慧產業升級方案。探索用戶與產業的創新互動，打通產業上下游不同企業，聯動線上線下的場景與資源，助力零售、醫療、教育、交通等產業數字化升級，同時協助企業更智能地服務用戶，構建連接用戶與商業的智慧產業新生態。

6、平台與內容事業群（PCG）：推進互聯網平台和內容文化生態融合發展，整合QQ、QQ空間等社交平台，和應用寶、瀏覽器等流量平台，以及新聞資訊、視頻、體育、直播、動漫、影業等內容平台，為內容生態創造更好的生長環境。同時，以技術驅動，推動IP 跨平台多形態發展，為更多用戶創造多樣化的優質數字內容體驗。