介绍架构分类、设计及架构师工作

介绍

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

什么是架构和架构分类

什么是架构

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

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

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

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

对架构的基本认识

架构定义了系统结构

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

架构定义了行为

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

架构关注系统的主要元素

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

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

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

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

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

架构会受到环境的影响

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

架构会影响开发团队结构

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

架构分类

没有统一标准

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

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

  • 按实现层次划分
    1. 移动架构:在移动端这边的架构,从早期MVC架构形式到MVP,MVVM,MVC等等架构形式。虽然这些架构形式在不断变化,但是对于它的本质一直是没有变的,对于MVX系列的设计它的本质都是关注点分离,还有做高内聚,低耦合,基本都是围绕这个思路在演化架构的形式。
    2. 前端架构:不管是android、IOS,H5还是微信小程序统称大前端,它的架构形式有相似之处,一般来说会为前端专门做一个后端来公用,也就是它的支撑能力同时满足多端需要。
    3. 系统架构
      • 应用架构:完整系统组成结构,比如说把这个系统分成几个部分,每个部分都干些什么事情,然后把每个功能进行细分,最后把整个系统功能分成逻辑功能模块,并且看起来是科学、合理 的,那这个组成起来就是业务上的系统架构。
      • 技术架构:从技术方向上来看,主要是技术层面的东西来描述系统。比如说做一个单体应用架构还是一个分布式应用架构,亦或是一个微服务架构等等,还有包含分层模型、领域驱动模型(DDD),比如说做表现层、应用层、持久层,甚至加入缓存层、静态资源层等。包括每一层具体使用哪些技术框架,比如是spring、hibernate、springmvc,使用哪些成熟的类库,中间件等等。当然还要考虑到系统如何去部署,如何支持分布式,如何实现高可用、高稳定性、健壮性和高性能,包含能够灵活扩展、安全性等等一系列问题。这些问题全部都放在技术架构方案里面,这个也是我们未来做架构设计一个非常重要的方向。
    4. 平台架构:指在实现一个业务系统采用的基础平台,一般来说平台架构和业务是无关的,是可重用的部分,可以是第三方开源或商用的,也可以是公司自建的平台。例如做微服务可选的是spring boot + spring cloud这一套。
    5. 应用集成架构:指如何集成第三方或遗留系统,具体以怎样的形式去做,要有一套自己的调用机制,比如通讯方式等等。
    6. 数据库架构:库表、还有表之间的关系,库该如何拆分,要不要集群,几主几从等。
    7. 存储架构:数据介质选择,存在哪个地方,灾备机制
    8. 网络架构:网络设备、广域网如何接入等
  • 按关注方向划分
    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架构师,前面两者设计都要做。
  • 从某种意义上来讲,功能设计可以大到一个软件系统,小到某一个具体功能的设计。
    如果你这个系统非常非常庞大,把整个系统分成了几十个微服务,而每个微服务就是独立的工程,独立的软件系统,这完全没有问题。
  • 大到一个软件系统的功能设计,就类似是软件设计
  • 小到某一个具体功能的设计,可以看作是对一些重难点功能进行的详细设计
  • 由于具体的功能多种多样,因此进行好的功能设计需要较强的设计技巧和功力
  • 功能设计认同好的设计经验、最佳实践、设计模式等的复用

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

什么是架构师

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

概述架构师主要干什么

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

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

三个核心概念的关系

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

如何衡量架构优劣

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