1.概述
架构设计的主要目的: 解决软件系统复杂度带来的问题。
架构设计复杂度的来源: 高性能、高可用、高可扩展以及低成本.
架构设计的原则:合适、简单、演化.
架构设计流程：识别系统复杂度->设计备选方案->评估和选择备选方案->详细方案设计
2.容量评估
这是架构设计的基本功,什么样的场景需要进行容量预估、容量设计呢？
（1）容量有质变性增长
（2）临时运营活动（如双11，春节红包）
（3）新系统上线
评估哪些指标？
看具体业务，对应到系统测的主要矛盾是什么？例如：
（1）数据量 (新鲜事评论, 视频点播平台)
（2）并发量，吞吐量（12306抢票,商品抢购）
（3）带宽（直播，推流，音视频业务）
（4）CPU/MEM/DISK IO等
如何进行容量评估？（QPS吞吐量）
1). 评估总访问量：参考产品品和运营预估数据
2). 评估平均吞吐量：总访问量/总时间，一天按4W秒（一天总共60x60x24=86400秒；一般认为请求都发生在白天即4W秒）
3). 评估高峰吞吐量：根据业务访问曲线来评估（二八原则，秒杀等特殊业务除外）
4). 评估单机极限吞吐量：压测
5). 根据线上冗余度做决策：计算需求与线上冗余差值（灾备）
3.高性能
1). 高性能常见指标
1. 响应时间（Response Time）
2. 吞吐量（Throughput）
3. 每秒查询率QPS（Query Per Second）
4. 并发用户数
2).提升系统性能的方法：
1. 垂直扩展（Scale Up） 增强单集硬件性能，提升单集架构性能
2. 水平扩展（Scale Out） 只要增加机器数量，就能线性扩展系统性能 每一层都必须支持水平扩展， 才能理论上性能无限.
3) .常用方法: 读写分离, 动静分离（页面静态化）,数据库水平切分（水平分表、分库）,高性能缓存架构, CDN加速.
CDN适合静态资源的加速访问:通过“智能DNS”来实现的！智能DNS通过用户ip来解析域名实现就近访问
4)缓存架构
进程内缓存可以节省内网带宽 并且 时延更低, 但保证数据一致性 复杂性很高.且违背了””服务无状态”的设计准则，数据和状态尽量存储到后端统一存储.
什么时候可以使用进程内缓存？
1. 只读数据
2. 并发极高，透传后端压力极大 （秒杀类业务）
3. 允许一定程度上数据不一致 （计数业务）
如何保证进程内缓存的一致性？
方案一：单节点通知其他节点
同一功能在一个集群的多个节点相互耦合在一起，节点比较多时，连接关系会比较复杂
方案二：MQ解耦合,但引入MQ系统复杂性提高
方案三：放弃实时一致性，定期从后端更新数据
4.高可用
Cap理论
高可用HA（High Avaliability），是分布式系统架构设计必须考虑的因素,如何保障系统的高可用？
（1）集群化（冗余）
（2）故障自动转移
高可用存储架构：双机架构
高可用存储架构：集群和分区
业务高可用的保障：异地多活架构
主从一致性，究竟如何解决？
主从不一致发生原因：写请求发生后，数据还没同步到从库，立刻发生读请求（主从同步时延）
主从数据冗余，主从不一致：
1. 忽略不计（业务接受很短的时延内读到老数据）
2. 强制读主（放弃读写分离，一主多从的分组架构；使用缓存来提升读性能，引入缓存与数据库的数据不一致问题）
3. 借助缓存，选着性读主（主从同步的时延范围内读主库，否则读冲库，缓存记录写的数据库，表，主键）
主主不一致发生原因：主库使用自增长主键；两个主库同时发生写请求，自增主键冲突，同步失败，造成数据永久性丢失
主主数据冗余，主主不一致：
1. 数据库自增id设置不同初始值，相同增长步长
2. 应用层生成不冲突的id （雪花算法等）
3. 只有一个主库提供服务，影子主不服务（牺牲资源利用率，数据一致性与资源利用率的折中）
5.高可扩展
可扩展的基本思想:拆分. 就是将原本大一统的系统拆分成多个规模小的部分，扩展时只修改其中一部分即可，无须整个系统到处都改，通过这种方式来减少改动范围，降低改动风险。
按照不同的思路来拆分软件系统，就会得到不同的架构。常见的拆分思路有如下三种,不同的拆分方式，将得到不同的系统架构:
面向流程拆分：分层架构。将整个业务流程拆分为几个阶段，每个阶段作为一部分。
面向服务拆分：SOA、微服务。将系统提供的服务拆分，每个服务作为一部分。
面向功能拆分：微内核架构。将系统提供的功能拆分，每个功能作为一部分。
架构分层方法论：
（1）分层架构，是一个“数据移动”，被“处理”，然后被“呈现”的过程
（2）架构分层方法论：
让上游更高效的获取与处理数据，复用
让下游能屏蔽数据的获取细节，封装
MQ （消息总线，Message queue）是互联网架构中最常见的结构利器
6.微服务
服务化有什么好处：
1. 复用性，消除代码拷贝2. 专注性，防止复杂性扩散
3. 解耦合，消除公共库耦合
4. 高质量，SQL稳定性有保障
5. 易扩展，消除数据库解耦合
6. 高效率，调用方研发效率提升
但是如果服务化不合理，将个性化的数据下沉到了底层的微服务，耦合和瓶颈会更加严重。
如何解耦: 个性化代码上浮，公共代码下沉，服务化更彻底！
