这是我参与「第三届青训营 -后端场」笔记创作活动的的第2篇笔记
什么是架构
架构定义
Q：如何给架构下定义？
A：架构：
-
是有关软件整体结构与组件的抽象描述
-
用于指导软件系统各个方面、功能的设计
Q：架构的重要性？
A：
-
架构设计差，软件隐藏bug多，扩展性差，功能实现困难，用户体验差。最终重构或放弃
-
架构设计好，软件的稳定性高，用户体验高，开发新功能，维护容易
架构类型：
单机架构
所有的功能都集成在一个进程里，部署在一个机器上。
优点：
- 简单
缺点：
-
运维需要停服，用户体验较差
-
承载能力有限。了解下 c10k 问题
-
**c10k问题：**C10K 问题是这样的：如何在一台物理机上同时服务 10000 个用户？这里 C 表示并发，10K 等于 10000。得益于操作系统、编程语言的发展，在现在的条件下，普通用户使用框架或库就可以轻轻松松写出支持并发超过 10000 的服务器端程序，甚至于经过优化之后可以达到十万，乃至百万的并发，但在二十年前，突破 C10K 问题可费了不少的心思，是一个了不起的突破。
单体架构
在单机架构的基础上，将同一个进程部署到多个机器上。
优点：
-
具备水平扩容能力
-
运维不需要停服
缺点：
-
后端进程职责太多，维护开发困难
-
高耦合，进程中一个模块出现问题，会导致整个进程崩溃
垂直应用架构
在单机架构基础上，将进程按照某种依据切分开。比如，A 软件和 B 软件的后端原先采用单机架构部署，那就是一个进程部署在多个机器上；如果用垂直应用架构，可以将 A 和 B 的后端拆分为 A、B 两个进程，然后再按照单体模式的思路，部署在多个机器上。
优点：
-
一定程度上减少了后端进程职责
-
一定程度上降低耦合程度
缺点：
- 没有根本解决单体架构的问题
SOA (面向服务架构)
SOA 架构中，服务为一等公民，将进程按照不同的功能单元进行抽象，拆分为『服务』。有了服务之后，SOA 还为服务之间的通信定义了标准，保证各个服务之间通讯体验的一致性。
优点：
-
各服务的职责更清晰
-
运维粒度减小到服务，耦合程度更低
缺点：
- ESB (企业服务总线) 往往需要一整套解决方案，处理如下问题
- 数据一致性不能保证
- 高可用性：进程如何协作
- 服务修复问题
- 运维成本问题
微服务
在 SOA 架构中，ESB 起到了至关重要的作用。但从架构拓扑来看，它更像是一个集中式的模块。有一个 SOA 分布式演进的分支，最终的形态便是微服务。
优点：
-
兼具 SOA 解决的问题
-
服务间的通信更敏捷、灵活
缺点：
- 运维成本
小结
-
架构演进的初衷：满足软件迭代诉求，提高迭代效率
-
架构演进的思路：垂直切分——分布式，水平切分——分层/模块化
企业级后端架构剖析
云计算
云计算基础：
-
虚拟化技术
- 硬件层面（VM 虚拟机）- KVM/Xen/VMware
- 操作系统层面（Container 容器）- LCX/Docker/Kata Container
- 网络层面 - Linux Bridge/Open v Switch
-
编排方案
- VM - OpenStack/VMWare Workstation
- Container - Kubernetes/Docker Swarm
云计算架构：
-
云服务
- IaaS - 云基础设施，对底层硬件资源池的抽象
- PaaS - 基于资源池抽象，对上层提供的弹性资源平台
- SaaS - 基于弹性资源平台构建的云服务
- FaaS - 更轻量级的函数服务。好比 LeetCode 等 OJ，刷题时只需要实现函数，不需要关注输入输出流
-
云部署模式（拓展）
- 私有云 - 企业自用
- 公有云 - AWS/Azure/Google Cloud/Huawei
- 混合云
云原生
云原生，实际是云原生（计算）的简称，它是元计算发展到现在的一种形态。
云原生技术为组织（公司）在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能。 它的代表技术：
-
弹性资源：虚拟化容器、快速扩缩容
-
微服务架构：业务功能单元解耦、统一的通信标准
-
DevOps：敏捷开发，CVCD
-
服务网格：业务与治理结构、异构系统的治理统一化、复杂治理能力
弹性资源
基于虚拟化技术，提供的可以快速扩缩容的能力。可以分为弹性计算资源和弹性存储资源两个方面。
弹性计算资源：
-
计算资源调度
- 在线计算 - 互联网后端服务
- 离线计算 - 大数据分析。Map-Reduce/Spark/Flinnk
-
服务资源调度：微服务、大服务
-
消息队列
- 在线队列 - 削峰、解耦
- 离线队列 - 结合数据分析的一整套方案，如 ELK
弹性存储资源：
-
经典存储
- 对象存储 - 视频、图片等。结合 CDN 等技术，可以为应用提供丰富的多媒体能力
- 大数据存储 - 应用日志、用户数据等。结合数据挖掘、机器学习等技术，提高应用的体验
-
关系型数据库
-
元数据
- 服务发现
-
NoSQL
- KV 存储 - Redis
- 文档存储 - Mongo
在云原生的大背景下，不论是计算资源还是存储资源，他们都像是服务一样供用户使用。
微服务架构
微服务架构下，服务之间的通讯标准是基于协议而不是 ESB 的。
-
HTTP - H1/H2
-
RPC - Apache Thrift/gRPC
如何在 HTTP 和 RPC 之间选择？
-
性能 - RPC 协议往往具备较好的压缩率，性能较高。如 Thrift, Protocol Buffers
-
服务治理 - RPC 中间件往往集成了丰富的服务治理能力。如 熔断、降级、超时等
-
可解释性 - HTTP 通信的协议往往首选 JSON，可解释性、可调试性更好
服务网格
什么是服务网格？
-
微服务之间通讯的中间层
-
一个高性能的 4 层网络代理
-
将流量层面的逻辑与业务进程解耦
服务网格相比较于 RPC/HTTP 框架：
-
实现了异构系统治理体验的统一化
-
服务网格的数据平面代理与业务进程采取进程间通信的模式，使得流量相关的逻辑（包含治理）与业务进程解耦，生命周期也更易管理
企业级后端架构的挑战
挑战
基础设施层面：
Q：云如何解决近乎无限的弹性资源和有限的物理资源之间的矛盾？
Q：如何提高资源利用率，提高物理资源的价值转换率？
Q：使用云原生微服务后，服务之间的通信开销较大，应该如何做成本优化？
Q：微服务抖动导致的运维成本较高，如何解决？
Q：异构的物理环境应该对用户是透明的，如何屏蔽这些细节？
离在线资源并池
考虑到在线业务的潮汐性，物理资源的用量不是一成不变的。
在线业务：IO密集，潮汐性，实时性
离线业务：计算密集，非实时
使离在线资源并池，可以：
-
提高物理资源利用率
-
提供更多的弹性资源
自动扩缩容：利用在线业务潮汐性自动扩缩容
微服务亲合性部署
将满足亲和性条件的容器调度到一台宿主机，
微服务中间件与服务网格通过共享内存通信，
服务网格控制面实施灵活、动态的流量调度。
微服务之间的通信成本较高，是否可以：
-
形态上是微服务架构
-
通信上是单体架构
亲合性部署，通过将微服务调用形态与资源调度系统结合，将一些调用关系紧密、通信量大的服务部署在同一个机器上，并且使用 IPC 代替 RPC 的方式，降低网络通信带来的开销
CPU水位负载均衡：
收益：为自动扩缩容提供正向输入，打平异构环境算例差距
如何设计一个根据主机层面的资源信息，实时进行流量调度的系统，打平不同宿主机异构环境的算力差异。
关键点：
-
紧急回滚能力
-
大规模
-
极端场景
自适应静态权重
方案：采集宿主物理资源信息，调整容器注册的权重
优势：复杂度低，完全分布式，可用性高，微服务中间件无适配成本
缺点：无紧急回滚能力、缺乏运行时自适应能力
自适应动态权重
方案：容器动态权重的自适应调整，服务网格的服务发现、流量调度能力
优势：复杂度低，完全分布式，可用性高，微服务中间件无适配成本
解决缺点：可以紧急回滚，运行时权重自适应。
缺点：过度流量倾斜可能会有异常情况
自适应动态权重Beta
方案：服务网格上报RPC指标
优势：复杂度低，完全分布式，可用性高，微服务中间件无适配成本、可以紧急回滚，运行时权重自适应。
解决缺点：可以进行极端处理
缺点：时序数据库压力较大，动态权重决策中心职责越来越多，风险变高
自适应动态权重Release
方案：服务网格上报RPC指标
优势：复杂度低，完全分布式，可用性高，微服务中间件无适配成本、可以紧急回滚，运行时权重自适应。
解决缺点：微服务化，引入消息队列削峰、解耦，离在线链路切分、梳理强弱依赖
