1、架构是系统的顶层设计；框架是面向编程或配置的半成品；组件是从技术维度上的复用；模块是业务维度上的职责划分；系统是相互协调运行的实体。
2、背景：
（1）编程语言进步：机器语言（01二进制难写、难读、难改）；汇编语言（用符号代替指令或操作数地址）。
3、架构设计目的：是为解决软件复杂度带来的问题。（复杂度包括系统要求高可用、易扩展、高性能等）
4、高性能：（1）进程，线程的由来？以及如何提高性能的？
（2）任务分配、任务分解提高性能。
5、高可用：本质上用“冗余”手段实现。了解分布式算法：paxos
6、可扩展性：需要做到两点：
（1）正确预测变化
（2）完美封装变化
7、架构要求：
（1）低成本，不是架构的首要目的，而是附加约束（2）安全，很重要，网站越大越重要（3）规模，系统功能多导致复杂度大；数据多倒置系统复杂度变大。
8、架构设计的三个原则：
（1）合适原则：适合优于业界领先（2）演化原则：演化优于一步到位，因为不能预测未来。（3）简单原则：简单优于复杂
9、淘宝架构演化过程
10、学会分析项目，确定项目中的复杂度，需求驱动技术，技术辅助业务。
11、学会设计备选方案，注意备选方案之间要差异明显，此时关注技术选型，备选个数3~5个就行。
12、评估和选择备选方案：360度环评，还要考虑性能、业务需求、运维团队的经验、技术体系等等。
13、详细方案设计：进一步细化架构设计，此过程中可能会发现备选架构的错误，如果有还会重新评审。
14、读写分离：本质是将访问压力分散到集群中的多个节点上，但是没有分散存储压力，因为每台从机保存和主机一样的数据。此时主机负责写，从机负责读数据，此时会引入新问题：复制延迟，也就是说写入数据后立刻查询，可能从机还未同步过来数据。
15、分库分表：
分库：按照业务模块将数据分散到不同的数据服务器。
分表：水平和垂直分表，水平相比垂直更加引入复杂性。
水平分表：就是表的行数比较大时，一般mysql单表500万就要考虑了。引入join操作问题，事务问题、count()、order by等。
垂直分表：适合将某些不常用的字段列拆分出去。例如描述列。
16、NoSQL：Not Only SQL。解决传统关系型数据库不能解决的一些问题，通常nosql分为4种：K-V存储（redis），文档数库(MongoDB)，列式数据库（HBase），全文检索引擎(Elasticsearch)。
17、高性能缓存架构：缓存命中返回缓存中的数据，通过分布式锁控制去后台是请求数量。还要解决引入缓存之后引入的问题：缓存穿透、缓存击穿、缓存雪崩。当请求数很大时，需要多份缓存，例如有1000万请求，那就设置10份缓存到不同电脑上，每次随机分配其中一台电脑为之服务，注意过期时间不要设置一样，否则会出现缓存雪崩现象。
18、熟悉PPC（进程级别）与TPC（线程级别）模式，以及连接数和请求数。知道系统该选什么模式。
19、
20、高性能负载均衡组合原则：DNS负载均衡用于实现地理级别的负载均衡；硬件负载均衡用于实现集群级别的负载均衡；软件负载均衡用于实现机器级别的负载均衡。
21、高性能负载均衡算法
任务平分类：平分请求到后台服务器，缺点不能根据服务器状态实时改变分发请求方式。轮询，加权轮询。
负载均衡类：根据后台服务器的负载情况动态分发请求，能够感应后台服务器状态，相对实现复杂。根据具体业务判断负载情况，可以是IO,连接数等。
性能最优类：谁响应速度最快，优先给谁分派任务。
hash类：根据源地址Hash，目标地址Hash，session id等。好处，同一用户的不同请求可以由后台同一服务器处理。
微信抢红包的高并发架构，应该采取什么样的负载均衡算法？谈谈你的分析和理解。
22、CAP理论
Consistency：一致性 Avaliability:可用性 Partition:分区容错
分区容错不可避免，三者只能实现其中两者，因此CP（保一致性，牺牲可用性）和AP（保可用性牺牲一致性）。
Zookeeper保CP的，Eureka保AP的。
23、CAP理论细节
（1）CAP是关注数据的，而不是系统，也就是说一个系统中可以设计CP和AP并存，具体看业务。
（2）CAP是忽略网络延迟
（3）Base理论：第一：CAP理论是忽略延时的，而实际应用中延时是无法避免的。第二：AP方案中牺牲一致性只是指分区期间，而不是永远放弃一致性。
24、FMEA方法，排除架构可用性隐患的利器
25、双机架构
（1）主备：备机只备份主机数据，不提供服务，等到主机挂了，需要人工参与切换；因此主备适合实时性较低的管理系统，学生管理系统，图书管理系统。
（2）主从：主机可以读写，从机分担读。
以上两种都有个问题，主机故障后，需要人工参与切换，而不能自己切换。因此产生，中介者模式，用于完成自动切换，但是一定保证其高可用，避免单点故障。
（3）主主：双击互相备份，都能对外提供服务。看似简单，事实上复杂，适用于可覆盖，能重生成的数据，例如session;不适用于余额，库存等。
26、高可用存储架构：集群和分区
高可用存储架构，本质就是适当的冗余数据。集群分为集中式（支持业务量小，要求一台电脑能存下所有数据）和分散式（每台存一部分数据，适合存大量数据）。
分区：体现在异地容灾备份，有独立备份机房，有机房互备等，当一处故障，需要借助备份恢复数据。
27、如何设计高可用架构？
主备（冷备，温备）适合一些实时性要求不高的管理系统。 出故障人工处理
主从（从机也会分担任务，但是任务分类分配相对复杂）。出故障人工处理
集群（对称集群或者叫负载均衡集群，非对称集群）
负载均衡集群设计：后台服务器相同
（1）采用合适的任务分配策略（2）当服务挂掉，不在给该服务器分发任务（3）服务器重新上线后，继续给分发任务
非对称集群设计：后台服务器不同
（1）区分后台不同的服务器的不同角色（2）任务分配需要分给不同的服务器（3）当指定类型的服务器挂了，需要重新分配角色。
27-1、高效学习：以学习redis为例，（1）安装（2）运行（3）思考原理，优缺点分析（4）测试（5）分析源码
28、异地多活：就是异地部署高可用架构，主要面对的是网络延迟问题。
29、异地多活总结一句话：采用各种手段，要求保证核心数据和核心业务异地多活。
30、
31、如何应对接口级别故障？
降级，限流，熔断，排队
32、可扩展思想：基本原则就是拆分；按照流程拆分（controller>service>dao），面向服务拆分(微服务)，面向功能拆分。
33、分层架构与SOA架构
分层架构之所以能够较好地支撑系统扩展，因为隔离关注点，每层只处理本层的逻辑。
SOA是解决企业内部的IT系统重复建设且效率低的问题。有3个关键的概念：服务，ESB（企业服务总线）,松耦合。
34、SOA与微服务的区别
微服务的坑：（1）服务拆分粒度太小，导致系统间调用复杂（2）服务太多，团队效率下降（3）调用链太长，性能下降（4）调用链长，出问题难以定位（5）需要自动化，否则难以落地（7）需要治理服务
35、服务拆分分为几个方向：按照业务拆分，基于可扩展拆分，基于可靠性拆分，基于性能拆分。
36、微服务最佳实战，需要先搭建基础设施。自动化，服务注册发现，监控等。
37、微内核架构，基本就是将变化部分封装在插件里面，从而达到快速灵活扩展的目的，而又不影响整体体系的稳定。
38、技术发展的主要驱动力是业务发展驱动力。
39、技术演进模式
初创期：一个创新的业务点；对于技术的要求就是“快”，要快速实现。
发展期:完善业务，不断有新功能加入到系统中。客户规模越来越大，会优化系统，改善架构。
竞争期：注重效率
成熟期：注重性能，可用性。
40、存储层技术
开发层：优先选成熟框架。
服务层：虚拟化技术，配置中心，服务中心