1）场景设计
a）尝试模拟解决诸如淘宝、京东等早期架构形式
b）考虑到大部分公司的TPQ高峰一般为促销或者秒杀场景
2）场景问题
a）如何进行容量设计
架构设计三原则：合适原则、简单原则、演化原则，均在告诉我们架构的设计需要贴合场景，并需要保留一定的可成长性。
容量设计的相关内容详见：待完成。
b）初步了解各中间件的并发极限
软件技术经过几十年的发展，新技术层出不穷，但是经过时间考验，已经被各种场景验证过的成熟技术其实更多。例如，高可用的主备方案、集群方案，高性能的负载均衡、多路复用，可扩展的分层、插件化等技术，绝大部分时候我们有了明确的目标后，按图索骥就能够找到可选的解决方案。
只有当这种方式完全无法满足需求的时候，才会考虑进行方案的创新，而事实上方案的创新绝大部分情况下也都是基于已有的成熟技术。
在高并发架构设计中，中间件的并发性能一般需要通过压测来确认，但是在系统设计阶段可以通过官方文档或者经验来评估中间件的可接受并发数。我们可以通过这些数据来安排请求分流，避免服务被并发压垮。
常用中间件的极限并发连接数：待完成。
2.设计思路及方向
1）设计思路
a.分层思想
架构师在设计架构时还要掌握抽象的方法，不能胡子眉毛一把抓，要做好分层和区隔。
因为架构师面对的是一个很庞大的系统，为了避免过早陷入细节，不要去看各个组件的细节，而是把它们的角色定义下来之后，再分块来思考。而在看每个分块时，其他分块都可以视为一个抽象的概念，另外，也需要考虑复用的问题。
b.设计备选方案
架构师需要设计多个备选方案，但方案的数量可以说是无穷无尽的，架构师也不可能穷举所有方案：
i.备选方案的数量以3~5个最最佳
ii.备选方案的差异性要比较明显
iii.备选方案的技术不要局限于已经熟悉的技术
2）设计方向
a.将请求尽量拦截到设计上游
将请求尽量拦截在系统上游（不要让锁冲突落到数据库上去）。传统秒杀系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小。以12306为例，一趟火车其实只有2000张票，200w个人来买，基本没有人能买成功，请求有效率为0。
b.充分利用缓存
充分利用缓存，秒杀买票，这是一个典型的读多写少的应用场景，大部分请求是车次查询，票查询，下单和支付才是写请求。一趟火车其实只有2000张票，200w个人来买，最多2000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9%，非常适合使用缓存来优化。好，后续讲讲怎么个“将请求尽量拦截在系统上游”法，以及怎么个“缓存”法，讲讲细节。
3.多级缓存架构
-
流量发出客户端层
-
浏览器，APP层
-
-
流量接入缓存层
-
HTTPDNS
-
Waf
-
全网CDN
-
硬防火墙
-
完成流量清洗、分发
-
-
应用接入缓存层
-
Nginx静态文件缓存
-
Nginx动态数据缓存
-
Lua-resty-lrucache
-
URL定向缓存请求转发
-
Kafka异步日志分析
-
单点登录系统
-
-
应用缓存层
-
Redis Cluster集群
-
-
Kafka 集群
-
Zookeeper 集群
-
-
JVM EHcache
-
应用业务层
-
SpringCloud
-
Flink
-
Spark
-
-
数据持久层
-
Mysql 集群
-
MyCat
-
