1.1 什么是软件架构

1.1.1 什么是架构？

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

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

为什么需要软件架构？

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

一个软件架构的优劣，可以用它满足用户需求的成本来衡量。如果该成本很低，并且在系统的整个生命周期内一直都维持这样的低成本，那么这个系统的设计就是优良的，如果该系统的每次发布都会提升下一次变更的成本，那么这个设计就是不好的，就这么简单。

--架构整洁之道

产品经理

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

1.1.2 什么是架构师？

系统的维度

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

应用程序的维度

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

业务流程的维度

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

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

降低成本

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

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

如何降低成本？

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

设计原则会给我们答案

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

职能

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

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 因素

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

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

云原生 VS 微服务

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

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

而想要享受云原生应用的各种益处，也并非一定需要微服务

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

1.3.4 技术中台

本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

欢迎转载、使用、重新发布，但务必保留文章署名郑子铭（包含链接： http://www.cnblogs.com/MingsonZheng/ ），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。

如有任何疑问，请与我联系 (MingsonZheng@outlook.com) 。

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

目录