架构

架构满足了应用程序的非功能性需求:可维护性、可测试下、可扩展性、可部署性等。

软件架构的最高优先级是保持系统正常工作,软件架构的策略就是京可能长时间保留尽可能多的可选项

架构是什么

开发

一个软件系统的开发,应该就是要方便其开发团队

一个系统的架构,反映了开发该系统的团队组织结构

部署

良好的软件结构可以让系统构建完成就能部署,同时实现一键式的轻松部署是设计软件架构的一个目标

运行

设计良好的架构能明确地反映出系统运行时的需求

架构是系统运行时的一个表示

维护

维护的主要成本

保持可选项

用例:对系统如何响应外接请求的描述

软件系统可降解为

在大部分时间,无法预知系统的所有用例,越晚决定实现细节,就能掌握更多信息,更有利于决策

设备无关性

高层策略与低层实现细节分离

解耦

系统可以被按层解耦,将不同层隔离开来,避免变化扩散到其他层

当对用例进行分组时,增加新用例就会对旧的用例影响降低

解耦模式

软件架构是生长的,从单体到相互独立可部署单元,再到服务化

设计良好的架构应该允许软件系统从单体到服务,也可以从服务退化到单体

重复

重复需要分清表面重复还是实际重复,随着软件的演进,两段重复的代码可能会变得不同

独立性

分类

基础架构

中间件与大数据架构

业务系统架构

这些不同分类的架构界限不是很清晰 随着时间演进 各个类型之间的系统边界会互相渗透

架构视图

绘图原则4R:

四加一

4+1视图

业务架构图

描述系统对用户提供了什么业务功能

2022511135653

前端架构图

描述客户端和前端的领域逻辑架构

2022511135951

系统架构图

描述后端的逻辑架构

用来表示系统角色 用来表示角色之间的关系

应用架构图

跟系统架构图很像,唯一需要注意的点就是复杂系统分域来画

202251114521

部署架构图

描述后端系统具体是如何部署的

202251114630

系统序列图

描述某个业务场景下,系统各个角色如何配合起来完成业务功能

202251114746

架构立方体

架构体系框架

架构的演进

站在后端开发人员的角度上软件架构风格从大型机(Mainframe),到原始分布式(Distributed),到大型单体(Monolithic),到面向服务(Service-Oriented),到微服务(Microservices),到服务网格(Service Mesh),到无服务(Serverless)

谈起微服务,会想到技术异构,便于部署,高性能等等,但这些似乎都只是锦上添花,架构的核心在于解决软件的存活问题,如果一个软件压根就不能提供服务,这些锦上添花的功能也毫无作用

架构认知派别

组成派

架构由 模块/服务/领域 组成

本质在描述组件与组件之间的交互(画各种架构图)

决策派

软件架构由一个个决策组成的有机整体(把架构比作城市规划)

每个做的决策都有它背后的原因

架构的目标

用最小的人力成本来满足构建和维护该系统的需求,主要目的是为了解决软件系统复杂度带来的问题

复杂性的来源:

在乱麻系统下工作,过度的自信导致软件维护成本持续上升

软件的两个价值:

维护架构价值,是研发人员所需要进行斗争的

架构的意义

项目干系人交流的手段

语境不同、立场不同、渠道问题等导致的语义失真 所以使用架构作为手段沟通

架构演进有助于原型的确定与设计

早期设计决策的体现

如果做架构决策:

明确系统实现的约束条件

202191322132

RAID矩阵:

- Risk Assumption Issue Dependency
决策1
决策2
决策3

是组织架构的反映 会影响组织架构

是可复用、可传递的模型

架构可复用的内容一般都是比较少的,每个项目的架构肯定不能照搬 需要裁剪

为了复用,需要对架构资产进行更新与保留,拥有一个知识传承的平台

实现细节

数据库

web

应用程序框架

架构边界

边界划分

软件架构设计就是一门划分边界的艺术

为了划分划分边界线,软件系统被分割成组件,这些组件的一部分是核心的业务相关组件,另一部分是非核心的但是是提供必要功能的组件,让这些非核心组件去依赖系统的核心组件

通过划清边界,可以推迟一些细节性的决策

何时何地划分

IO是无关紧要的,软件系统的核心,是业务逻辑

插件式架构

软件开发技术发展的历史就是如何想方设法增加插件,这些插件要么可以去掉,要么要多种实现

跨边界调用

边界线一侧的函数调用另外一侧的函数

边界形式

单向边界

设计架构时,往往需要使用反向接口来维护边界两侧组件的隔离性

202002031612

边界与层次

作为架构师,需要考虑:

同时,设计边界需要深思熟虑,过度的工程设计往往比工程设计不足还要糟糕

策略与层次

本质上,软件系统是一组策略语句的集合

软件架构的重点之一,是将策略彼此分离

直接管理IO的策略,层次是最低的

当源码依赖方向统一调整低层指向高层策略,可以大幅度降低系统变更带来的影响

业务逻辑

业务逻辑就是系统中真正用于赚钱或者省钱的过程,这些过程被称为关键业务逻辑,关键业务逻辑通常会处理一些数据,这些数据叫做关键业务数据,关键业务逻辑与关键业务数据通常是紧密相连的,所以将他们两个放在一起,这种对象称之为业务实体

用例

请求和响应模型

对用例的输入输出对象,应该保持独立

COLA

扩展设计

在系统设计时,针对业务或者场景预留一些扩展点

整洁架构

许多架构都是按照不同关注点对软件进行切割

特点

依赖关系规则

202002031554

谦卑对象

谦卑对象模式是让单元测试的编写者区分容易测试的行为与难以测试的行为

一个优秀的架构,应该拥有强大的可测试性

Main组件

系统中,至少需要一个组件来负责创建、协调、监督其他组件,这个组件称为Main组件

Main组件是系统中细节信息最多的组件,即Main组件是一个底层模块,处于架构圈的外层

测试

测试组件,可以视为最外圈的最外圈程序

可测试设计

脆弱的测试问题

不良的测试设计,会导致一个对通用组件的修改产生许多测试错误

解决方法就是测试不要依赖于多变的东西

整洁的嵌入式架构

固件程序也可以指针对具体平台的编码

程序适用测试

仅仅停留在让代码能跑起来的阶段

架构的未来

具体技术下的架构

使用传统的分层,打成一个jar包 运行它

20201027154734

高可用 高性能等需求使我们不得不对系统进行拆分,在前面的单体架构下,分成多个工程 业务代码与服务基础设施代码耦合在一起 构成了传统的微服务,也是目前最流行的架构

20201027154755

在传统的微服务下,基础设施代码与业务代码耦合在一起,这个阶段下使用了K8S的容器基础设施来完成大部分服务治理功能,应用程序可以更专注我们的业务

20201027154819

K8S将服务治理沉淀到基础设施只是第一步,接下来服务网格将这事做的更加彻底,更加可管理 可观测

20201027154819

上传代码,某些事件会触发你的代码运行它,彻底不用管理基础设施,一切交给云