數字化營運基礎
在如今“雙十一”不再是線上活動的代名詞，而逐漸變為一場線上線下同時進行的消費者盛宴。銷售、營運、物流、生産商等都在開足馬力在各大管道備戰，據統計：
- 消費者在期間被平均推送200+活動消息
- 消費者會花幾個小時比較、提前篩選自己中意産品
- 除了線上外，90%線下店鋪都挂出針對雙十一營運活動
雙十一觸客管道也呈現多樣化，例如：網絡店鋪、短信、郵件、微信公衆賬号、派單與Kitty闆、自提櫃、智能裝置（例如天貓精靈點單）、多媒體裝置（例如電視或機頂盒購物）等。
面對如此多的管道和銷售方式，營運和銷售如何有效掌控，并通過數字化方式進行營運是一項硬能力。讓我們來看幾個例子：
例子1：新使用者引流
網際網路經典書籍《上瘾：建構習慣養成的産品》把使用者擷取過程分為4個階段：觸發、行動、獎勵、投入。作為最開始的觸發環節，給使用者群發消息是最有效的手段之一。但如何衡量轉化效果呢？
我們可以在推廣資訊中做一個埋點，把使用者點選短信帶上關聯資訊，例如設計一個如下的URL，其中放入2個關鍵參數：
- t: 代表發送的批次編号，也可以作為管道的辨別
- m：代表發送的短信号碼
html://mywebsite.com/new?t=1002&m=13860394XX 
當使用者點點選消息通路站點時，我們在服務端通路日志中會自動記錄對應資訊:
202.168.1.209 - - [02/Feb/2016:17:44:13+0800] "GEThtml://mywebsite.com/new?t=1002&m=13860394XX HTTP/1.1" 200 209 - "Mozilla/5.0(Macintosh; Intel Mac OS X10_11_3) AppleWebKit/537.36(KHTML, like Gecko)Chrome/48.0.2564.97 Safari/537.36" 這樣我們就能獲得推廣效果和轉化率：
例子2：線上購買意圖捕捉
在擷取客戶後，下一步是讓使用者付諸于行動。使用者在浏覽商品時，會有頁面的停留，閱讀，比較和加入購物車等操作。可以借助Web Tracking和Serve端埋點來進行靜态與動态資料采集。
在靜态網頁和浏覽器埋點：
<img src=‘http://${project}.${sls-host}/logstores/${logstore}/track_ua.gif?APIVersion=0.6.0&key1=val1&key2=val2’/> 通過JS埋點：
varlogger = new window.Tracker('cn-hangzhou.log.aliyuncs.com','ali-test-tracking','web-tracking');
logger.push('customer','zhangsan');
logger.push('product','iphone6s');
logger.push('price',5500);
logger.logger(); 在完成資料埋點後，我們可以在日志服務分析功能中，獲得每個環節的點選數和轉化數字，以衡量購買階段的效果。
Web Tracking連結： https://help.aliyun.com/document_detail/31752.html 服務端埋點連結： https://help.aliyun.com/document_detail/28979.html
資料采集挑戰
從上面例子來看，資料采集是數字化IT的基礎。讓我們來看一個典型的資料采集架構：
- 購買一批機器搭建網絡伺服器
- 為伺服器搭建負載均衡裝置
- 在網絡伺服器（例如Nginx）子產品中使用Kafka等中間件寫入資料
該方案通過無狀态設計解決了高可用，按需擴容等問題，也是衆多廠商采用的方案，在理想狀态下運作得非常好。但在現實過程中，往往會遇到如下挑戰：
| 步驟 | 子產品 | 挑戰 | 成本 |
|---|---|---|---|
| 端 | 協定封裝與用戶端開發 | 需要開發衆多SDK，例如Android、IOS、嵌入式等 | 研發成本、運維 |
| 用戶端傳輸 | 面向網絡不可用 | 斷點續傳功功能 | |
| 傳輸過程中安全問題 | HTTPS協定支援與證書 | ||
| 用戶端更新 | 用戶端如果有Bug如何更新 | 運維成本 | |
| 傳輸 | 網絡品質差 | 購買昂貴專線 | |
| 地域與合規 | 使用者資料不能出國，例如歐盟等協定 | 在全球建各資料中心 | |
| 網絡選擇 | 營運商速度、品質不一，品質差 | 購買第三方加速服務 | |
| 服務端 | 擴容 | 流量上漲時，如何自動擴容 | 購買伺服器、手動運維 |
| 防攻擊 | 采集伺服器可能被DDOS | 運維伺服器 | |
| 認證 | 進行使用者認證與管理 | 開發負責的認證與管理子產品 | |
| 資料加工 | 資料到服務端後，增加來源IP、服務端時間等字段 | 服務端開發成本 | |
| 上下遊對接 | 對接各種流計算、離線處理系統 | 硬體采購、程式開發與維護 |
作為使用者最終的目标是為了分析資料。但這些問題的存在，需要在業務、規模與增長上消耗大量人力、精力和物力，幹了不一定幹得好。
日志服務LogHub功能
阿裡雲日志服務（Log Service，/原SLS）是針對實時資料一站式服務，其中的LogHub子產品就是專為資料采集定制的功能，該功能有如下特點：
1. 30+實時采集手段
LogHub提供
30+種開箱即用的資料采集手段，包括直接和雲産品打通的日志、移動端、服務端、程式、SDK、網頁、嵌入端等，以下我們分别介紹下最常用的四種與試用場景：
| 方式 | 應用場景 | 目前規模 | 優勢 |
|---|---|---|---|
| Logtail | X86伺服器采集 | 百萬-千萬 | 功能強 |
| Android/IOS SDK | 移動端資料采集、手機、POS機等 | 千萬DAU | 斷點續傳 |
| C Producer Library | 硬體資源受限的系統（如 IoT、嵌入式、RTOS等） | 千萬-億級 | 資源消耗低 |
| Web Tracking | 網頁靜态資料采集 | 輕量級，無驗證 |
1.1 Logtail（部署量最大Agent）
Logtail安裝在X86裝置上，通過中央伺服器進行管控，隻需點點滑鼠或API就能夠在幾秒鐘内對百萬機器下達資料采集指令。Logtail目前每天有幾百萬的運作執行個體，适配所有Linux版本、Window、Docker、K8S等環境；支援幾十種資料源對接，關于Logtail功能可以參見
介紹文檔。
得益于阿裡巴巴集團場景的不斷錘煉，Logtail和開源Agent（例如Fluentd、Logstash、Beats）相比，性能、資源消耗、可靠性和多組合隔離等硬名額上較為領先。可以滿足國内最大的直播網站、最大的教育類網站、最大的金融類網站的苛刻要求。和開源Agent主要差距在于日志格式的豐富性（目前Logtail版本已支援Logstash、Beats協定，既可以将這些開源插件無縫跑在Logtail之上）。
2018年Logtail針對Docker/K8S等場景做了非常多的适配工作，包括：
- 一條指令一個參數即可實作部署，資源自動初始化
- 支援CRD方式配置，支援K8S控制台、kubectl、kube api等，與K8S釋出、部署無縫內建
- K8S RBAC鑒權，日志服務STS鑒權管理
可以自豪地說，Logtail方案是K8S下所有Agent中最全，最完整的之一，感興趣可以參見
LC3視角：Kubernetes下日志采集、存儲與處理技術實踐：
1.2 C Producer Library系列（面向嵌入式裝置新秀）
除X86機器外，我們可能會面對各種更底層IoT/嵌入式裝置。針對這種場景，LogHub推出C Producer Library系列SDK，該SDK可以定位是一個“輕量級Logtail”，雖沒有Logtail實時配置管理機制，但具備除此之外70%功能，包括：
- 多租戶概念：可以對多種日志（例如Metric，DebugLog，ErrorLog）進行優先級分級處理，同時配置多個用戶端，每個用戶端可獨立配置采集優先級、目的project/logstore等
- 支援上下文查詢：同一個用戶端産生的日志在同一上下文中，支援檢視某條日志前後相關日志
-
并發發送，斷點續傳：支援緩存上線可設定，超過上限後日志寫入失敗
專門為IoT準備功能：
- 本地調試：支援将日志内容輸出到本地，并支援輪轉、日志數、輪轉大小設定
- 細粒度資源控制：支援針對不同類型資料/日志設定不同的緩存上線、聚合方式
- 日志壓縮緩存：支援将未發送成功的資料壓縮緩存，減少裝置記憶體占用
關于C Producer Library的更多内容參見目錄： https://yq.aliyun.com/articles/304602
目前針對不同的環境（例如網絡伺服器、ARM裝置、以及RTOS等裝置）從大到小我們提供了3種方案：
在X86以及ARM裝置測試場景中，C-Producer系列SDK能在穩定服務情況下，極大優化性能和記憶體空間占用，勝任隻有4KB運作記憶體的火火兔場景（Brick版本）。
使用C Producer系列的客戶有： 百萬日活的天貓精靈、小朋友們最愛的故事機火火兔、 遍布全球的碼牛、釘釘路由器、 相容多平台的視訊播放器、 實時傳輸幀圖像的攝像頭等。
這些智能SDK每天DAU超百萬，遍布在全球各地的裝置上，一天傳輸百TB資料。關于C Producer Library 的細節可以參考這篇文章:
智能裝置日志利器：嵌入式日志用戶端（C Producer）釋出 2. 服務端多地域支援
用戶端問題解決了後，我們來看看服務端。LogHub 是阿裡雲化基礎設施，在
全球阿裡雲所有Region都有部署。確定無論業務在哪個Region開展，都可以選擇就近的Region。
例如歐盟、新加坡等國家有相關的法律限制資料不能出境，對于這類場景我們可以選擇合适的資料中心來提供服務。對于同Region下ECS、Docker等服務，我們可以直接使用同Region服務進行處理，節省跨洋傳輸的成本。
3. 全球加速網絡
對全球化業務而言，使用者可能分布在全球各地（例如遊戲，App、物聯網等場景），但在建構數倉業務的過程中，我們往往需要對資料進行集中化處理。例如一款移動App使用者散布在全國各省市
- 将日志采集中心定在杭州，那對于西南（例如成都）使用者而言，遠端進行日志傳輸的延時和品質難以保障
- 将日志采集中心定在成都，那對位于東部和東北使用者又難以權衡，更不用說中國的三大營運商鍊路品質的影響
2018年6月初LogHub 聯合 CDN 推出了一款全球自動上傳加速方案：“基于阿裡雲CDN硬體資源，全球資料就近接入邊緣節點，通過内部高速通道路由至LogHub，大大降低網絡延遲和抖動 ”。隻需簡單配置即可建構起快速、穩定的全球資料采集網絡，任意LogHub SDK都可以通過Global域名獲得自動加速的支援。
在我們測試case中，經過全球7個區域對比整體延時下降50%，在中東，歐洲、澳洲和新加坡等效果明顯。除了平均延時下降外，整體穩定性也有較大提升（參見最下圖，幾乎沒有任何抖動）。確定如何在世界各地，隻要通路一個統一域名，就能夠高效、便捷将資料采集到期望Region内。
4. 服務端彈性伸縮
在解決網絡接入問題後，我們把問題聚焦在服務端流量這個問題上。熟悉Kafka都知道，通過Partition政策可以将服務端處理資源标準化：例如定義一個标準的單元Partition或Shard（例如每個Shard固定5MB/S寫，10MB/S讀）。當業務高峰期時，可以背景Split Shard以擷取2倍的吞吐量。
這種方法看起來很工程化，但在使用過程中有兩個難以繞開的現實問題：
- 業務無法預測：事先無法準确預估資料量，預設多少個shard才合适呢
- 人的反應滞後：資料量随時會突增，人不一定能夠及時處理，長時間超出服務端負載能力會有資料丢失風險
針對以上情況，LogHub提供了全球首創Shard自動分裂功能：在使用者開啟該功能後，背景系統實時監控每個shard的流量，如果發現一個shard的寫入在一段時間内，有連續出現超過shard處理能力的情況，會觸發shard的自動分裂，時刻保障業務流量。
更多細節可以參考這篇文章: 支援Shard自動分裂
5. 豐富上下遊生态與場景支援
LogHub也提供豐富上下遊與生态對接，包括各種主流流計算、資料倉庫等引擎支援：
- 采集端：Logstash、Beats、Log4J等
- 實時消費端（流計算）：Flink/Blink、Storm、Samza等
- 存儲端（數倉）：Hadoop、Spark、Presto、Hive等
通過LogHub與日志服務其他功能+産品組合，可以輕松支撐安全、營運、運維和研發對于資料處理的各種場景需求，更多可以
參考學習路徑和
使用者手冊 寫在最後
日志服務是阿裡自産自用的産品，在雙十一、雙十二和新春紅包期間承載阿裡雲/螞蟻全站、阿裡電商闆塊、雲上幾千商家資料鍊路，每日處理來自百萬節點幾十PB資料，峰值流量達到每秒百GB， 具備穩定、可靠、低成本，生态豐富等特性。
阿裡雲官網上提供
同款産品，隻要5分鐘便可開通并開啟數字化IT之旅，歡迎試用。