接著上篇文章 我們已經設計好了日誌的結構，接下來我們就準備要開始擼代碼了，我最喜歡這部分的環節了，可是一個上來連就擼代碼的程序肯定不是好程序員，要不先設計設計流程圖？那來吧！！！
- 用戶發起文章操作，發起請求日誌
- 日誌將由SLB服務器進行負載到日誌打點服務器。
- NSA將作為日誌收集中心進行存儲，也可以使用Rsync把節點上的日誌同步到日誌中心。
- 作為核心的ETL程序，將要對日誌中心上所有節點的數據進行抽取轉換加載。
- 上圖中出現的Hbase比較好理解，但是為什麼要出現Mysql？因為我們要更細粒度地控制日誌的寫入時間點，主要用來記錄日誌時間的offset，後續會有詳細的介紹。
- 用戶發起文章操作，發起請求日誌
- 日誌將由SLB服務器進行負載到日誌打點服務器。
- Filebeat 收集節點日誌 到Kafka，主要是用來日誌削峰使用。
- 或者：使用nginx直接將日誌寫入kafka,因為nginx也是生產級別的。
- ETL 將消費Kafka 數據並寫到Hbase。
- 與設計一相同
日誌中心的存儲會是下面這樣
├── log
│ ├── 2019-03-21
│ │ ├── 111.12.32.11
│ │ │ ├── 10_01.log
│ │ │ └── 10_02.log
│ │ ├── 222.22.123.123
│ │ │ ├── 0_01.log
│ │ │ ├── 0_02.log
│ │ │ └── 0_03.log
│ │ └── 33.44.55.11
│ ├── 2019-03-22
│ └── 2019-03-23
- 每分鐘每節點會生成一個文件。
- 一天一個文件夾。
- 這樣子的設計可以方便查錯。
日誌內容如下
{"time":1553269361115,"data":{"type": "read","aid":"10000","uid":"4229d691b07b13341da53f17ab9f2416","tid": "49f68a5c8493ec2c0bf489821c21fc3b","ip": "22.22.22.22"}}
{"time":1553269371115,"data":{"type": "comment","content":"666,支持一下","aid":"10000","uid":"4229d691b07b13341da53f17ab9f2416","tid": "49f68a5c8493ec2c0bf489821c21fc3b","ip": "22.22.22.22"}}
選擇設計一
因為我們就看上了第5點,在線上業務穩定了一年的使用情況來看，這種方案是可行的。
在下篇文章中，我們將真實開始擼我們的黃金代碼了，所有程序將使用scala進行實現，你想問我什麼嗎？四個字：
心明眼亮的你、從此刻開始。
分享到:
閱讀更多 IT實戰聯盟 的文章
