这个架构能实现吗?

标签: 架构
6387人阅读 评论(7) 收藏 举报
分类:

近来一直在做一个产品的架构升级,架构升级的前期工作是对旧架构现存的问题进行梳理,考虑新架构的设计如何规避旧架构的坑,完善旧架构支持不佳的缺陷。终于完成了新架构设计,在给开发工程师讲解时,还会遇到开发的疑惑:新架构真能实现旧架构上支持的特别困难或别扭的场景么,如此等等。一个架构从设计到实现,到底要做些什么,关注些什么?

那么我们就从下面这个问题开始梳理吧。

架构做什么

查了下维基百科(Wikipedia)架构(Architecture)一词最早源自建筑学术语,后来被计算机科学领域所借用。

架构是规划、设计和构建建筑及其物理结构的过程与产物。在计算机工程中,架构是描述功能、组织和计算机系统实现的一组规则与方法。
Architecture is both the process and the product of planning, designing, and constructing buildings and other physical structures. In computer engineering, “computer architecture” is a set of rules and methods that describe the functionality, organization, and implementation of computer systems.

要明白做什么,首先需要考虑目标是什么?软件架构的目标是要设计软件系统来解决问题,所以架构要做的事从抽象的维度上看,就是:

  • 根据问题域,界定系统的边界
  • 对系统进行切分,切分的目的是分工与协作(并行,以获得效率)
  • 被切分的各部分之间建立交互与沟通原则与机制
  • 将部分连接合并成一个整体,完成系统的目标

更具体一些来说,架构做得就是结构设计,在不同维度和层次上:

  • 高维度:是系统、子系统或服务的切分与交互结构
  • 中维度:是系统或服务内部的模块划分
  • 低纬度:是代码结构、数据结构、表结构

当在架构升级这样的事情中,架构师的职责之一是要交付“一种架构”,而这“一种架构”的载体现在通常又会以某种文档的形式出现。所以,很容易误解架构师的工作就是写文档,实际上架构师的交付成果是一整套决策流,交付载体通常体现成了文档。在这个过程中,架构师的首要工作就是保证在架构方案执行中,整个开发团队的实施效果与决策保持一致。即使在这个过程发现了实施与决策的冲突,就又需要重新协调沟通讨论以取得新的一致。

当系统规模比较小时,比如架构师一个人就能把全部的设计决策在交付期限内开发完成,这就省却了很多的沟通协调讨论成本。五年前,我就曾这样做过一个小系统的架构升级改造,但后来的系统越来越大,慢慢就需要几十人的团队来分工协作,如何保证架构设计中的决策在架构执行过程中保持一致,这成为了架构工作的真正难点所在。

架构关注点

架构设计的决策流一旦落在了文档的载体上,它实际就是一个静态的东西了。而真正的架构执行过程却是动态的。在这个动态过程中,架构师需要定期地去对系统的状态做快照,观察是否有出现需要解决的问题,而这些问题就是技术层面的架构关注点。

一些问题也许是架构执行中新出现的,在当初的架构设计中未能考虑到,需要对此做分析判断,并形成新的决策。而另一些问题,也许是执行过程中的走样,导致和当初的决策形成了偏差。架构师需要考虑所有这些关注点,并和开发工程师找到解决这些关注点的各种选项,在适当的时候根据真实环境的情景去采取合适的行动。有时,我们称这些行动叫作:重构或优化。当一个旧系统长期没有这样的行动,积累久了后,我们将迫不得已采取另外一种行动,我们称之为 —— 架构升级。

软件系统或架构,不像建筑物会因为时间的流逝而自然耗损腐坏,它只会因为变化而腐坏。一开始清晰整洁的架构与实现随着需求的变化而不断变得浑浊、混乱。信息与计算机科学都爱借用一个物理学的术语「熵」,它表达体系的混乱程度,而软件系统的「熵」很容易不经意间随着需求的变化而变得更高。

软件系统「熵」有个临界值,当达到并超过临界值后,软件系统的生命也基本到头了。这时,我们就要采取那个迫不得已的行动了。图例展示了软件系统「熵」值的生命周期变化。

所以,近年流行的微服务架构有个很大的优势,服务粒度合适,服务物理隔离,单个服务的「熵」增问题被局限在单个微服务内部。单个微服务的替换与重构成本十分有限,使得「熵」增问题局部化,不容易传染全局,以致失控。当然这有个前提,就是微服务的拆分和接口交互要合理,合理的检验标准就是随需求变化,总是实现变化或接口新增,而非总是调整接口交互。

架构始于系统生命之初,并伴随系统生命周期全程。每次需求变化带来的变动都应进行一次或大或小的重新架构过程。架构的关注点在于控制软件系统变动时「熵」值的变化。

架构等效性

架构升级中一开始的疑惑:这个新架构能实现么?其实,这根本不是一个值得疑惑的问题。

相对于建筑架构,软件架构过程其实更像是城市的规划与演变过程,有一定历史的城市,慢慢都会演变出所谓的“旧城”和“新城”,新城相对于旧城,就是一次架构升级的过程。城市规划师会对城市的分区、功能划分进行重新定位和规划。一个旧城所拥有的所有功能,如:社区、学校、医院、商业中心,你难道能想象新城会没有吗?或者说“实现”不了吗?

所以,如果一个单体应用能实现的功能,换成微服务架构肯定也可以实现,只是编写代码的方式不同。不同架构在功能的可实现性上其实是完全相同的,我称之为:架构等效性。不同的地方在于哪里呢?如前所述,切分方式不同导致的分工协作完全不同,因此获得的效率与付出的成本也会不同。

架构升级,仅仅是一次系统的重新布局与规划,成本与效率的重新计算与设计,熵的重新分布与管理。

架构就是关于系统的决策流。
架构关注系统「熵」的变化。
架构都是等效的,不同的是成本和效率。

新城区(架构)活动的人(需求)多了,也是要堵车(…)的。


写点文字,画点画儿,记录成长瞬间。
微信公众号「瞬息之间」,既然遇见,不如一起成长。

9
2

猜你在找
【直播】机器学习&数据挖掘7周实训--韦玮
【套餐】系统集成项目管理工程师顺利通关--徐朋
【直播】3小时掌握Docker最佳实战-徐西宁
【套餐】机器学习系列套餐(算法+实战)--唐宇迪
【直播】计算机视觉原理及实战--屈教授
【套餐】微信订阅号+服务号Java版 v2.0--翟东平
【直播】机器学习之矩阵--黄博士
【套餐】微信订阅号+服务号Java版 v2.0--翟东平
【直播】机器学习之凸优化--马博士
【套餐】Javascript 设计模式实战--曾亮
查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1176226次
    • 积分:11527
    • 等级:
    • 排名:第1336名
    • 原创:171篇
    • 转载:0篇
    • 译文:9篇
    • 评论:914条
    文章分类
    最新评论