如何用go語言每分鐘處理100萬個請求

在Malwarebytes 我們經歷了顯著的增長，自從我一年前加入了硅谷的公司，一個主要的職責成了設計架構和開發一些系統來支持一個快速增長的信息安全公司和所有需要的設施來支持一個每天百萬用戶使用的產品。我在反病毒和反惡意軟件行業的不同公司工作了12年，從而我知道由于我們每天處理大量的數據，這些系統是多么復雜。

創新互聯建站專注于企業成都全網營銷推廣、網站重做改版、榆陽網站定制設計、自適應品牌網站建設、H5響應式網站、商城網站建設、集團公司官網建設、成都外貿網站制作、高端網站制作、響應式網頁設計等建站業務，價格優惠性價比高，為榆陽等各大城市提供網站開發制作服務。

有趣的是，在過去的大約9年間，我參與的所有的web后端的開發通常是通過Ruby on Rails技術實現的。不要錯怪我。我喜歡Ruby on Rails，并且我相信它是個令人驚訝的環境。但是一段時間后，你會開始以ruby的方式開始思考和設計系統，你會忘記，如果你可以利用多線程、并行、快速執行和小內存開銷，軟件架構本來應該是多么高效和簡單。很多年期間，我是一個c/c++、Delphi和c#開發者，我剛開始意識到使用正確的工具可以把復雜的事情變得簡單些。

作為首席架構師，我不會很關心在互聯網上的語言和框架戰爭。我相信效率、生產力。代碼可維護性主要依賴于你如何把解決方案設計得很簡單。

問題

當工作在我們的匿名遙測和分析系統中，我們的目標是可以處理來自于百萬級別的終端的大量的POST請求。web處理服務可以接收包含了很多payload的集合的JSON數據，這些數據需要寫入Amazon S3中。接下來，map-reduce系統可以操作這些數據。

按照習慣，我們會調研服務層級架構，涉及的軟件如下：

Sidekiq

Resque

DelayedJob

Elasticbeanstalk Worker Tier

RabbitMQ

and so on…

搭建了2個不同的集群，一個提供web前端，另外一個提供后端處理，這樣我們可以橫向擴展后端服務的數量。

但是，從剛開始，在 討論階段我們的團隊就知道我們應該使用Go，因為我們看到這會潛在性地成為一個非常龐大（ large traffic）的系統。我已經使用了Go語言大約2年時間，我們開發了幾個系統，但是很少會達到這樣的負載（amount of load）。

我們開始創建一些結構，定義從POST調用得到的web請求負載，還有一個上傳到S3 budket的函數。

type PayloadCollection struct {

WindowsVersion string `json:"version"`

Token string `json:"token"`

Payloads []Payload `json:"data"`

}

type Payload struct {

// [redacted]

}

func (p *Payload) UploadToS3() error {

// the storageFolder method ensures that there are no name collision in

// case we get same timestamp in the key name

storage_path := fmt.Sprintf("%v/%v", p.storageFolder, time.Now().UnixNano())

bucket := S3Bucket

b := new(bytes.Buffer)

encodeErr := json.NewEncoder(b).Encode(payload)

if encodeErr != nil {

return encodeErr

}

// Everything we post to the S3 bucket should be marked 'private'

var acl = s3.Private

var contentType = "application/octet-stream"

return bucket.PutReader(storage_path, b, int64(b.Len()), contentType, acl, s3.Options{})

}

本地Go routines方法

剛開始，我們采用了一個非常本地化的POST處理實現，僅僅嘗試把發到簡單go routine的job并行化：

func payloadHandler(w http.ResponseWriter, r *http.Request) {

if r.Method != "POST" {

w.WriteHeader(http.StatusMethodNotAllowed)

return

}

// Read the body into a string for json decoding

var content = PayloadCollection{}

err := json.NewDecoder(io.LimitReader(r.Body, MaxLength)).Decode(content)

if err != nil {

w.Header().Set("Content-Type", "application/json; charset=UTF-8")

w.WriteHeader(http.StatusBadRequest)

return

}

// Go through each payload and queue items individually to be posted to S3

for _, payload := range content.Payloads {

go payload.UploadToS3() // ----- DON'T DO THIS

}

w.WriteHeader(http.StatusOK)

}

對于中小負載，這會對大多數的人適用，但是大規模下，這個方案會很快被證明不是很好用。我們期望的請求數，不在我們剛開始計劃的數量級，當我們把第一個版本部署到生產環境上。我們完全低估了流量。

上面的方案在很多地方很不好。沒有辦法控制我們產生的go routine的數量。由于我們收到了每分鐘1百萬的POST請求，這段代碼很快就崩潰了。

再次嘗試

我們需要找一個不同的方式。自開始我們就討論過， 我們需要保持請求處理程序的生命周期很短，并且進程在后臺產生。當然，這是你在Ruby on Rails的世界里必須要做的事情，否則你會阻塞在所有可用的工作 web處理器上，不管你是使用puma、unicore還是passenger（我們不要討論JRuby這個話題）。然后我們需要利用常用的處理方案來做這些，比如Resque、 Sidekiq、 SQS等。這個列表會繼續保留，因為有很多的方案可以實現這些。

所以，第二次迭代，我們創建了一個緩沖channel，我們可以把job排隊，然后把它們上傳到S3。因為我們可以控制我們隊列中的item最大值，我們有大量的內存來排列job，我們認為只要把job在channel里面緩沖就可以了。

var Queue chan Payload

func init() {

Queue = make(chan Payload, MAX_QUEUE)

}

func payloadHandler(w http.ResponseWriter, r *http.Request) {

...

// Go through each payload and queue items individually to be posted to S3

for _, payload := range content.Payloads {

Queue - payload

}

...

}

接下來，我們再從隊列中取job，然后處理它們。我們使用類似于下面的代碼：

func StartProcessor() {

for {

select {

case job := -Queue:

job.payload.UploadToS3() // -- STILL NOT GOOD

}

}

}

說實話，我不知道我們在想什么。這肯定是一個滿是Red-Bulls的夜晚。這個方法不會帶來什么改善，我們用了一個 有缺陷的緩沖隊列并發，僅僅是把問題推遲了。我們的同步處理器同時僅僅會上傳一個數據到S3，因為來到的請求遠遠大于單核處理器上傳到S3的能力，我們的帶緩沖channel很快達到了它的極限，然后阻塞了請求處理邏輯的queue更多item的能力。

我們僅僅避免了問題，同時開始了我們的系統掛掉的倒計時。當部署了這個有缺陷的版本后，我們的延時保持在每分鐘以常量增長。

最好的解決方案

我們討論過在使用用Go channel時利用一種常用的模式，來創建一個二級channel系統，一個來queue job，另外一個來控制使用多少個worker來并發操作JobQueue。

想法是，以一個恒定速率并行上傳到S3，既不會導致機器崩潰也不好產生S3的連接錯誤。這樣我們選擇了創建一個Job/Worker模式。對于那些熟悉Java、C#等語言的開發者，可以把這種模式想象成利用channel以golang的方式來實現了一個worker線程池，作為一種替代。

var (

MaxWorker = os.Getenv("MAX_WORKERS")

MaxQueue = os.Getenv("MAX_QUEUE")

)

// Job represents the job to be run

type Job struct {

Payload Payload

}

// A buffered channel that we can send work requests on.

var JobQueue chan Job

// Worker represents the worker that executes the job

type Worker struct {

WorkerPool chan chan Job

JobChannel chan Job

quit chan bool

}

func NewWorker(workerPool chan chan Job) Worker {

return Worker{

WorkerPool: workerPool,

JobChannel: make(chan Job),

quit: make(chan bool)}

}

// Start method starts the run loop for the worker, listening for a quit channel in

// case we need to stop it

func (w Worker) Start() {

go func() {

for {

// register the current worker into the worker queue.

w.WorkerPool - w.JobChannel

select {

case job := -w.JobChannel:

// we have received a work request.

if err := job.Payload.UploadToS3(); err != nil {

log.Errorf("Error uploading to S3: %s", err.Error())

}

case -w.quit:

// we have received a signal to stop

return

}

}

}()

}

// Stop signals the worker to stop listening for work requests.

func (w Worker) Stop() {

go func() {

w.quit - true

}()

}

我們已經修改了我們的web請求handler，用payload創建一個Job實例，然后發到JobQueue channel，以便于worker來獲取。

func payloadHandler(w http.ResponseWriter, r *http.Request) {

if r.Method != "POST" {

w.WriteHeader(http.StatusMethodNotAllowed)

return

}

// Read the body into a string for json decoding

var content = PayloadCollection{}

err := json.NewDecoder(io.LimitReader(r.Body, MaxLength)).Decode(content)

if err != nil {

w.Header().Set("Content-Type", "application/json; charset=UTF-8")

w.WriteHeader(http.StatusBadRequest)

return

}

// Go through each payload and queue items individually to be posted to S3

for _, payload := range content.Payloads {

// let's create a job with the payload

work := Job{Payload: payload}

// Push the work onto the queue.

JobQueue - work

}

w.WriteHeader(http.StatusOK)

}

在web server初始化時，我們創建一個Dispatcher，然后調用Run()函數創建一個worker池子，然后開始監聽JobQueue中的job。

dispatcher := NewDispatcher(MaxWorker)

dispatcher.Run()

下面是dispatcher的實現代碼：

type Dispatcher struct {

// A pool of workers channels that are registered with the dispatcher

WorkerPool chan chan Job

}

func NewDispatcher(maxWorkers int) *Dispatcher {

pool := make(chan chan Job, maxWorkers)

return Dispatcher{WorkerPool: pool}

}

func (d *Dispatcher) Run() {

// starting n number of workers

for i := 0; i d.maxWorkers; i++ {

worker := NewWorker(d.pool)

worker.Start()

}

go d.dispatch()

}

func (d *Dispatcher) dispatch() {

for {

select {

case job := -JobQueue:

// a job request has been received

go func(job Job) {

// try to obtain a worker job channel that is available.

// this will block until a worker is idle

jobChannel := -d.WorkerPool

// dispatch the job to the worker job channel

jobChannel - job

}(job)

}

}

}

注意到，我們提供了初始化并加入到池子的worker的最大數量。因為這個工程我們利用了Amazon Elasticbeanstalk帶有的docker化的Go環境，所以我們常常會遵守12-factor方法論來配置我們的生成環境中的系統，我們從環境變了讀取這些值。這種方式，我們控制worker的數量和JobQueue的大小，所以我們可以很快的改變這些值，而不需要重新部署集群。

var (

MaxWorker = os.Getenv("MAX_WORKERS")

MaxQueue = os.Getenv("MAX_QUEUE")

)

直接結果

我們部署了之后，立馬看到了延時降到微乎其微的數值，并未我們處理請求的能力提升很大。

Elastic Load Balancers完全啟動后，我們看到ElasticBeanstalk 應用服務于每分鐘1百萬請求。通常情況下在上午時間有幾個小時，流量峰值超過每分鐘一百萬次。

我們一旦部署了新的代碼，服務器的數量從100臺大幅 下降到大約20臺。

我們合理配置了我們的集群和自動均衡配置之后，我們可以把服務器的數量降至4x EC2 c4.Large實例，并且Elastic Auto-Scaling設置為如果CPU達到5分鐘的90%利用率，我們就會產生新的實例。

總結

在我的書中，簡單總是獲勝。我們可以使用多隊列、后臺worker、復雜的部署設計一個復雜的系統，但是我們決定利用Elasticbeanstalk 的auto-scaling的能力和Go語言開箱即用的特性簡化并發。

我們僅僅用了4臺機器，這并不是什么新鮮事了。可能它們還不如我的MacBook能力強大，但是卻處理了每分鐘1百萬的寫入到S3的請求。

處理問題有正確的工具。當你的 Ruby on Rails 系統需要更強大的web handler時，可以考慮下ruby生態系統之外的技術，或許可以得到更簡單但更強大的替代方案。

GO語言商業案例（六）：PayPal

創建 PayPal 的目的是使金融服務民主化，并使個人和企業能夠加入并在全球經濟中蓬勃發展。這項工作的核心是 PayPal 的支付平臺，該平臺使用專有技術和第三方技術的組合來高效、安全地促進全球數百萬商家和消費者之間的交易。隨著支付平臺變得越來越大、越來越復雜，PayPal 尋求對其系統進行現代化改造并縮短新應用程序的上市時間。

Go 在生成干凈、高效的代碼方面的有著極高的價值。這些代碼可以隨著軟件部署的擴展而輕松擴展，這使得該語言非常適合支持 PayPal 的目標。

支付處理平臺的核心是 PayPal 用 C++ 開發的專有 NoSQL 數據庫。然而，代碼的復雜性大大降低了開發人員發展平臺的能力。Go 的簡單代碼布局、goroutine（輕量級執行線程）和通道（用作連接并發 goroutine 的管道）使 Go 成為 NoSQL 開發團隊簡化和現代化平臺的自然選擇。

作為概念驗證，一個開發團隊花了六個月的時間學習 Go 并在 Go 中從頭開始重新實現 NoSQL 系統，在此期間，他們還提供了有關如何在 PayPal 更廣泛地實施 Go 的見解。截至今天，已遷移 30% 的集群以使用新的 NoSQL 數據庫。

隨著 PayPal 的平臺變得越來越復雜，Go 提供了一種輕松簡化大規模創建和運行軟件的復雜性的方法。該語言為 PayPal 提供了出色的庫和快速工具，以及并發、垃圾收集和類型安全。

借助 Go，PayPal 使其開發人員能夠將更多時間從 C++ 和 Java 開發的噪音中解放出來，從而能夠花更多時間查看代碼和進行戰略性思考。

在這個新改寫的 NoSQL 系統取得成功后，PayPal 內更多的平臺和內容團隊開始采用 Go。Natarajan 目前的團隊負責 PayPal 的構建、測試和發布管道——所有這些都是在 Go 中構建的。該公司擁有一個大型構建和測試農場，它使用 Go 基礎設施進行完全管理，以支持整個公司的開發人員的構建即服務（和測試即服務）。

憑借 PayPal 所需的分布式計算能力，Go 是刷新系統的正確語言。PayPal 需要并發和并行的編程，為高性能和高度可移植性而編譯，并為開發人員帶來模塊化、可組合的開源架構的好處——Go 已經提供了所有這些以及更多幫助 PayPal 對其系統進行現代化改造。

安全性和可支持性是 PayPal 的關鍵問題，該公司的運營管道越來越多地由 Go 主導，因為該語言的簡潔性和模塊化幫助他們實現了這些目標。PayPal 對 Go 的部署為開發人員提供了一個創意平臺，使他們能夠為 PayPal 的全球市場大規模生產簡單、高效和可靠的軟件。

隨著 PayPal 繼續使用 Go 對其軟件定義網絡 (SDN) 基礎設施進行現代化改造，除了更易于維護的代碼外，他們還看到了性能優勢。例如，Go 現在為路由器、負載平衡和越來越多的生產系統提供動力。

作為一家全球性企業，PayPal 需要其開發團隊有效管理兩種規模：生產規模，尤其是與許多其他服務器（如云服務）交互的并發系統；和開發規模，尤其是由許多程序員協同開發的大型代碼庫（如開源開發）

PayPal 利用 Go 來解決這些規模問題。該公司的開發人員受益于 Go 將解釋型動態類型語言的編程易用性與靜態類型編譯語言的效率和安全性相結合的能力。隨著 PayPal 對其系統進行現代化改造，對網絡和多核計算的支持至關重要。Go 不僅提供了這種支持，而且提供的速度很快——在單臺計算機上編譯一個大型可執行文件最多需要幾秒鐘。

PayPal 目前有 100 多名 Go 開發人員，未來選擇采用 Go 的開發人員將更容易獲得該語言的批準，這要歸功于公司已經在生產中的許多成功實現。

最重要的是，PayPal 開發人員使用 Go 提高了他們的生產力。Go 的并發機制使得編寫充分利用 PayPal 的多核和聯網機器的程序變得很容易。使用 Go 的開發人員還受益于它可以快速編譯為機器代碼的事實，并且他們的應用程序獲得了垃圾收集的便利和運行時反射的強大功能。

今天 PayPal 的第一類語言是 Java 和 Node，Go 主要用作基礎設施語言。雖然 Go 可能永遠不會在某些應用程序中取代 Node.js，但 Natarajan 正在推動讓 Go 成為 PayPal 的第一類語言。

通過他的努力，PayPal 還在評估遷移到 Google Kubernetes Engine (GKE) 以加快其新產品的上市時間。GKE 是一個用于部署容器化應用程序的托管、生產就緒環境，并帶來了 Google 在開發人員生產力、自動化操作和開源靈活性方面的最新創新。

對于 PayPal 而言，部署到 GKE 將使 PayPal 更容易部署、更新和管理其應用程序和服務，從而實現快速開發和迭代。此外，PayPal 會發現更容易運行機器學習、通用 GPU、高性能計算和其他受益于 GKE 支持的專用硬件加速器的工作負載。

對 PayPal 來說最重要的是，Go 開發和 GKE 的結合使公司能夠輕松擴展以滿足需求，因為 Kubernetes 自動擴展將使 PayPal 能夠處理用戶對服務不斷增長的需求——在最重要的時候保持它們可用，然后在安靜的時間來省錢。

《Go語言實戰》epub下載在線閱讀，求百度網盤云資源

《Go語言實戰》（威廉·肯尼迪 (William Kennedy)）電子書網盤下載免費在線閱讀

鏈接：

提取碼：1234

書名：Go語言實戰

作者：威廉·肯尼迪 (William Kennedy)

譯者：李兆海

豆瓣評分：7.7

出版社：人民郵電出版社

出版年份：2017-3-1

頁數：224

內容簡介：

Go語言結合了底層系統語言的能力以及現代語言的高級特性，旨在降低構建簡單、可靠、高效軟件的門檻。本書向讀者提供一個專注、全面且符合語言習慣的視角。Go語言實戰同時關注語言的規范和實現，涉及的內容包括語法、類型系統、并發、管道、測試，以及其他一些主題。

作者簡介：

William Kennedy，是一位熟練的軟件開發者，也是博客GoingGo.Net的作者。

Brian Ketelsen和Erik St. Martin是全球Go語言大會GopherCon的組織者，也是Go語言框架Skynet的聯合作者。

李兆海，多年專注于后端分布式網絡服務開發，曾使用過多個流行后端技術和相關架構實踐，是Go語言和Docker的早期使用者和推廣者，《第1本Docker書》的譯者。作為項目技術負責人，成功開發了百萬用戶級直播系統。

golang+vue3開發的一個im應用

這是一個開源的前后端分離的IM網頁應用。

服務端：

web端：

如何實現支持數億用戶的長連消息系統

此文是根據周洋在【高可用架構群】中的分享內容整理而成，轉發請注明出處。

周洋，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寫網絡并發程序給大家帶來的便利，讓大家把以往為了降低復雜度，拆解或者分層協作的組件，又組合在了一起。

QA

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是哪個如果開源？

即構科技IM即時通訊怎么樣？

個人覺得還不錯，即構的IM產品不僅支持基礎的單聊/群聊功能，還支持消息高并發量的房間聊天，單房間人數支持到百萬以上。總的來說可以為開發者提供全平臺互動、海量并發、超低延時、消息必達的通信服務，助力打造大型直播、語聊房、客服系統等場景。