[麻雀虽小，五脏俱全] 之网站重写之路

入职三年， 除了参与公司核心产品研发外，另外负责了一个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越来越高，我也不知道这架马车什么时候会被公司战略放弃，但是只要还在，定会进化不止。