如今,几乎所有的事情都离不开软件,当你开车时,脚踩上油门,实际上是车载计算机通过力度感应等计算输出功率,最终来控制油门,你从未想过这会是某个工程师的代码。
作者 | 张羽辰(同昭)阿里云交付专家
导读:如今,几乎所有的事情都离不开软件,当你开车时,脚踩上油门,实际上是车载计算机通过力度感应等计算输出功率,最终来控制油门,你从未想过这会是某个工程师的代码。
当我们谈论架构时,我们到底在谈论什么?
面向对象编程?函数式?模块化设计?微服务?这些词汇貌似都和架构这个 buzzword 有点关系,的确我们这个领域充满了很多难以理解的词汇,这些词汇从英语翻译到中文已经丧失了部分上下文,再随着上下文的改变使得意义彻底扭曲,比如:引擎、框架、架构、应用、系统……诚然大家都或多或少对这些词语达成共识,在工作中使用这些词汇进行沟通,某时就是指“我们都懂的那个东西”,但是在我深入的想聊聊架构或者说软件架构时,的确不得不问自己这个问题,我们到底是谈论什么?
事实上,架构这个词根据上下文所确定的范围较为固定,建筑学上的架构指代房屋结构、整体设计、组合构成等,而这些 high-level 设计往往并不需要全面了解底层,就像使用 RestTemplate 进行 WebService 调用时,我们也不关心 socket 是在四层连接的一样,因为细节被隐藏了。
但是,建筑学上的架构与软件架构却又极大的不同之处,问题出现在“软件”这个词上,按照 software 的词解,ware 是指产品一样的东西,而 soft 则强调易变,这是与 hardware 所对应的。我们希望“软件”能够进行快速的修改,应该能够快速响应甲方或者客户的需求,所以软件架构必然不像建筑架构一样,建筑一经建成,修改的成本极高,而软件应该走对应的方向,发挥易于修改的特点。
“现在的大多数软件非常像埃及金字塔,在彼此之间堆建了成千上万的砖块,缺乏结构完整性,只是靠蛮力和成千上万的奴隶完成。” —— Alan Kay。
笔者认为,虽然这句话表达的意思我很赞同,但实际上,金字塔作为帝王的陵墓,是有着完整的设计逻辑,并且随着好几座金字塔的迭代的,以及逐渐完备的施工管理,后期金字塔是非常杰出的建筑代表,并作为地球上最高的人造建筑持续了好几千年。关于金字塔是否由奴隶建造还是存有争议。(图片来自 Isabella Jusková @ Unsplash)。
作为工程师,我们一方面关注软件产品的能力和行为,这往往是一个项目的起点,另一方面我们需要关注软件的架构设计,因为我们希望设计有着弹性、易于维护、高性能、高可用的系统,更希望系统能够不断演进,而不是在未来被推倒重做。所以,回正我们的视野,当我们决心要设计一个好的架构时,我们需要明确,架构往往决定的是软件的非功能性需求。这些非功能性需求有:
- 易于开发:我们希望工程师一进入团队就可以立刻开始进行研发工作,我们希望代码易于阅读与理解,同时开发环境足够简单统一,说到这里大家可以回想下当你进入项目时,学习上下文的痛苦。当我们开始采用 docker 辅助开发时,时任架构师提出了一个要求,只要一行命令就可以使用 docker 启动本地测试环境,而且必须所有的微服务都要做到这一点。痛苦的改造完成后,三年后进入项目的同学只需要安装好 docker,再在 ternimal 中运行一句 ./run-dev.sh 就能够获取一个具有完整依赖的本地环境,提效明显。
- 方便部署:如果系统的部署成本很高,那使用价值就不会很高了,我们很多企业都存在那种动也不敢动,改也不敢改,停也不敢停的系统,除了祈祷它别挂掉好像没有别的办法,或者很多企业都采用了 K8s 这种先进的编排系统,但是在应用部署和上线时,还是走的每周四变更的路子。现代的发布方式 AB、金丝雀、灰度无法采用是因为改造成本过高,或者没有足够的自动化测试来保证改动安全,更别提将发布做到 CI\CD 里面了。
- 易于运维:DevO