架構實戰

莱布尼茨發表於2024-08-29

所謂架構,意即系統架構,廣義上它涵蓋業務架構、運維架構、組織架構等所有系統構建場景,本文特指一般開發人員主要關注的開發架構

關於架構的理論有很多,每個人也都有各自的理解,筆者相信很多人在實際運用中也會遇到各種各樣的問題和困惑,本文拋開教條,從一個實際專案的演化看何為架構。

專案背景

開始之前,先了解下專案背景。該專案原本是為某東南亞公司開發的相簿,提供圖片使用授權服務,正規專案。無奈當地營商環境魚龍混雜,黑白手段層出不窮,有好幾個其它專案要麼被 DDOS,要麼流量被劫持,要麼莫名出現違規內容,搞得該公司苦不堪言,這回乾脆重金懸賞,遍求挑梁賢能。這不,被筆者一個在國內靈活就業的朋友揭了榜,幾年之後才回國,這中間發生的種種又是另外的故事了。

不管怎麼說,雖然專案看著不大,但除業務本身內容外,伺服器和資料安全也須重點考慮。

基礎版

顯然,使用者瀏覽網站需要一個site,如果採用前後端分離還得有api-server

為了防止惡意使用者上傳違規內容,所有圖片都由管理員上傳至圖床比如AWS-S3(公共讀私有寫模式)

S3 同步版

基礎版雖然在業務端保證了資料安全,但由於兩處伺服器(S3、site/api,即紅色節點)直接對外暴露,駭客能輕而易舉地實現定位進而展開攻擊。S3 是可靠的雲服務,倒也不用太擔心,然而驚弓之鳥的甲方要求管理員不能直接訪問 S3,防止駭客嗅探到管理端。

於是,在管理端和 S3 中間新加一箇中轉節點minio,圖片先上傳到 minio,再同步給 S3,如此,管理端暴露的風險大大降低。

注意此時還沒有解決 site/api 暴露的問題,後面會講。

會員版

馬上新的需求出來了,甲方要求加入收費會員模式,但是不能出現任何關於公司的賬戶資訊(看來甲方真的是怕了,要徹底地隱藏自己)。

要有會員體系,得先有賬號模組,為防止惡意註冊,加上郵箱驗證即可。

收費不能體現公司賬號比較麻煩,常規走銀行流水肯定不行,第三方甚至套殼支付總是會被追蹤到,剩下的選擇只有加密貨幣了,所幸加密貨幣在當地是被廣泛使用的。

加密貨幣交易一般都是非同步的,所以要設計一個定時器,定時從鏈上獲取最新的交易記錄,同步給賬號中心處理。

圖中虛線表示連線的是內部服務。

CMS 版

管理員除管理圖片外,還需對網站本身進行管理,比如廣告投放、佈局調整、會員策略等。於是新增了CMS-Service

當然以後還會需要其它非 CMS 的站點管理功能比如會員管理、系統監控等,統一以admin-site對管理端提供服務。

CQRS 版

現在,把圖片管理一同併入站點管理,並對各服務應用CQRS模式,為以後做讀寫策略/叢集/分散式打下良好基礎。

注意,其中 admin-site 兼具 site-command、album-command 職責。

IM 版

為了提升服務質量,甲方老闆要求加上線上客服,客戶訴求第一時間反饋,同時其它一些訊息(比如客戶下單、圖片合約到期等),管理員也能第一時間收到。

這就不單單是一個即時聊天系統了,還得有訊息推送的功能。

再考慮到當地朝九晚五懶散的工作狀態,想要管理員一直呆在電腦前也不現實,那麼客戶訊息和系統訊息就容易錯過。

還好,這裡有一個人人都離不開的聊天 App ——Telegram,這玩意兒類似國內的微信,但是開放了很多介面和協議,使第三方系統能方便地接入它。比如我們可以使用它的Telegram-Bot,當客戶傳送訊息時,IM 服務除向管理端實時推送外,還會推送給 Telegram-Bot,Telegram-Bot 再將訊息推至 Telegram,如此,沉浸在美女頻道的管理員就能及時知道有待反饋訊息了。

Cloudflare 版

系統的主要功能基本都實現了,但甲方心心念唸的安全問題反倒隨著功能的擴充套件顯得更加嚴峻。如之前所述,直接暴露給使用者的節點風險等級最高,其次為管理員使用節點,進而會影響到整個系統內部。

自己搭建一套安全體系成本太高,實力也不允許,幸好市面上有免費的午餐,比如Cloudflare

Cloudflare 是全球知名的網路服務商,提供保護、最佳化、加速網站等相關服務。本專案中至少可以考慮如下服務:

  • 源站 IP 隱藏
  • Bots - 自動遮蔽惡意爬蟲
  • Turnstile - 人機驗證
  • S3 域名重寫為本站域名(做了 cname 解析)

同時要求管理員在所使用的裝置上安裝VPN,將風險降到最低。

可以看到,圖中的紅黃線塊都沒了,整個系統只要內部不出問題,從外部攻破的可能性不大。

CI/CD 版

還有一個漏洞,甲方意味深長地說。他指的是從本地開發/測試機部署至生產環境這道工序,同樣會出現本地裝置直連線上節點的情況。雖然現在伺服器已經藏得夠深,直接登入被發現的機率不大,但安全起見,甲方還是要求每次都採用跳板機中轉一下。

對於經常發版的任務,跳板中轉屬實也有點麻煩,可以採用CI/CD方案,自動化部署,既輕鬆又安全。

至此,開發架構與運維架構產生了交集,前者也總算可以告一段落了。


總結

架構,既是名詞,亦是動詞,既是實體,亦是變化,它是一種理念,也是一種實施。但它肯定不是一套模板 —— 如果所有的房屋都千篇一律,那也不存在架構師了。

整個專案,甲方對安全的要求簡直到了偏執的程度,很多要求看似無理,聰明的你也許能看出些端倪:)

相關文章