第02课:深入剖析架构师角色

第02课:深入剖析架构师角色

什么是系统架构设计:关于架构演进理论

在过去软件开发过程发展的很长一段时间内,软件架构表现为一种集中式的单块(Monolithic)式,即先对系统进行分层,然后通过单个进程进行部署和维护,典型的分层体系包括界面交互层、业务逻辑层和数据访问层。直至今日,这种单块模式在部分系统构建过程中仍然是最基本的架构模式。

随着业务功能的不断发展以及性能、数据存储等系统瓶颈问题的出现,单块模块逐渐不适合系统的维护和扩展,分布式架构应运而生。通过把系统业务进行服务化,以及完善服务治理功能,系统架构就可以如同搭建积木一样构建成高度可集成、高内聚松耦合的业务系统,如下图中系统主体由 Frontend-Service 和 Core-Service 两层服务化构成,为 Web 层提供网关和核心业务服务。

服务化架构为系统提供了扩展性和伸缩性,然而随着系统用户体量的增加以及分布式系统固有的网络通信机制,性能问题在业务关键链路逐渐成为系统运行的瓶颈。解决性能问题的切入点有很多,一方面可以从硬件设备和软件服务器入手,但对系统架构而言,更多的场合需要我们分析系统实现方案,并使用以缓存为代表的架构设计手段重构业务关键链路,下图即为在 Frontend-Service 和 Core-Service 两层服务中分别添加分布式缓存之后所得到的系统部署图。

缓存能够提升性能,但不能解耦系统。当系统中分布式服务数量和种类日渐增多,而这些服务又分别属于不同业务层次时,如何合理的管理这些服务之间的调用关系,进一步确保系统的健壮性和扩展性成为系统架构设计的又一大难题。分布式服务的自身特征决定了其在时间、空间和技术上都具有一定程度的系统耦合性,在使用分布式服务时需要谨慎处理服务调用的时序、所使用的服务定义以及技术平台的差异性等问题,这些问题为如何开展快速架构重构和扩展、如何进行高效分布式团队协作带来了挑战。以各种消息传递组件为代表的中间件系统为降低系统耦合性、屏蔽技术平台差异性带来了新的思路。当不同的服务需要进行交互、但又不需要直接进行服务的定位、调用和管理时,消息中间件能显著降低系统的耦合程度,下图中在 Frontend-Service 和 Other-Service 中添加了消息传递中间件,确保两个服务在并不需要意识到对方存在的前提下进行数据的有效传输。

试想这样一种场景,我们的系统需要跟外部的多个系统进行集成以形成关键业务链路闭环管理,而这些外部系统分别部署在其他供应商或客户环境,并且每个系统都可能基于完全不同的技术平台和体系构建,随着业务发展需求,这些外部需求还需要实现动态的注册和注销。对系统架构设计而言,一方面我们需要整合这些外部系统提供的服务进行数据的获取和操作,另一方面,我们又不希望我们系统对它们产生强依赖。消息中间件在这种场景下已经失去系统解耦的价值,因为外部系统不在控制范围之内,我们对其内部实现原理一无所知。如何在异构系统、分布式服务和基于租户的基本架构需求下实现有效的系统集成,企业服务总线(Enterprise Service Bus,ESB)提供了相应的解决方案。通过在核心业务服务中引入 ESB 以及对应的路由、过滤、转换、端点等系统集成模式,即可屏蔽由于技术差异性导致的各种系统集成问题,并动态管理 ESB 上的第三方服务。如下图中,ESB 为内部的 Core-Service 整合外部的 Thirdparty-Service1 和 Thirdparty-Service2 提供了集成平台。

随着大数据时代到来,许多业务系统也面临着对庞大业务数据进行管理和利用的难题。近年来,以 Hadoop 生态圈为代表的大数据处理平台,以及以 Lucene 为内核的多种垂直化搜索引擎系统为业务发展提供了高效的批量数据处理和数据搜索功能。在系统架构设计维度,我们也可以引入如 Spring Batch、Spring Data 等轻量级的批处理和数据访问框架,以便与基于 Spring 的核心系统构建框架进行无缝整合,见下图。

上述的系统架构演进过程在现有的互联网应用中具有一定的代表性,很多 App 后台就是从一个简单的单块系统开始,当面临系统架构设计问题时,通过引入各种技术体系逐步完善架构,直至具备庞大体量的大型集群系统。在这个系统架构演进过程中,我们再来回答“什么是系统架构设计“这个问题时,我们可以认为系统架构设计就是在系统开发演化过程中,解决一系列问题的方法论和工程实践。关于方法论与工程实践的含义我们已经在上一篇中做了讨论。

关于架构师的几个常见的话题

在明确了架构设计的基本概念之后,我们将要进一步讨论架构师角色。围绕架构师角色存在如下几个常见的话题。

  • 架构设计到底是一种技术活还是业务活?
  • 架构师到底要做哪些工作?
  • 架构师到底是不是一个技术管理岗?
  • 架构师有哪些类型?
  • 架构师应该具备哪些技能和职责?

在本篇后续内容中,我们将对以上问题做一一解答。当然,如同前面给出的关于架构设计方面的定义,不同的公司、不同的行业和不同的时期对这些问题也是见仁见智,我们只是基于最普遍的场景给出适合我们自身的答案。

架构设计到底是一种技术活还是业务活?

在很多技术人员的眼中,架构设计可能就只是一种技术性的工作,很多公司在招聘架构师的时候也过多的关注了候选人的技术能力。事实上,在大型软件系统中,架构设计被认为是从问题领域到解决方案的一种桥梁(见下图),从图中我们可以看到架构设计活动与代表问题域的需求分析活动和代表解决域的软件开发活动都有直接的交集,连接着两个软件开发的核心领域。

架构师是架构设计的执行者,架构设计的桥梁作用给架构师带来了挑战,意味着架构师需要同时具备处理两个核心领域的能力,即架构师需要能够从问题领域出发推导出满足业务需求的架构体系,同时又能够从实现方法入手设计出能够满足业务架构需求的技术架构体系,最终实现业务架构和技术架构的统一。

架构师到底要做哪些工作?

架构师是负责设计、记录和领导能够满足所有干系人需求的系统构建过程的人。通常,这个角色需要完成以下几项活动。

  • 识别干系人并让他们参与进来

干系人是业务需求的源头,识别正确的干系人能够确保业务需求的正确性,让干系人参与能够确保业务需求的实时性和有效控制需求变更。

  • 理解和记录系统功能和非功能相关的关注点

通过需求分析,架构师梳理并抽象系统的各项功能性和非功能性需求,并对这些需求进行系统建模。

  • 创建并拥有应对这些关注点的架构定义

对功能性和非功能性需求,从扩展性(Extensibility)、性能(Performance)、可用性(Availability)、安全性(Security)、伸缩性(Scalability)等架构设计的基本维度出发定义架构,关于这些维度的讨论是下一篇的主要内容。

  • 在把架构实现为具体系统的过程中起主要作用

推动架构设计活动按照项目和产品计划有序进行,参与需求、设计评审等各种技术评审过程,并管理系统设计和开发团队的日常工作。

就一个完整的系统开发生命周期而言,架构设计活动有其时效性。下图体现了传统瀑布(Waterfall)模型下的系统开发生命周期与架构师参与情况,从图中可以看出在由需求分析和系统建模所构成的系统初始阶段和由服务集成和产品接受所构成的最后交付阶段,架构师会较多的参与到系统建设过程中去,具体参与程度取决于系统本身的特征以及生命周期模型。对于类似 Scrum 的敏捷开发模型,如果把一个个迭代看成是小型的 Water-Scrum-Fall 模型的话,架构师参与程度实际上也与上图所示的结果相类似,即重点参与迭代计划阶段和迭代演示回顾阶段。

架构师到底是不是一个技术管理岗?

很多时候,我们也把架构师归为是一种技术管理者角色。技术管理者的工作包括设计行业与解决方案、推进业务结构与产品化、架构设计和技术创新、开展软件项目管理和研发过程体系建设等。视环境的不同,架构师也会在这些工作中发挥一定的推动作用。

但就一个完整的产品开发生命周期而言,技术管理活动也具有其时效性,这种时效性相较于系统架构设计和实现等技术专业类活动而言还具有较大的灵活性。我们可以理解为系统开发生命周期是整个完整软件产品生命周期的一部分,如下图所示。在系统开发工作开展之前,技术管理者需要进行行业分析、技术解决方案的设计以及产品开发策略的规划,同时针对行业特点也可能会从事部分的技术预测工作。而在系统开发工作结束之后,随着产品和运营工作的开展,技术管理者也要深入其中从组织战略的角度出发对技术提出进一步的规划方案和创新措施。

架构师有哪些类型?

基于以上关于架构师的工作内容、参与程度和系统工程的分析,可以看到架构师根据其作用、职责和对系统关注层次的不同,可以分成很多类型。狭义上的架构师往往偏重于技术架构设计,但从广义上讲,业界对架构师的划分有一定的体系。首先,根据所发挥的核心作用,可以把架构师划分成设计型、救火型、布道型、极客型等类型。相较于传统意义上的设计型架构师,这些类型的架构师更加偏重于执行某一项特定的架构工作,并不一定会完整参与系统开发生命周期,更加不一定会从系统工程的角度去看问题。其次,产品型、基础设施型和应用型等架构师是从其所处的业务和职责出发进行分类的结果。产品型架构师偏重于进行业务架构设计,往往在系统开发前期会重点参与;基础设施型架构师偏重于进行技术基础框架设计,一般采用独立于系统开发生命周期的特有开发模式;常见的系统架构师指的是应用型架构师,正如前文所述,负责将问题领域进行建模并转变成解决方案。再次,根据关注层次的不同,架构师也可分为几种不同的类型,包括但不限于功能、非功能、团队组织和管理、产品运营等方面。

  • 应用设计型架构师

本课程所阐述的架构师角色从作用上讲限于应用设计型架构师,从职责上讲偏重于应用开发,并关注于功能、非功能、团队组织和管理等层次。这是行业内最常见的架构师类型,也是需求量最大的架构师类型。应用设计型架构师需要同时考虑业务架构和技术架构,从而实现业务架构和技术架构的统一。

  • 大数据架构师

现在是大数据时代,在大数据领域也存在大数据架构师这一细分岗位。大数据架构也只是一种架构,通用架构风格和架构模式、通用架构设计原则和维度同样适用。而且大数据架构肯定也是一种分布式架构,从技术体系上讲也存在很多通用的应用场景,例如 RPC 在Hadoop、Yarn、Storm 中的应用;高可用架构在 Hadoop、Yarn、HDFS 中的应用;Zookeeper 在 Hadoop、Kafka 中的应用;消息传递机制在 Spark、Storm 中的应用;加密、授权、认证等安全性机制在大数据体系中的应用等。以上关于 RPC、高可用架构、Zookeeper、消息传递机制等技术体系在本课程中都会讲到。我们在第 10 篇中也会提到技术体系的相通性,所以大数据架构师也是架构师的一种表现形式,在掌握架构设计原理和核心技术的同时需要掌握大数据生态相关工具和框架,并具备架构师应有的综合能力。

架构师的技能和职责

作为一名合格的架构师,完备的技术领域知识是必备的技能,但针对应用设计型架构师,所需的技能不仅仅限于了解和掌握技术体系,也需要从业务领域和软技能两个层面进行技能拓展。

  • 技术领域知识

架构设计相关的技术领域知识包括在上文中架构演进理论中提到过的分布式系统、缓存、消息中间件、企业服务总线、搜索引擎和批量数据处理等各种目前业务主流的技术体系,也包括软件架构体系结构中所蕴含的架构风格、架构模式和架构模型思想。

  • 业务领域知识

在应用程序开发过程中,业务架构驱动技术架构现象非常普遍。提升业务领域知识和提升技术领域知识一样,都对架构设计有直接的影响。从这个角度讲,架构师应该具备跨领域的技能。

  • 软技能

无论是传统型软件还是互联网应用,当前的开发模式已不再崇尚靠能力出众的个人来决定系统的产出,而是要靠团队。架构设计同样面临着项目计划同步、第三方服务集成、外部团队协作等团队性活动需求,很多场景下架构师需要与内部团队、外部团队统一协作才能设计出适合业务发展方向的系统架构。从这个角度讲,架构师应该具备跨团队的技能。

如果一名架构师具备以上能力,就可以从事架构设计工作。对于具体的工作内容,任何一名团队成员都应明确其职责并赋予相应的权力,架构师自然也不例外。架构师作为技术负责人,从问题领域出发进行抽象和建模并提供系统解决方案。同时,需要与过程管理人员进行合作,制定计划、分配资源、组建团队。最后,通过自身影响力和协作能力,保证项目按既定计划和成本完成。定义并记录系统的架构、构建和部署系统的策略、确保架构满足系统的质量属性、促进系统级别决定的产出、确保这些决定与干系人的期望一致、对架构方面的各项指标做平衡性的判断并确保达成一致意见等都是架构师的一些职责示例。

下篇导读

本篇深入剖析了架构师这一特定角色,并给出了架构师的工作职责、分类以及技能要求。在下一篇中,我们再来看一下架构设计相关的核心问题并讨论架构设计的层次、维度和视图。

上一篇
下一篇
目录