架构的本质：功能的拆分与整合(类比：代码模块/类划分，以及模块之间的交互)
互联网架构的演进
- 单机架构(单台机器上同时部署 Java服务 和 数据库)
一个类中完成所有操作
- 硬件资源告警：数据库与应用分离。
业务与数据处理分离
- 单服务支撑能力不足：水平扩容，采用代理服务器解决负载均衡问题
线程并发
负载均衡算法：①轮询 ②随机 ③hash ④加权轮询 ⑤最小链接数
负载均衡过程中需解决session/cookies的有状态问题
- 解决方案：①hash方式负载均衡 ②Session拷贝 ③发布书session存储 ④客户端加密存储
- 数据库压力变大：①数据库读写分离 ②redis缓存技术 ③引入搜索引擎作为读服务器
①数据结构改进
- 出现非关系型存储需求：NoSQL数据库
特殊服务新增数据结构
- 数据库中表过大：分库分表(①根据业务类型拆分数据库，②根据键值实现分布式表存储，③冷热数据隔离）
单一对象容纳数据量过大，合适分割
- 应用逐渐复杂：根据服务拆分(此时存在信息孤岛问题，不同服务中对相同表的操作存在代码重复)
类拆分
- 服务化(SOA)：架构出现层次划分，底层负责资源管理，上层实现业务交互，中间通过ESB实现信息通信
组件化层次化模块化
- 分布式架构(微服务化 - 服务网格)：SOA完成了架构的分层，而微服务借鉴SOA服务的思想，并实现进一步拆分(强调细粒度)，实现了(服务注册与发现，负载均衡，服务网关，配置中心等)
引入IOC容器，实现对所有对象的控制
SOA是层次化的架构(不太确定)，而微服务呈现为基于注册中心的星状网络。有点 架构 -> 生态的转变那感觉
--- 微服务：将组件web服务化，零件组装。
- 服务网格：部分基础设施交由统一代理服务实现(原本需要在服务内部完成熔断，限流等操作)，现在可通过服务网格实现，服务只需关注业务代码
异构RPC...面向切面编程(将一些与业务无关的处理抽离出来)
高可用设计 - 避免单点故障
- 集群 - 负载均衡(硬件F5服务器，软件：nginx,haproxy)
对于负载均衡服务器，依然需要采用集群模式，通过选举，心跳等方式避免负载均衡服务器的单点故障
负载均衡算法：①轮询 ②随机 ③hash ④加权轮询 ⑤最小链接数
- 热备：服务内部自带单点故障的处理方法(如 nginx的 lvs+keepalived ，redis 哨兵：master/slave, Raft选举算法，zookeeper：zab(Paxos)选举算法
- 多机房部署(同城，异地)：涉及到状态同步问题
- 应用的可用性：微服务集群部署
- 容错性：快速失败，服务隔离，代码容错，接口设计(幂等，事务，数据校验)
- 服务的自我保护能力：熔断，限流，缓存，主动降级
- 监控 ①系统资源 ②应用层面分析-日志分析 ③告警 ④应用监控，全链路跟踪
高并发 - 单位时间内的吞吐量
瀑布流设计(例如网页，先加载用户可见的信息，当用户下翻后再加载后续资源)
异步化(MQ消息队列)
架构层面
微服务 -> 服务拆分|性能瓶颈
数据库层面 -> ①数据分片(分库分表) ②读写分离 ③业务拆分
存储 -> 非结构化存储Nosql
服务无状态设计：restful，实现服务水平扩容的灵活性(加机器）
分布式缓存(热点数据缓存)
容量规划：当预期出现巨大流量时，收集指标(压测 - 单机吞吐量等)
异步化架构：对于实时性不高的场景，采用异步化队列(生产消费者模式)
冗余：CDN内容分发网络
代码层面
- 避免在for循环中请求IO，网络等
- HashMap预计容量，避免多次扩容
- 数据预热，
- SQL 查询语句优化
- 异步化
- 合理使用空间换取时间，合理使用顺序读写等特性
客户端优化：
合并请求
数据缓存
渐进式重试
服务负载均衡
代理层负载(反向代理)：
DNS轮询(单个域名对应多个IP)
四层负载(IP + 端口)：nginx，haproxy，f5负载均衡服务器
七层负载(http协议，更改URI重定向)：nginx，haproxy，spring cloud gateway
应用层负载(正向代理)：Ribbon
锁/分布式锁
CAP：C - 一致性 A - 高可用 P - 分区容错性
zookeeper(CP)
redis(AP)