这是我参与「第五届青训营 」伴学笔记创作活动的第 3 天
什么是架构
软件整体结构与组件的抽象描述、指导软件系统各个方面的设计
指导软件实现的方法选择
-
单机架构：所有功能实现在一个进程里，部署在一台机器上【简单、C10k问题、运维需停服】
-
单体架构：分布式部署；垂直应用架构：按应用垂直切分的单体；
【水平扩容、运维不需停服、职责太多、开发效率不高、爆炸半径大】 -
SOA架构：将应用的不同功能单元抽象为服务，定义服务之间的通信标准
微服务架构：SOA的去中心化演进方向
【数据一致性问题、高可用问题、治理问题、解耦vs过微问题】
演进初衷：需求量变大、变复杂
演进思路：垂直切分、水平切分
企业级后端架构剖析
**云计算：**通过软件自动化管理，提供计算资源的服务网络
基础：虚拟化技术、编排方案
架构：IaaS、PaaS、SaaS、FaaS
**云原生：**为公司在公有云、自由云、混合云等新型动态环境中，构建和运行可弹性扩展的应用 弹性资源：虚拟资源可弹性扩缩容
微服务架构：业务功能单元解耦、统一通信标准
DevOps：敏捷开发、CI/CD
服务网格：业务与治理解耦、异构系统统一治理、复杂的治理能力
1. 弹性计算资源
服务资源调度：微服务、大服务
计算资源调度：在线、离线
消息队列：在线、离线
弹性存储资源
经典：对象存储【宣传视频】、大数据存储【用户消费记录】
关系型数据库：收银记录
元数据：服务发现【蛋糕店通讯录】
NoSQL：KV存储【来个xx蛋糕】
2. DevOps
软件交付的利器，贯穿整个软件开发周期
结合自动化流程，提高软件开发、交付效率
3. 微服务架构
通信标准：HTTP（RESTful API）、RPC（Thrift， gRPC）
微服务中间件RPC vs HTTP选择考量：性能、服务治理、协议可解释性
在云原生场景下，微服务不必实现符合通信标准的交互逻辑，交给框架来做
4. 服务网格
微服务之间通讯的中间层、高性能网络代理、业务代码与治理解耦
相较于RPC/HTTP：异构系统治理统一化，与业务进程解耦、生命周期易管理
企业级后端架构的挑战
问题挑战：
基础设施层面：物理资源有限【机器、带宽】、资源利用率受制于部署服务
用户层面：网络通信开销较大、网络抖动致运维成本高、不同实例资源水位不均
离在线资源并池
核心收益：降低物理资源成本；提供更多弹性资源，增加收入
在线业务特点：IO密集型为主；潮汐性、实时性；
离线业务特点：计算密集型占多数；非实时性
自动缩扩容
核心收益：降低业务成本
利用在线业务潮汐性自动缩扩容
指标：CPU 内存
微服务亲合性部署
核心收益：降低业务成本；提高服务可用性
满足亲合性条件的容器调度到同一台宿主机、微服务中间件与服务网格通过共享内存通信、服务
网格控制面是是灵活、动态的流量调度
流量治理
核心收益：提高微服务调用容错性、容灾、提高开发效率
解决思路：基于微服务中间件&服务网格的流量治理
【熔断、重试；单元化；复杂环境的流量调度】
CPU水位负载均衡
核心收益：打平异构环境算力差异；为自动扩缩容提供正向输入
IaaS【提供资源探针】、服务网格【动态负载均衡】
后端架构实战
**问题背景：**CPU水位负载均衡如何设计【哪些输入、哪些关键点】
问题提炼：
输入：服务网格数据面【支持带权重的负载均衡策略】；注册中心存储所有容器的权重信息；宿主机能提供容器资源使用情况、物理资源信息
关键点：紧急回滚能力；大规模；极端场景
自适应静态权重
方案：采集宿主机物理资源信息、调整容器注册的权重
优势：复杂度低；完全分布式，可用性高；微服务中间件无适配成本
缺点：无紧急回滚能力、缺乏运行时自适应能力
自适应动态权重 Alpha
方案：容器动态权重的自适应调整；服务网格的服务发现&流量调度能力
演进方向：解决无法紧急回滚的问题；运行时权重自适应
缺点：过度流量倾斜可能有异常情况
自适应动态权重 Beta
方案：服务网格上报RPC
演进方向：极端场景的处理成为可能
缺点：时序数据库压力较大；动态权重决策中心职责越来越多【迭代→变更→风险】
自适应动态权重 Release
演进方向：微服务化；
引入消息队列削峰、解耦；
离在线链路切分；梳理强弱依赖
总结
架构只有最合适，没有最好
设计架构：需求先行；业界调研；技术选型；异常情况；
架构与工程师成长：技术经理；架构师
