.NET 云原生架构师训练营（模块一 架构师与云原生）--学习笔记

目录

• 什么是软件架构
• 软件架构的基本思路
• 单体向分布式演进、云原生、技术中台

1.1 什么是软件架构

1.1.1 什么是架构？

Software architecture = {Elements, Forms, Rationale/Constraints}

元素、形式/模式、基本原理和限制

为何须要软件架构？

软件架构的终极目标是用最小的人力成原本知足构建和维护系统的需求

一个软件架构的优劣，能够用它知足用户需求的成原本衡量。若是该成本很低，而且在系统的整个生命周期内一直都维持这样的低成本，那么这个系统的设计就是优良的，若是该系统的每次发布都会提高下一次变动的成本，那么这个设计就是很差的，就这么简单。

--架构整洁之道

产品经理

• 需求分析
• 需求设计
• 项目管理
• 产品运营

1.1.2 什么是架构师？

系统的维度

负责总体系统的架构设计，主要是基础服务和各系统间的协调上，着眼全局不太注重某个应用自己架构，好比关注服务器负载，可靠性，伸缩，扩展，数据库切分，缓存应用等方法的基础架构设计

应用程序的维度

负责某个应用的技术架构，主要偏业务系统，关注理解业务，梳理模型，设计模式，接口，数据交互等方面

业务流程的维度

关注某一个行业、业务的领域分析，获取领域模型，最终得到系统的模型

也能够叫业务领域专家、行业专家、产品咨询师、资深顾问

下降成本

经过设计和实现优良的软件架构来持续下降软件的构建和维护成本

软件架构这项工做的实质就是规划如何将系统拆分红组件，并安排好组件之间的排列关系以及组件之间互相通讯的方式

如何下降成本？

• 低成本维护（容易被改动和理解）
• 软件可复用
• 轻松部署

设计原则会给咱们答案

软件架构师的目标是建立一种系统形态，该形态会以策略为最基本的元素，并让细节与策略脱离关系，一个优秀的软件架构师应该致力于最大化可选项数量

职能

1. 负责公司系统架构设计、研发工做
2. 承担从业务向技术转换的桥梁做用
3. 协做项目经理制定项目计划和控制项目进度
4. 负责辅助并指导 SA 开展设计工做
5. 负责组织技术研究和攻关工做
6. 负责组织和管理公司内部的技术培训工做
7. 负责组织及带领公司内部员工研究与项目相关的新技术
8. 管理技术支撑团队并给项目、产品开发实施团队提供技术保障
9. 理解系统的业务需求，制定系统的总体框架（包括：技术框架和业务框架）
10. 对系统框架相关技术和业务进行培训，指导开发人员开发
11. 解决系统开发、运行中出现的各类问题
12. 对系统的重用、扩展、安全、性能、伸缩性、简洁等作系统级的把握

软件周期内，标准组织架构下的各个职位的分工

• CEO
• CTO/CIO
• 产品总监/技术总监/架构师 Architect Director
• 资深开发/Manager
• 高级开发/Leader

1.1.3 软件架构分类

从架构师的工做内容上来划分能够分为三类：

• 系统架构师
• 应用架构师
• 业务架构师

系统架构师/基础架构师

从系统的维度，负责总体系统的架构设计，主要是基础服务和各系统间协调上，着眼全局不太注重某个应用自己架构，好比关注服务器负载，可靠性，伸缩，扩展，数据库切分，缓存应用等方面的基础架构设计。

应用架构师

从应用程序的维度，负责某个应用的技术架构，主要偏业务系统，关注理解业务，梳理模型，设计模式，接口，数据交互等方面。

业务架构师

从业务流程的维度，关注某一个行业、业务的领域分析，获取领域模型，最终得到系统的模型。也能够叫业务领域专家、行业专家、产品咨询师、资深顾问。

基础架构、前端架构、后端架构是从职责上的分类。

.NET云原生架构师训练营讲什么，怎么讲，讲多久

https://mp.weixin.qq.com/s/JWOIScGrX0Hszz4uqdA6qw

1.1.4 架构风格

• 分层架构
• 微核架构/六边形架构/简洁架构
• 事件驱动架构
• 微服务架构
• 云架构

软件架构入门

http://www.ruanyifeng.com/blog/2016/09/software-architecture.html

1.2 软件架构的基本思路

1.2.1 如何理解需求

软件需求（第3版）

https://book.douban.com/subject/26307910/

需求分类

1.2.2 非功能性需求

• 观感需求
• 易用性：性能/可用性
• 可扩展性
• 可维护性

1.2.3 4+1模型

• 场景视图
• 逻辑视图
• 开发视图
• 处理视图
• 物理视图

1.2.4 场景视图

• 用户能够开设一个训练营成为营长
• 营长能够制定训练营学生的任务和计划，能够快速利用到其余训练营
• 营长能够邀请其余用户加入训练营成为学员
• 营长能够对学员进行分组
• 营长能够添加指定学员成为助教并指定到分组
• 学员能够接受邀请加入训练营成为学员
• 学员加入训练营以后能够完成训练营内的任务
• 学员能够对训练营内的指定问题进行提问
• 学员能够查看本身的学员档案
• 营长/助教能够回答学员提出的问题
• 营长/助教能够对学员完成的任务进行考评打分

1.2.5 逻辑视图

面向对象分解

用来支持功能性需求、系统应该被拆分为哪些问题域、对象

1.2.6 开发视图

关注软件模块组织和开发环境上、从组件、模块、子系统的组织和分层

每一层为上层提供有限的良好定义的接口供调用

• 团队结构
• 开发流程
• 测试计划
• 项目协做工具
• Road Map 发布计划

1.2.7 处理视图

关注进程、线程、对象等运行的概念，以及相关的并发、同步、通讯等问题

从软件实现的角度去关注非功能性需求

单体

分布式

2.8 物理视图

从硬件角度去关注非功能属性

单体

分布式

1.3 单体向分布式演进、云原生、技术中台

1.3.1 单体的问题

• 巨大的代码库
• 过载的 IDE
• 过载的 WEB 容器
• 持续部署困难
• 应用扩展困难
• 难于进行规模化开发

模式: 单体架构

https://microservices.io/patterns/cn/monolithic.html

1.3.2 高可用架构

系统设计

• 故障转移
• 超时控制
• 降级和限流

系统运维

• 灰度发布
• 故障演练

故障转移

彻底对等的节点之间作故障转移

在对等节点之间作故障转移，相对来讲简单些

在这类系统中全部节点都承担读写流量，而且节点中不保存状态，每一个节点均可以做为另外一个节点的镜像

不对等的节点之间，即系统中存在主节点也存在备节点

使用最普遍的故障检测机制是“心跳”

你能够在客户端上按期地向主节点发送心跳包，也能够从备份节点上按期发送心跳包

当一段时间内未收到心跳包，就能够认为主节点已经发生故障，能够触发选主操做

超时/降级/限流

数据库访问超时、rpc/远程调用超时、缓存/队列等其余中间件访问超时

探测出系统或者服务单位内容许出现的最大请求，直接拒绝后面的请求

水平/垂直扩展

水平（也叫横向扩展）：用更多的节点支撑更大的请求

如成千上万的蚂蚁完成一项搬运工做

垂直（也叫纵向扩展）：扩展一个点的能力支撑更大的请求

如利用一我的的能力，如蜘蛛侠逼停火车

AKF 扩展立方

X 轴：表明无差异的克隆服务和数据，工做能够很均匀的分散在不一样的服务实例上

Y 轴：关注应用中职责的划分，好比数据类型，交易执行类型的划分

Z 轴：关注服务和数据的优先级划分，如分地域划分

业务模块化打造单体和分布式部署同步支持方案

https://mp.weixin.qq.com/s/HE7BxH_RZo45bY2baNgt5Q

模块拆分原则

• 微服务拆分的大部份原则依旧适用
• 一个业务模块对应一个数据库，不能直接查另外一个业务模块的数据库
• 模块之间的调用经过抽象契约接口来完成
• 模块之间互相依赖只能依赖于抽象契约

1.3.3 云原生

什么是云原生

云原生技术有利于各组织再公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用

云原生的表明技术包括容器、微服务、服务网络、不可变基础设施和声明式 API

这些技术可让咱们构建高度稳定、可控、可观测的松散耦合应用

但云原生方案的重点并非应用部署在何处，而是如何构建、部署和管理应用

关键点

• 不可变基础设施
• 12 因素：https://12factor.net/zh_cn/

12 因素

1. 基准代码：基准代码和应用之间老是保持一一对应的关系：

• 一旦有多个基准代码，就不能称为一个应用，而是一个分布式系统。分布式系统中的每个组件都是一个应用，每个应用能够分别使用 12因素 进行开发
• 多个应用共享一份基准代码是有悖于 12因素 原则的。解决方案就是将共享的代码拆分为独立的类库，而后使用 依赖管理 策略去加载它们

1. 显示声明依赖
2. 配置：推荐将配置保存于环境变量中
3. 把后端服务看成附加资源
4. 严格分享构建和运行
5. 以一个或多个无状态进程运行应用
6. 经过端口绑定提供服务：12因素 应用彻底自我加载，而不依赖于任何网络服务就能够建立一个面向网络的服务。互联网应用经过端口绑定来提供服务，并监听发送至该端口的请求
7. 经过进程模型进行扩展
8. 快速启动和优雅终止可最大化健壮性
9. 尽量的保持开发，预发布，线上环境相同
10. 把日志看成事件流
11. 后台管理任务看成一次性进程运行

云原生 VS 微服务

云原生方案与微服务架构相似

然而，尽管微服务可经过构建云原生应用来交付，可企业仍须要采起许多措施，才能在生产环境中熟练地管理微服务

而想要享受云原生应用的各类益处，也并不是必定须要微服务

不少企业都经过基于相同的原则，构建出更优秀的模块化单体式应用，从而取得云原生方案的种种效益

1.3.4 技术中台