2020 年，从架构谈起，到 Mesh 结束

如今，几乎所有的事情都离不开软件，当你开车时，脚踩上油门，实际上是车载计算机通过力度感应等计算输出功率，最终来控制油门，你从未想过这会是某个工程师的代码。

作者 | 张羽辰（同昭）阿里云交付专家

导读：如今，几乎所有的事情都离不开软件，当你开车时，脚踩上油门，实际上是车载计算机通过力度感应等计算输出功率，最终来控制油门，你从未想过这会是某个工程师的代码。

当我们谈论架构时，我们到底在谈论什么？

面向对象编程？函数式？模块化设计？微服务？这些词汇貌似都和架构这个 buzzword 有点关系，的确我们这个领域充满了很多难以理解的词汇，这些词汇从英语翻译到中文已经丧失了部分上下文，再随着上下文的改变使得意义彻底扭曲，比如：引擎、框架、架构、应用、系统……诚然大家都或多或少对这些词语达成共识，在工作中使用这些词汇进行沟通，某时就是指“我们都懂的那个东西”，但是在我深入的想聊聊架构或者说软件架构时，的确不得不问自己这个问题，我们到底是谈论什么？
事实上，架构这个词根据上下文所确定的范围较为固定，建筑学上的架构指代房屋结构、整体设计、组合构成等，而这些 high-level 设计往往并不需要全面了解底层，就像使用 RestTemplate 进行 WebService 调用时，我们也不关心 socket 是在四层连接的一样，因为细节被隐藏了。
但是，建筑学上的架构与软件架构却又极大的不同之处，问题出现在“软件”这个词上，按照 software 的词解，ware 是指产品一样的东西，而 soft 则强调易变，这是与 hardware 所对应的。我们希望“软件”能够进行快速的修改，应该能够快速响应甲方或者客户的需求，所以软件架构必然不像建筑架构一样，建筑一经建成，修改的成本极高，而软件应该走对应的方向，发挥易于修改的特点。

“现在的大多数软件非常像埃及金字塔，在彼此之间堆建了成千上万的砖块，缺乏结构完整性，只是靠蛮力和成千上万的奴隶完成。” —— Alan Kay。

笔者认为，虽然这句话表达的意思我很赞同，但实际上，金字塔作为帝王的陵墓，是有着完整的设计逻辑，并且随着好几座金字塔的迭代的，以及逐渐完备的施工管理，后期金字塔是非常杰出的建筑代表，并作为地球上最高的人造建筑持续了好几千年。关于金字塔是否由奴隶建造还是存有争议。（图片来自 Isabella Jusková @ Unsplash）。

作为工程师，我们一方面关注软件产品的能力和行为，这往往是一个项目的起点，另一方面我们需要关注软件的架构设计，因为我们希望设计有着弹性、易于维护、高性能、高可用的系统，更希望系统能够不断演进，而不是在未来被推倒重做。所以，回正我们的视野，当我们决心要设计一个好的架构时，我们需要明确，架构往往决定的是软件的非功能性需求。这些非功能性需求有：

1. 易于开发：我们希望工程师一进入团队就可以立刻开始进行研发工作，我们希望代码易于阅读与理解，同时开发环境足够简单统一，说到这里大家可以回想下当你进入项目时，学习上下文的痛苦。当我们开始采用 docker 辅助开发时，时任架构师提出了一个要求，只要一行命令就可以使用 docker 启动本地测试环境，而且必须所有的微服务都要做到这一点。痛苦的改造完成后，三年后进入项目的同学只需要安装好 docker，再在 ternimal 中运行一句 ./run-dev.sh 就能够获取一个具有完整依赖的本地环境，提效明显。
2. 方便部署：如果系统的部署成本很高，那使用价值就不会很高了，我们很多企业都存在那种动也不敢动，改也不敢改，停也不敢停的系统，除了祈祷它别挂掉好像没有别的办法，或者很多企业都采用了 K8s 这种先进的编排系统，但是在应用部署和上线时，还是走的每周四变更的路子。现代的发布方式 AB、金丝雀、灰度无法采用是因为改造成本过高，或者没有足够的自动化测试来保证改动安全，更别提将发布做到 CI\CD 里面了。
3. 易于运维：DevOps 的初衷是建立一种缩短运维与研发距离的文化，让出现问题后更容易处理，希望让大家将视野放在产品上而不是限定自己