这是我参与「第五届青训营」伴学笔记创作活动的第 7 天。
架构（软件架构）：是有关软件整体结构与组件的抽象描述，用于指导软件系统各个方面的设计。通俗一点：架构是在指导软件的方法选择上起至关重要的指导作用。
单机：软件系统需要具备对外提供服务，单机，就是把所有功能都实现在一个进程里，并部署在一台机器上
优点：简单
问题：
①C10K problem 单机架构提供的服务是有瓶颈的
②运维需要停服
单体架构：分布式部署
优化（垂直切分）就到了垂直应用架构
垂直应用架构：按应用垂直切分的单体
优点：水平扩容 运维不需要停服
问题：
①职责太多，开发效率不高
②爆发半径大（如果某一部分出现了问题，接下来就无法执行）
分工协作（水平切分）
SOA(Service-0riented Architecture)
1.将应用的不同功能单元抽象为服务
2.定义服务之间的通信标准
微服务架构：SOA的去中心化演进方向
就是将职责和服务拆分更为细致，提倡服务之间自由建立沟通方式，避免中心化的存在，耦合性更低。
数据一致性，高可用（服务之间的调用沟通怎么保障通畅），治理（链路出现问题怎么进行容灾）解耦vs过微(运维成本提高了，值得吗)
云计算：是指通过软件自动化管理，提供计算资源的服务网络，是现代互联网大规模数据分析和存储的基石
基础：虚拟化技术，编排方案
架构：
IaaS基础设施即服务 PaaS平台即服务
SaaS软件即服务 FaaS功能即服务
云原生技术为组织（公司）在公有云、自有云、混合云等新型的动态环境中，构建和运行可弹性扩展的应用提供了可能。
弹性资源：
虚拟化容器——快速扩缩容
弹性计算资源类型：
服务资源调度：微服务（快速承载）、大服务（长期占用，使用量高）
计算资源调度：在线（热销榜单）、离线（热销榜单更新）
消息队列：在线（削峰，解耦）离线（大数据分析）
弹性存储资源类型：
经典：对象（宣传视频）大数据（用户消费记录）
关系型数据库：（收银记录）
元数据：服务发现（蛋糕店通信录）
NoSQL：KV存储，key和value
总结：将存储资源当成服务一样
微服务架构：
业务功能单元结构，统一的通信标准
通信标准：
HTTP（RESTful API）
RPC（Rhrift,gRPC）
微服务中间件 RPC vs HTTP
性能（RPC压缩方案） 服务治理(RPC) 协议可解释性（HTTP）
云原生场景下，微服务大可不必在业务逻辑中实现符合通信标准的交互逻辑，而是交给框架来做
DevOps： 敏捷开发，CI/CD（开发和运营）
服务网格： 业务与治理结构，异构系统的治理统一化，复杂治理能力
大众点评——连锁店——售卖——从缓存拿——缓存击穿——制作——更新缓存——用户分析——数据量大——离线——（实时性——在线——会员激励）——冷存——产品分析——新品研发——满意度分析然后再到冷存
挑战：
基础设施层面——物理资源（机器、带宽）是有限的
资源利用率受制于部署服务
用户层面
①网络通信开销较大 ②网络抖动导致运维成本提高（如何容灾）③异构环境下，不同实例资源水位不均（配置、量级不同）
合理收益：
降低物理资源成本 提供更多的弹性资源，增加收入
解决思路：离线在线资源并池
在线业务特点：IO密集型为主 潮汐性：凌晨的时候比较少，然后
晚高峰的时候非常大 实时性：延迟比较敏感
离线业务特点：计算密集型占多数 非实时性
根据潮汐性对在离线资源的占用进行调整
自动扩缩容
核心收益：降低业务成本
解决思路：自动扩缩容——利用在线业务潮汐性自动扩缩容
根据CPU的某一个统计分位数来作为指标，也可以把CPU和内存的利用率作为指标
微服务亲和性部署
核心收益：降低业务成本 提高服务可用性
解决思路：微服务亲和性部署
将满足亲和性条件的容器调度到一台宿主机
微服务中间件与服务网格通过共享内存通信
服务网格控制面实施灵活、动态的流量调度
流量治理
核心收益：提高微服务调用容错性 容灾 进一步提高开发效率，DevOps发挥到极致
解决思路：基于微服务中间件&服务网格的流量治理
熔断、重试（单次请求失败了，如何处理）
单元化（同一类的请求不影响另一类的请求）
复杂环境（功能、预览）的流量调度 演练新开发的功能
CPU水位负载均衡
核心收益：打平异构环境算力差异 为自动扩缩容提供正向输入
解决思路：CPU水位负载均衡
IaaS——提供资源探针 服务网格——动态负载均衡
如何设计CPU水位负载均衡
需要哪些输入
服务网格数据面：支持带权重的负载均衡策略
注册中心存储了所有容器的权重信息
宿主机能提供：容器的资源使用情况、物理资源信息（如CPU信号）
设计时需要考虑哪些关键点（动态变化）
关键点：紧急回滚能力 大规模 极端场景
自适应静态权重
方案：采集宿主机物理资源信息 调整容器注册的权重
优势：复杂度低 完全分布式，可用性高 微服务中间件无适配成本
缺点：无紧急回滚能力 缺乏运行时自适应能力
自适应动态权重Alpha
方案：容器动态权重的自适应调整 服务网格的服务发现&流量调度能力
演进方向：解决无法紧急回滚的问题 运行时权重自适应
缺点：过度流量倾斜可能会有异常情况
自适应动态权重Beta
方案：服务网格上报RPC指标
演进方向：极端场景的处理成为可能
缺点：时序数据库压力较大 动态权重决策中心职责越来越多，迭代——>变更——>风险
自适应动态权重Release
演进方向：①微服务化 ②引入消息队列削峰、解耦 ③离在线链路切分 ④梳理强弱依赖
