[麻雀雖小，五臟俱全] 之網站重寫之路

入職三年， 除了參與公司核心產品研發外，另外負責了一個2C的小項目： 調用API拿到解析結果 & 計費。

項目最初是.NetCore 1.0-Preview+sqlite部署在IIS上，閒來沒事，這個項目已經被我徹底重寫，在此記錄一些自認爲還比較切合項目實際且平衡成本的開發實踐。

用例圖以下：

改造歷程

改造是個持續迭代的過程，期間深入思考並應用了ASP.NET Core框架、TPL Dataflow、 Redis支撐消息隊列、容器化、CI相關的知識點；
與此同時，爲了適應更現代化的部署方式，項目歷經單體程序--->容器化--->Docker-Compose部署--->DockerSwarm部署;

當前部署圖以下：

業務重寫

業務1

核心業務: C端請求--->發起百度雲API調用---->記錄解析結果，併發布到Redis訂閱， 我使用了Actor模型來達成目的。
數據流圖：

1. TPL Dataflow 流水線組件應對高併發，低延遲場景 至關巴適
2. HttpClientFactory的套路，你知多少？

業務2：

利用redis hash存儲白名單租戶的配額、記錄配額消費，每次消費使用redis HINCRBY myhash field -1命令；
間隔30s將消費次數同步到sqlite.

1. [同步租戶白名單] ASP.NET Core+Quartz.Net實現web定時任務
2. [C# Redis客戶端] DotNetCore三大Redis客戶端對比和使用心得
3. [數據持久化] EFCore批量操做，你真的清楚嗎？

業務3： 認證和安全

解析結果以ASP.NET Core靜態文件服務器的形式提供給Etl訪問， 這裏給這個靜態文件服務器訪問地址加上了基礎身份驗證；
項目後期添加了HTTPS證書、HTHS安全策略

1. ASP.NET Core 實現基本認證
2. 白話文解讀HTTPS原理， 結合.NET Core聊一聊HTTPS應用方式
3. HTTP Strict Transport Security (HSTS) in ASP.NET Core

技術改造

分佈式

在早期以單體程序部署的瞬間（服務不可用）會有少許流量沒法處理；更糟糕的狀況下，迭代部署的這個版本有問題，上線後沒法運做， 更多的流量沒有獲得處理。
引入Redis List數據結構實現了一個簡易版本的消息隊列，解耦數據接收和 數據處理。

1. ASP.Net Core結合Redis實踐消息隊列，今後放心安全迭代
2. Quartz.NET對集羣的支持

面向Linux的部署

底層的技術棧是ASP.NET Core，推進項目從windows平臺遷移到Linux平臺部署

1. ASP.NTE Core跨平臺技術內幕
2.Linux上最小化部署ASP.NET Core程序

容器化部署

雲原生時代，容器技術大行其道，欲罷不能。

1. docker-compose是個好東西，越用越香
2. ASP.NET Core暴露端點對接Docker健康檢查
3. 基於Docker-compose的Gitlab CI/CD實踐
4. 深度解讀Docker Swarm

總結

重寫是個演進的過程，引入了不少先進的輪子，也付諸了一些思考實踐。
在寫公衆號的過程當中，偶爾會發現以前寫的文章有勘誤，因此這對認知而言，也是一個持續演進的過程(請持續關注博客園原文)。

我始終認爲 不管多小的程序，都有值得進化的切入點。

這駕馬車隨着個人改造，已經最大化壓縮公司成本，SLA愈來愈高，我也不知道這架馬車何時會被公司戰略放棄，可是隻要還在，定會進化不止。