工作这么多年,今天对架构做了一个简单思考

图片来自网络

架构,如果让你给它一个定义,恐怕一时不好表达。正如,问你,山,是什么;水,是什么一样。对于程序员来讲犹如游山玩水的侠客,畅游在程序-代码-架构之中。为架构,下一个定义,和为山水,下一个定义,一样可能会略作沉思之后,方能概述。


微服务是一种架构风格。曾经也思考,微服务,到底是先有了微服务这个动作,还是先有微服务这个名词。想到此,想起我们的祖先,拿来一个木棍,在另外一根木棍上,使劲旋转,生出火来。后来,我们为其取了一个名词:钻木取火。因此,微服务也恐怕是这样,我们实践了分布式架构的动作,后又继续尝试精进更能符合业务和组织的方法。后来有技术达人总结为:微服务。


我们再说回架构,架构一定是为应用程序服务的,那么应用程序的需求是什么,有两个,一个是功能性需求,实现一些什么样的功能,这些功能的实现是通过代码编写最终完成;另外一个是非功能性需求,包括这套应用程序的可维护性、可测试性、可扩展性和可部署性。这个非功能性需求便是架构要解决的问题。


对于功能性需求你完全可以用一个"大肚子"应用程序去实现,只有对我们说的非功能性需求有要求的时候,也一定会对这样的非功能性需求有要求的,因为你肯定不希望自己的程序不可维护、不可测试、不可扩展和不可部署。非功能性需求更是一种能力,是应用程序健壮与否的能力,是程序的"肌肉"。


那架构是什么,你可以清晰的为之定义了吗?


程序的架构,有时候我们往往与建筑架构类比,更有意思的一点是,在英语中 建筑师 和 架构师 是同一个词architect。建筑架构,一般有结构、管线、电气等多个构成。那么程序架构呢,早在不少年之前,国外就有这方面的专家,提出了4+1的视图模型来描述架构。


4+1视图中的4,有逻辑视图、实现视图、进程视图、部署视图。其中的1,是场景。场景来负责把视图串联在一起。这种视图模型表示法是对现代化应用程序架构一个准确的描述,放在我们如今广泛使用的微服务架构中能很清晰的给出精准的定位。无论如何架构,都会涉及逻辑、实现、进程和部署。


架构有它的风格,在类比到建筑上。建筑架构的风格可以有 "大裤衩"的豪放之风,也可以有细腻的江南水乡之风。程序的架构也有它的风格,分层式的架构是一种风格,为其代表的是MVC;六边形的架构是一种风格,定义了端口和适配器,解耦了业务逻辑和依赖;微服务是一种架构风格,将应用程序构建为松耦合、可独立部署的一组服务。


计算机软件已经发展了那么多年,开发程序仍然是一个需要认真对待的复杂过程。无论今天你如何敏捷,定义问题、需求分析、软件架构、详细设计、编码与调试、单元测试、集成测试、保障维护,这些动作都少不了。你承认不承认都会在大脑中和行动上经历这些动作,而架构活动是软件开发中的核心活动。


那么架构师呢?


架构,对于架构师,是解决问题的工具,如果架构不能解决问题,架构对于架构师就是一个玩具。

推荐阅读更多精彩内容