3cb0d525d334eda408ecb12bd2ba16c3
019 | 回归架构本真:架构规划

前一篇文章聊了设计模式背后的几大设计原则,接下来我们聊聊架构的话题。也不聊具体表层的东西,而是回归本真,聊聊那些非常重要但却很少人谈及的层面,我将分三篇文章分别聊聊架构规划、架构思维和架构原则。本篇文章先谈谈架构规划。

什么是架构

关于什么是架构,业界从来没有一个统一的定义。Martin Fowler在《企业应用架构模式》中也没有对其给出定义,只是提到能够统一的内容有两点:

  1. 最高层次的系统分解
  2. 系统中不易改变的决定

《软件架构设计》一书则将架构定义总结为组成派和决策派:

  • 组成派:架构 = 组件 + 交互:软件系统的架构将系统描述为计算组件及组件之间的交互。
  • 决策派:架构 = 重要决策集:软件架构是在一些重要方面所作出的决策的集合。

而架构的概念最初来源于建筑,因此,我想从建筑的角度去思考这个问题。Wikipedia中,对架构,即 Architecture 的定义如下:

Architecture is both the process and the product of planning, designing, and constructing buildings and other physical structures.

简单翻译就是:架构是规划、设计和构建建筑物或其他物理构筑物的过程和结果。

从上面的定义中可知,首先,架构的最终目标是为了产出建筑物或其他物理构筑物,构筑物可以只是一套房子,也可以是一栋楼盘,抑或是一个小区、商业区,甚至是一个城市。构筑物越大,其架构必然也越复杂。

其次,产出建筑物之前需要经过三个阶段规划(planning)设计(designing)构建(constructing)。这三个阶段其实也是架构的核心了。比如,开发商要建一个住宅小区,首先肯定要对该小区有一个整体的规划吧:小区的建设选址、建设的规模、建设的内容、投资估算、建设周期等等。接着,就要对小区的各方面进行设计了,最高层次的应该是小区的总体布局设计,拆分开的话就是各楼盘的设计、绿化的设计、各种配套设施的设计等等,再细化下去就是各种户型的设计、楼盘内和小区内各种走道的设计等等。最后,构建阶段也就是施工阶段了,是将之前所有的想法转为实际的建筑物的阶段。

最后,架构包含了以上的过程和结果。也就是说,对小区总体规划的过程是架构,规划的结果方案也是架构,小区总体布局的设计、楼盘的设计、户型的设计等等的每个过程也都是架构,每个过程产出的设计方案也是架构,构建阶段的施工图也是架构,可以说,产出建筑物期间的每个过程和结果都是架构。

那么,如果将建筑物换成了软件,那就变成对软件架构的定义了:软件架构是规划、设计和构建软件的过程和结果。

相应地,软件架构的最终目标就是为了产出软件,可以是一个 App,也可以是一个平台,如 SaaS、PaaS、BaaS 等等,甚至还可以是智慧城市这样庞大的生态系统,地球人都知道,越庞大复杂的系统,架构越难。规划阶段更多考虑的是软件的需求,包括业务上的功能性需求和技术上的非功能性需求,如可靠性、可扩展性、可维护性等;此阶段的架构一般为系统架构。设计阶段的工作更多的就是拆分细化,以满足各种需求;此阶段的架构一般为逻辑架构。构建阶段主要就是对软件的实现和部署了;此阶段的架构一般为物理架构。

架构规划

架构规划做什么呢?我觉得主要是规划好下个阶段架构设计的边界。而影响架构边界的,其实就是需求。需求形成了对架构的约束条件,从而也对架构设计形成了边界。那么,有哪些需求呢?可以分为三大类:商业需求功能需求质量需求

商业需求

商业需求是最高层次的需求,对其含义,我比较赞同温昱在《软件架构设计》中提到的解释:它关注从客户群、企业现状、未来发展、预算、立项、开发、运营、维护在内的整个软件生命周期涉及的商业因素,包括了商业层面的目标、期望和限制等。商业需求一般对架构的影响比较大,对架构产生限制的商业因素也比较多,在此列举一些比较常见的:

  1. 上市时间:上市时间限定了系统从设计、开发、测试到上市的时间边界。之前我跟进过一个垂直于大学生市场的应用,上市时间就要求在新生入学前,不然就会错过推广的最佳时期,预留给开发的时间只有两个月。因此,我们只好大部分重用前个项目的元素,包括重用服务端的一些模块,还包括客户端的架构和界面。当然,一般情况下,预留给开发的时间不会这么短,但也不会特别长。架构师需要根据时间长短,平衡各方面需求,做好架构选型。
  2. 成本预算:成本预算就限定了能使用的资源边界。不同架构的开发成本肯定不同,要满足更多功能需求和更多质量需求的架构成本也更高,在预算有限的情况下,只能权衡各种需求,优先满足重要程度高的需求。
  3. 人力现状:100人的开发团队和10人的开发团队,软件的架构会有很大不同。另外,开发团队人员所掌握的技术也会对架构选型有影响。例如,团队里还没有人会用React Native,那现阶段就不适合选择React Native作为App架构的技术基础。
  4. 与外围系统的集成:当需要与外围系统集成时,需要认真考虑集成方法,尤其是外围系统比较老的时候,集成难度可能更高。另外,外围系统的不可控因素一般也比较多,因此,对架构处理这些不可控风险的要求相对也高。
  5. 开放性:封闭的私有系统和开放式系统对架构的要求也不同,一个系统如果选择了开放,那对架构的质量要求更高,对安全性、扩展性、性能等质量属性都应该比封闭时高。
  6. 目标市场:目标用户10万、100万、1000万,不同级别的目标市场,架构也是大有不同。另外,大众市场和垂直的专门市场,架构也同样有区别,较大的专门市场一般都采用产品线的规划方案。
  7. 多端支持:现在移动端普遍支持Android、iOS、Wechat,管理端通常则支持PC Web,如果管理端也要支持Android、iOS、Wechat,或者移动端和管理端还要再支持WindowsPhone、黑莓,甚至再支持VR,则需要投入更多时间和人力,架构上相应也需要做出调整。
  8. 期望的系统生存期:从主观上说,谁都希望自己的系统可以生存很久,但生存期越长,意味着系统的可修改性、可扩展性、可移植性等需要更高。但是,受上市时间、成本预算等因素的制约,再加上软件本身的变化快,所以,客观上,一般也不会期望其生存期太长。当系统不能满足渐增的需求时,基本通过重构来解决。
  9. 阶段性计划:每一个大平台系统普遍都是分阶段完成的,因此,前期阶段的架构设计时就需要考虑好重用性、扩展性、伸缩性、移植性等特性。但因为每个阶段经过市场验证后,需求有可能会变化,所以又不能过度设计,否则就会造成设计浪费,还可能加大了后续阶段架构调整的难度。
  10. 国际化:如果走国际化路线,那架构上就要考虑好对多国语言的支持。
  11. 竞争对手:产品要比竞争对手优秀,那就要在一些关键的功能或质量上超越对方,也意味着在这些方面的架构需要投入更多。
  12. 法律法规:比如,对某些关键字要进行过滤屏蔽,这是天朝独有的,大家懂的。
top Created with Sketch.