简单即美,一场架构师和建筑师之间的世纪对话

徐进
5627     
摘要:世间万事万物,道理总是相通的,软件架构与建筑架构之间也密切相关……

世间万事万物,道理总是相通的。新兴软件行业与传统建筑行业之间,看似毫无关联,实则联系紧密。项目经理的职责最早其实是在建筑行业内被明确的。软件架构师和建筑师的英文描述都是Architect,他们的职能也是如此相似。这或许能为我们理解微服务提供新思路。


建筑师与架构师的世纪对话


面对现实世界中需求的复杂性,建筑师或者架构师都能通过辩证的审视需求,对引入系统的需求进行合适的取舍,同时,根据周围的资源和环境状态,设计出适合当下的建筑设计和软件架构。著名建筑师勒柯布西耶与著名软件工程师马丁福勒之间虽然联系甚少,但他们的代表作却似乎在冥冥中进行着世纪对话。

 

功能主义之父柯布西耶

著名建筑师勒柯布西耶是功能主义建筑的泰斗,他曾在1923年的著作《走向新建筑》中提出建筑的模块化、标准化。代表作有:萨伏伊别墅、马塞公寓。

 

敏捷联盟成员马丁福勒

在软件架构师领域,也有一名大家熟悉的大牛——ThoughtWorks的首席科学家、敏捷联盟成员马丁福勒。他曾撰写了:分析模式---可重用对象模型、企业应用架构模式、UML精粹---标准对象建模语言简明指南等。2001年,他与其他16名合著者一起创作了敏捷软件开发宣言。当然,他还第一个对微服务下了定义描述。下面我们就来看看,这两位智者在不同时期的思想瑰宝,有何神奇的相似之处。


企业应用架构 VS 马塞公寓


21世纪初期,Java语言推广、面向对象的设计与封装、组件复用以及模块化开发的深入发展使得我们的企业级系统规模迅速膨胀。软件系统研发团队内部的沟通成本、变更成本、测试和维护成本迅速赶超纯粹的研发成本。于是,越来越多的行业大拿开始致力于寻找非技术层面的工程解决方案。

 

工程学为软件开发提供了不少妙法:将CMM用于管理项目团队的开发过程、UML用于降低研发团队各环节的沟通成本、设计模式用于重构软件的模块组织、DevOps用于提升软件的交付与运维能力。而这些解决方案与软件工程领域的大牛马丁福勒密切相关。

 

早期的企业级应用架构看上去很像建造一座马赛公寓:



马赛公寓是密集型建筑的一个典范,能够容纳1600人。为节约有限的空间资源,设计师大量使用跃层式布局。早期的企业级应用架构系统内部俨然如同一个社会,有不同结构的业务模块功能、有用于系统保障的支撑设施、有提供模块间不同交互的通道设计、或者还有一些诸如屋顶花园般炫酷的对外表现。

 

这种架构有效地降低了企业系统的复杂程度,各种被抽象的模块与组件各司其职,再通过架构将它们有机地组织起来,完成复杂的功能输出。当系统规模一再扩大,系统内的交互组件越来越多,交互方式也日趋复杂的情况下,系统的研发者发现,一个优雅系统的实现完全依赖大师级架构进行的“有机组织”,然而,具备这种能力的架构师并不充裕。更多系统被置于高昂的沟通成本、变更成本和运维成本之中。另外试想,如果有一日要在马赛公寓的商店楼层引入一家苹果用户中心,或许便要淘汰掉一家麦当劳速食,因为楼层的店铺都排满了。那么,这个变动究竟会影响337户住客中的哪些麦当劳忠实者呢?没人能够知道!


微服务架构 VS 萨伏伊别墅

 

系统规模扩大的紧迫性让福勒等科学家萌生出敏捷开发、微服务架构的想法。在微服务架构里,模块化是被描述成面向业务领域的,模块内部是业务的高内聚,模块之间的通讯变得更轻量化,往往一些简单松散的RESTful就能完成模块之间的交互。对比马赛公寓,每个微服务似乎更像是一座萨伏伊别墅:



萨伏伊别墅的设计师认为住户应该可以按自身需要划分自己的居住空间,由此提出自由平面,将承重结构与分隔结构完全分离,以极大程度地实现空间划分的灵活性和适应性。微服务在实现模块业务功能闭包的基础上,内部的结构更趋向于简洁和灵活。微服务起源于敏捷开发,因此,这种架构更适合需求的演化和持续的迭代——敏捷原本就是用于解决这类问题的。每个微服务简洁的结构降低了实现它的技术门槛;高内聚松耦合的模块分离也降低了单个服务的演化成本;当然,随着开发微服务的团队规模得到控制,开发过程中的团队内部沟通效率也大幅提升。如同诸多别墅构建起一个开放式村落。

 

此时再想想,苹果用户中心要进驻村落,只需申请一块新的空地,投入、构建,当它开张之时,村落即拥有了苹果产品销售和售后的服务能力。


建筑师与架构师的法宝:简单


马赛公寓和萨伏伊别墅都是建筑业的优秀之作。没人能比较出两者之中哪种建筑风格的理念更先进,它们各自适应着自身面对的用户需求。软件领域呢?答案也是如此。

 

没有更先进的架构,只有更适合需求的架构。福勒在描述微服务时进行了多次抽象,而操作层面却未做出严格的约束。多大的规模才是合适的微服务?微服务内部应有怎样的结构?微服务之间的交互依赖有什么样的标准?这些问题都留给了微服务架构师来决策,而决策的依据统统起源于需求。何谓适合?工程领域没有标准回答,但有一个方向可以参照:简单。架构的目的是将复杂问题简单化,否则,架构这道工序便没有存在的意义,因此,简单是美——将成为架构设计一个永恒不变的方向

未经授权禁止转载,详情见转载须知

联系我们

恒 生 技 术 之 眼