介绍

本文从理论上分析、梳理架构相关知识，帮助自己更好的理解架构工作。

请添加图片描述

什么是架构和架构分类

什么是架构

关于架构的定义业界有太多不同的定义，但大同小异、本质趋同，只不过侧重各有不同，就以IEEE（电气和电子工程师协会）的定义来说：

架构描述了一个系统的基本组织结构，包含了组成系统的组件、组件之间的关系、组件与环境之间的关系，以及指导上述内容进行设计和演化的原则。

系统
组织起来完成一系列功能的组件集
组件
组件是一个系统模块化的某部分，从设计角度来理解组件其实就是一系列功能集的封装体。
环境
环境或上下文，指的是会地这个系统的开发、运行等造成影响的环境和设置，比如：政策法规、软硬件环境等，是一些软件系统之外的因素。

透过一个系统的架构可以看到它是怎么组成的，有哪些部分组成，它们之间的相互关系是怎样。组件之间的关系其实指的是那些功能集之间的关系，比如说依赖、调用和扩展等关系，还有组件与环境之间的关系，比如说组件和环境怎样适应，这些都是架构应该包含的内容。

对架构的基本认识

架构定义了系统结构

对于我们做架构工作来说不会去关注具体实现，而是着眼于高层结构上，高层结构可以理解成粗略的、概要的、轮廓性的结构。比如说一个系统分成五个子系统，每个子系统里面又分成三大块，以及它们之间的关系，谁又调用了谁，谁又依赖了谁等关系。

架构定义了行为

这里撰述的行为其实就是组件之间的关系，也就是一些交互行为，包含了组件之间、环境之间的关系。

架构关注系统的主要元素

一般来说做架构工作时不关注具体细节，只关注主要组件，从业务角度来讲就是用户关注的难点功能，或者是有特色、亮点的功能。另外比如说高可用、高性能的因素。这些元素是做架构设计特别关注的工作。

架构要平衡系统利益相关者的需要

所谓系统利益相关者，指的是对这个系统感兴趣，或者与这个系统有关系的人、团队或组织。通常不同的相关者关注点肯定是不相同的，把这些总结起来其实就代表着这个系统的质量或约束，那对于架构师而言，这些往往是最重要的需求。利益相关者并不只是与你聊需求的客户，事实上这个范围会比较广，比如说客户方的老板，他是直接出钱的，虽然他不直接用这个系统。

架构基于合理的证据使决策具体化

为什么要用这种架构形式来实现，这肯定要有一个决策过程，对于这个不能拍脑袋来决定。我们要通过调研掌握一些确切的证据，这些证据可能来源于同类产品的参考，来自以前的经验，已经证明这样做是可行的，或者来自于自己demo的实际测试等等。总之要有一些证据来说明你的决策是透明、可行的。

架构会受到环境的影响

环境决定了系统必须在其中运行的范围，从而来影响架构。影响架构的环境因素有，架构支持的业务因素，系统的利益相关者，还有内部的技术约束，比如公司内的一些开发规范，以及外部的技术约束。还比如有行业内的一些技术规范、性能要求等。

架构会影响开发团队结构

比如说我们已经决定采用微服务架构，接下来会把开发团队拆分成各个小组，即一个大团队拆分成小团队，可能某两、三个人负责一个或几个服务开发工作，很明显是架构形式改变了团队结构。

架构分类

没有统一标准

事实上业界对架构并没有统一的分类标准，我们也看过很多架构分类方式，总结起来大体有这样一些。

有按实现层次划分的、有按关注方向划分的，有按软工阶段划分的，有按视图类型划分的，有按技术实现风格划分的等等，这些分类有很多是交叉重叠的。

按实现层次划分
1. 移动架构：在移动端这边的架构，从早期MVC架构形式到MVP，MVVM，MVC等等架构形式。虽然这些架构形式在不断变化，但是对于它的本质一直是没有变的，对于MVX系列的设计它的本质都是关注点分离，还有做高内聚，低耦合，基本都是围绕这个思路在演化架构的形式。
2. 前端架构：不管是android、IOS，H5还是微信小程序统称大前端，它的架构形式有相似之处，一般来说会为前端专门做一个后端来公用，也就是它的支撑能力同时满足多端需要。
3. 系统架构
- 应用架构：完整系统组成结构，比如说把这个系统分成几个部分，每个部分都干些什么事情，然后把每个功能进行细分，最后把整个系统功能分成逻辑功能模块，并且看起来是科学、合理的，那这个组成起来就是业务上的系统架构。
- 技术架构：从技术方向上来看，主要是技术层面的东西来描述系统。比如说做一个单体应用架构还是一个分布式应用架构，亦或是一个微服务架构等等，还有包含分层模型、领域驱动模型（DDD），比如说做表现层、应用层、持久层，甚至加入缓存层、静态资源层等。包括每一层具体使用哪些技术框架，比如是spring、hibernate、springmvc，使用哪些成熟的类库，中间件等等。当然还要考虑到系统如何去部署，如何支持分布式，如何实现高可用、高稳定性、健壮性和高性能，包含能够灵活扩展、安全性等等一系列问题。这些问题全部都放在技术架构方案里面，这个也是我们未来做架构设计一个非常重要的方向。
1. 平台架构：指在实现一个业务系统采用的基础平台，一般来说平台架构和业务是无关的，是可重用的部分，可以是第三方开源或商用的，也可以是公司自建的平台。例如做微服务可选的是spring boot + spring cloud这一套。
2. 应用集成架构：指如何集成第三方或遗留系统，具体以怎样的形式去做，要有一套自己的调用机制，比如通讯方式等等。
3. 数据库架构：库表、还有表之间的关系，库该如何拆分，要不要集群，几主几从等。
4. 存储架构：数据介质选择，存在哪个地方，灾备机制
5. 网络架构：网络设备、广域网如何接入等
按关注方向划分
1. 业务架构：指支撑业务的技术架构，要从业务和商业的角度看。
2. 应用架构
3. 技术架构
4. 开发架构：从具体的实现角度来看，比如选用什么样的框架，代码规范等
5. 数据库架构
6. 存储架构
7. 安全架构：基础设施安全，防火墙，应用系统安全，数据安全，防重放机制，传输安全
8. 部署架构：应用开发完之后发布到哪几台机器上，比如这台放应用，那台放数据库等等
9. 开放架构：OpenAPI架构，比如百度、京东、天猫的开放接口
按软工阶段划分
1. 解决方案架构：在项目立项初期跟客户进行浅层次交流的时候，我们可能根据用户关注的问题输出一些解决方案，主要是一些概要性的架构设计，或者是根据用户关注的技术点做的一些设计。
2. 业务架构
3. 系统架构
4. 概念架构：是指组件及其之间的交互，那么这些构成的就是概念架构，通常不涉及接口细节。
5. 细化架构：就是对概念架构进行细化，细化到具体的模块、功能和接口，甚至是具体的实现类上，那么一层一层的把概念架构落地。
6. 平台架构
7. 开发架构
8. 部署架构
9. 运维架构：实际上是从运维的角度来看，我不仅仅知道你要部署到多少台机器上，还要对这些东西进行监控、管理，比如重启、替换和数据迁移等工作。
按视图类型划分
1. 逻辑架构：对整个系统进行每一级的划分，然后划分子系统、模块和组件，以及定义接口相互之间的关系。
2. 数据架构：与数据库架构略微有一点不同，它关注数据的存储、分布、访问以及数据本身的安全等等，包括未来数据怎样备份、扩容。
3. 开发架构
4. 运行架构：考虑系统在运行期间的一些质量属性，比如说性能怎么样，可伸缩性怎么样，持续可用、易用性，运行起来的线程数，对资源的消耗，包括并发、同步和通讯问题。
5. 物理架构
按技术实现风格划分
1. 分布式架构：通过业务分散，远程调用的一种形式
2. 分层架构：现在纯粹分层已经很少用了，但是我们在某一个功能块里面还是会用到，比如说分表现层、数据层
3. 事件驱动架构：纯粹的事件驱动也比较少见，可能会在复杂的架构中有一部分看到事件驱动这种方式。
4. 微内核架构
5. 微服务架构：把功能包装成一个一个微服务，当然这个需要对功能进行合理的划分，这个拆分要合理，每个服务相对独立，向外去提供功能。
6. SOA架构
7. 响应式架构

什么是架构设计和功能设计

什么是架构设计

软件架构设计指的是：对一个软件系统进行的架构定义、文档编写、维护和改进、并验证实现的一系列活动，架构设计的产物就是一个系统的架构。

对架构设计的基本认识

架构设计是一门尚不成熟的科学
对架构设计来讲是一门科学，这点在业界是一种基本的共识。但是作为一门科学来讲，它应该要有自己完善的基础理论，基础方法，具体的实现方法论。所以从这个角度来说，架构设计作为一门科学确实还不太成熟。因为从业界来看它的基础体系是不完善的，方法论上百花齐放，有这样或那样做，其实大家都还处于一个探索阶段。
如果从科学角度来看，架构设计主要关注架构设计过程中的技术、流程、资源以及如何去完善并改进架构。
架构设计是一门艺术，需要一定的创造力
除了前面提到架构设计是一门科学，再加上技术更新太快，发现每一年在业界都会出很多的新技术，新的东西太多、太快。总会面临很多新型的没有先例的系统，可以用新的技术、框架和解决方案来做同样的事情，因此在做架构设计时是需要一定的创造力的。
架构设计是一系列的活动，是不断演化和完善的过程
架构设计不是一上来就做的特别好，它不是一蹉而就的。通常情况下它也是由粗到精，逐步完善和细化的一个过程。在做的过程中也和软工一样，也有一个粗的架构设计，然后就开始来迭代并逐步推进去完善的。
架构设计跨越软工的全流程
通常架构设计是要跨越软工的全部流程，重大的项目立项前期就要参与进来，便于提前做架构的规划。一是要评估能不能搞定这个事？二是按照这个思路下去成本大概有多大？那么在立项时架构师就得去考虑，你的成本、投资收益等。
在实现阶段也需要参与进去，要把你的设计完整的、具体的向开发人员讲清楚，你的理念和思路，以确保大家按照并理解你的设计，并且按照设计与完成而不会走偏。
架构设计需要不断的决策、不断进行平衡
只要是做过架构设计工作就会比较有体会，因为一个系统关注的方方面面实在是太多，利益相关者太多，大家关注点不同，这也就意味着我们在做设计过程中不断的判断且做决策。比如说为了满足什么而要用什么样的技术，这个时候你需要在其中不断的折衷平衡。
举个例子就拿关注成本和性能来说，业务方老板关注这个项目要用多少钱，软件公司老板关注安排多少人做多少天事情，它需要你的架构。
架构设计是系统利益相关者的共识
必须考虑到各个利益相关者的关注点

什么是功能设计

通常指的是：针对架构设计后要具体设计的每部分所进行的设计，包括设计这部分实现的整体结构、划分子功能模块、确定每个模块的实现算法、对外提供的接口等，从而形成的具体实现的设计方案。

对功能设计的认识

与架构设计是互补的关系，架构设计关注高层和整体，而功能设计更关注实现和落地
通常我们去做一个系统的功能设计，除了做架构设计也要做功能设计，如果要做一个合格架构师而不是一个PPT架构师，前面两者设计都要做。
从某种意义上来讲，功能设计可以大到一个软件系统，小到某一个具体功能的设计。
如果你这个系统非常非常庞大，把整个系统分成了几十个微服务，而每个微服务就是独立的工程，独立的软件系统，这完全没有问题。
大到一个软件系统的功能设计，就类似是软件设计
小到某一个具体功能的设计，可以看作是对一些重难点功能进行的详细设计
由于具体的功能多种多样，因此进行好的功能设计需要较强的设计技巧和功力
功能设计认同好的设计经验、最佳实践、设计模式等的复用

什么是架构师、架构师主要干什么

什么是架构师

架构师是：负责系统架构设计的人、团队或组织

概述架构师主要干什么

架构师是技术领导，领导并负责架构设计，负责做决策。
架构师可以是团队或组织，这个时候通常会有首席架构师。
架构师必须掌握足够的技术知识
架构师必须掌握足够的架构设计技能
架构师必须具备很好的编程能力，实际参与架构原型的设计和开发实现。
架构师必须深入理解业务及业务领域的知识，让架构更好支持业务目标。
架构师应该具备很好的沟通能力，讲解架构、指导开发、协调冲突等。
架构师必须了解软件过程，为项目全流程提供支持

架构、架构设计和架构师三个核心概念的关系

三个核心概念的关系

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nZXIPcdy-1675527568180)(/images/三个核心概念的关系.png)]

架构设计相关术语的元模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-O3RI6rym-1675527568180)(/images/架构设计相关术语的元模型.png)]

如何衡量架构优劣

对于架构的评价没有统一、客观的标准
所谓适合的才是最好的，遵循实践是检验真理的唯一标准，大致有如下一些衡量因素。
- 功能性：一定要满足用户真实的功能需求
- 可用性
- 可靠性
- 健壮性
- 高效率
- 可伸缩
- 可维护
- 可扩展
- 可重用
- 易理解
- 易开发
- 可测试
- 可监测
- 可管理
- 兼容性
- 可移植
- 可替换
- 容灾性
- 价格有效性