做架构要考虑什么？
一切为了用户体验！
- 前端页面性能足够好，流畅不卡顿；
- 后端数据支撑性能足够好，快速返回响应；
- 完善的项目管理流程，快速迭代更新；
- be simple，没有银弹
前端
业务层面
- 完成需求并且通过测试
- 代码质量高，高质量的组件设计，SOLID 原则；
- BUG 少，性能好，前端兼容性好；
- 减少打包体积，懒加载、预加载策略
- 合理的缓存策略，静态资源 CDN 缓存，OSS 存储
- 完善的文档，Storybook 等
技术选型
多页 VS 单页应用？
服务端渲染 VS 客户端渲染？
UI 组件库？
考虑的点：运行环境兼容性，移动端 还是 PC 端，2B 还是 2C，SEO 需求大不大，可维护性怎么样，团队水平怎么样。
阶段二：基建
业务是无限增长的，但是人不是。
- 版本控制，GitFlow
中间层 & 后端
业务相关
- 鉴权
- 安全性
- RBAC 权限设置
- OAuth 2
负载均衡
高并发场景，防止单点服务器过载导致宕机。
DNS 解析
将同一个域名解析到不同的 IP。
- view 功能，分析地理位置分配节点；
- 节点负载能力，健康度；
- 有点是易配置，不需要专门的负载均衡服务器；缺点是不够灵活。
Nginx 反向代理
一般来说会有一台负载均衡服务器，专门将大量请求分发到其他服务器上。
upstream
- 灵活，配置不同策略，round robin 轮询、加权轮训、源 IP 哈希，URL 哈希、随机法（平均）；
- 插件强大，健康度检测；nginx_upstream_check_module 阿里 tengine 自带
Kubernetes
服务发现和负载均衡
自动部署和回滚 CI CD
自动二进制打包
自我修复
Redis 缓存
我理解的请求的本质，就是争夺数据库写表的操作权利。
在高并发场景下，我们可以利用 Redis 加缓存减轻 db 的压力，提升用户读写的速度。因为缓存是在内存中的，读写会非常快。
MySQL 扛不住，就去找 Redis 嘛，写一个定时脚本，在秒杀还未开始之前，就把当前口罩的库存数量写入 Redis，让 Node 服务的请求从 Redis 这里拿数据进行处理，然后异步的往 kafka 消息队列里面写入抢到口罩用户的订单信息。
当然，Redis 也是要用事务机制来保证原子操作，进而保证数据隔离和一致性。
那如果单台 Redis 扛不住，我们可以对 Redis 进行集群，主从同步这一系列的操作，然后再搞点哨兵，持久化也搞上。
Kafka 消息队列
kafka 消息队列就是基于生产者-消设计模式滴，按具体场景与规则，针对上层请求让生产者往队列的末尾添加数据，让多个消费者从队列里面依次读取数据然后自行处理。
结合到我们的高并发场景就是，对订单进行分组存储管理，然后让多个消费者来进行消费，也就是把订单信息写入 db。
Docker
我们可以用 docker 来复用配置好的开发环境，这样就很轻量并且很方便管理。
数据库
项目管理流程
- 良好的 API 设计？
- API 版本设计、公共接口、权限接口
- 文档管理，storybook
注意点
架构匹配需求，越简单越好
避免过度工程化，避免为了高大上而搞得很复杂
过早优化