这是我参与「第三届青训营-后端场」笔记创作活动的的第八篇笔记
架构初探
什么是架构？
有关软件整体结构与组件的整体描述
用于指导软件系统的各个方面的设计
指导方法选择
单机：把所有功能都实现在一个进程里面，并部署在一台机器
简单，C10K problem，运维需要停服
演进->多雇几个蛋糕师傅
单体架构：分布式部署
垂直应用架构：按应用垂直切分的单体
水平扩容，运维不需要停服，爆炸半径大，职责太多，开发效率不高
分工协作
SOA（service-oriented architecture）
将应用的不同功能单元抽象为服务
定义服务之间的通信标准
微服务架构：SOA的去中心化演进方向
问题：数据一致性、高可用、治理、解耦vs过微
企业级后端架构剖析
云计算：通过软件自动化管理，提供计算资源的服务网络，是现代互联网大规模熟悉分析和存储的基石
基础：虚拟化技术-整租还是合租，编排方案-业主还是租赁平台
架构：IaaS(Infrastructure as a Service),Paas(Platform as a Service),SaaS(Software as a Service),Faas(Function as a Service)
云原生技术：弹性资源（虚拟化容器，快速扩缩容），微服务架构（业务功能单元解耦，统一的通信标准），DevOps(敏捷开发，CI/CD)，服务网络（业务与治理解构，异构系统的治理统一化，复杂治理能力）
弹性计算资源类型：
服务资源调度
微服务，大服务
计算资源调度：
在线：热销榜单，离线：热销榜单更新
消息队列：
在线：削峰，解耦，离线：大数据分析
弹性存储资源：
经典：对象，大数据
关系型数据库：收银记录
元数据：服务发现
NoSQL：KV
将存储资源当成服务一样
DevOps:软件交互。贯穿整个软件开发周期，结合自动化的流程，提高软件开发，交付效率
通信标准：
HTTP（RESTful API）,RPC(Thrift,gRPC)
微服务中间件RPC vs HTTP:性能，服务治理，协议可解释性
云原生场景下，微服务大可不必在业务逻辑中实现符号通信标准的交互逻辑，而是交给框架去做
服务网格（Service Mesh）
微服务之间通讯的中间层，高性能网络代理，业务代码与治理解耦
相较于RPC/HTTP框架：异构系统治理统一化，与业务进程解耦，生命周期易管理
企业级后端架构的挑战
挑战：
基础设施层面
物理资源是有限的：机器，带宽，资源利用率受制于部署服务
用户层面：网络通信开销大，网络抖动导致运维成本高，异构环境下，不同实例资源水位不均
核心收益：
降低物理资源成本，提供更多的弹性资源，增加收入
解决思路：离在线资源并池
在线业务的特点：
IO密集型为主，潮汐性、实时性
离线业务的特点：
计算密集型占多数，非实时性
同一个机器怎么做离在线隔离？（cgroup）
自动扩缩容
核心收益：降低业务成本
解决思路：自动扩缩容。利用在线业务潮汐性自动扩缩容
扩缩容依据指标：
CPU利用率，内存利用率
微服务亲和性部署
核心收益：降低成本，提高服务可用性
解决思路：微服务亲和性部署
将满足亲和性条件的容器调度到一台宿主机
微服务中间件与服务网格通过共享内存通信
服务网格控制面实施灵活、动态的流量调度
流量治理
核心收益：提高服务调用容错性，容灾，进一步提高开发效率，Devops
发挥到极致
解决思路：基于微服务中间件&服务网格的流量治理
熔断、重试，单元化，复杂环境的流量调度
Cpu水位负载均衡
核心收益：打平异构环境算力差异，为自动扩缩容提供正向输入
解决思路：CPU水位负载均衡，IaaS提供资源探针，服务网络，动态负载均衡
后端架构实战
cpu水位负载均衡，应该如何设计？
需要哪些输入？设计时需要考虑哪些关键点？
输入：
服务网格数据面（支持带权重的负载均衡策略），注册中心存储了所有容器的权重信息
宿主机能提供（容器的资源使用情况，物理资源信息）
关键点：
紧急回滚能力，大规模，极端场景
自适应静态权重
方案：采集主机物理资源信息，调整容器注册的权重
优势：复杂度低，完全分布式，可用性高，微服务中间件无适配成本
缺点：无紧急回滚能力，缺乏运行时自适应能力
alpha版本
动态权重决策中心
解决无法紧急回滚的问题，运行时权重自适应
缺点：过度流量倾斜可能会有异常情况
Beta版本
服务网格上报RPC指标
演进方向：极端场景的处理成为可能
时序数据库压力较大
动态权重决策中心职责越来越多，迭代-》变更-》风险
release版本
演进方向：
微服务化，引入信息队列削峰，解耦，离在线链路切分，梳理强弱依赖
