技术选型
初期
-
技术选型，先看业务需求，任何脱离需求的技术选型，就是耍流氓
-
早期架构：ALL in one
-
早期选型依据：熟悉的，擅长的
-
建议选型：PHP体系，Java体系
-
早期主要矛盾：业务开发效率与质量低，CURD出错
-
早期重要组件：DAO/ORM
要不要自研
-
早期不建议自研
-
随着规模的扩大，要控制技术栈
-
建议浅浅的封装一层
-
随着业务规模，研发团队进一步扩大，适当造一些轮子
容量设计
-
评估总访问量：询问产品、运营
-
评估平均访问量：总量除以总时间，一天算4w秒
-
评估高峰QPS：根据业务曲线图来（或者八二原则：80%的请求在20%的时间爆发）
-
评估系统、单机极限QPS：压测很重要
-
根据线上冗余度做决策：计算需求与线上冗余度差值
伪分布式
-
随着流量的提升，系统最先遇到的两大问题是
-
慢，性能下降
-
—挂全挂，耦合
-
-
如何快速提升性能：伪分布式，三大分离（读写，动静，前台后台）
-
如何快速解耦：垂直拆分（业务，代码，数据库，研发团队）
-
垂直拆分，在架构演进的各个阶段，会持续进行
-
早期解决问题的思路：增加硬件资源（时间短），避免大规模代码重构（时间长）
-
早期最大的成本，是时间成本，能用“钱”解决的系统问题，往往不是问题
接入层架构
反向代理，负载均衡
-
单体架构，如何“真集群”，解决扩展与高可用的问题？反向代理
-
代理，代表用户
-
反向代理，代表web集群
-
-
最常见的反向代理是nginx
-
引入反向代理，要解决：负载均衡+反向代理高可用，两个问题
-
负载均衡，利用nginx的随机，轮询，静态权重，一致性hash解决
-
反向代理高可用，用VIP+keepalived解决
DNS轮询
-
单体架构，要解决性能扩展问题
-
早期，使用DNS轮询架构
-
现在，可以使用nginx反向代理架构
-
-
反向代理，不高可用，需要进一步升级为高可用反向代理架构
-
高可用反向代理，扩充性能，可以使用多级（LVS&F5）反向代理架构
-
多级反向代理架构，扩充到无限性能，使用DNS轮询架构
-
DNS轮询，解决性能扩展问题；VIP+keepalived，解决高可用问题
session一致性
-
session同步法：多台web-server相互同步数据
-
客户端存储法：一个用户只存储自己的数据
-
反向代理hash一致性：四层（使用ip地址）hash和七层（使用http协议中的某些属性）hash都可以做，保证一个用户的请求落在一台web-server上
- 推荐使用四层hash，让nginx做路由转发，尽量不要引入业务层的业务属性
-
后端统一存储法（数据库或缓存）：web-server重启和扩容，session也不会丢失
CDN就近访问
-
CDN的核心是就近访问，降低网络拥塞，提高用户访问速度
-
CDN适合静态资源（js，css，jpg，flash，静态html等）加速
-
CDN由智能DNS（核心），源，镜像构成
-
常更新的静态资源，建议加上版本号，防止数据不一致
-
资源更新，使用镜像拉取
TCP负载均衡
-
web-server如何实施负载均衡？http短连接，可以利用反向代理
-
tcp-server如何快速实施？单体架构，但无法保证高可用
-
tcp-server如何快速实施负载均衡+高可用？客户端内置集群，但无法保证扩展性
-
tcp-server如何保证负载均衡+扩展性？服务端提供get-tcp-ip接口
-
提供get-tcp-ip接口后，如何保证高可用？服务状态上报，但会出现耦合
-
提供get-tcp-ip接口后，保证负载均衡+高可用+可扩展+解耦？服务状态拉取
架构性能优化
- 早期，对架构影响最小，最快提升性能的优化方法：三大分离
动静分离
-
动静分离，是指“静态页面与动态页面，分开不同的系统访问”的架构设计方法
-
“页面静态化”是一种将原本需要动态生成的站点提前生成静态站点的优化技术
-
总数据量不大，生成静态页面数量不多的业务，非常适合于“页面静态化”优化
读写分离
-
读写分离，用数据库分组，快速提升数据库读性能
-
水平切分，用数据库分片，提升数据库存储容量（往往涉及系统改造）
前台与后台分离
- 前台后台分离，系统解耦，消除底层资源瓶颈