0620 - 關於 Klib 分享,各種糾結之後,我選瞭如下方案

weixin_33918357發表於2017-06-20

關於 Klib 分享,各種糾結之後,我選瞭如下方案

技術方案選型是件很有意思的事,各個環節都有各種選擇,可以組合出各種可能。在這些可能性中,挑選出最佳方案,是我很喜歡做的事

最近剛剛完成 Klib 的標註分享,趁著熱乎勁,小結一下:過程中糾結了哪些方案,以後最後選擇了什麼。

0) 先來看看最終效果

561122-08572448ab24a1d5.gif

這就是 Klib 分享標註的操作流程:點選分享,立即得到可以全球訪問的網頁。操作不能更簡單,背後的技術邏輯卻很複雜:

實際的開發是混在一起的、思路也是交叉的,不過,為了介紹方便,我大致按照資料流來推演。

561122-c369316b81072326.jpg

1) Klib 與介面伺服器

這部分的功能比較直接:Klib 將標註內容傳送給介面伺服器,伺服器處理完後返回結果。

需要介紹的,倒是功能之外的東西:

  • 如何防止介面被攻擊
  • 如何做身份識別

這部分內容其實是很複雜的,我最終採用了和 Klib 安全性相稱的方案。

1.0) 防止介面被攻擊

1.0.0) 介面伺服器使用 https

這是最基礎、但非常有效的方式,全程使用 https 加密,已經可以大大提高安全性。

1.0.1) 防止介面被非法使用

如果介面是公開的、所有人都可以任意訪問,就可以隨意地向伺服器丟垃圾資料,迅速將伺服器擠爆。

比如好的做法是 使用非對稱加密,即使用一對私鑰、公鑰,使用 私鑰加密 的資料,只能使用 公鑰解密;反之,使用 公鑰加密 的資料,只能使用 私鑰解密。整體流程大致如下:

561122-d0f32c6e1e0cb95c.jpg
  • 介面伺服器開放 公鑰 A
  • 每個 Klib 客戶端生成新的 私鑰 B公鑰 B
  • Klib 客戶端使用 公鑰 A 加密 公鑰 B,並將其傳送給介面伺服器
  • 介面伺服器使用 私鑰 A 解密後,儲存該客戶端對應的 公鑰 B
  • 之後,Klib 客戶端傳送資料時,使用 私鑰 B 加密,介面伺服器收到後使用 公鑰 B 解密,並用 公鑰 B 加密後返回資料

聽起來有點像繞口令?

開發上也有點麻煩,畢竟伺服器還要儲存每個 Klib 客戶端對應的公鑰。如果有多個伺服器,則需要在不同伺服器間同步公鑰,更加麻煩。對於我這個小產品 + 實驗功能來說,暫時不需要這麼高的安全級別。

於是,我採用了更簡單、但夠用的 AES 對稱加密。即 Klib 客戶端和介面伺服器使用相同的 AES 加密方法、同一個密碼,加密請求和響應的資料;如果不能提供正確的加密,就無法使用伺服器介面。

這一方案主要的風險是:黑客可以反編譯 Klib 得到密碼。除了 Klib 本身會編譯並簽名,我還在程式碼里加密儲存密碼。基本上除了跟我有八輩子解不開的愁,99.9999% 的人是不會花精力來破解這個密碼的。

1.0.2) 使用時間戳 + MD5

即使加密過的資料,最終也只是表現為一個 http 請求,而這個請求是可能被本地攔截,進而用於模擬正常使用者請求。

對應的防護是,在 http 請求中加入時間戳,並對 http 頭的內容部分計算 MD5(或 CRC 等),伺服器端進行驗證,就可保證 http 頭不被濫用。

其實,這是 OAuth 的範疇。好在,我在開發 圖床神器 iPic 時,先後從客戶端的角度實現了七牛、又拍、阿里雲、Imgur、Flickr、Amazon S3 的 OAuth,這次實現一個簡單的伺服器端部分,也不算麻煩。

1.1) 如何做身份識別

上面說的是在面對黑客時的防護,聽著有點暈是吧?下面來說說正常情況下的身份識別。

比如:如果使用者嘗試停止一個分享,如何判斷該使用者是否有許可權?

如果有賬戶系統,這點比較容易解決。而 Klib 尚未引用賬戶系統,怎麼辦呢?比較高階的是使用區塊鏈(咳咳),我目前的做法是:使用者使用 Klib 分享一本書的標註時,伺服器會返回一個隨機數。下次使用者在停止分享時,只要能提供這個隨機數,即判定為有效請求。在上述各種防護的前提下,可以有效地防止被惡意停止分享。

2) 介面伺服器

介面伺服器是整個系統中最複雜的部分,它的職責比較多:

  • 驗證請求,並接收資料
  • 儲存資料
  • 根據資料生成靜態網頁
  • 將靜態網頁輸送給靜態伺服器
  • 更新、刪除分享時,更新資料儲存和靜態伺服器

驗證請求和前面的介紹是對應的,這裡略過不表。

2.0) 使用 Python + Flask 實現功能部分

所謂介面伺服器,首先就是要開放介面(開門接客)具體的,就是 http 請求的路由表。比如,當 Klib 客戶端向 https://api.klib.me/share 傳送資料時,要有相應的程式碼來接收處理這個請求。

在之前的文章 我入門 Python 後總結的基礎教程 中,我已經介紹了使用 Flask 框架,這裡不再重複。

2.1) 使用 Nginx + Gunicorn 搭建伺服器

同上,請參考 我入門 Python 後總結的基礎教程

另外,使用 Supervisorctl 保證服務可靠執行。

2.2) 使用 MySQL + SQLAlchemy 儲存資料

從資料儲存的角度看,書的標註都是很規整的,無非是書名、作者、筆記內容等等。於是我選擇了最常用的關係型資料庫:MySQL

如果直接使用 SQL 語句運算元據庫,既繁瑣又不安全,這裡我使用可稱為 ORM (Object Relational Mapping) 界事實標準的 SQLAlchemy 構建 Model、運算元據庫。

我本來想說「這沒什麼好介紹的」,但實際上,MySQL 的坑很多。比如,如果要支援 Emoji 表情,就要全程使用 utf8mb4 編碼。還有很多其他的坑,此處略去一萬字…

2.3) 使用 Jinja 模板生成靜態網頁

關於標註部分,Klib 傳送的是 Markdown 格式,如:

# 簡單思考

## 卷首語

- 商業的本質就是“持續提供使用者真正想要的東西”,除此無他。

- 召集具備回應使用者需求的熱情與能力的員工,併為他們營造出無拘無束可最大限度地發揮其才能的環境,除此無他。

## 第一章 經商不是“打仗”

- 重要的是不斷磨鍊對“大眾真實需求”的感知能力和使之實體化的技術。

- 音樂和體育不同,不用與任何人戰鬥。

需要使用 markdown 模式將其轉換成 html 格式,如:

<h1>簡單思考</h1>
<h2>卷首語</h2>
<ul>
   <li>
      <p>商業的本質就是“持續提供使用者真正想要的東西”,除此無他。</p>
   </li>
   <li>
      <p>召集具備回應使用者需求的熱情與能力的員工,併為他們營造出無拘無束可最大限度地發揮其才能的環境,除此無他。</p>
   </li>
</ul>
<h2>第一章 經商不是“打仗”</h2>
<ul>
   <li>
      <p>重要的是不斷磨鍊對“大眾真實需求”的感知能力和使之實體化的技術。</p>
   </li>
   <li>
      <p>音樂和體育不同,不用與任何人戰鬥。</p>
   </li>
</ul>

這裡讚歎一下:Python 輪子就是多。只需輕輕地匯入 markdown 模組,即可優雅地將 Markdown 轉換為 html 格式,舒爽。

import markdown
html_str = markdown.markdown(markdown_str)

對於最終生成的靜態網站,像 css/js 等部分都是一樣的,只是頁面標題、正文等內容性的東西不同。於是,使用 Jiaja 模式表示這些通用部分,並 {{ title }} 這樣的標註符表示各個分享所不同的內容部分;再用 render_template 方法替換模板中的內容,即可生成對應的靜態檔案。

感嘆:這樣簡潔直接的操作、無需各種複雜的配置,就能得到最後想要的東西,真真是程式設計中最可愛的環節

3) 靜態伺服器與 CDN

有了靜態伺服器,就像是有了寶貝,不能只是自己藏著,得拿出來讓大家瞧瞧,這就是靜態 (Web) 伺服器要乾的事。

當然,靜態伺服器和介面伺服器,在物理上可以是同一臺伺服器,這裡只是從角色上進行區分。

在展示靜態網頁方面,技術選型上主要有 2 方面的需求:

  • 網頁內容能實時更新
  • 使用者訪問速度快

其中,內容的更新對應使用者分享時的 3 種操作:

  • 建立分享
    • 對應建立靜態 html 檔案
  • 更新分享的內容
    • 對應更新 html 檔案內容
  • 停止分享
    • 對應刪除 html 檔案

好,帶著「實時」建立、更新、刪除 html 檔案這 3 個需求,我們來看看如何提高訪問速度

3.0) ? 僅使用單一伺服器

首先,如何什麼都不做,意味全球的使用者(Klib 必須是國際性產品,得考慮全球使用者,嗯)都要連線這臺伺服器。

且不說併發數等限制,單從網速上看,如果將伺服器放在國內,國外使用者勢必慢;反之亦然。更何況國內還是電信、網通、以及神奇的長寬,國外也有 N 多國家。

如果確實要這麼做,比較好的方案是使用 阿里雲香港伺服器,可以兼顧國內國外使用者。暫時,不採用這一方案,每月省下 $19…

3.1) ? CDN

進而,通常的做法是使用 CDN.

CDN 確實可以有效提高不同地區、不同網路環境下的訪問速度,且極大地降低對靜態伺服器的壓力。不過,CDN 有個致命的侷限:內容更新慢。尤其在更新、刪除內容時,這種慢會帶來業務上的問題

比如,使用者在 Klib 中分享標註後又停止,卻發現之前產生的網頁依然可以訪問,使用者會覺得這是 Bug,進而會帶來很大的客服壓力。於是,跳過這一方案。

3.2) ? 國內、國外多臺伺服器

下一方案是:國內、國外各一臺(或多臺)伺服器,通過 DNS 伺服器進行分流,相當於自建 CDN。

不料,卻遇到一個坑:國內伺服器的外網速度普遍較慢。比如我試了阿里雲上海節點,從國外伺服器使用 scp 或 rsync 傳輸一個 10 KB 的檔案需要 4s,跌破了我的眼鏡。並且,阿里雲我也只買了 1 MB 頻寬的小水管,併發時速度會很慢。於是,這一方案也被放棄。

3.3) ? 最終方案

最終採用的方案時:國內使用阿里雲 OSS、國外使用 Amazon S3(注:因為測速顯示,我的國外伺服器在全球的訪問速度尚可,暫未實施,不過原理是一樣的)

  • 速度 方面,測試軟體顯示,阿里雲 OSS,在國內的訪問速度是不錯的。
  • 可靠性 方面,阿里雲 OSS 本身肯定值得依賴的(至少比我自己搭靜態伺服器靠譜的多)
    • 另外,阿里雲 OSS 可以從我的國外靜態伺服器回源,意味著使用者通過阿里雲 OSS 訪問網站時,肯定可以得到內容,這已經滿足了 90% 的場景
  • 實時更新 方面,伺服器端使用 pyinotify 監控 html 檔案所在目錄,一旦發現有檔案更新、刪除,立即同步至阿里雲 OSS 上。同步速度也不錯(比阿里雲 ECS 強太多),使用者的響應幾乎是實時的

比如,你訪問這篇分享試試速度如何:
http://s.klib.me/share.html

以及 全國測速結果,開啟時間基本在 1s 內,滿意。

561122-a91e85b57be4dad5.jpg

注:我另外也考慮了七牛雲,不過 七牛不支援為儲存空間繫結域名、而只支援 CDN 的方式繫結域名,而 CDN 的方案已經被放棄,所以只能放棄七牛(以及七牛的免費 http 流量…)

3.4) 搜尋引擎優化

這是個全方面的話題,這裡只提幾點:

  • 搜尋引擎直接訪問靜態伺服器,因為 CDN 等因素對搜尋引擎是種干擾。這一點,可以通過 DNS 伺服器來解決。
561122-b796e3dda59776ea.jpg
  • 向搜尋引擎提供 sitemap 檔案,包含靜態網頁的網址列表。雖然搜尋引擎不一定真的使用這個檔案,但必要的基本功還是要做的,萬一被用了呢?

4) 網頁的適配

好,經過千辛萬苦,使用者終於可以開啟網址、看到分享內容了,是不是大功告成了?

錯,還有很大一個坑:網頁佈局及適配

比如:

  • 作為文字類的網頁,字型、字號、配色、行間距、留白得看得過去吧?
  • 使用者可能在 24 寸顯示器、iPad、手機等不同裝置上開啟網頁,總得能正確顯示吧?
  • 總得方便使用者分享到不同 SNS 吧?
  • 使用者分享到微信、朋友圈,總得顯示個縮圖吧?
  • 使用者分享到 Facebook、Twitter,總得以卡片形式顯示、摘要總要有吧?

這方面我不是專家,Klib 的分享也只是做個入門。

在 Klib 中閱讀效果類似:

561122-f9eb6f69fd1f3cb4.jpg

PC 端最終效果類似:

561122-902ab6d58c0c9cb0.jpg

手機端類似:

561122-8bb85a8092a6e751.jpg

5) 其他

表一漏萬,除了看得見的、說得出的,還有很多看不見的東西,挑幾個來說。

5.0) 區分開發、測試、線上環境

如何在同一程式碼倉庫下,區分開發、測試、線上環境?

我目前的做法是,建立排除在 Git 外的 .env 檔案,其中儲存了開發、測試、線上環境所對應的配置。程式啟動時,先讀取配置檔案,然後根據配置檔案啟動對應的引數,如資料庫地址、服務埠、日誌級別及檔案位置等等。

5.1) 服務監控

從上面的介紹可以看到,整體的框架涉及多個模式,並且互為備份的環節並不多,有一個模組出問題,就可以導致整個流程出問題。最好有個機器人一直盯著,一旦出問題,立即通知我(總比使用者跑過來報 Bug 強)

如何能有效監控呢?幾個供參考:

  • 介面伺服器方面,一旦發現嚴重錯誤,立即發告警郵件(目前還沒做)
  • 在介面伺服器建立測試指令碼,包含建立、更新、刪除分享功能,並定期工作。一旦出問題,立即發告警郵件
  • 使用 360 監控等服務,監控某分享連結是否可訪問
  • 以及,一些基礎的伺服器監控工具

5.2) 一定要有日誌

日誌可以說是線上服務的生命線,一旦出問題,第一件要做的事:查日誌。那首先得有日誌呀?恩,程式碼裡要輸出。

另外,日誌檔案要 定期切割,避免過大。

5.3) 一定要有備份

萬一伺服器被黑了、被人 rm / -rf 了,萬一資料庫被刪了…作為獨立開發者,我總不能申請破產保護吧?

備份一定要有(雖然最好不要用),比如:

  • 伺服器級別的定期製作映象,一般雲伺服器都有此功能
  • 製作指令碼,定期將資料庫、日誌等關鍵資料,備份至 Dropbox、Amazon S3 等可靠的網路儲存中,當然要加密儲存
  • 使用 GitHub/GitLab 等私有 Git 倉庫備份程式碼。什麼都沒了,只要有程式碼,就能東山再起

6) 事務諸葛亮

以上就是 Klib 分享大體的技術選型、以及期間的糾結。雖然已經能幹活,現在回過頭來看,主要的問題是:

涉及模組多,維護成本高

想象一下這個場景:

  • 在吃年夜飯時,收到不能建立分享的報警郵件
  • 一邊後悔沒有給伺服器上香,一邊放下筷子、開啟 MBP
  • 查了半天,發現是 MySQL 的問題
  • 又查了半天,發現竟然是因為 VPS 硬碟空間不夠了
  • 於是,新增新資料盤,小心翼翼地遷移資料,膽戰心驚地重啟資料庫
  • 手動測試,持續觀測日誌一段時間,好在沒有問題
  • 剛巧,新年的鐘聲敲響,完美…

相比之下,如果使用 AWS 這種能託管 MySQL 的服務,上述問題都不會發生,還不會錯過微信紅包裡的幾個億。

再比如,使用 Heroku 之類的服務,就可以免去大部分需要自建伺服器部分。沒選 Heroku 主要的原因是:國內訪問速度太慢。不過現在想想,可以通過國內、或香港伺服器回撥的方式加速。於是,Heroku 又成為很有優勢的選擇。

聽完之後,你會怎麼選?


我所說的,都是錯的。

那麼,我的公眾號「自在開發」,你還關注嗎?每週二早 8 點,技術長文、準時推送。

561122-d0b14cf41694d9cb.jpg
自在開發

相關文章