技術方案選型是件很有意思的事，各個環節都有各種選擇，可以組合出各種可能。在這些可能性中，挑選出最佳方案，是我很喜歡做的事。
最近剛剛完成 Klib 的標註分享，趁著熱乎勁，小結一下：過程中糾結了哪些方案，以後最後選擇了什麼。
0) 先來看看最終效果
這就是 Klib 分享標註的操作流程：點選分享，立即得到可以全球訪問的網頁。操作不能更簡單，背後的技術邏輯卻很複雜：
實際的開發是混在一起的、思路也是交叉的，不過，為了介紹方便，我大致按照資料流來推演。
1) Klib 與介面伺服器
這部分的功能比較直接：Klib 將標註內容傳送給介面伺服器，伺服器處理完後返回結果。
需要介紹的，倒是功能之外的東西：
- 如何防止介面被攻擊
- 如何做身份識別
這部分內容其實是很複雜的，我最終採用了和 Klib 安全性相稱的方案。
1.0) 防止介面被攻擊
1.0.0) 介面伺服器使用 https
這是最基礎、但非常有效的方式，全程使用 https 加密，已經可以大大提高安全性。
1.0.1) 防止介面被非法使用
如果介面是公開的、所有人都可以任意訪問，就可以隨意地向伺服器丟垃圾資料，迅速將伺服器擠爆。
比如好的做法是 使用非對稱加密，即使用一對私鑰、公鑰，使用 私鑰加密 的資料，只能使用 公鑰解密；反之，使用 公鑰加密 的資料，只能使用 私鑰解密。整體流程大致如下：
- 介面伺服器開放
公鑰 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 客戶端向 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) ? 最終方案
…
如何實現 全國秒開、及更多詳盡分析，盡在「自在開發」公眾號：