这是我参与「第五届青训营」伴学笔记创作活动的第9天
架构定义
架构，又称软件架构：
- 是有关软件整体结构与组件的抽象描述
- 用于指导软件系统各个方面的设计
架构的重要性
我们都知道，地基对于一栋楼房的主要性，架构对于一个软件的重要性也是类似的：
- 架构没设计好，软件容易崩，用户体验上不去。最终要么重构，要么放弃
- 架构设计好了，软件的稳定性上去了，用户体验高了，口碑一点点就打造出来了
- 良好的架构基础，也为软件的未来发展提供了更多的可能。为用户赋能，实现自身价值
单机架构
All in one，所有的东西都在一个进程里，部署在一个机器上。
优点：
- 简单
缺点：
- 运维需要停服，用户体验较差
- 承载能力有限。
单体架构
在单机架构的基础上，将进程部署到多个机器上。
优点：
- 具备水平扩容能力
- 运维不需要停服
缺点：
- 后端进程职责太多，越来越臃肿
- 爆炸半径较大，进程中一个很小的模块出现问题，都可能导致整个进程崩溃
垂直应用架构
在单机架构基础上，将进程按照某种依据切分开。比如，A 软件和 B 软件的后端原先采用单机架构部署，那就是一个进程部署在多个机器上；如果用垂直应用架构，可以将 A 和 B 的后端拆分为 A、B 两个进程，然后再按照单体模式的思路，部署在多个机器上。
优点：
- 一定程度上减少了后端进程职责
- 一定程度上缩小爆炸半径
缺点：
- 没有根本解决单体架构的问题
SOA (面向服务架构)
SOA 架构中，服务为一等公民，将进程按照不同的功能单元进行抽象，拆分为『服务』。有了服务之后，SOA 还为服务之间的通信定义了标准，保证各个服务之间通讯体验的一致性。
优点：
- 各服务的职责更清晰
- 运维粒度减小到服务，爆炸半径可控
缺点：
- ESB (企业服务总线) 往往需要一整套解决方案
微服务
在 SOA 架构中，ESB 起到了至关重要的作用。但从架构拓扑来看，它更像是一个集中式的模块。有一个 SOA 分布式演进的分支，最终的形态便是微服务。
优点：
- 兼具 SOA 解决的问题
- 服务间的通信更敏捷、灵活
缺点：
- 运维成本
- 架构演进的初衷：满足软件迭代诉求，提高迭代效率
-
架构演进的思路：垂直切分——分布式，水平切分——分层/模块化
云原生之DevOps
云原生时代软件交付。结合自动化流程，提高开发效率,工作流。
云原生之微服务架构
-
HTTP(Restful API,提供形式供他人调用
-
RPC(Thrift,gRPC
- 性能
- 服务治理
- 协议可解释性
云原生之服务网格
服务网格Service Mesh：
- 微服务之间通讯的中间层
- 高性能网络代理
- 通过加一层代理的方式业务代码与治理解耦 相比较RPC/HTTP
- 异构系统治理统一化 所有进程是剥离的 在数据面中实现
- 与业务进程解耦
企业级后端架构的挑战
物理资源和资源利用率是有限的。网络开销和运营成本较高。
解决资源
资源并池
核心利益：更少的机器提供更多的弹性资源，降低物理资源成本
解决思路：在线离线资源并池，根据需求动态调整比例
-
在线业务
- io密集型(如高并发
- 潮汐性(不同时间访问频率不同和实时性
-
离线业务
- 计算密集型（mapreduce，需要消耗很多资源
- 非实时性 对一个机器，如何实现在线资源和离线资源的隔离？
离线资源对应离线进程·，在线资源对应在线进程。可以使用cgroup或容器化方式来实现，达到隔离效果。
自动扩缩容
利用在线业务潮汐性实现自动扩缩容。
那么自动扩缩容依据什么指标进行？
- cpu的某个性能。如使用率。
- 如果对内存有要求，那么将cpu和内存结合在一起进行衡量
- 当前来说对io隔离在可行性上是比较困难的。
- 业务的qps，不同的业务指标难以量化，因此对自动扩缩容能力要求更严格。
微服务亲和性部署(?
容灾能力、可用性
不同的服务，但是运行时关系紧密，因此调度到一台宿主机，微服务中间件与服务网格通过共享内存通信。服务网格控制面实施灵活、动态的流量调度。
服务网格的服务发现和中间件的服务发现的区别？ 中间件拿到被调用方列表后能做的事情是有限的。服务网格具有中心化的控制面，具有全部视野，能感知A服务和B服务的部署和实例。
流量治理
解决思路：基于微服务中间件，服务网格的流量治理
CPU水位负载均衡
不同的容器面临资源水位差异，可能来源于cpu型号，有可能是网络差异，如何在网络中打平水位差异，在业务的运维或监控有更有效的监控指标？
cpu水位负载均衡。改变调用权重。IaaS提供资源探针
实战
输入
-
服务网格数据面
- 需要支持负载均衡策略
-
注册中心
- 需要提供所有容器的权重信息
-
宿主机
- 需要提供容器的资源使用情况
- 需要提供物力资源信息
关键点
- 快速回滚
- 大规模的情况下使用，具有一定稳定性
- 对于极端场景也适用
自适应静态权重
采集各容器的资源信息，调整容器权重，来实现需求。
完全分布式，复杂度变低，对中间件无适配成本。
但是缺乏运行时的自适应
自适应动态权重 ALpha
权重进行自适应调整，但是借助服务网格的服务发现和流量调度能力。
自适应动态权重 Beta
服务网格上报rpc指标来实现，可以处理极端场景。
但是时序数据库压力较大，动态权重决策中心职责越来越多。
自适应动态权重 Release
-
微服务化
-
引入消息队列薛峰解耦
-
离线在线链路切分
-
梳理强弱依赖
