1、架构基础
1.1、软件架构定义
软件架构是构建应用系统所需要的一组结构，包括软件元素、元素之间的关系以及两者的属性。其中如何分解软件元素以及这些元素之间的关系，变得非常重要。
一个好的软件架构具备两个特点:
- 合理调配生产关系与生产力，让具备不同专业知识与技术栈的的人士都参与到软件系统开发中来， 高效地协同工作;
- 能让各个软件元素有清晰的定义与职责，并有一套良好、高效的交互机制.
1.2、常见软件架构
-
单机：所有功能都实现在一个进程里，进程部署在单台机器上，运维时需要停服。
单机架构瓶颈：
- 需要大量进程 / 线程作为处理单元，需要占用大量内存空间
- 进程 / 线程切换，系统调度代价高
解决方案： 采用协程（Routine），一个线程中，存在多个协程。如Go语言的轻量级线程Goroutine。协程由程序控制，在用户态中执行，在线程的基础上通过分时复用的方式运行多个协程。
-
单体：分布式部署，进程部署在多台机器上，具备水平扩容能力（添加更多服务器），运维不需要停服
-
垂直应用（分布式架构）：单体架构基础上，将一个单体系统按业务垂直拆分为若干系统，系统之间通过网络交互来完成用户的业务处理，每个系统可分布式部署，
-
面向服务型架构（SOA，Service Oriented Architecture）：将应用的不同功能单元抽象为服务，将不同业务功能按服务进行拆分，通过定义服务间的通信标准建立联系。
-
微服务架构： SOA的去中心化演进方向，每个服务都有自己的数据模型和数据库。基于SOA架构的思想，为了满足移动互联网对大型项目及多客户端的需求，对服务层进行细粒度的拆分，所拆分的每个服务只完成某个特定的业务功能，比如订单服务只实现订单相关的业务，用户服务实现用户管理相关的业务等等，服务的粒度很小，所以称为微服务架构。
1.3、架构演进方式：
业务需求量逐渐增大、系统逐渐复杂
- 水平切分：分层 / 模块化
- 垂直切分：分布式
2.企业级后端架构剖析
背景
兰师傅蛋糕店经过3年的蓬勃发展，积累了良好的口碑和用户基础，接下来，需要扩大规模：
- 店面怎么盘？
- 师傅怎么招？
- 是否还要坚持纯手工制作？
- 规模扩大了之后，工作重心应该是？
2.1企业级后端架构剖析-云计算
云计算：是指通过软件自动化管理。提供计算资源的服务网络，是现代互联网大规模数据分析和存储的基石。
基础：
- 虚拟化技术 - 整租 vs 合租
- 编排方案 - 业主 vs 租赁平台
云计算架构：
云服务
IaaS - 云基础设施，对底层硬件资源池的抽象
PaaS - 基于资源池抽象，对上层提供的弹性资源平台
SaaS - 基于弹性资源平台构建的云服务
FaaS - 更轻量级的函数服务。好比 LeetCode 等 OJ，刷题时只需要实现函数，不需要关注输入输出流
云部署模式（拓展）
私有云 - 企业自用
公有云 - AWS/Azure/Google Cloud/Huawei
混合云
2.2企业级后端机构剖析-云原生
云原生技术为组织（公司）在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能。它的代表技术有：弹性资源、微服务架构、DevOps、服务网格
2.2.1企业级后端架构剖析-云原生之弹性计算资源
弹性计算资源类型：
- 服务资源调度
- 微服务：和面、雕花
- 大服务：烤箱
- 计算资源调度
- 在线：热销榜单，互联网后端服务
- 离线：热销榜单更新，大数据分析
- 消息队列
- 在线队列：削峰、解耦
- 离线队列：结合数据分析的一整套方案，如ELK
弹性存储资源类型：
- 经典存储
- 对象存储：宣传视频、图片等。结合 CDN 等技术，可以为应用提供丰富的多媒体能力
- 大数据存储：应用日志、用户数据等。结合数据挖掘、机器学习等技术，提高应用的体验
- 关系型数据库
- 收银记录
- 元数据
- 服务发现：蛋糕店通讯录
- NoSQL
- KV存储：Redis，来个xx蛋糕
- 文档存储：Mongo
在云原生的大背景下，不论是计算资源还是存储资源，他们都像是服务一样供用户使用。
2.2.2企业级后端架构剖析-云原生之DevOps
DevOps是云原生时代软件交付的利器，贯穿整个软件开发周期 结合自动化流程，提高软件开发、交互效率
2.2.3企业后端剖析-云原生之微服务架构
通信标准：
微服务架构下，服务之间的通讯标准是基于协议而不是 ESB 的。
- HTTP（RESTful API）
- RPC（Thrift， gRPC）
微服务中间件 RPC vs HTTP：
- 性能 - RPC 协议往往具备较好的压缩率，性能较高。如 Thrift, Protocol Buffers
- 服务治理 - RPC 中间件往往集成了丰富的服务治理能力。如 熔断、降级、超时等
- 可解释性 - HTTP 通信的协议往往首选 JSON，可解释性、可调试性更好
云原生场景下，微服务大可不必在业务逻辑中实现符合通信标准的交互逻辑，而是交给框架来做
2.2.3企业后端剖析-云原生之服务网格
什么是服务网格？
- 微服务之间通讯的中间层
- 一个高性能的4层网格代理
- 将流量层面的逻辑与业务进行解耦
没有什么是加一层代理解决不了的问题，服务网格相比较于 RPC/HTTP 框架：
1.实现了异构系统治理体系的统一化
2.服务网格的数据平面代理与业务进程采取进程间通信的模式，使得流量相关的逻辑（包含治理）与业务进程解耦，生命周期也更容易管理
