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

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

面向对象编程？函数式？模块化设计？微服务？这些词汇貌似都和架构这个 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 里面了。

DevOps 的初衷是建立一种缩短运维与研发距离的文化，让出现问题后更容易处理，希望让大家将视野放在产品上而不是限定自己的工种，这并不是期望运维的同学能够成为 Java 专家，迅速的进行 heap 分析发现问题，我们强调的是运维时的闭环能力。在软件产品层面，我们也希望产品是足够独立的、自治，可以独立部署，能够做到横向扩展，有着完整的可观测性，毕竟当今的硬件成本很多时候是远远小于人力的。

随着时间的推移，给软件增加新功能就会变的越来越难，越是运行长久的项目就会陷入重写还是重构的苦恼。往往风险在与，修改代码会增加破坏已有功能的风险，而且技术债也会越来越多难以偿还，即使是重写某些功能和模块，我们也很难确定是否真的覆盖到了所有的功能，简而言之，don't break anything 的确很难做到。

以及最重要的一点：演进能力。良好的架构设计应该能让系统处于易于演进的状态，能够实现给飞驰的汽车换轮胎的能力，而不会被框架、底层的某种数据库、操作系统或者其他东西所绑架，但是这太难以做到了。的确，在项目进行技术选型时，因为某种数据库的特性而有倾向，但是在上层设计中，我们必须保证不依赖于数据库的特性，而将使用这些特性的地方放到底层细节中。我们也需要考虑，不使用 Spring 提供的 Dependency Injection，我们该如何组织我们的 beans，也要考虑将来系统的前端是 web 还是 mobile 还是都要支持？

这里引用 Robert C·Martin（Uncle Bob）的原语，“软件产品是有两方面的价值，一方面是实现功能的价值，另一方面是架构的价值，而架构的价值可能更重要一些，因为它代表着软件 soft 的特性。”

本书例子过少，而且缺乏现有流行框架的重构或者改进建议，有点形而上，但是在方法论层面笔者还是认为值得一读。

Robert C·Martin 对数据库（特指 RDBMS）的态度很值得讨论，首先他认为数据库是一种细节，在架构中应该与业务解耦，他强调业务代码与数据库的无关性。同时在我们的代码进行计算时，表格往往不是理想的数据结构，比如有些场景会使用树、DAG 等等。可以回想一下，当你需要把一个树存入数据库时，你该如何实现？

随着规模的扩大，单体应用的代码改动成本会越来越大。很多时候我们微服务的架构实践是存在误区的，我们总认为流量经过某个 gateway 后直达某个服务，确忽视了服务之间调用的场景，理想的微服务架构应该是一张网，每个节点都是独立的、自治的服务。

这个开幕雷击虽然槽点满满，但并没有降低社区对 Istio 的信心，反倒是渐渐发现这次的大改动使 Istio 变得有点好用了，可以在生产中采用而不需要付出太多代价了。当然，漂亮话永远好说。

实践微服务，作为架构师所考虑的东西远远大于只是实现业务，但是一旦铺平道路，下来的研发与迭代将会更加顺利。