用户您好!请先登录!

架构杂谈

架构杂谈

什么是架构

架构是针对某种特定目标系统的具有体系性的、普遍性的问题而提供的通用的解决方案,架构往往是对复杂形态的一种共性的体系抽象。

业务架构体系是针对企事业信息管理系统中具有体系的、普遍性的问题而提供的通用解决方案,更确切的说,是基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统,比如业务架构体系认为一个信息系统必须由组织机构、业务流程、业务信息、业务功能、和业务语义等层次构成。

复杂系统集成的关键,是基于架构(或体系)的集成,而不是基于部件(或组件)的集成。

在ISO/IEC 42010:20072中对架构有如下定义:

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

架构思维

大家谈起架构时的第一印象,就是各种各样的架构图,有一个高高在上的人,坐在那里,阔谈自己的理念。

诚然画图是架构师的一项日常工作,但通过一张图,来道出事物发展的本质,却是另外一种功夫。做了这么多年的程序员之后,如果只有打开了Idea才会思考架构,或者是敲起了Sql代码才会理解业务,细细想来,只能是自己的功夫不到,理解不透罢了。

架构的第一印象,不应该是多流行的技术,或者是多么高性能的框架,而是它能不能满足业务的需求,既不能跑不动,也不能太超前。

那么架构是什么?从理论上讲,它描述了系统中不同实体之间的抽象关系。抽象这件事其实很重要,因为你要跟一个软件工程师、或者是产品经理、或者是客户,来讲清楚某个复杂的商业模式,难度是非常高的。

这个时候,把商业模式来简化,抽象成一个个普通的“词汇”,让大家准确的理解,能够进行重新组合,生产力就爆发了出来。

再进一步,软件过程中的架构,就是两个目标:“降低系统的熵”、“支持快速扩展”。软件开发是一件多方合作的系统工程,功能越完善,系统的复杂度就越高,管理的难度越大,出现问题的概率就越高。

如何系统性的降低系统的认知负荷,就是在“降低系统的熵”,对于后续继续开发的人而言,生产力的提升就越高。但需求不会是一成不变的,理想的状态就像是云服务那样,不断扩容就能够解决一切问题。因此“组件化”、“微服务”等概念的不断涌现,也是在尝试为未来不确定的需求做扩展上的预留。

架构思维的核心,就是解决复杂性的问题,并在解决的过程中找到平衡点:既要简单又能满足发展。这种平衡的思维绝非一天两天能够练就的,生活中也处处存在:如何平衡生活与工作、如何平衡体重与食欲、如何平衡休息与学习… 无他,唯手熟尔。

系统分析

能够对业务有了深入的理解之后,下一步就是要进行系统分析,拆解业务的细节。系统分析有很多种方式,但总的来说,有两种最为常用:一种是“自底向上”,一种是“自顶向下”。

“自底向上”指先有具体的问题,然后通过分析来进行抽象。开发同学在日常的工作中,每天都要与各种各样的需求打交道,有一些是来自业务方的诉求,有一些是来自于脑暴,有一些是来自于常规功能迭代。那么这些需求细节来了之后,我们就需要开始抽象的过程,这是一个严密的推导过程,即业务建模 + 应用逻辑 = 系统架构。

业务建模通常需要对某个领域的知识积累,多搜集相关领域的业务知识,通过搭建业界通用的最小业务单元,一步步向上推导顶层结构,对于业务建模帮助很大。

另一部分就是应用逻辑,例如面向对象设计方法,提炼出可复用的模块及稳定的依赖关系,这部分取决于开发人员的经验积累。

“自顶向下”是指先有抽象的概念,再一步步拆解到具体的做法,这种推导方法依赖于“准确的定义问题”。通常而言,有这么几个阶段可以参考:准确提出问题 – 设想需求疑问 – 与需求方进行对话 – 提炼新的需求疑问 – 继续与需求方对话。

“脑子想得通,说话才能说通,说话说得通,做事才能做通。”

我们在设计架构的时候,通常都是直接从产品或者业务方面拿到的需求,在对问题进行逐层分解的过程中,有一些环节能够直接定义成技术问题,但总有一些特定的功能需求,是通过业务语言描述的,这部分需要进行重新对话确认后,转化为技术问题。

最终将一个大的需求,拆解成若干的技术子问题,完成架构的“自顶向下”推导。

架构设计

目前比较主流的企业架构理论是“TOGAF”,大约有80%的福布斯全球排名前50的公司在使用,国外有SAP、IBM、HP、Oracle等公司在推动。

TOGAF到底是个什么东西

整天幻想去阿里做数据架构,醒醒吧!你还有很多要学

用了理论指导,接下来就开始简述一下日常的工作流程:

  1. 设计工具:“工欲善其事,必先利其器。”架构如果没有工具来辅助思考的话,可太难了。在系统设计上,首推UML统一建模语言。UML最大的特点,就是对于不同的领域,其所采用的本质元素是相同的,大家能够基于共同的“模型”来理解业务、需求
  2. 需求分析:需求分析阶段,首先要进行“利益分析”,尤其是在面对多方向的业务方交付,就要抓住系统最主要的受益者,做好牵头的利益分配;其次做好“资源评估”,包括了人力和机器资源;再次整理“需求规范”,这一步是面向技术人员的,通过一系列的规范来保障开发人员的理解能够精准匹配业务方的需求。
  3. 模型建立:建模的目的是通过构造简单的模型,来替代复杂的业务现实。建模方法有很多种:领域驱动(DDD)、用例驱动(UDD)、四色建模法,等等。建模的过程让那个需要用到领域对应的知识,比如权限、人群、活动等,用于匹配具体的业务过程:授权、圈选人群、营销规则等。通过建模方法,对具体的领域知识进行消化,我们就可以输出最终的领域模型图。
  4. 架构输出:这一步主要包括了方案描述、设计约束、技术选型、系统结构、数据设计等部分。最终我们能够确定技术的大致架构类型,比如分层架构(MVC)、微服务架构、云原生架构等。

架构落地

大道至简的道理,浓缩成一条条原则,用于指导技术人员的日常开发设计,使我们不论面对多么复杂的软件系统,都能够处理的游刃有余,则是架构能够真正落地的基石。

大家日常所熟知的设计原则,也称之为SOLID原则,主要有五类:

  • 单一职责:改变类的原因只有一个。即每个类只做一种类型责任,当这个类有多个责任的时候,要将类分解
  • 开闭原则:对扩展开放,对修改关闭。
  • 里式替换:子类尽量不要覆盖父类的方法,子类可以扩展父类的功能,但不能改变父类原有的功能。
  • 接口隔离:使用多个专门的接口比使用单一的总接口要好。
  • 依赖倒置:高层模块不应该依赖于底层模块,而这都应该依赖于抽象,即抽象不应该依赖于细节,细节应该依赖于抽象。

权衡与学习

既需要满足未来的发展,又要避免过度设计。例如在数据开发中,实时的意思并不一定意味着一定要使用实时计算的框架,通过OLAP引擎提升查询速度,或者是15分钟/30分钟更新数据,同样能够满足大多数感官上的“实时计算”。

对于架构师而言,提升对于技术的思考能力,以及相应领域的解决方案理解,是最底层的能力,即便是纯框架,或者是纯架构相关的开发岗位,也越来越强调要贴近业务了。

在平时大量的业务开发过程中,最大的难点永远是两个:一个是逻辑的复杂性,一个是需求的变化性。很多时候,带着问题主动去思考,客户是谁?诉求是什么?有没有更好的方案?经过长时间的刻意训练,能力的提升也就是自然的事情了。

附:TOGAF

TOGAF 即 The Open Group Architecture Framework (开放组体系结构框架),是由致力于技术标准制定和推广的非盈利组织 The Open Group 制定的用于开发企业架构(Enterprise Architecture)的一套方法和工具

TOGAF 是一个架构框架,简而言之,是一种协助开发、验收、运行、使用和维护架构的工具。

它强调商业目标作为架构的驱动力,并提供了一个最佳实践的储藏库,其中包括:

  • TOGAF架构开发方法(ADM):ADM是一个可靠的,行之有效的方法,以发展能够满足商务需求的企业架构,它是TOGAF的关键。
  • TOGAF架构内容框架:提供了一个详细的架构工件模型,包括交付物、交付物的工件和架构构建块。
  • TOGAF参考模型:提供了两个参考模型,Technical Reference Model (TRM) 和Integrated Information Infrastructure Model (III-RM)
  • ADM指引和技术:提供应用ADM的一些指导(迭代、安全等)和技术(定义原则、业务场景、差距分析、迁移计划、风险管理等)
  • 企业连续统一体:EA 专业人员和涉众的资源库,例如,模型、解决方案模式,和其他可以在企业架构实现和裁减过程中用作构建块的资产。
  • TOGAF能力框架:一套资源、指导、模板、背景信息等等,帮助在组织中进行架构实践

更详细的,可以参见其官网及白皮书。

行走的code
行走的code

要发表评论,您必须先登录