专栏首页ThoughtWorks#TWer 好读书 读好书# 美丽的架构

#TWer 好读书 读好书# 美丽的架构

美丽的架构

文/张逸

美丽的架构究竟是怎样的?架构师们上下求索,孜孜以求,始终不得其解。归根结底,美丽这个词语总还是偏于感性认识,就仿佛音乐之美,绘画之美,不能以尺度来衡量,追求的其实是一种艺术的幽玄与妙悟,述之以规范,述之以标准,就未免落入下乘了。然而,软件架构终归属于工程学的范畴,不能一概以“只可意会不可言传”来搪塞,因为架构知识是可以传递的,架构文档是可以共享的,最重要的是,架构自身是可以评审、验证与实现的。

Stephen J. Mellor在《架构之美》序中,画龙点睛地勾勒出美丽架构的模样,即必须遵循的一些普遍原则,分别为:

  • 一处一个事实
  • 自动传播
  • 架构也包含构建
  • 最少量机制
  • 构建引擎
  • O(G),增长的阶
  • 抵制熵增

这些原则,其实就是架构师的智慧,没有足够深刻的理解与深入实践,是不可能给出如此言简意赅的架构建议的。按照我的理解,这些普适性原则其实就是在说明所谓美丽的架构,就是简单、一致、适应变化并能去除重复的架构。其实,泄露天机的一句话还是Mellor所言——美丽的架构用更少的机制做更多的工作。这就是《架构之美》一书不凡的开篇了。

若是一本平庸的书,必然会惧怕这样精彩绝伦的序,因为它愈发的美,就愈发能照映出正文的丑;它愈发的言之有物,又愈发会衬托出正文的空洞无味。 然而,若是内容也是如此的精彩绝伦,那就无异于锦上添花,珠联璧合了。通透点儿,就是齐活!这就好比一首歌曲的领唱者,倘若一开始就飙出高音,声入云霄。跟唱者没有点儿本事,恐怕就难以为继了;可要都是高手呢?那就真是一场音乐的盛宴了。《架构之美》合唱团荟萃了全球最为顶级的那部分架构师,所以说本书是架构的盛宴,似乎也不为过。

让我们先看看本书的第一部分《论架构》。第1章《架构概述》延续了序言的高屋建瓴,全篇介绍了架构师的角色、软件架构的含义、架构结构,并展示了什么才是好的架构,美丽的架构。虽然仅仅是一些概念的阐释,却仍然不乏真知灼见。例如在本书1.2节,给出了创建软件架构的如下意见:

  • 软件架构师的首要关注点不是系统的功能;
  • 考虑折中;
  • 运用“分而治之”的架构原则;
  • 概念完整性是架构最重要的特征;
  • 一份更完整的清单;
  • 架构会影响组织架构。

第2章《两个系统的故事:现代软件神话》的角度又有所不同。首先它注重实例,讲述了两个软件城市的故事;其次它突出对比,比较了混乱大都市性质的项目与“设计之城”。对比是最好的老师,如果你茫然不知一个系统究竟好在哪里,坏在哪里,通过引入对比,一切的好与坏都被放大,且清晰无比地被标示出来。Pete Goodliffe运用隐喻将设计看作是城市的规划与建设,有效地促进读者的理解,加深了整体认识。本章给出了设计的反模式与模式,引导我们对自己过往的设计进行反思,进行印证。例如,本章图2-4给出的“设计之城”最终架构,就很好地阐释了什么才是好的架构,因为该架构图如此地简单,既能清晰地表达设计者意图,又能很好地保证架构的一致性。同时,该图又突出体现了整个系统的核心功能,并通过引入管道-过滤器模式,建立了一个利于扩展、结构清晰的音频架构。

因为自己工作性质的原因,我重点关注了本书第二部分的内容,即对企业级应用架构的介绍。这也是我阅读本书收获最大的几章内容。例如第3章对伸缩性架构的介绍,以Darkstar开源项目的架构开发为例,较为全面地剖析了整个系统的架构过程。作者特别谈到了该项目支持游戏开发的特征,从而识别出可伸缩性以及并发处理对整个系统的重要性。这就好像是质量属性驱动,或风险驱动,先从最紧要、最核心的部分开始架构的分析,学会取舍,才能更好地遵循帕累托原则,将好钢用到刀刃上。作者对服务的分解代表了整个架构最重要的设计决策,每个服务承担了不同的职责,既保证了关注点分离,又能因为服务的独立性与自治性,保障系统的可伸缩性。例如通信服务中提供的会话服务(Session Service)与通道服务(Channel Service),就能够因为分离而降低通信机制的复杂性。这很好地体现了架构师的抽象能力,这种抽象既能简化模型,又能隐藏实现,保证系统的可移植与可伸缩。文章写到:

“既然所有通信都必须通过Darkstar会话或通道的抽象层,而这些抽象层又不暴露客户端与服务器通信的真实端点,那么在实体通信和通信起止端的实际位置之间就存在着一个抽象层。”

文中还提到了“元服务”的概念,我以为这是该架构设计的点睛之笔。

“这些元服务是网络层面的服务,对于游戏或虚拟世界的程序员是不可见的,但是它们对Darkstar栈中的服务是相互可见的。” “由于元服务对于游戏或虚拟世界的程序员是不可见的,所以它们在任何时刻都可以改变,不会影响到游戏逻辑的正确性。”

第4章《记忆留存》的作者Michael Nyard是获得Jolt大奖的《Release It!》一书的作者,长期战斗在一线扮演救火队员的角色,架构实证经验非常丰富。而本章在整本书中,也是工程实证主义表现得最为浓烈的一章。Michael完整地介绍了Creation Center项目的架构过程。作者通过明确事实,发现重要问题,然后识别关注点的方式来剖析架构,理解需求到功能实现的映射。作者的讲述都是经验之谈,因而总是显得言之有物。例如在讲解架构模块中的渲染管道时,提出了一种“快速失败”模式,遵循“快速失败、大声失败”的设计哲学。之所以运用这一原则,是因为系统的核心功能是生产照片。这样的生产过程不允许因为软件的原因而导致生产线停下来。这就决定了渲染管道的设计,必须在最早的过程中进行验证。

整章内容让我唯一感到恼怒的就是篇幅太短,许多步骤、技巧以及设计思想都是点到即止,终究有些隔靴搔痒的感觉。作者自己写道:

“我本可以花更多的时间和篇幅来描述每个类、每次迭代或每个设计决定,就像初为人父的人描述宝宝的每次打嗝和摇晃一样。”

我私心更希望Michael Nyard能做到这一点,可惜,这个说明读起来更像是偷懒的借口。

我很喜欢第5章《面向资源的架构:在Web中》。抛开Roy Fielding具有卓越远见以及超凡创造性的那篇博士论文不谈,就REST的讲解而言,本章很好地呈露了REST架构风格的原貌。其实,将REST架构风格引入到企业应用开发中,并非本篇作者的独特见解,譬如说《Rest in Practice》一书的作者,我的同事Jim Webber等人就是这一观点的坚决拥护者。如果对比本章与《REST in Practice》一书,感觉本章更像是《REST in Practice》的浓缩精华版,虽然作者完全不同。短短的篇幅,不仅给读者深入剖析了面向资源架构的本质特征,还对比了传统的Web服务,阐释了Web的性质,算是理清了REST的历史渊源,基本思想。这个基本思想就是“关注点分离”,REST就是将Web中的人机交互看做是人们感兴趣的资源、操作这些资源的动作以及选择收发这些资源的方式,从而得到名词、动词和表示形式三个重要概念。如文中所说:“REST方式的基本工作原理是分离关注逻辑命名资源、操作资源的方式,以及选择的表示资源的方式”。

当然,如果从Richardson提出的成熟度模型来讲,本章并未过多提及第三级服务的特征,即“Web感知的服务级别,支持超媒体作为应用状态的引擎的观念。【注:引自《REST实战(REST in Practice)》第27页。】”因为就Fielding博士的本意而言,REST是要将超媒体作为应用状态的引擎(Hypermedia As The Engine Of Application State,HATEOAS)。这或许是因为篇幅所限的原因吧。坦白说,这其实也是本书最大的硬伤。因为荟萃了如此众多的优秀架构师,势必不可能给出太多的空间让作者自由发挥。容量的限制决定了整本书的每一章节都是欲言又止的感觉。似乎讲解通透了,读起来又还不够明白。必须要再三研读,方才能明白字里行间的真意。

我仅仅是粗略地阅读了本书的第三部分,主要还是因为自己对系统架构的知识远远不够,没有这种基础,也就缺失了理解这些内容的资格。于是就畏难而退,跳到了第四部分和第五部分。第12章介绍的Akonadi框架从最初的层划分草案到最后“从里向外、而非自底向上”架构的演进,可谓深得我心。虽然架构策略以及系统背景并不相同,但就我这几年的架构经验来讲,我确实越来越重视内核模式在关注点分离中发挥的作用。许多系统的架构确乎都可以从纵向与横向进行分解,从而获得系统的应用逻辑架构与业务逻辑架构;然而从内核的观点来看,则可以理解为系统多个核心功能的交集,是整个系统的共同品质。它并不一定处于架构的最底层,如基础设施层所包含的内容;也不一定是公共的体现横切关注点的切面(aspect),而是系统最不可缺失的处于核心地位的高内聚职责。

第13章是Bertrand Meyer的大作,提供了很好的例子对比了函数式语言与面向对象语言的优缺点。其实本章的主要观点到如今已经没有太多人会反对。近几年函数式语言的迅猛发展,以及多语言开发的趋势已经说明了二者之间的互补性。本章最有价值的还是Meyer对函数式的推导与优势评价,以及包括对面向对象最基本要素如继承、多态、代理的剖析,这些内容对今时今日掌握面向对象设计技能,理解函数式编程本质思想,仍有非常大的参考价值。

在我这样杂乱的介绍下,本书听起来好像是一盘大杂烩。事实上它确实如此。因为全书涵盖的内容太多太广,以至于让人产生目不暇接之感。尤其对于术有专攻的开发人员来讲,要彻底吃透本书讲解的内容,无疑是一项艰巨的挑战。然而,如果从架构师所必须具备的技能来看,本书的内容其实并没有超出架构的范畴,因为架构师必须要见识广博,你才能针对不同的需求场景,面对不同的实现技术,选出最适合当前场景的恰如其分的架构方案。当然,在阅读时,千万不要在太多的技术细节中迷失自己,关键还是要把握美丽架构的基本原则。而这正是本书的主线,使得本书能够在散乱的主题中,还能做到“形散而神不散”。

作者:张逸

张逸,怀揣梦想的架构师,沉迷于设计之美,希望写程序能写到老。游走于.NET与Java之间,但更偏好关注架构与设计本质,偶尔还会玩玩Ruby和Python。四川大学软件工程硕士,是一只有着十余年IT从业生涯的老鸟,但还不是专家。著译作包括《软件设计精要与模式》、《WCF服务编程》等,个人网站为:http://www.agiledon.com。

本文分享自微信公众号 - 思特沃克(ThoughtWorks)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2013-01-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 微服务即演进式架构 | TW洞见

    今日洞见 文章作者来自ThoughtWorks:Neal Ford& Rebecca,译者来自ThoughtWorks:禚娴静。 本文所有内容,包括文字、图片和...

    ThoughtWorks
  • 技术雷达之微服务架构|洞见

    最近几年,微服务架构异军突起,与容器技术相辅相成,成为架构设计领域热议的话题。而《技术雷达》作为ThoughtWorks出品的一份关于技术趋势的报告,在技术社区...

    ThoughtWorks
  • 王健:技术雷达之微服务架构

    作为一家服务于全球不同类型客户的IT专业服务公司,ThoughtWorks一直追求最卓越的技术,并用它们来解决客户实际的问题。而为了体现技术卓越,Thought...

    ThoughtWorks
  • 《互联网架构 》来自一位大牛的分享

    对于大部分程序员来说架构师这条路还很远。但是掌握现阶段Java的主流技术无疑提升了自身的竞争力。

    用户1518699
  • 小钢的架构思考:什么是架构

    最近在思考架构方面一些最基本的问题,比如什么是架构?如何评价一个架构的好坏?是否有一些通用的基本原则指引架构设计?在面向对象设计方面,有单一职责、里氏替换、依赖...

    Keegan小钢
  • 干货 | 魅族云平台系统架构师梁鹏:魅族基础系统架构运维之路

    嘉宾演讲视频 Guest Video ? 温馨提示 本视频时长48分46秒,建议在wifi下观看 5月13日,应用性能管理大讲堂第十七期——《架构演进中的关键技...

    IT大咖说
  • 架构漫谈(一):什么是架构?

    架构漫谈是由资深架构师王概凯Kevin执笔的系列专栏,专栏将会以Kevin的架构经验为基础,逐步讨论什么是架构、怎样做好架构、软件架构如何落地、如何写好程序等问...

    Java高级架构
  • 什么才是真正的架构设计?

    在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义,概...

    xcbeyond
  • 美丽的架构

    美丽的架构究竟是怎样的?架构师们上下求索,孜孜以求,始终不得其解。归根结底,美丽这个词语总还是偏于感性认识,就仿佛音乐之美,绘画之美,不能以尺度来衡量,追求的其...

    张逸
  • 聊聊架构设计做些什么来谈如何成为架构师

      也因为碎片化的时间多了,所以开始刷某乎了,关注了架构相关的板块,也顺手回答了一些问题。发现有很多同道中人正在经历着我前两年经历的阶段,对于做架构没有相对具象...

    Zachary_ZF

扫码关注云+社区

领取腾讯云代金券