1 大型网站架构演进

• 初始阶段(LAMP)
• 应用服务和数据服务分离
• 使用缓存
• 应用服务器集群
• 数据库读写分离
• 使用反向代理和CDN
• 使用分布式文件系统和分布式数据库系统
• 使用nosql和搜索引擎
• 应用拆分(MQ通信)
• 分布式服务
• 云计算

大型网站架构演进

2 如何实现高可用？

HA的标准

• 2个9：基本可用，全年故障时间88小时
• 3个9：较高可用，全年故障时间9小时
• 4个9：具有自动恢复能力的高可用，全年故障时间53分钟，比如QQ
• 5个9：极高可用，全年故障时间小于5分钟

实现HA的手段

• 分布式和集群
  • client到Nginx：keepalived+virtual IP
  • Nginx到server：Nginx能自动故障转移
  • server到cache：Redis的HA保障，比如说主从、哨兵、cluster、codis、twemproxy等
  • server到DB：DB的HA(MySQL的5种HA) + keepalived + Virtual IP
• 自动故障转移
  • keepalived
  • heartbeat
• 监控
• 服务治理：降级、限流、熔断
• session管理
  • session复制
  • session绑定/会话粘滞
  • 利用cookie记录session
  • session服务器：无状态的应用服务器+有状态的session服务器
• 质量控制：自动化测试、灰度发布

HA和LoadBalance的区别

• HA集群的节点一般是一主多备，通过备份提高系统可用性
• LoadBalance集群的节点一般是多主，每个节点都分担流量请求

HA常用工具

• Nginx
• LVS
• Haproxy
• keepalived
• heartbeat

3 如何实现高并发高性能？

• 前端优化：网站业务逻辑之前的部分。

• 浏览器优化：减少 HTTP 请求数，使用浏览器缓存，启用压缩，CSS JS 位置，JS 异步，减少 Cookie 传输；CDN 加速，反向代理。

• 应用层优化：处理网站业务的服务器。使用缓存，异步，集群。

• 代码优化：合理的架构，多线程，资源复用（对象池，线程池等），良好的数据结构，JVM调优，单例，Cache 等。

• 存储优化：缓存、固态硬盘、光纤传输、优化读写、磁盘冗余、分布式存储（HDFS）、NoSQL 等。

4 如何实现可伸缩架构？

伸缩性是指在不改变原有架构设计的基础上，通过添加/减少硬件（服务器）的方式，提高/降低系统的处理能力：

• 应用层：对应用进行垂直或水平切分。然后针对单一功能进行负载均衡（DNS、HTTP[反向代理]、IP、链路层）。

• 服务层：与应用层类似。

• 数据层：分库、分表、NoSQL 等；常用算法 Hash，一致性 Hash。

5 如何实现可扩展架构？

可以方便地进行功能模块的新增/移除，提供代码/模块级别良好的可扩展性：

• 模块化，组件化：高内聚，低耦合，提高复用性，扩展性。

• 稳定接口：定义稳定的接口，在接口不变的情况下，内部结构可以“随意”变化。

• 设计模式：应用面向对象思想，原则，使用设计模式，进行代码层面的设计。

• 消息队列：模块化的系统，通过消息队列进行交互，使模块之间的依赖解耦。

• 分布式服务：公用模块服务化，提供其他系统使用，提高可重用性，扩展性。

6 如何实现安全的架构？

• 基础设施安全：硬件采购，操作系统，网络环境方面的安全。一般采用正规渠道购买高质量的产品，选择安全的操作系统，及时修补漏洞，安装杀毒软件防火墙。防范病毒，后门。设置防火墙策略，建立 DDOS 防御系统，使用攻击检测系统，进行子网隔离等手段。

• 应用系统安全：在程序开发时，对已知常用问题，使用正确的方式，在代码层面解决掉。
  防止跨站脚本攻击（XSS），注入攻击，跨站请求伪造（CSRF），错误信息，HTML 注释，文件上传，路径遍历等。还可以使用 Web 应用防火墙（比如：ModSecurity），进行安全漏洞扫描等措施，加强应用级别的安全。

• 数据保密安全：存储安全（存储在可靠的设备，实时，定时备份），保存安全（重要的信息加密保存，选择合适的人员复杂保存和检测等），传输安全（防止数据窃取和数据篡改）。

• 复杂的加解密算法。

• 流程制度建设。

7 集群&分布式&微服务区别

• 集群：同一模块重复叠加
• 分布式：拆分成更小模块

8 亚马逊云elb配置

9 怎么设计一个rpc框架，map方法是干嘛的，跟什么方法结合

10 分布式事务

• 2PC
• 3PC
• TCC
• MQ+本地事务
• BED

10.1 2PC

• XA协议是Oracle Tuexdo系统提出来的分布式事务协议，XA是强一致性，XA协议有两种实现，2PC和3PC
• 2PC，Two-Phrase Commit，二阶段提交，事务参与者+事务协调者
  • 投票阶段
  • 事务提交阶段

2PC的缺陷

1. 性能问题
   XA协议遵循强一致性。在事务执行过程中，各个节点占用着数据库资源，只有当所有节点准备完毕，事务协调者才会通知提交，参与者提交后释放资源。这样的过程有着非常明显的性能问题。
2. 协调者单点故障问题
   事务协调者是整个XA模型的核心，一旦事务协调者节点挂掉，参与者收不到提交或是回滚通知，参与者会一直处于中间状态无法完成事务。
3. 丢失消息导致的不一致问题。
   在XA协议的第二个阶段，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致。

10.2 3PC

• 3PC，Three-Phrase Commit，三阶段提交，XA协议的一种实现
  • can_commit
  • pre_commit
  • do_commit
• 3PC在2PC基础上增加了CanCommit阶段，同时引入了超时机制，事务参与者超时没有commit会自动本地commit。

10.3 TCC

• TCC，补偿性事务，服务器A调用服务器B，B处理时间长，A调用完返回成功，B处理如果成功了就OK了；如果B处理失败了，通知A回滚。
  • Try
  • Confirm
  • Cancel

10.4 MQ+本地事务

• MQ+本地事务
  通过消息队列解耦业务，主要解决消息的幂等性，即消息重复投递和重复消费问题，通过发送消息时候写入一份到本地消息表中。

10.5 柔性事务

• BED
  Best Effort Delivery，最大努力送达型柔性事务，Sharding-Sphere采取的方式，记录事务日志，失败重试

10.6 多数据源管理器

• Atomikos
  多数据源管理器。

分布式事务业界难题，没有统一解决方案，需要根据业务来制定合适的解决方案，以上方案都不行的情况下，从商业上来讲，还需要人工补偿。

11 实现一个秒杀系统架构？(https://github.com/qiurunze123/miaosha)

11.1 秒杀系统架构

秒杀系统垂直架构

秒杀系统架构

秒杀系统架构

11.2 秒杀系统核心业务流程

• 校验库存
• 扣库存：乐观锁&Lua脚本原子操作
• 下单
• 支付

11.3 秒杀系统设计思路

• 缓存
• 异步：消息队列
• 降级
• 限流
  • 前端：按钮置灰，到点了才能点，点了过几秒才能继续点
  • 后端：令牌桶
• 削峰
  • 缓存
  • 消息中间件
• 加锁
  • 扣库存：乐观锁+Lua原子操作
  • 超卖：分布式锁
• 安全控制：防刷

11.4 秒杀系统实现思路

• 前端优化
  • 页面静态化
  • CDN加速
  • 防止提前下单
• API接入层优化
  • 限制用户维度访问频率
  • 限制商品维度访问频率
• Nginx负载均衡
  • HA
  • 防刷
• Redis
  • HA
  • 缓存预热：库存商品加载到Redis
• 超卖
  • Lua脚本原子操作
  • 分布式锁
• 降级
• 限流
• 异步：kafka

12 电商架构是怎么样的，要注意什么？

电商系统架构

13 用户下单30分钟内支付，如果大量都是延时30分钟内支付，会有什么问题，怎么实现这个功能？

14 灰度发布

灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

为什么要灰度发布？

1. 灵活选择用户参与产品测试。
2. 规避一定的发布风险，降低产品迭代升级所影响的范围。
3. 快速获取用户的反馈意见，完善产品功能，提升产品质量。
4. 避免停服发布给用户带来不便。
5. 具有容灾能力：降低全量发布引起的服务器崩溃等风险，逐步发布产品，逐步控制服务器压力。

灰度发布三大类型？

• web页面灰度：按照ip或者用户id切流啊。具有随机性，可以控制比例
• 服务端灰度：考验主系分能力了，可以做逻辑切换开关，按照义务相关属性逐渐切流
• 客户端灰度：一般按照用户逐渐推送包，主要是PC端(WIN，MAC)、移动端（安卓，OS）内部大规模内测

web页面灰度

服务端灰度

客户端灰度/全流程灰度

涉及到数据的灰度服务

假设灰度的服务，需要使用到数据库，如果灰度前后数据库的字段保持不变，那么新旧两套系统使用同一套数据库就可以了。如果前后数据不一致，需要处理的情况就比较复杂，分为以下几种情况：

• 部分灰度

在部分灰度的情况下，有部分请求到旧系统上，另一部分请求到了新的灰度系统上．走到旧系统的请求，还是照原样处理．但是走到了新版灰度系统的请求，需要同时将请求转发给旧系统上来对应的接口上修改旧系统的数据．如果走到新系统的请求查不到该用户的数据，还需要首先同步一份来新系统上．如果是事务性的请求，以写入老系统成功来做为操作成功的标准．

• 全部灰度

在灰度系统已经全部接管了线上流量之后，为了安全起见，仍然需要对新老系统进行双写，步骤和前面一样。

• 灰度完成

灰度完成与前面的全量灰度状态不太一样，区别在于前面的全量灰度状态下，仍然不能肯定系统一定是没有问题的，所以需要进行新旧系统的双写来保证数据可以在老系统上进行回滚．而在灰度完成状态，此时认为这个新版本已经完全通过了验证，无需再写入旧系统了．但是此时可能存在部分在灰度期间没有上线的用户，此时需要做一次同步，从旧系统上将这部分数据同步过来．

可以看到，这三个状态下，对新旧系统是否进行双写，做了严格的区分，目的只有一个：一旦新上线的系统出现问题，可以马上撤掉灰度系统，而这期间用户的任何修改在旧系统上都是可以找到的．

灰度发布步骤

1）定义目标
2）选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
3）筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等
4）部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调
5）发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表
6）产品完善
7）新一轮灰度发布或完整发布

灰度发布常见一般有三种方式

• Nginx+LUA方式
• 根据Cookie实现灰度发布
• 根据来路IP实现灰度发布

灰度发布方案

• 基于F5做灰度
• 基于K8S Ingress controller 做灰度
• 基于SpringCloud架构的ribbon组件做灰度
• 基于Istio架构方案做灰度（采用sidecar对应用流量进行了转发，通过Pilot下发路由规则）
• 自研基于Nginx方案做灰度
• 基于Kubernetes SLB引流：更新客户端或DNS解析，将Kubernetes 集群SLB地址追加到客户端或DNS中，实现流量引入。（不推荐，引流成本高，回滚风险高）

15 如何实现动静分离？

16 osgi的底层原理

17 CDN原理

18 如何读源码？

1. 猜想：70%
2. 验证：30%

19 微服务&SOA区别

微服务&SOA

• 微服务是 SOA 的延续，都强调松耦合，只是 SOA 高度依赖服务总线（ESB），而微服务不需要。

• 微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

• 微服务，从本质意义上看，还是 SOA 架构。但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有 Java 编写的服务，也可以有 Python编写的服务，他们是靠Restful架构风格统一成一个系统的。所以微服务本身与具体技术实现无关，扩展性强。