編者薦語：

當業務量快速增長的時候，業務保障平台就要應運而生，預判問題發出告警，越快越好，從宏觀到微觀一路下鑽響應越快越好，尤其是交易量暴漲的高峰時段。怎麼做到？看思源的現身說法：

以下文章來源於雲縱達摩院 ，作者劉勤紅

——業務保障平台性能提升走過的那些路
禧雲信息/研發中心/劉勤紅(思源) 2019年11月
 
業務保障平台需從多維度去監控業務的可靠性，快速定位問題並自動解決或推薦出解決方案，所以時效性顯得非常重要。接下來我將從以下三個維度展開如何將百億級數據量監控鑽取從十幾秒提升到秒級體驗：
· 工具升級：OpenTSDB–>Druid
· 調用鏈收集的優化
· 聚合查詢的優化
 

一、背景回顧

· 禧雲的團餐業務發展非常迅速，短短几個月的時間，日交易量就從數百萬拉高到千萬級，隨着調用鏈追蹤得愈發細緻，業務數據量也從億級上升到百億級別。
· 團餐的高峰交易量比外賣更集中，外賣可以提前預訂，而團餐的早中晚就餐非常集中，全國的學生幾乎都是一個點兒下課，從下單到吃完也就集中在20-30分鐘內，下圖0為交易量的曲線圖，坡度幾乎是直線上升，真是爭分奪秒！

圖0 團餐高峰期爭分奪秒不容有失
在這種高強度業務場景下，業務保障平台應運而生，它主要是多場景多維度實時監控大盤，從設備終端到服務端全鏈路監控，讓技術團隊從事後追查和整改，轉變為事前預警和快速判定根因。它主要涉及交易、業務調用鏈路、網絡監控、設備運行指標、業務日誌等維度數據。架構如下圖1所示。
圖1 基於OpenTSDB版的大致架構
· 千萬級日交易數據：從各業務系統或支付網關迴流的交易數據—>交易迴流服務—>多維度聚合入庫OpenTSDB和ElasticSearch集群；
· 十億級業務調用鏈數據：基於Jaeger Trace植入–>Nginx多路分發–>經Jaeger-collector收集到Kafka–>被多組消費者處理（Flink實時寫入OpenTSDB，批量寫入ES）；
· 百億級網絡和設備指標數據：主要是智能設備上報的各種監控指標：基於HTTP/HTTPS層監視–>Nginx–>太空橋（我司IoT平台）設備監控–>批量入庫ES。
技術棧為：
· 鏈路採集：Uber開源的Jaeger
· 基礎數據存儲：ES
· 指標數據存儲：OpenTSDB
· 削峰填谷的消息隊列：Kafka
· 實時計算：Flink  

二、工具升級：OpenTSDB升級到Druid

在禧雲業務保障平台上，OpenTSDB確實沒有太好的性能表現，查詢數據量在百萬級的時候，速度還是可以的，在暑假交易額低谷期並未暴露出OpenTSDB的性能問題。但是進入9月開學季之後，數據延時和查詢緩慢的問題立馬就暴露出來了，中途也寄希望於升級OpenTSDB版本，但依然效果不佳。
 

A. OpenTSDB性能表現不佳的原因

第一個原因，Rowkey設計過長的問題。Rowkey第一大設計原則是保證唯一性，否則原先的數據會被覆蓋掉，第二大設計原則是長度原則，Rowkey是一個二進制，它的長度建議設計在10~100個字節，越短越好。Rowkey如果過長，對性能有以下影響：
1）HBase的持久化文件HFile是按照KeyValue存儲的，如果Rowkey過長，比如500個字節，1000萬列數據，光Rowkey就要佔用500*1000萬=50億個字節，將近1G數據，這會極大影響HFile的存儲效率。
2）MemStore緩存部分數據到內存，如果Rowkey字段過長，內存的有效利用率會降低，系統無法緩存更多的數據，這會降低檢索效率。
需要指出的是不僅Rowkey的長度越短越好，列族名、列名等也盡量使用短名字，因為這些名字都是會寫入HFile中的，過長的Rowkey、列族名、列名都會導致整體的存儲量成倍增加。
 
第二個原因，業務監控業務場景非常多，涉及到不同業務線的多個維度，比如多機房、多支付渠道、商戶/門店/設備/碼等多維度聚合，很難設計出一個滿足全場景的Rowkey方案。在任意維度的組合查詢下，OpenTSDB 查詢效率會明顯降低。
比如對於組合條件查詢使用的就是scan方式，在使用時有以下幾點值得注意：
1）通過setCaching、setBatch方法提高速度，以空間換時間；
2）通過setStartRow與setEndRow來限定範圍，範圍越小，性能越高；
3）通過setFilter方法添加過濾器，這也是分頁、多條件查詢的基礎，比如使用SingleColumnValueFilter。
以上優化當遇到真正海量數據時，會消耗很大的資源，每次都需要花較長的時間處理。
 

B. 升級為Druid

我司其他技術團隊已經試用了Druid， 其核心是通過數據預先聚合提高查詢性能，針對預先定義好的Schema，因此適合實時分析的場景，結果返回時間在亞秒級。
我們切換到Druid之後，響應速度上確實有一個數量級的提升，查詢千萬級的數據範圍基本秒級響應。
 

三、調用鏈收集的優化

調用鏈收集的數據流為：jaeger-collector–>Kafka–>jaeger-ingester 消費–>入庫ES。下面講一下如何優化。
A. 第一階段：Kafka消息堆積高峰期由千萬級降到百萬級
強調一點，合理的分區設置很重要。
剛開始我們嘗試調整每次拉取的消息條數，將ingester.parallelism由1000調整為6000，消息堆積似乎好了一點，但效果不明顯。
考慮到可能是因為併發數不夠，所以通過擴充Kafka的分區數去提高併發。先將分區數由5個擴到8個，消息堆積由千萬級降到百萬級。但繼續將分區擴到10個，就幾乎沒有什麼效果了。  
B. 第二階段：Kafka的版本選擇不可忽視
莫名其妙的是jaeger-ingester消費非常不穩定，頻繁與kafka斷開重連，嘗試去消費其他分區消息，導致消費速率上不去。
後來發現，當Kafka版本為v2.3時，多個jaeger-ingester節點會反覆觸發kafka的消費再平衡機制，結果導致jaeger-ingester只能單點消費。
所以我們又將Kafka版本回退到了v2.2，調整jaeger-ingester實例個數和Kafka分區數為1:1，可橫向擴容支持高併發。
 
C. 第三階段：消息堆積高峰期由百萬降到萬級，延時秒級已可接受
我們觀察到ES的負載已經很高了，單節點高峰期CPU負載達到16。之前為了方便定位問題，給網絡請求實時加上了traceId標記，調用的是jaeger原生的trace鏈路計算。現在分析發現查詢QPS太高，所以嘗試優化查詢邏輯，一方面改為自定義的邏輯直接查詢ES，一方面調整好批量閾值查詢（指的是1次查多少，目前是按時間10ms和數據條數100條一個批次去查ES）。
優化完成后，消息堆積又下降一個數量級。目前高峰期堆積非常少，秒級消費已可接受。
 

四、聚合查詢的優化

A. 散點圖 vs 柱狀圖

對於調用鏈宏觀展示來說，慣常使用散點圖，它可以表達出一段時間內請求的耗時分佈情況，如下圖2所示。

圖2 調用鏈散點圖
但是存在一個問題，當時間區間選得比較大的時候，服務端查詢的數據過多而響應變慢，客戶端要渲染的點太多也會非常卡。所以點要抽樣。抽樣方式能想得到的有：
a.過濾出耗時長的數據；
b.取最近一段時間的數據；
c.只取指定數量的數據；
d.對相同耗時進行聚合展示等等。
這些調整可謂犧牲了監控者的真實需求，因為有些數據監控者看不了，或者很難看全。
我們對比了阿里雲日誌服務的設計，他山之石可以攻玉，借鑒了以下兩點：
第一點，人們看問題的方式總是從宏觀一路下鑽到微觀，所以我們加了柱狀圖做為時間段聚合，方便從宏觀上看到請求量的規模分佈。下圖3是某區域的訂單趨勢柱狀圖。

圖3 訂單趨勢柱狀圖
第二點，如果數據量非常大，可繼續點擊柱圖，展開當前時間條件下的子柱狀圖。系統根據數據量規模，自動展示出散點圖，方便用戶瀏覽耗時分佈。這樣一層層穿刺下鑽，既滿足了人的操作習慣，又提高了處理速度，做到了秒級響應。

圖4柱狀圖下鑽
 

B. 從宏觀到微觀，化繁為簡

就宏觀到微觀的監控下鑽，下面講三個案例。
案例一，單一維度下鑽
其實多數時候人們只想關注某一維度的分佈情況，比如按應用、按工程、按服務IP、按請求URL、按商戶、按門店、按設備看分佈。對於ES來說，單一條件聚合速度很快，秒級響應。
案例二，網絡質量監察
我司在全國大江南北分佈着大量餐飲中心（即食堂），如何快速定位出哪些食堂網絡環境糟糕呢？不能等客戶告訴我們。
我們從請求量級篩選（系統推薦和自定義）、dns/http/ssl/tcp/mqtt耗時情況、趨勢發展等諸多因子中分析出餐飲中心網絡情況，哪怕是學校食堂的一次網絡抖動，都可以被我們偵查到。不僅能分析出網絡問題，而且還能下鑽到請求鏈路上的任何階段，比如是DNS、TCP、SSL、首包等，並分析出受影響的終端設備。依然是秒級響應，如下圖5所示。

圖5 設備耗時下鑽
 
案例三，找出掉單
當用戶已支付而商戶未收款時，如何從千萬級訂單中快速找到丟失的那一筆訂單呢？內部稱sos訂單：

• 秒級偵查出來；
• 快速定位在哪個環節出了問題；
• 系統自我修復能力

具體做法為：
第一步，將內部可能發生的業務場景圈出來，通過Flink實時計算形成閉環，當其中一個鏈條斷了，就會立馬把待排查的sos訂單壓入隊列任務，然後不斷主動查詢第三方支付渠道確認支付狀態。
第二步，對於一些疑難問題如短時間內系統無法解決時，比如第三方支付渠道出現了故障，就會發出告警消息給客服，客服預先跟進，減少用戶投訴處理時間。
 
總結一下：
OpenTSDB切換為Druid，明顯提升了從宏觀下鑽到微觀的響應時間，基本能做到百億級數據量秒級響應。高峰時段Kafka消息堆積也大幅降低。下鑽方式做了優化，更符合工程師探查習慣。
 
-完-

歡迎關注公眾號：老兵筆記

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

※專營大陸快遞台灣服務

※台灣快遞大陸的貨運公司有哪些呢?

被視為未來趨勢的電動車，目前在車市中的市占仍然相當低，而若談到推動電動車發展，印度絕對是當前最野心勃勃的國家。近日，印度電力部長提出新政策，要讓電動車購車族免付頭期款，以提高民眾購買的意願，最終目標是要在 2030 年前，讓印度境內上路的車輛 100% 為電動車。

印度為目前全球空氣污染最嚴重的國家之一，國內有 13 個城市名列全球前 20 大最受污染城市。為了從根本改善印度的空氣品質，降低對化石燃料的依賴勢在必行，而印度電力部懷抱著強大的信心，表示不造成人民經濟上的壓力，就能全力推動國內電動車發展。   印度電力部長 Piyush Goyal 日前信誓旦旦的表示，「印度將成為全球首個在如此國土規模大小之下，100% 全電動車上路的國家」，且 Goyal 透露，將努力嘗試讓這項計畫由電力部的資金供應運作，「我們不需要用到政府與印度人民的任何一毛錢」。   有了電動車購車零頭期款的政策，Goyal 相信，這可提高購車意願，使人們更輕鬆的將省下大筆油錢轉往購買電動車。Goyal 透露，目前正與其他政府官員合作，由印度道路運輸與公路部部長 Nitin Gadkari、石油部長 Dharmendra Pradhan 及環境部長 Prakash Javadekar 帶領成立的工作小組，商討與評估這個政策提議是否可行，以及「確保電動車車主能享有便宜的充電價格」。   雖然利用電動車取代排放溫室氣體的傳統汽車，能夠為空氣品質本就相當糟糕的印度，減少交通運輸這部分所造成的碳排放，但也有人質疑，推動電動車的結果將造成電力需求上升，最終可能會導致供給發電的能源產業製造更多碳排放量也說不定，畢竟，印度目前約 60% 的能源產出來自燃煤發電，而燃煤發電廠在印度已經是一大污染來源之一，且其溫室氣體排放量在這幾年依然持續成長中。   此外，印度曾對外公開其再生能源目標，要使再生能源裝置量從 2016 年的不到 12 GW，增加到 2022 年的 175 GW，根據先前的報導曾指出，印度要達到 175 GW 的目標，所需花費的資金相當「可觀」，若又加上推動電動車發展所提出的免付頭期款政策，可能會讓印度走向再生能源主導之路，更顯困難重重了。

（首圖來源： CC BY 2.0）

（本文授權轉載自《》─〈〉）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

※專營大陸快遞台灣服務

※台灣快遞大陸的貨運公司有哪些呢?

你好，我是彤哥，本篇是netty系列的第四篇。

歡迎來我的公從號彤哥讀源碼系統地學習源碼&架構的知識。

簡介

上一章我們一起學習了Java中的BIO/NIO/AIO的故事，本章將帶着大家一起使用純純的NIO實現一個越聊越上癮的“群聊系統”。

業務邏輯分析

首先，我們先來分析一下群聊的功能點：

（1）加入群聊，並通知其他人；

（2）發言，並通知其他人；

（3）退出群聊，並通知其他人；

一個簡單的群聊系統差不多這三個功能足夠了，為了方便記錄用戶信息，當用戶加入群聊的時候自動給他分配一個用戶ID。

業務實現

上代碼：

// 這是一個內部類
private static class ChatHolder {
    // 我們只用了一個線程，用普通的HashMap也可以
    static final Map<SocketChannel, String> USER_MAP = new ConcurrentHashMap<>();

    /**
     * 加入群聊
     * @param socketChannel
     */
    static void join(SocketChannel socketChannel) {
        // 有人加入就給他分配一個id，本文來源於公從號“彤哥讀源碼”
        String userId = "用戶"+ ThreadLocalRandom.current().nextInt(Integer.MAX_VALUE);
        send(socketChannel, "您的id為：" + userId + "\n\r");

        for (SocketChannel channel : USER_MAP.keySet()) {
            send(channel, userId + " 加入了群聊" + "\n\r");
        }

        // 將當前用戶加入到map中
        USER_MAP.put(socketChannel, userId);
    }

    /**
     * 退出群聊
     * @param socketChannel
     */
    static void quit(SocketChannel socketChannel) {
        String userId = USER_MAP.get(socketChannel);
        send(socketChannel, "您退出了群聊" + "\n\r");
        USER_MAP.remove(socketChannel);

        for (SocketChannel channel : USER_MAP.keySet()) {
            if (channel != socketChannel) {
                send(channel, userId + " 退出了群聊" + "\n\r");
            }
        }
    }

    /**
     * 擴散說話的內容
     * @param socketChannel
     * @param content
     */
    public static void propagate(SocketChannel socketChannel, String content) {
        String userId = USER_MAP.get(socketChannel);
        for (SocketChannel channel : USER_MAP.keySet()) {
            if (channel != socketChannel) {
                send(channel, userId + ": " + content + "\n\r");
            }
        }
    }

    /**
     * 發送消息
     * @param socketChannel
     * @param msg
     */
    static void send(SocketChannel socketChannel, String msg) {
        try {
            ByteBuffer writeBuffer = ByteBuffer.allocate(1024);
            writeBuffer.put(msg.getBytes());
            writeBuffer.flip();
            socketChannel.write(writeBuffer);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

服務端代碼

服務端代碼直接使用上一章NIO的實現，只不過這裏要把上面實現的業務邏輯適時地插入到相應的事件中。

（1）accept事件，即連接建立的時候，說明加入了群聊；

（2）read事件，即讀取數據的時候，說明有人說話了；

（3）連接斷開的時候，說明退出了群聊；

OK，直接上代碼，為了與上一章的代碼作區分，彤哥特意加入了一些標記：

public class ChatServer {
    public static void main(String[] args) throws IOException {
        Selector selector = Selector.open();
        ServerSocketChannel serverSocketChannel = ServerSocketChannel.open();
        serverSocketChannel.bind(new InetSocketAddress(8080));
        serverSocketChannel.configureBlocking(false);
        // 將accept事件綁定到selector上
        serverSocketChannel.register(selector, SelectionKey.OP_ACCEPT);

        while (true) {
            // 阻塞在select上
            selector.select();
            Set<SelectionKey> selectionKeys = selector.selectedKeys();
            // 遍歷selectKeys
            Iterator<SelectionKey> iterator = selectionKeys.iterator();
            while (iterator.hasNext()) {
                SelectionKey selectionKey = iterator.next();
                // 如果是accept事件
                if (selectionKey.isAcceptable()) {
                    ServerSocketChannel ssc = (ServerSocketChannel) selectionKey.channel();
                    SocketChannel socketChannel = ssc.accept();
                    System.out.println("accept new conn: " + socketChannel.getRemoteAddress());
                    socketChannel.configureBlocking(false);
                    socketChannel.register(selector, SelectionKey.OP_READ);
                    // 加入群聊，本文來源於公從號“彤哥讀源碼”
                    ChatHolder.join(socketChannel);
                } else if (selectionKey.isReadable()) {
                    // 如果是讀取事件
                    SocketChannel socketChannel = (SocketChannel) selectionKey.channel();
                    ByteBuffer buffer = ByteBuffer.allocate(1024);
                    // 將數據讀入到buffer中
                    int length = socketChannel.read(buffer);
                    if (length > 0) {
                        buffer.flip();
                        byte[] bytes = new byte[buffer.remaining()];
                        // 將數據讀入到byte數組中
                        buffer.get(bytes);

                        // 換行符會跟着消息一起傳過來
                        String content = new String(bytes, "UTF-8").replace("\r\n", "");
                        if (content.equalsIgnoreCase("quit")) {
                            // 退出群聊，本文來源於公從號“彤哥讀源碼”
                            ChatHolder.quit(socketChannel);
                            selectionKey.cancel();
                            socketChannel.close();
                        } else {
                            // 擴散，本文來源於公從號“彤哥讀源碼”
                            ChatHolder.propagate(socketChannel, content);
                        }
                    }
                }
                iterator.remove();
            }
        }
    }
}

測試

打開四個XSHELL客戶端，分別連接telnet 127.0.0.1 8080，然後就可以開始群聊了。

彤哥發現，自己跟自己聊天也是會上癮的，完全停不下來，不行了，我再去自聊一會兒^^

總結

本文彤哥跟着大家一起實現了“群聊系統”，去掉註釋也就100行左右的代碼，是不是非常簡單？這就是NIO網絡編程的魅力，我發現寫網絡編程也上癮了^^

問題

這兩章我們都沒有用NIO實現客戶端，你知道怎麼實現嗎？

提示：服務端需要監聽accept事件，所以需要有一個ServerSocketChannel，而客戶端是直接去連服務器了，所以直接用SocketChannel就可以了，一個SocketChannel就相當於一個Connection。

最後，也歡迎來我的公從號彤哥讀源碼系統地學習源碼&架構的知識。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

※專營大陸快遞台灣服務

※台灣快遞大陸的貨運公司有哪些呢?