起360，我們的第一印象就是“殺毒”。
殺毒是“網絡安全”中重要的一環，在“殺毒”之前，能否精準的識別出垃圾信息及潛在的安全風險，并予以防護，這就是防火墻的作用了。
基于這樣的理念，360在8月8日正式發布了360家庭防火墻路由器5Pro（以下簡稱360防火墻5Pro），可以說這款路由器的設計理念與“防火墻”的概念高度一致——防火墻技術是通過有機結合各類用于安全管理與篩選的軟件和硬件設備；對比路由器，在硬件上，其自身就是硬件；軟件方面，其專屬App支持多項防護措施。就第一印象來說，360家庭防火墻路由器5Pro，最起碼跟防火墻沾上邊了，那么其實際使用體驗到底如何呢？我們來實際測試一下、
一、外觀·配置
當這款360最新發布的家庭防火墻5Pro到達IT之家、并被滄某拿到手時，一時間“花里胡哨”的包裝設計引來其他同事的駐足觀看，“啥呀這是？樂高？”、“不會吧，樂高路由器？這也太高端了吧，趕緊打開看看”！在嘈雜的驚呼聲中，滄某緩緩打開包裝盒，在打開盒子的那一剎那，與包裝盒上五顏六色的樂高色彩不同的是，盒子里靜靜地就只躺著一臺黑色的路由器，外加一張樂高色彩圖——準確的是一張彩色的簡短說明書。
那么問題來了，樂高呢？
360防火墻5Pro整體設計方方正正，其面板設計延續凸點矩陣設計，能夠適配各種積木組件，這也是這款路由器樂高元素所在——用戶可以將自己喜歡的樂高積木擺在上面，增添美觀性。之前那些高喊樂高是“噱頭”的同事，也包括滄某自己，在看到這個設計之后，不由得羞愧的低下了頭。面板最前方則采用傾斜平面設計，除了360 logo之外，沒有其他多余的設計，簡潔大方。
360家庭防火墻5Pro的整體機身要比普通路由器大一圈，而且機身也比較厚，但如果把它拿起來的話你會發現，很輕，機身底部的散熱部分做的很好，較大的機身、很輕的質量、出色的散熱設計，這似乎在暗示著這款360防火墻5Pro的不簡單。
360防火墻5Pro外置高增益全向性6天線，其中4根5GHz天線增益提升至6dBi，利用電磁場疊加效應令5GHz WiFi的穿墻能力提升一倍，開闊環境中信號傳輸直線距離可達200m。
在機身背面，也就是與4根天線相接的那一面，集中設計了這款路由器的全部外部接口——一個防火墻WLAN口加4個LAN口，外加電源鍵及一個重置鍵。這里需要說明的是，重置的時候不要長按，用卡針輕按一下，等待指示燈全亮再全滅就意味著重置成功了。
除了外部接口，機身背面還設計了兩個散熱口，機身底部也設計了多個散熱口；而機器的正面則有8個指示燈，分別是系統指示燈、防火墻指示燈、2.4G無線狀態指示燈、5G無線狀態指示燈、上網狀態WLAN口指示燈和四個局域網LAN口指示燈。當對應的指示燈都處于閃爍狀態則意味著業務正常，否則防火墻相應業務無法工作。
從這款產品的設計，我們不難猜測其性能，不然要這么多散熱口干什么。根據官方的說法，360家庭防火墻5Pro是一款AC2100雙頻千兆無線路由器，擁有5個千兆網口，5GHz WiFi達1733Mbps，可跑滿1000M寬帶，無線下載1080P超清電影僅需30秒。
除此之外，360家庭防火墻5Pro采用目前家用路由領域最先進的4T4R（4發4收）架構，滿足市面幾乎所有電腦和手機，其中最具代表性的就是蘋果的MacBook，后者采用3T3R（3發3收）架構。如果沒有相匹配的路由器，那么就無法最大限度的發揮其WiFi能力。
核心配置上，360家庭防火墻5Pro搭載雙核CPU，雙通路同步處理數據，內置128MB DDR3大內存。支持4X4 Wave2 MU-MIMO技術和特有360QoS技術，能同時與多臺上網設備進行數據傳輸，即使同時玩游戲也流暢不卡。
二、連接·測試
360家庭防火墻5Pro的連接可以說非常簡單，全部操作只需動動手指即可。
插上電源，將網線插入機身背面的黃色WLAN口，等手機WiFi列表中出現360WiFi XXXX和360WiFi XXXX 5G的時候，直接連接該WiFi即可，系統會提示你進行網絡設置。
在設置路由器時有兩種選擇，一種是設置新的路由器，另一種是從舊路由器獲取。后者需要在連接電源的情況下，用一根網線將兩個路由器連接起來，幾步操作即可完成舊路由配置同步。在這里滄某選擇了將其設置為新的路由器，系統會自動檢測當前的上網方式，用戶只需填入寬帶賬號密碼即可。
寬帶賬號填好之后，接著就是設置WiFi名稱及對應的密碼了。設置完成之后，需要在360家庭防火墻App中將其綁定，具體操作還是傻瓜式操作，只需提前下載好App并登錄即可。
整個設置路由器、設置WiFi并綁定App的全部過程到這里就結束了，不夸張的說，全程耗時不超過3分鐘——插電源、插網線、填寫密碼，打開App點幾下，搞定！
滄某始終認為，科技的進步并不體現在某個產品操作多么復雜、多么高深，恰恰體現在某一個產品的操作對消費者而言，是“傻瓜式”的，學習成本很低。高科技、高難度的層面由廠家來實現，并且將最簡單地操作層面交給消費者，這是消費者想要的。拿滄某來舉例子，我才不管你這路由器是什么神仙設計、神仙邏輯、神仙科技，我只要安裝簡單、好使、廠家宣傳的功能都能實現就可以了。顯然，360家庭防火墻5Pro就是這樣的產品。這款產品的亮點在于大帶寬、高標準及防火墻功能，我們來一一介紹。
正如前文所說，360家庭防火墻5Pro可跑滿1000M寬帶，目前100Mbps、200Mbps帶寬的網絡已不再是什么稀奇的存在，未來的趨勢是千兆寬帶進入每家每戶。
目前，千兆寬帶入戶正在大力推廣中，今年運營商先后宣布，北京、天津都將年內實現對天津市的大規模千兆寬帶覆蓋。
千兆寬帶是未來的趨勢，但是普通的1200Mbps路由器在面對500Mbps以上特別是千兆寬帶時，已經力不從心，達到理論上限。360家庭防火墻5Pro作為一款2100M全千兆無線路由器（300+1800），可輕松跑滿1000M帶寬。按照官方的說法，“無線下載1080P超清電影僅需30秒”。
一般來說，同一個路由器下，連接的設備越多，實際的使用體驗就越差；為了獲得更好的使用體驗，對路由器性能的要求就更高。
得益于4T4R技術，360家庭防火墻5Pro的5G速率將更快，比現有的2T2R路由器要快的多；此外，六根高增益天線的存在，使得其覆蓋范圍得到有效的提升，滄某將路由器在放在客廳，關上門，去到臥室的小陽臺那里信號依舊給力，玩游戲、上網一切正常。
說了這么多，沒個數據支撐怕也沒人信，那么接來下我們來看一下這款路由器的實際表現到底怎么樣。
遺憾的是千兆級、500兆、甚至200兆的測試環境都沒有，因為滄某使用的是聯通100兆帶寬，即便如此，360家庭防火墻5Pro路由器還是有著相當不錯的表現。
我們先來看一下360家庭防火墻5Pro的覆蓋能力及網絡性能到底如何。房間構造大致如下圖，畫的不太精確，約90平：
實際測試結果如下（衛生間、廚房、陽臺1數據基本一致，統一在陽臺1數據顯示）：
▲每處測三次，速率相差不大取中間值，截圖
通過實際測試我們可以看到，360家庭防火墻5Pro在90平的房間內，即便是在隔了幾堵墻之后，其信號依然保持在較高水準。
除了網速達標之外，360家庭防火墻5Pro在整個房間的各個角落，其時延都保持在很高的水準，最高時延11ms，最低時延9ms，全程不存在丟包，時延抖動也保持在4ms以內（測試過程中最大4ms，只出現過一次）。
經過實際測試，360家庭防火墻5Pro無論是網絡性能、空間覆蓋能力、時延丟包等方面都保持的較高水準，其穿墻模式使得WiFi信號在經過多堵墻之后，其實際下載速率依然能達到7MB/s左右，而時延也僅僅下降2ms，絲毫不影響游戲體驗。
除了常規的性能之外，這款路由器的安全防護功能不僅強大，而且還很貼心。
在App內成功添加新成員為家庭成員之后，可以為其單獨設置相應的網絡防護措施。
我們拿學生模式舉例（設置內容與兒童模式一致），當你為某一特定用戶設置了該模式，如果使用者超過你所設置的時間上限后，App將自動提醒，這其中包括當被設定人打開學習軟件時、玩游戲時間超過預期設定時、看視頻時間超時時、進行網絡打賞支付時、瀏覽不良信息網站時等。
這個功能可以有效保護青少年的網絡安全，在避免其瀏覽不良信息的同時，還可以做到減少未成年人網絡打賞行為。近期有多則新聞報道，未成年人打賞主播成千上萬元，最后家長追訴要求退款的新聞，除了家長自身的疏忽大意之外，如果有相關提醒功能存在的話，也能在一定程度上緩解類似事件的發生。
在防蹭網及設置客人專訪網絡這一點上，360家庭防火墻5Pro跟其他路由器不存在很大的差異，都是通過設置專門的網絡及問題來限制他人上網。
實際的使用效果如下圖：
此外，在游戲加速、網速下載方面，360家庭防火墻5Pro也有著不錯的智能調度機制。
防火墻設置里的諸多選項基本不需要人為設置，都是系統優先調用最佳的配置。其他方面需要多說幾句的是極光加速、摩根加速器和下載加速器這個功能。
例如極光加速這個功能，可針對當前（列表中支持）的游戲進行網速優化，智能調度當前網絡資源給實時在玩的游戲，最大化減少網絡延遲及卡頓，不過在實際游戲體驗中并沒有什么區別，因為路由器本身給予的網絡資源已經足夠出色，在優化也只能是錦上添花，其實際體驗幾乎感覺不出來。從下圖我們可以看到，實際使用中，網絡延遲保持在41ms左右，除此之外，全程無460的現象，網速穩定，對游戲而言無疑是相當重要的。
摩根加速器這個功能，支持游戲跨服，類似電腦游戲加速器的效果，一分錢體驗7天，目前支持4款游戲，期待官方進一步更新。
最后的下載加速功能還是很不錯的，由于滄某的全部智能設備加起來也就5個，并不能很好的體現出該功能的強大之處，但是得益于這款設備的大帶寬支持及高設備容量，這個功能可以說是專為多用戶準備的，保證高速下載。
三、總結
這款定價229元，首發179元的360家庭防火墻路由器5Pro，隱藏著不俗的強悍性能，另外對樂高積木的“外設”支持，可以讓路由器都變成家中一道亮麗的風景線。隨著千兆網絡的普及，普通路由器的作用難以發揮網絡的實際性能，而這些問題在360家庭防火墻路由器身上全部不存在；尤其是大戶型及家庭成員多的情況下，360家庭防火墻路由器5 Pro幾乎是同價位下的首選。
滿足不同商務用戶在不同場景下對筆記本的配置有多樣化的需求，惠普在2019年推出了戰66 AMD版，采用了以高性價比著稱的銳龍平臺。因此，在原本就很實惠的基礎之上，戰66 AMD版將更多實惠給到了用戶。
惠普戰66 AMD版 15（6YF48PC）電商報價京東商城 ￥3999本地商家 ￥4499
作為近幾年來最為成功的商務型筆記本之一，戰66系列是專為中小企業用戶打造的高質價比產品，尤其是在產品品質上，經過了多道嚴苛的軍工級測試，同時在接口擴展性上給用戶帶來足夠好的體驗，這是其能夠獲得認可的重要原因所在。
惠普戰66全系經過美國國防部MIL-STD-810G軍標測試，其中包括跌落測試、功能性沖擊測試、10-500Hz振動測試、關機低溫測試、濕度測試、關機高度測試、防塵測試、熱沖擊測試、開機高溫測試、開機低溫測試、20-2000Hz振動測試、關機高溫測試以及開機高溫測試等。旨在為用戶提供最為安全、可靠的產品。
外觀設計上，戰66 AMD版與英特爾版沒有差異，使用了相同的模具打造，本次新品對處理器進行了升級，從銳龍2000U系列升級為銳龍3000U系列。所以接下來讓我們先從硬件配置和性能著手，一步步了解這款頗受好評的高質價比產品。
·升級AMD Ryzen 5 3500U處理器
基于AMD銳龍處理器不錯的性能表現，惠普戰66 AMD勝任目前任何主流辦公應用都沒有太大問題。本次我們拿到的產品配置了AMD Ryzen 5 3500U處理器、8GB內存、512GB固態硬盤以及AMD Radeon Vega 8集顯。此外，惠普戰66 AMD版內部還預留了內存插槽和硬盤接口，用戶可以自行擴展雙通道內存或大容量硬盤，在預留升級空間的同時，也給用戶帶來一定的可玩性。
接下來我們來看看各個硬件的性能情況。
AMD Ryzen 5 3500U處理器是一顆4核8線程的處理器，TDP為15W，基于12nm制程工藝設計，三級緩存4MB，基準頻率2.1GHz，最大動態加速頻率3.7GHz。
使用CINEBENCH R15和CINEBENCH R20對這顆處理器進行測試，前者單核得分132cb，多核得分609cb；后者核得分344cb，多核得分1370cb。從單核成績來看，AMD Ryzen 5 3500U因頻率影響相對低一些，但是多核成績基本達到了主流低功耗處理器的水準，在處理多線程任務時有著不錯的效率和計算能力。
我們本次拿到的評測機配置了512GB固態硬盤，使用CrystalDiskMark對其性能進行測試，結果如下：1GiB數據5次測試情況下，隊列深度為32時Seq讀取速度3395.5MB/s，寫入速度1994.1MB/s。另外在4K各項測試中，這塊固態硬盤的表現也非常不錯。
戰66 AMD版定位于商務向應用的產品，所以我們在測試綜合性能時選擇了PCMark 10的生產力測試項目。最終測試結果如上圖所示：視頻會議、網頁瀏覽、應用程序啟動等各項常用基本功能得分7282分；文檔、表格等應用的生產力評分為5729分；圖片編輯、渲染、視頻等數位內容創作應用得分為3325分，總評分3711分。就結果而言，屬于目前輕薄本、商用向筆記本電腦的主流水準。滿足各類文檔、表格辦公需求無壓力，能夠應付基本的視頻剪輯、渲染和視覺化應用。
·經典外觀設計
外觀方面，惠普戰66 AMD版強化了機身的金屬質感，AC面采用高強度5系航空鋁材質。A面中央的亮面LOGO與金屬外殼搭配相得益彰。
惠普戰66 AMD版B面采用了兩側窄邊框設計，雖然屏占比受到一定程度影響，但是這樣做的好處在于更好的保護屏幕，在遭遇意外撞擊、擠壓時保證屏幕的安全。對于商務產品來說，這類涉及到實用性的設計其實更為可貴。
同時，這款產品還采用了霧面屏設計，有效避免了鏡面屏常出現的反光、眩光等問題，保證了用戶在不同使用環境下的使用體驗。窄邊框設計則有效縮小了機身的尺寸，帶來了僅1.6kg的重量和17.95mm的機身厚度，便攜性體驗更佳。
此外，惠普戰66 AMD版的屏幕還幕還支持180°開合，方便用戶小范圍分享屏幕內容，不用來回移動電腦，即可讓周圍的同事看清屏幕內容。同時，14英寸1920×1080分辨率IPS顯示屏帶來舒適的視覺體驗。
操控方面，惠普戰66 AMD版鍵盤按鍵的鍵程較長，回彈迅速、反饋有力，長時間打字不會感到疲勞。指紋識別升級為按壓式傳感器后，整體接觸面積更大，開機進系統的時候對于指紋識別的精確度更高、識別速度更快，使用起來非常方便。
接口配置上，惠普戰66 AMD版可以說相當豪華，使其擴展性得到極大拓展，標準USB-A、網口、HDMI、SD讀卡器一應俱全，并且還有全功能的Type-C接口，這個接口不僅可以外接移動存儲設備傳數據，還可以外接顯示器擴展60Hz的4K屏幕，另外還支持給筆記本充電，一口三用，非常實用。
可以看到，這款機器的機身右側配置了電源插孔、全功能TYPE-C接口、標準網口、標準HDMI接口、2個USB 3.1 TYPE-A接口以及3.5mm耳麥插孔。機身左側配置了安全鎖孔、USB 2.0接口以及標準的SD讀卡器。
·散熱與續航能力評估
最后我們來看看散熱與續航能力，這對于商務本也是很重要的技術指標。
其內部采用了雙熱管散熱系統，在CPU+GPU雙拷機環境下，處理器核心溫度平均只有61.4℃，散熱效果極佳！
續航方面，我們使用PCMark 10辦公模式對其進行了測試，在屏幕亮度為50%、連接WiFi的情況下，最終續航成績為7小時30分鐘，可以滿足用戶一天不插電辦公的需求，續航能力表現非常不錯。
除了擁有出色的續航能力之外，惠普戰66 AMD版還支持快充功能，30分鐘充電量可達50%，讓工作高效不斷電。
·選購與評測總結
惠普戰66 AMD版 15（6YF48PC） AMD處理器，集成顯卡，輕薄商務本，指紋識別
京東商城
3999元
進入購買
目前，惠普戰66 AMD版在京東開啟預約，本次評測機型配置價格僅為4299元，可以說是性價比相當高的產品了。在此價格基礎之上，用戶可以享受惠普專業售后服務。包括2年電池保修服務、1年上門維修服務、7×24小時云在線服務、以及1年意外損壞（意外進水、意外電擊、意外跌落、意外擠壓）免費保修服務。
總體來看，本次的惠普戰66 AMD版新品主要在處理器上進行了升級，整體性能表現也有進一步的提升。從商務本角度來評判的話，惠普戰66 AMD版擁有出色的外接擴展能力、過硬的做工品質，以及極為合理的市場定價，因此很可能再次成為商務本里的熱銷產品，從而延續系列傳統。
搭載Windows 10 Pro的設備，能夠為用戶提供端到端的安全性，有助于防止與未經授權的公司信息共享，保護用戶身份，防范現代威脅，并保護鎖定設備的信息。通過使用Windows Hello面部識別或指紋登錄等功能，用戶能夠確保業務信息、客戶數據、員工數字身份的安全性，從而最終保護公司的聲譽和品牌。同時，通過與電腦硬件軟硬結合，相輔相成，Windows 10 Pro能夠為用戶提供穩定的使用體驗，可以支持遠程和移動辦公，進而進一步提升工作效率。
HP推薦使用商用Windows 10專業版。
惠普戰 D9為工作站級專業顯示器，采用三邊微邊框設計，給用戶帶來無縫的多屏體驗。升降旋轉底座自由調節屏幕位置，配合無閃屏+低藍光技術，可以給商務用戶帶來最佳的觀看體驗。點擊鏈接進入購買頁面！
是『全棧技術群』第一期分享：360消息推送系統介紹
分享人：全棧技術管理員之一，花椒直播技術總監周洋。
今天晚上內容分成以下幾個部分：
360消息系統更確切的說是長連接push系統，目前服務于360內部50多個產品，開發平臺數千款app，也支持部分聊天業務場景，單通道多app復用，支持上行數據，提供接入方不同粒度的上行數據和用戶狀態回調服務。
目前整個系統按不同業務分成9個功能完整的集群，部署在10個idc上（每個集群覆蓋不同的idc），實時在線2億量級.
通常情況下，pc，手機，甚至是智能硬件上的360產品的push消息，基本上是從我們系統發出的~ 期望大家收到的push都是自己關心的... 如果不是，請相信，“我們不生產消息，我們只是消息的搬運工”~
很多同行比較關心go語言在實現push系統上的性能問題，單機性能究竟如何，能否和其他語言實現的類似系統做對比么？甚至問如果是創業,第三方云推送平臺，推薦哪個? （廣告招商~）
其實各大廠都有類似的push系統，市場上也有類似功能的云服務。包括我們公司早期也有erlang，nodejs實現的類似系統，也一度被公司要求做類似的對比測試。
我感覺在討論對比數據的時候，很難保證大家環境和需求的統一，我只能說下我這里的體會，數據是有的，但這個數據前面估計會有很多定語~
做過長連接的同行，應該有體會，如果在穩定連接情況下，連接數這個指標，在沒有網絡吞吐情況下對比，其實意義往往不大，維持連接消耗cpu資源很小，每條連接tcp協議棧會占約4k的內存開銷，系統參數調整后，我們單機測試數據，最高也是可以達到單實例300w長連接。
但做更高的測試，我個人感覺意義不大。因為實際網絡環境下，單實例300w長連接，從理論上算壓力就很大：因為實際弱網絡環境下，移動客戶端的斷線率很高，假設每秒有1000分之一的用戶斷線重連。300w長連接，每秒新建連接達到3w，這同時連入的3w用戶，要進行注冊，加載離線存儲等對內rpc調用，另外300w長連接的用戶心跳需要維持,假設心跳300s一次，心跳包每秒需要1w tps。
單播和多播數據的轉發，廣播數據的轉發，本身也要響應內部的rpc調用，300w長連接情況下，gc帶來的壓力，內部接口的響應延遲能否穩定保障。
這些集中在一個實例中，可用性是一個挑戰。所以線上單實例不會hold很高的長連接,實際情況也要根據接入客戶端網絡狀況來決定。
這一點上，使用go語言情況下，由于協程的原因，會有一部分額外開銷。但是要做兩個推送系統的對比，也有些需要確定問題。
比如系統從設計上是否需要全雙工（即讀寫是否需要同時進行）如果半雙工，理論上對一個用戶的連接只需要使用一個協程即可（這種情況下，對用戶的斷線檢測可能會有延時），如果是全雙工，那讀/寫各一個協程。兩種場景內存開銷是有區別的.
另外測試數據的大小往往決定我們對連接上設置的讀寫buffer是多大，是全局復用的，還是每個連接上獨享的，還是動態申請的。另外是否全雙工也決定buffer怎么開. 不同的策略，可能在不同情況的測試中表現不一樣。
這一點上，也要看我們對消息到達的QoS級別(回復ack策略區別），另外架構策略，每種策略有其更適用的場景，是純粹推，還是推拉結合。甚至是否開啟了消息日志，日志庫的實現機制，緩沖開多大，flush策略,這些都影響整個系統的吞吐量。另外為了HA，增加了內部通信成本，為了避免一些小概率事件，提供閃斷補償策略，這些都要考慮進去。如果所有的都去掉，那就是比較基礎庫的性能了.
所以我只能給出大概數據，24核，64G的服務器上，在Qos為message at least，純粹推的情況，消息體256B~1kB情況下，單個實例100w實際用戶（200w+）協程，峰值可以達到2~5w的QPS...
內存可以穩定在25G左右，gc時間在200~800ms左右.（還有優化空間） 我們正常線上單實例用戶控制在80w以內，單機最多兩個實例~
事實上，整個系統在推送的需求上，對高峰的輸出不是提速，往往是進行限速，以防push系統瞬時的高吞吐量，轉化成對接入方業務服務器的ddos攻擊
所以對于性能上，我感覺大家可以放心使用，至少在我們這個量級上，經受過考驗，go1.5到來后，確實有之前投資又增值了的感覺~
下面是對消息系統的大概介紹，之前一些同學可能在gopher china上可以看到分享，這里簡單講解下架構和各個組件功能，額外補充一些當時遺漏的信息：
架構圖如下，所有的service都 written by golang.
舉兩個常見例子，了解工作機制：
比如發一條單播給一個用戶，center先請求Register獲取這個用戶之前注冊的連接通道標識、room實例地址，通過room service下發給長連接。
Center Service比較重的工作如全網廣播，需要把所有的任務分解成一系列的子任務，分發給所有center，然后在所有的子任務里，分別獲取在線和離線的所有用戶，再批量推到Room Service。通常整個集群在那一瞬間壓力很大。
7.deployd/agent service 用于部署管理各個進程，收集各組件的狀態和信息,zookeeper和keeper用于整個系統的配置文件管理和簡單調度
常見的推送模型有長輪訓拉取，服務端直接推送（360消息系統目前主要是這種），推拉結合（推送只發通知，推送后根據通知去拉取消息）.
拉取的方式不說了，現在并不常用了，早期很多是nginx+lua+redis，長輪訓，主要問題是開銷比較大，時效性也不好, 能做的優化策略不多。
直接推送的系統，目前就是360消息系統這種，消息類型是消耗型的，并且對于同一個用戶并不允許重復消耗,如果需要多終端重復消耗，需要抽象成不同用戶。
推的好處是實時性好，開銷小，直接將消息下發給客戶端，不需要客戶端走從接入層到存儲層主動拉取.
但純推送模型，有個很大問題，由于系統是異步的，他的時序性無法精確保證。這對于push需求來說是夠用的，但如果復用推送系統做im類型通信，可能并不合適。
對于嚴格要求時序性，消息可以重復消耗的系統，目前也都是走推拉結合的模型，就是只使用我們的推送系統發通知，并附帶id等給客戶端做拉取的判斷策略，客戶端根據推送的key，主動從業務服務器拉取消息。并且當主從同步延遲的時候，跟進推送的key做延遲拉取策略. 同時也可以通過消息本身的QoS，做純粹的推送策略，比如一些“正在打字的”低優先級消息，不需要主動拉取了，通過推送直接消耗掉。
首先是sdk的完善程度，sdk策略和細節完善度，往往決定了弱網絡環境下最終推送質量.
有些開源服務可能會針對用戶hash一個該接入區域的固定ip，實際上在國內環境下不可行，最好分配器（dispatcher）是返回散列的一組，而且端口也要參開，必要時候，客戶端告知是retry多組都連不上，返回不同idc的服務器。因為我們會經常檢測到一些case，同一地區的不同用戶，可能對同一idc內的不同ip連通性都不一樣，也出現過同一ip不同端口連通性不同，所以用戶的選路策略一定要靈活，策略要足夠完善.
另外在選路過程中，客戶端要對不同網絡情況下的長連接ip做緩存，當網絡環境切換時候(wifi 2G,3G)，重新請求分配器，緩存不同網絡環境的長連接ip.
針對不同網絡環境，或者客戶端本身消息的活躍程度，心跳要自適應的進行調整并與服務端協商，來保證鏈路的連通性。并且在弱網絡環境下，除了網絡切換（wifi切3G）或者讀寫出錯情況，什么時候重新建立鏈路也是一個問題。客戶端發出的ping包，不同網絡下，多久沒有得到響應，認為網絡出現問題，重新建立鏈路需要有個權衡。另外對于不同網絡環境下，讀取不同的消息長度，也要有不同的容忍時間，不能一刀切。好的心跳和讀寫超時設置，可以讓客戶端最快的檢測到網絡問題，重新建立鏈路，同時在網絡抖動情況下也能完成大數據傳輸。
另外系統可能結合服務端做一些特殊的策略，比如我們在選路時候，我們會將同一個用戶盡量映射到同一個room service實例上。斷線時，客戶端盡量對上次連接成功的地址進行重試。主要是方便服務端做閃斷情況下策略，會暫存用戶閃斷時實例上的信息，重新連入的時候，做單實例內的遷移，減少延時與加載開銷.
很多創業公司愿意重新搭建一套push系統，確實不難實現，其實在協議完備情況下（最簡單就是客戶端不回ack不清數據），服務端會保證消息是不丟的。但問題是為什么在消息有效期內,到達率上不去？
往往因為自己app的push service存活能力不高。選用云平臺或者大廠的，往往sdk會做一些保活策略，比如和其他app共生，互相喚醒，這也是云平臺的push service更有保障原因~ 我相信很多云平臺旗下的sdk，多個使用同樣sdk的app，為了實現服務存活，是可以互相喚醒和保證活躍的~ 另外現在push sdk本身是單連接，多app復用的，這為sdk實現，增加了新的挑戰~
綜上，對我來說，選擇推送平臺，優先會考慮客戶端sdk的完善程度~ 對于服務端，選擇條件稍微簡單，要求部署接入點（IDC）越要多，配合精細的選路策略，效果越有保證，至于想知道哪些云服務有多少點，這個群里來自各地的小伙伴們，可以合伙測測~
這個系統在開發過程中遇到挑戰和優化策略，給大家看下當年的一張圖，在第一版優化方案上線前一天截圖~
可以看到，內存最高占用69G，GC時間單實例最高時候高達3~6s.這種情況下，試想一次悲劇的請求，經過了幾個正在執行gc的組件，后果必然是超時... gc照成的接入方重試，又加重了系統的負擔。遇到這種情況當時整個系統最差情況每隔2，3天就需要重啟一次~
1.散落在協程里的I/O，Buffer和對象不復用。
當時由于對go的gc效率理解有限，比較奔放，程序里大量short live的協程，對內通信的很多io操作，由于不想阻塞主循環邏輯或者需要及時響應的邏輯，通過單獨go協程來實現異步。這回會gc帶來很多負擔。
針對這個問題，應盡量控制協程創建，對于長連接這種應用，本身已經有幾百萬并發協程情況下，很多情況沒必要在各個并發協程內部做異步io，因為程序的并行度是有限，理論上做協程內做阻塞操作是沒問題。
如果有些需要異步執行，比如如果不異步執行，影響對用戶心跳或者等待response無法響應，最好通過一個任務池，和一組常駐協程，來消耗，處理結果，通過channel再傳回調用方. 使用任務池還有額外的好處，可以對請求進行打包處理，提高吞吐量，并且可以加入控量策略.
2.網絡環境不好引起激增
go協程相比較以往高并發程序，如果做不好流控，會引起協程數量激增。早期的時候也會發現，時不時有部分主機內存會遠遠大于其他服務器，但發現時候，所有主要profiling參數都正常了。
后來發現，通信較多系統中，網絡抖動阻塞是不可免的(即使是內網)，對外不停accept接受新請求，但執行過程中，由于對內通信阻塞，大量協程被創建，業務協程等待通信結果沒有釋放，往往瞬時會迎來協程暴漲. 但這些內存在系統穩定后，virt和res都并沒能徹底釋放，下降后，維持高位。
處理這種情況，需要增加一些流控策略，流控策略可以選擇在rpc庫來做，或者上面說的任務池來做，其實我感覺放在任務池里做更合理些，畢竟rpc通信庫可以做讀寫數據的限流，但它并不清楚具體的限流策略，到底是重試還是日志還是緩存到指定隊列。任務池本身就是業務邏輯相關的，它清楚針對不同的接口需要的流控限制策略。
3.低效和開銷大的rpc框架
早期rpc通信框架比較簡單，對內通信時候使用的也是短連接。這本來短連接開銷和性能瓶頸超出我們預期，短連接io效率是低一些，但端口資源夠，本身吞吐可以滿足需要，用是沒問題的，很多分層的系統，也有http短連接對內進行請求的。但早期go版本，這樣寫程序，在一定量級情況，是支撐不住的。短連接大量臨時對象和臨時buffer創建，在本已經百萬協程的程序中，是無法承受的。所以后續我們對我們的rpc框架作了兩次調整。
第二版的rpc框架，使用了連接池，通過長連接對內進行通信（復用的資源包括client和server的：編解碼Buffer、Request/response），大大改善了性能。
但這種在一次request和response還是占用連接的，如果網絡狀況ok情況下，這不是問題，足夠滿足需要了，但試想一個room實例要與后面的數百個的register，coordinator，saver，center，keeper實例進行通信，需要建立大量的常駐連接，每個目標機幾十個連接，也有數千個連接被占用。
非持續抖動時候（持續逗開多少無解），或者有延遲較高的請求時候，如果針對目標ip連接開少了，會有瞬時大量請求阻塞，連接無法得到充分利用。第三版增加了Pipeline操作，Pipeline會帶來一些額外的開銷，利用tcp的全雙特性，以盡量少的連接完成對各個服務集群的rpc調用。
4.Gc時間過長
Go的Gc仍舊在持續改善中，大量對象和buffer創建，仍舊會給gc帶來很大負擔，尤其一個占用了25G左右的程序。之前go team的大咖郵件也告知我們，未來會讓使用協程的成本更低，理論上不需要在應用層做更多的策略來緩解gc.(最新版本的Go，GC 已經優化了很多)
改善方式，一種是多實例的拆分，如果公司沒有端口限制，可以很快部署大量實例，減少gc時長，最直接方法。不過對于360來說，外網通常只能使用80和433。因此常規上只能開啟兩個實例。當然很多人給我建議能否使用SO_REUSEPORT，不過我們內核版本確實比較低，并沒有實踐過。另外能否模仿nginx，fork多個進程監控同樣端口，至少我們目前沒有這樣做，主要對于我們目前進程管理上，還是獨立的運行的，對外監聽不同端口程序，還有配套的內部通信和管理端口，實例管理和升級上要做調整。
解決gc的另兩個手段，是內存池和對象池,不過最好做仔細評估和測試，內存池、對象池使用，也需要對于代碼可讀性與整體效率進行權衡。
這種程序一定情況下會降低并行度，因為用池內資源一定要加互斥鎖或者原子操作做CAS，通常原子操作實測要更快一些。CAS可以理解為可操作的更細行為粒度的鎖（可以做更多CAS策略，放棄運行，防止忙等）。這種方式帶來的問題是，程序的可讀性會越來越像C語言，每次要malloc，各地方用完后要free，對于對象池free之前要reset，我曾經在應用層嘗試做了一個分層次結構的“無鎖隊列”
上圖左邊的數組實際上是一個列表，這個列表按大小將內存分塊，然后使用atomic操作進行CAS。但實際要看測試數據了，池技術可以明顯減少臨時對象和內存的申請和釋放，gc時間會減少，但加鎖帶來的并行度的降低，是否能給一段時間內的整體吞吐量帶來提升，要做測試和權衡…
在我們消息系統，實際上后續去除了部分這種黑科技，試想在百萬個協程里面做自旋操作申請復用的buffer和對象，開銷會很大，尤其在協程對線程多對多模型情況下，更依賴于golang本身調度策略，除非我對池增加更多的策略處理，減少忙等，感覺是在把runtime做的事情，在應用層非常不優雅的實現。普遍使用開銷理論就大于收益。
但對于rpc庫或者codec庫，任務池內部，這些開定量協程，集中處理數據的區域，可以嘗試改造~
對于有些固定對象復用，比如固定的心跳包什么的，可以考慮使用全局一些對象，進行復用，針對應用層數據，具體設計對象池，在部分環節去復用，可能比這種無差別的設計一個通用池更能進行效果評估.
下面介紹消息系統的架構迭代和一些迭代經驗，由于之前在其他地方有過分享，后面的會給出相關鏈接，下面實際做個簡單介紹，感興趣可以去鏈接里面看
根據業務和集群的拆分，能解決部分灰度部署上線測試，減少點對點通信和廣播通信不同產品的相互影響，針對特定的功能做獨立的優化.
消息系統架構和集群拆分，最基本的是拆分多實例，其次是按照業務類型對資源占用情況分類，按用戶接入網絡和對idc布點要求分類（目前沒有條件，所有的產品都部署到全部idc）
我們利用Go原生的profiling工具，做了些可視化工作。可以對比多次上線出現的問題，通過壓測程序復現部分瓶頸。定位cpu或者內存消耗的瓶頸。
另外，我們也可以對基礎庫代碼做內嵌，將RPC庫，Redis庫，內存池命中數據等，做可視化的展示，統計它的QPS、網絡帶寬占用、idle與working，各種出錯情況。然后再通過各種壓測手段，觀察優化性能點，上線前后是否有影響。如果一個系統不可評估就無法優化，利用壓測評估就會發現一些潛在的問題。
go語言在并發測試上有獨特優勢。
在功能測試上，系統分成兩套，一套是我們針對自己的功能，自己設計并測試，但這樣難免會有問題。另一套是公司的自動化測試部門（python實現的~）根據我們的功能來測試。雙保險~
對于壓力測試，目前主要針對指定的服務器，選定線上空閑的服務器做長連接壓測。然后結合可視化，分析壓測過程中的系統狀態。但壓測早期用的比較多，但實現的統計報表功能和我理想有一定差距。理論上壓測完后，可以根據協議版本，匯總每一次壓測進程詳細數據，業務的QPS數量、每秒鐘建立連接數量，極限狀態下的cpu和內存消耗，等每一個考核細節。現在只是能看一個大概趨勢.對于細微的性能提升，沒法評估，我們后續準備結合自己寫的中央管理組件keeper，做這個數據收集和展示~
對于go語言適用的場景。之前在gopher china上，有過我個人的理解和概括：適用于重邏輯的io密集型應用.
我覺得最近出的golang開源產品都符合這種場景， go寫網絡并發程序給大家帶來的便利，讓大家把以往為了降低復雜度，拆解或者分層協作的組件，又組合在了一起。
比如go的web框架是在做負責并發的webserver和負責業務處理cgi程序，放在了webserver中。新近的一些go寫的“智能”代理或者中間件，把很多原先分層控制或者不同功能但類似的子系統，以各種形式組裝起來，reborn一個新的中間件或者新產品~包括之前百度放出的go-bfe也是把重邏輯和io密集型很好結合的產物~（群里有bfe的同學么，求更多資料）
個人感覺在國內互聯網創業公司爆發環境下，大廠的復雜設備，很多將被golang重新打包成適用在一定量級下的“全能”工具箱~
以上就是今天的go分享~ 謝謝大家，歡迎提問~
提問：對比kafaka這些消息系統 有什么優點？
回答：我們是消息推送系統 指的對客戶端的高并發推送的 面對場景不一樣
提問：hadoop生態圈的大數據，算重邏輯和IO密集型應用不？
回答：不算 Hadoop主要是計算
提問：這種推送的方式如何保證消息是有序到達的？
回答：如果要保證有序 需要重新設計協議 對消息編號 先存儲 后拉取 可以按人存儲也可以按訂閱關系 目前花椒的im系統 屬于這種場景 有機會大家感興趣可以分享升級版本聊天架構
提問：golang適不適合寫web應用
回答：這個可以單獨一講回答 我的建議新的應用 大并發的場景可以考慮 老項目酌情改寫替換
提問：推送的消息會有多級轉發嗎？還是說客戶端直接跟一個server保持長鏈接就完事了？
回答：當流量大到一定程度 可以多級轉發 類似cdn架構 目前花椒直播的推送系統支持這種場景 為idc流量做分級轉發 普通場景不需要
提問：極光推送跟這種推送的應用場景就是差不多吧？
回答：方案都類似 協議復雜度會不同 比如為了保證一致性采取編號 先存儲后發送
提問：多級之間也是長鏈接吧
回答：多級別只是rpc調用 rpc通常keepalive
提問：推送系統目前支持什么協議呢？ mqtt？web socket？
回答：分傳輸層和協議層 傳輸層web socket 沒問題 mqtt是一個具體交互協議了 不具備通用可比性
提問：推送系統里面有用到epoll嗎？有沒有開源地址？
回答：用的golang； go原生就是對epoll封裝…目前不開源 安全公司理解下
本文由「Go語言中文網」整理