入职三年, 除了参与公司核心产品研发外,另外负责了一个2C的小项目:调用API拿到解析结果 & 计费。
❝项目最初是.NetCore 1.0-Preview+sqlite部署在IIS上,闲来没事,这个项目已经被我完全重写,在此记录一些自认为还比较
❞切合项目实际且平衡成本
的开发实践。
用例图如下:
改造历程
改造是个持续迭代
的过程,期间深刻思考并应用了ASP.NET Core框架、TPL Dataflow、 Redis支撑消息队列、容器化、CI相关的知识点;
与此同时,为了适应更现代化的部署方式,项目历经单体程序-->容器化-->DockerCompose部署-->DockerSwarm部署。
当前部署图如下:
业务重写
业务1
核心业务: C端请求--->请求百度云API---->记录解析结果,并发布到Redis订阅, 我使用Actor模型
来达成目的。
数据流图:
TPL Dataflow 流水线组件应对高并发,低延迟场景 相当巴适
HttpClientFactory的套路,你知多少?
业务2:
利用redis hash
存储白名单租户的配额、记录配额消费,每次消费使用redis HINCRBY myhash field -1
命令;
间隔30s将消费次数同步到sqlite.
[同步租户白名单] ASP.NET Core+Quartz.Net实现web定时任务
[C# Redis客户端] DotNetCore三大Redis客户端对比和使用心得
[数据持久化] EFCore批量操作,你真的清楚吗?
业务3:认证和安全
解析结果以ASP.NET Core静态文件服务器的形式提供给Etl访问, 这里给这个静态文件服务器访问地址加上了基础身份验证;
项目后期添加了HTTPS证书、HTHS安全策略
ASP.NET Core 实现基本认证
白话文解读HTTPS原理, 结合.NET Core聊一聊HTTPS应用方式
HTTP Strict Transport Security (HSTS) in ASP.NET Core
技术改造
分布式
在早期以单体程序部署的瞬间(服务不可用)会有少量流量无法处理;更糟糕的情况下,迭代部署的这个版本有问题,上线后无法运作, 更多的流量没有得到处理。
引入Redis List
数据结构实现了一个简易版的消息队列,解耦数据接收和 数据处理。
ASP.Net Core结合Redis实践消息队列,从此放心安全迭代
Quartz.NET对集群的支持
面向Linux的部署
底层的技术栈是ASP.NET Core,推动项目从windows平台迁移到Linux平台部署
1. ASP.NTE Core跨平台技术内幕
2. ASP.NET Core在Centos上的最小化部署实践
容器化部署
Docker-compose是个好东西,越用越香
谁说docker-compose不能水平扩展容器、服务多实例?
ASP.NET Core暴露端点对接Docker健康检查
Gitlab CI/CD的实践
深度解读Docker Swarm
总结
重写是个演进
的过程,引入了很多先进的轮子,也付诸了一些思考实践。
在写公号的过程中,偶尔会发现之前写的文章有勘误,所以这对「认知」而言,也是一个持续演进的过程。
这驾马车随着我的改造,已经最大化压缩公司成本,SLA越来越高,我也不知道这架马车什么时候会被公司战略放弃,但是只要还在,定会进化不止。
关注我们
更多干货及潮流技术
请关注Dotnet Plus公众号
▲
▲
“阅读全文,体验更佳”