① 外包管理人員怎麼使用釘釘管理人員
考勤心得_基於釘釘考勤數據自動化處理的實踐 原創
2021-01-12 04:22:33
蘭小龍
碼齡4年
關注
基於釘釘考勤數據自動化處理的實踐
點擊上方「技術支持聯盟」，選擇「置頂公眾號」
第一時間了解程序員大小事兒
作者:冬日暖陽
摘要：隨著公司業務拓展，科技賦能的推進，系統逐漸增多，相應外包公司及人員也在迅速擴充，人員管理問題日漸突出，為了能夠更有效的管理外包人員，通過對接釘釘考勤信息，用數據了解部門中外包實際工作情況。
.png
01
痛點
廠商過多
外包廠商過多，無各個廠商單獨釘釘情況，只有組內每月匯總，不好逐日逐周的追蹤本組內外包廠商詳情，從而及時調整組內外包人員工作積極性。
人員流動性大
外包人員流動性大，沒有數據支撐，無法對人員個體及整體情況進行總結，通過數據從側面了解外包工作時長、工作態度及工作能力，通過打卡詳情數據，做到精確管理，典型追蹤。
0 2
釘釘小程序創建
通過企業內部自建應用創建小程序：
.png
1.登錄釘釘開發者後台。
說明：只有管理員和子管理員可登錄開發者後台。
2.在應用開發頁面，選擇企業內部開發 > 小程序，然後單擊創建應用。
.png
3.填寫應用的基本信息，然後單擊確定創建。 .png
4.在應用信息頁面，單擊開發管理，然後單擊修改。
.png
5.根據以下信息配置開發信息，然後單擊保存。
伺服器出口IP：輸入調用釘釘服務端API時使用的IP即企業伺服器的公網IP，多個IP請以","隔開，支持帶一個*號通配符的IP格式。
說明：同一個IP只能被一個企業使用。
6.管理後台地址(可選)：輸入管理後台地址。
在釘釘管理後台-工作台-找到對應應用，點擊應用圖標，跳轉到填寫的地址。如設置為https://open.dingtalk.com/，登錄釘釘管理後台，點擊進入後如圖所示。
.png
7.單擊憑證與基礎信息獲取應用的AppKey和AppSecret。
.png
03
現階段實現功能
日、周、月情況匯總，包含：
①外包廠商報備人員及打卡人員(含遠程)對比，計算打卡率；
②匯總缺卡及缺勤人員詳情及月度統計名單；
③匯總遲到人員(打卡時間9:30以後且前一天21:00之前打卡離場)及月度統計名單；
④工作時長統計：考勤打卡總時長、打卡人數、平均時長以及排名情況。
當日
.png
當月
.png
當周
.png
04
後續功能規劃
1.覆蓋范圍由新一代組轉為所有產品組
2.根據人力日常需要的信息調整規則，自動提供日、周、月數據，並發送郵件；
3.將考勤人員與外包管理系統人員進行統一關聯管理
4.郵件板式調整，使整體更直觀
歷史文章
解決方案：
開源規則引擎--drools
redis基本原理介紹
spring-session集成redis問題
通過分析Nginx伺服器日誌統計用戶流量並預警
加密與認證技術
【雙十一鉅惠：科技人的專屬保障】移動端交互速度保證 ——影像上傳優化
【雙十一鉅惠：科技人的專屬保障】移動端認證保障 ——非對稱加密及jwt應用
系統安全建設小經驗
公共組件-需求自動錄入TAPD
python初體驗
HTML5實現自定義鍵盤及使用
Sentinel限流
基於公有雲實時音視頻通道的構建音視頻組件方法與實戰經驗
分布式定時任務調度探討
阿里雲OSS javaAPI分享
Jmeter壓測的使用
API介面安全優化淺談
基於idea將傳統應用maven化改造實踐
安全漏洞預掃小工具
Nacos作為注冊中心，配置中心部署方案
Rancher+K8S簡化學習環境搭建方案
Excel大數據量解析優化方案
Sharding-JDBC個性化分表方案
基於JWT的介面許可權認證
Spring Cloud Gateway實現限流
公網發布的通用技術解決方案
Nginx結合Lua實現限流
Mysql數據同步Canal方案
Weblogic部署基於Spring Cloud項目應用實例
智能驗證碼解析java語言實現
資料庫的演繹與變遷-下架最後一台小型機
關於struts架構通過引入spring包實現bbo調用測試的未來式
架構系列：
雙十一鉅惠：科技人的專屬保障】如何保障移動端活動的穩定運轉？——移動端基礎平台建設的經驗分享
【雙十一鉅惠：一個有溫度的技術公眾號】科技人需要什麼樣的保障
架構師入門系列：架構三板斧「緩存，消息，非同步」
監控&運維
redis監控工具-redislive
微服務鏈路追蹤工具 Apache SkyWalking部署與實踐
快速發現生產環境SQL問題
Grafana-業務數據監控實踐
自動化運維能力提升
伺服器監控及問題定位排除
基於Spring Boot Admin告警之應用狀態告警
Ansible在自動化運維中的使用
自助遷發分支工具
大數據
淺談大數據平台的建設
基於CDH集群的大數據項目的優化總結
Oracle實時同步大數據平台解決方案
實時流關聯維表解決方案
中間件
淺談Elasticsearch的資源分配
Apache Kafka使用規范Elasticsearch安裝及使用
SSDB介紹及使用
RabbitMq使用簡單介紹
Spring Cloud常用組件介紹
前端
ESLint + Prettier 規范前端代碼
Vue.js對WinXP系統對兼容性
關於採集操作系統、瀏覽器版本的設計方案及一些瀏覽器兼容性問題處理
安卓動態載入SO文件
對瀏覽器的理解及兼容移動端H5本地化方案調研和實踐
自適應網頁設計
簡訊/瀏覽器喚起APP方案
基礎知識
Sonar簡介
JVM基礎系列1：JVM內存模型介紹
JVM基礎系列2：JVM配置參數和Java內存模型
JVM基礎系列3 虛擬機位元組碼執行引擎
開發規范
Java異常處理規范
戰略方向
金融保險系統開源浪潮下機遇與挑戰
項目實戰
《Scrum精髓》心得分享
聊一聊我們程序猿--技術交流感悟分享
如何快速支撐健康險業務發展
《鳳凰項目-一個IT運維傳奇故事》心得分享
運維工作要學會「偷懶」
「用戶思維+中台架構」快速搭建金融寶app
多維分保的應用探索
用文化指引自身的成長之路 -2020年技術成長心得分享
從工作中探尋自身的成長之路
從《平凡的榮耀》到記一次兼容性改造優化後的技術感悟
客戶為中心，統籌協調，把控風險
讓我們的管理看的見
.png E N D
.gif
請識別下方二維碼，關注 技術支持聯盟.png
歡迎加入基於釘釘API功能開發交流，請掃碼進群
.png
AppKey
打開CSDN APP，看更多技術內容
釘釘開發DEMO
此程序為釘釘應用，親測可以用，非喜勿噴，有任何疑問可以私信，互相交流
同步考勤數據 釘釘_釘釘考勤打卡攻略①
釘釘考勤打卡是專門針對企業員工上下班打卡的一款考勤應用。考勤打卡應用可以讓人事隨時隨地了解團隊狀態，出勤人員一目瞭然；智能統計考勤數據，雲端存儲，考勤數據永不丟失哦[靈光一閃]一、如何新增考勤組？手機端：點擊【工作台】—【考勤】—【設置】—【新建考勤組】電腦端：登錄管理後台—【工作台】—【考勤打卡】—【考勤組管理】—【新建考勤組】二、考勤組如何添加人？手機端：點擊【工作台】—【考勤打卡】—【設置】...
繼續訪問
釘釘考勤數據抓取_VBA實戰篇|HR們的福利，從此不再為整理考勤記錄發狂
提示：這是7月的第1篇原創文章關於整理『考勤記錄』的案例如果你喜歡本文，就分享給你的小夥伴，你的喜歡是我前進的最大動力如果你有任何疑問，可以文章下方留言或後台留言在HR的日常工作中，統計考勤是其中一項工作。雖然現在有考勤機、釘釘等高科技的手段進行輔助，但是有些考勤機導出的數據會讓各位HR們集體吐槽為何如此反人類的設計。如下圖所示，是我一位HR朋友發我的考勤記錄(數據已做部分處理)，看到這...
繼續訪問
釘釘API考勤打卡記錄獲取並存入資料庫（python）
前言： 釘釘有個開發平台，通過API可以開發自己企業內部應用，釘釘開發文檔順序寫的有點亂，花了挺長時間才看懂，我寫了一個python腳本來獲取考勤記錄，當然能做的不止這些，可以刪除公司成員，修改部門，瞎發通知等等。。。（這是上路的新手，大神忽略。） 一、准備 釘釘API地址：https://open-doc.dingtalk.com/docs/doc.htm?spm=0.0....
繼續訪問
釘釘考勤介面調用與OA系統數據對接
釘釘考勤介面調用與OA系統數據對接 公司由原來的指紋打卡更換為釘釘打卡，需要釘釘和現有的OA考勤數據對接（合並釘釘打卡數據和OA上的請假，外出，出差數據） 1.查看釘釘介面文檔 https://ding-doc.dingtalk.com/doc#/serverapi2/gh60vz 2.項目搭建引入釘釘開發SDK 3.獲取釘釘考勤數據存儲伺服器資料庫（調整存儲格式） //測試 public s...
繼續訪問
最新發布 從釘釘後台獲取考勤數據（其他數據獲取類似）
從釘釘後台獲取數據
繼續訪問
釘釘考勤數據抓取_員工考勤管理系統：如何輕松計算出每月的考勤數據
其實想要達到你這種效果的話有兩種方法： 一個是使用考勤機 一個是使用員工考勤管理系統考勤機 一般的企業為了加強自己的考勤管理，使用比較多的就是指紋打卡考勤機，只要上下班的時候通過指紋打卡就行了。優點： 費用低幾百到幾千就能搞定，適合人數不太多的中小企業，只要在需要整理數據的時候把數據導出到電腦里就行。缺點： 沒法兒自動幫你匯總分析，導出來的數據只是作為記錄，如果你要計算或者和績效結合的話，需...
繼續訪問
釘釘考勤數據抓取_釘釘考勤答疑你關心的都在這里
釘釘/// ///那些事兒///答疑篇 ///為提高工作效率，公司引進釘釘考勤系統替代傳統打卡模式，經過一個月的使用，經過前期對數據的分析整理，現將釘釘使用過程中遇到的一些疑惑進行解答。首先請各部門確認所有人員都在「浙江新和成股份有限公司釘釘考勤組」，如果有新員工不在該群組的，部門考勤員要先將人員邀請進考勤組。01.釘釘數據是如何採集的？ ...
繼續訪問
釘釘API考勤打卡記錄獲取(php + JS)
前言： 釘釘有個開發平台，通過API可以開發自己企業內部應用，釘釘開發文檔順序寫的有點亂，花了挺長時間才看懂，我建立一個php後端以及一個單獨網頁（不運行在釘釘上）來獲取考勤記錄，當然能做的不止這些，可以刪除公司成員，修改部門，瞎發通知等等。。。（這是上路的新手，大神忽略，練習下AJAX倒是挺好的。） 一、准備 釘釘API地址： https://open-doc.dingtalk.co...
繼續訪問
熱門推薦 獲取釘釘考勤機的打卡記錄並且解析
有個特別惡心的地方就是打卡信息只能最多一次取七天的。所以要注意一下； 時間格式：2018-05-01 釘釘突然改介面了，直接獲取是被拒絕了，加了分頁限制，加了人數限制，頭大，之前得方法不能用了，重新寫了版，最多一次獲取50個人的考勤，並且這些人的考勤記錄一次只能獲取50條，我想了個辦法中心思想就是首先拆分公司人員的dingId的列表，拆成每50個一組，然後限制分頁最大50個每頁，50個人的打...
繼續訪問
釘釘考勤數據抓取_華躍考勤管理系統
華躍考勤管理系統通過我司考勤系統把人力資源管理重要環節做到及時管控，隨時可分析員工日出勤異常報表、周出勤、月出勤等出勤數據。軟體兼容先進的現代感應式、RFID、指紋、圖像管理等硬體設備，在防止代打卡和混加班等方面有獨到的實施經驗。可滿足不同企業的各種考勤制度，客戶自定義的設計使不同行業的用戶可根據其所制定的考勤制度對系統進行靈活設置。智能排班的自動抓取讓您對排班無需進行任何操作，班次採用...
繼續訪問
積分-釘釘考勤-取參與考勤人員
釘釘考勤介面調用與OA系統數據對接（多線程版）
釘釘考勤介面調用與OA系統數據對接（多線程版） 公司由原來的指紋打卡更換為釘釘打卡，需要釘釘和現有的OA考勤數據對接（合並釘釘打卡數據和OA上的請假，外出，出差數據），因為人數增減單線程定時任務數據抓取時間較長，做一下優化 1.線程池 class CountableThreadPool { private int threadNum; private AtomicInteger...
繼續訪問
從釘釘後台對接考勤打卡信息（僅供參考）
# -*- coding: utf-8 -*- import requests, logging, json, openpyxl, os, time #官方下載SDK import dingtalk.api from datetime import datetime as dt from datetime import timedelta import xlsxwriter import configparser import datetime logging.basicConfig(level=logg
繼續訪問
dingtalk 一個讓釘釘服務端開發更簡單的golang工具庫
dingtalk 這是一個集成釘釘常用功能的簡易版服務端開發工具庫,適用於創建一次客戶端，多次調用的場景。內置token過期時間維護；內置用戶id到用戶userid的計算函數，可以方便的在企業用戶名與userid之間自動轉換；同時在rece函數中可以設置加入白名單過濾，避免在測試環境中發信息給非白名單用戶。具體參數說明，請參考釘釘開發文檔 倉庫地址 https://github.com/kevin2027/easy-dingtalk 安裝 go get -u github.com/kevin2027
繼續訪問
【釘釘-場景化能力包】製造業考勤數據多維分析
企業結合釘釘考勤的能力後，可以獲取釘釘的考勤數據，並將考勤數據從時間、機構、部門、人員等多個維度進行橫向縱向比對分析，從而了解一段時間內企業考勤情況的變化趨勢以及各個部門在提升考勤率方面的成果對比，並通過宣導、鼓勵和問責等方式進一步提升員工的工作效能，逐步提升企業整體的考勤達成率。
繼續訪問
② ios app壓力測試工具有哪些
開發和壓力測試軟體大全：
ShareSDK
功能強大、簡單易用的iOS app開發必備社會化分享類庫：ShareSDK。iOS app開發者只需10分鍾即可集成到自己的APP中。不僅支持如QQ、微信、新浪微博、騰訊微博、人人網、豆瓣、facebook、twitter等國內外主流社交平台，還有強大的統計分析管理後台，可以實時了解用戶、信息流、迴流率等數據。
iOS加密
iOS app開發必備加密技術，全球獨有，針對iOS app開發的技術原理和破解原理，分別從本地數據、方法體/方法名、URL編碼、程序結構、網路傳輸數據等幾個方面對iOS app開發進行全方位的保護，從而實現iOS app防破解保護。
Tui
iOS app開發必備，基於FlashCS6的cocos2d-x UI編輯器，可用於操作系統：Mac OS,Windows
PonyDebugger
iOS app開發必備網路調試工具，用於操作系統：Mac OS,其他Pony Debugger 是一個iOS app開發必備的遠程調試工具包，通過使用 Chrome 開發者工具來調試 iOS app開發的網路流量和數據存儲。
iTestin
iTestin是免費服務iOS app開發者的真機自動化雲測試客戶端iOS app開發工具。基於真實的智能終端設備錄制一個測試腳本然後運行，並輸出運行結果。支持功能測試、UI測試、性能測試、穩定性測試、壓力測試，返回包括日誌和截圖的詳細測試報告。
Cornerstone
Mac上最佳的SVN管理iOS app開發必備工具，可用於的用於操作系統包括Mac OS
CocosBuilder
最牛iOS app開發必備Cocos2d編輯器，Mac專屬，對於開發iOS app，Cocos2d-iPhone引擎做的2D游戲開發者來說最大的福音
MarkMan
MarkMan是一款iOS app開發必備高效的設計稿標注和測量軟體，用於操作系統：Mac OS,Windows
SQLCipher
SQLite加密，iOS app開發必備，SQLCipher 提供了對 SQLite 資料庫的傳輸層進行全面加密的iOS app開發工具。而通過使用 SQLCipher ，整個加密過程對客戶端是透明的，無需改動應用程序。
③ 對於一個視頻會議軟體要如何測試，怎樣進行壓力測試呢
讓員工在不同的環境下分階段進入會議，人數逐漸增加，最後測試各種功能即可。
視頻會議軟體選擇中目視頻會議軟體。
中目視頻會議軟體具有以下優勢：
1.高清視頻和音頻：將高質量視頻、音頻和網路會議帶入任何大小的會議室中。
2.與任何人召開會議：在台式機、手機或其他會議室系統上加入遠程參與者。
3.單觸啟動會議：使用語音命令或單觸啟動即時會議或會議通過你的日歷系統。
4.與H.323協議的互操作性：與任何傳統的端點，包括寶利通，思科和LifeSize。
中目視頻會議軟體操作簡單無論何時何地，不受終端限制，一鍵加入會議，一鍵發起會議。同時支持文件共享、注釋等協同操作。同聲傳譯、美顏、滿足各種需求。還支持萬人超大規模會議。不受行業限制，多場景應用。高標准加密，數據更安全。支持私有雲部署，讓安全更有保障，售後提供一對一服務，出現問題及時解決，產品種類多，滿足各種高階需求。
中目視頻會議軟體是華萬旗下的一款產品。
上海華萬通信科技有限公司，2013年成立於上海，是業內知名的通信雲產品運營商。擁有工信部(中華人民共和國工業和信息化部)頒發的全國多方通信運營牌照。
華萬通信自成立以來，始終秉持向客戶提供優質的產品和服務為己任，以「創新研發驅動公司發展」為基本方針，已形成通信雲產品及雲通信智能硬體兩大業務板塊。通過不斷發展，定位聚焦「華萬品牌，華萬研發」，為近萬家政企及教育行業的客戶提供優質的通信雲產品及服務，致力讓每個組織享有高效快捷的智能雲通信產品及服務。
④ 如何實現支持數億用戶的長連消息系統
此文是根據周洋在【高可用架構群】中的分享內容整理而成，轉發請註明出處。
周洋，360手機助手技術經理及架構師，負責360長連接消息系統，360手機助手架構的開發與維護。
不知道咱們群名什麼時候改為「Python高可用架構群」了，所以不得不說，很榮幸能在接下來的一個小時里在Python群里討論golang....
360消息系統介紹
360消息系統更確切的說是長連接push系統，目前服務於360內部多個產品，開發平台數千款app，也支持部分聊天業務場景，單通道多app復用，支持上行數據，提供接入方不同粒度的上行數據和用戶狀態回調服務。
目前整個系統按不同業務分成9個功能完整的集群，部署在多個idc上（每個集群覆蓋不同的idc），實時在線數億量級。通常情況下，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.
幾個大概重要組件介紹如下：
dispatcher service根據客戶端請求信息，將應網路和區域的長連接伺服器的，一組IP傳送給客戶端。客戶端根據返回的IP，建立長連接，連接Room service.
room Service，長連接網關，hold用戶連接，並將用戶注冊進register service，本身也做一些接入安全策略、白名單、IP限制等。
register service是我們全局session存儲組件，存儲和索引用戶的相關信息，以供獲取和查詢。
coordinator service用來轉發用戶的上行數據，包括接入方訂閱的用戶狀態信息的回調，另外做需要協調各個組件的非同步操作，比如kick用戶操作,需要從register拿出其他用戶做非同步操作.
saver service是存儲訪問層，承擔了對redis和mysql的操作，另外也提供部分業務邏輯相關的內存緩存，比如廣播信息的載入可以在saver中進行緩存。另外一些策略，比如客戶端sdk由於被惡意或者意外修改，每次載入了消息，不回復ack，那服務端就不會刪除消息，消息就會被反復載入，形成死循環，可以通過在saver中做策略和判斷。（客戶端總是不可信的）。
center service提供給接入方的內部api伺服器，比如單播或者廣播介面，狀態查詢介面等一系列api,包括運維和管理的api。
舉兩個常見例子，了解工作機制：比如發一條單播給一個用戶，center先請求Register獲取這個用戶之前注冊的連接通道標識、room實例地址，通過room service下發給長連接 Center Service比較重的工作如全網廣播，需要把所有的任務分解成一系列的子任務，分發給所有center，然後在所有的子任務里，分別獲取在線和離線的所有用戶，再批量推到Room Service。通常整個集群在那一瞬間壓力很大。
deployd/agent service用於部署管理各個進程，收集各組件的狀態和信息,zookeeper和keeper用於整個系統的配置文件管理和簡單調度
關於推送的服務端架構
常見的推送模型有長輪訓拉取，服務端直接推送（360消息系統目前主要是這種），推拉結合（推送只發通知，推送後根據通知去拉取消息）.
拉取的方式不說了，現在並不常用了，早期很多是nginx+lua+redis，長輪訓，主要問題是開銷比較大，時效性也不好，能做的優化策略不多。
直接推送的系統，目前就是360消息系統這種，消息類型是消耗型的，並且對於同一個用戶並不允許重復消耗,如果需要多終端重復消耗，需要抽象成不同用戶。
推的好處是實時性好，開銷小，直接將消息下發給客戶端，不需要客戶端走從接入層到存儲層主動拉取.
但純推送模型，有個很大問題，由於系統是非同步的，他的時序性無法精確保證。這對於push需求來說是夠用的，但如果復用推送系統做im類型通信，可能並不合適。
對於嚴格要求時序性，消息可以重復消耗的系統，目前也都是走推拉結合的模型，就是只使用我們的推送系統發通知，並附帶id等給客戶端做拉取的判斷策略，客戶端根據推送的key，主動從業務伺服器拉取消息。並且當主從同步延遲的時候，跟進推送的key做延遲拉取策略。同時也可以通過消息本身的QoS，做純粹的推送策略，比如一些「正在打字的」低優先順序消息，不需要主動拉取了，通過推送直接消耗掉。
哪些因素決定推送系統的效果？
首先是sdk的完善程度，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）越要多，配合精細的選路策略，效果越有保證，至於想知道哪些雲服務有多少點，這個群里來自各地的小夥伴們，可以合夥測測。
go語言開發問題與解決方案
下面講下，go開發過程中遇到挑戰和優化策略，給大家看下當年的一張圖，在第一版優化方案上線前一天截圖~
可以看到，內存最高佔用69G，GC時間單實例最高時候高達3~6s.這種情況下，試想一次悲劇的請求，經過了幾個正在執行gc的組件，後果必然是超時... gc照成的接入方重試，又加重了系統的負擔。遇到這種情況當時整個系統最差情況每隔2，3天就需要重啟一次~
當時出現問題，現在總結起來，大概以下幾點
1.散落在協程里的I/O，Buffer和對象不復用。
當時（12年）由於對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.
改善方式，一種是多實例的拆分，如果公司沒有埠限制，可以很快部署大量實例，減少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語言在並發測試上有獨特優勢。
對於壓力測試，目前主要針對指定的伺服器，選定線上空閑的伺服器做長連接壓測。然後結合可視化，分析壓測過程中的系統狀態。但壓測早期用的比較多，但實現的統計報表功能和我理想有一定差距。我覺得最近出的golang開源產品都符合這種場景，go寫網路並發程序給大家帶來的便利，讓大家把以往為了降低復雜度，拆解或者分層協作的組件，又組合在了一起。
Q&A
Q1:協議棧大小，超時時間定製原則？
移動網路下超時時間按產品需求通常2g，3G情況下是5分鍾，wifi情況下5~8分鍾。但對於個別場景，要求響應非常迅速的場景，如果連接idle超過1分鍾，都會有ping，pong，來校驗是否斷線檢測，盡快做到重新連接。
Q2:消息是否持久化？
消息持久化，通常是先存後發，存儲用的redis，但落地用的mysql。mysql只做故障恢復使用。
Q3:消息風暴怎麼解決的？
如果是發送情況下，普通產品是不需要限速的，對於較大產品是有發送隊列做控速度，按人數，按秒進行控速度發放，發送成功再發送下一條。
Q4:golang的工具鏈支持怎麼樣？我自己寫過一些小程序千把行之內，確實很不錯，但不知道代碼量上去之後，配套的debug工具和profiling工具如何，我看上邊有分享說golang自帶的profiling工具還不錯，那debug呢怎麼樣呢，官方一直沒有出debug工具，gdb支持也不完善，不知你們用的什麼？
是這樣的，我們正常就是println，我感覺基本上可以定位我所有問題，但也不排除由於並行性通過println無法復現的問題，目前來看只能靠經驗了。只要常見並發嘗試，經過分析是可以找到的。go很快會推出調試工具的~
Q5:協議棧是基於tcp嗎？
是否有協議拓展功能？協議棧是tcp，整個系統tcp長連接，沒有考慮擴展其功能~如果有好的經驗，可以分享~
Q6:問個問題，這個系統是接收上行數據的吧，系統接收上行數據後是轉發給相應系統做處理么，是怎麼轉發呢，如果需要給客戶端返回調用結果又是怎麼處理呢？
系統上行數據是根據協議頭進行轉發，協議頭裡面標記了產品和轉發類型，在coordinator裡面跟進產品和轉發類型，回調用戶，如果用戶需要阻塞等待回復才能後續操作，那通過再發送消息，路由回用戶。因為整個系統是全非同步的。
Q7:問個pushsdk的問題。pushsdk的單連接，多app復用方式，這樣的情況下以下幾個問題是如何解決的：1）系統流量統計會把所有流量都算到啟動連接的應用吧？而啟動應用的連接是不固定的吧？2）同一個pushsdk在不同的應用中的版本號可能不一樣，這樣暴露出來的介面可能有版本問題，如果用單連接模式怎麼解決？
流量只能算在啟動的app上了，但一般這種安裝率很高的app承擔可能性大，常用app本身被檢測和殺死可能性較少，另外消息下發量是有嚴格控制 的。整體上用戶還是省電和省流量的。我們pushsdk盡量向上兼容，出於這個目的，push sdk本身做的工作非常有限，抽象出來一些常見的功能，純推的系統，客戶端策略目前做的很少，也有這個原因。
Q8:生產系統的profiling是一直打開的么？
不是一直打開，每個集群都有采樣，但需要開啟哪個可以後台控制。這個profling是通過介面調用。
Q9:面前系統中的消息消費者可不可以分組？類似於Kafka。
客戶端可以訂閱不同產品的消息，接受不同的分組。接入的時候進行bind或者unbind操作
Q10:為什麼放棄erlang,而選擇go，有什麼特別原因嗎？我們現在用的erlang？
erlang沒有問題，原因是我們上線後，其他團隊才做出來，經過qa一個部門對比測試，在沒有顯著性能提升下，選擇繼續使用go版本的push，作為公司基礎服務。
Q11:流控問題有排查過網卡配置導致的idle問題嗎？
流控是業務級別的流控，我們上線前對於內網的極限通信量做了測試，後續將請求在rpc庫內，控制在小於內部通信開銷的上限以下.在到達上限前作流控。
Q12:服務的協調調度為什麼選擇zk有考慮過raft實現嗎？golang的raft實現很多啊，比如Consul和ectd之類的。
3年前，還沒有後兩者或者後兩者沒聽過應該。zk當時公司內部成熟方案，不過目前來看，我們不準備用zk作結合系統的定製開發，准備用自己寫的keeper代替zk，完成配置文件自動轉數據結構，數據結構自動同步指定進程，同時裡面可以完成很多自定義的發現和控制策略，客戶端包含keeper的sdk就可以實現以上的所有監控數據，profling數據收集，配置文件更新，啟動關閉等回調。完全抽象成語keeper通信sdk，keeper之間考慮用raft。
Q13:負載策略是否同時在服務側與CLIENT側同時做的 (DISPATCHER 會返回一組IP)？另外，ROOM SERVER/REGISTER SERVER連接狀態的一致性|可用性如何保證? 服務側保活有無特別關注的地方? 安全性方面是基於TLS再加上應用層加密?
會在server端做，比如重啟操作前，會下發指令類型消息，讓客戶端進行主動行為。部分消息使用了加密策略，自定義的rsa+des，另外滿足我們安全公司的需要，也定製開發很多安全加密策略。一致性是通過冷備解決的，早期考慮雙寫，但實時狀態雙寫同步代價太高而且容易有臟數據，比如register掛了，調用所有room，通過重新刷入指定register來解決。
Q14:這個keeper有開源打算嗎？
還在寫，如果沒耦合我們系統太多功能，一定會開源的，主要這意味著，我們所有的bind在sdk的庫也需要開源~
Q15:比較好奇lisence是哪個如果開源？