架构思考随笔 - 回归单体架构？

引子

昨天看见一篇公众号文章叫<微服务全做错了！谷歌提出新方法，成本直接降 9 倍！>，内容是根据 google 的一篇文章<Towards Modern Development of Cloud Applications>，提出对整个行业的微服务化和云原生现状和一些失败案例进行反思。碰巧最近工作中遇到的一些应用架构设计上的争论，有些粗浅的感想记录一下。虽然作为一个非资深架构，菜鸟一思考，大佬就发笑，但是不能因此就不思考，希望这个思考过程能提供一些价值。

文章内容

Google 这篇文章发表的时间是 23 年 6 月，它其实不是说微服务和云原生是错的，而是讲行业中很多使用微服务和云原生的设计案例失败了，技术人员在拆分微服务这个过程由于不会拆或者拆不好导致了哪些问题。

我理解它的核心思想是这样的：现代的应用架构设计模式令人眼花缭乱，但回归第一性原理，编写程序这件事在进入高级语言的时代之后，“组件”概念代表了系统中的基础功能单元。不管是单体中的 CBB 还是 SOA 还是微服务等等各种架构风格或者模式，他们只是对不同颗粒度的组件在逻辑分组和物理分组（部署）。在很多项目中，部署架构是按照应用逻辑架构来设计的，而开发人员去拆分微服务的时候经常根据自己的理解随意去拆，比如简单地按一个业务模块一个微服务。有时过细的拆分导致了跨微服务的业务功能网络成本高，性能差，复杂度倍增，维护量倍增，跨微服务协同开发难等等问题。

那 google 的几位工程师们给出的建议是：

• 编写分为逻辑组件的整体应用程序（write monolithic applications divided into logical components）

• 将不同模块带来的挑战推迟到运行时（defer to a runtime the challenge of physically distributing and executing the modularized monoliths）

• 原子部署应用程序

翻译成人话是：开发不会拆微服务就别瞎拆，就先按单体来，你就写组件，只做逻辑分组，至于部署架构这种物理分组的事情，咱们灵活着来。比如单体里 ABC 三个组件，你想按 AB+C 部署两个微服务还是按 A+BC 部署两个微服务都行，部署的人去搞。

可能你会疑问，那有啥区别？最后总得把部署架构定下来。有一点区别，就是架构可修改性：

• 如果是在应用架构设计时提前划分微服务，整个微服务内部就是紧耦合的，微服务对外的接口也定型了，当运行一段时间发现想把一些微服务合并，这些 API 就得重新设计，代码重构也会有很大工作量；

• 如果都是单体=组件*n 的方式，那么你部署了发现 AB+C 不对，想改成 AC+B 是很简单的事情。

文章还涉及到一些动态部署的方案 blabla，就不赘述了。公众号们顺带列举了亚马逊 prime video 等等项目回归单体后性能大幅提升的案例，造成一种架构模式分高下的对立感，其实背后的本质是什么？

几个案例

• 第一个案例是在我们架构例会上，有一个场景是一个 B/S 架构的 OLTP 系统，后端按模块分了几个微服务，但页面功能需要跨多个微服务的数据，初版设计是在 BFF 中调多个微服务获取到多维度数据然后进行清晰整合：

但是这个方案的挑战是跨微服务关联查询和分页统合的复杂度问题，复杂度进而带来性能问题。

然后其中一位架构师 A 提出的方案是在数据库和代码层面直接整合，不是集成，是多微服务共库，然后表设计按统一数据结构标准进行设计，代码放进同一个工程，这样整合后各微服务直接关联表查共库就行了。此时各子系统已经不能叫做微服务了，应该叫做“组件”：

这里已经可以闻到一些奇怪的味道了。架构师 A 说我们之前搞了很久，最后觉得只有这样才能达到 OLTP 级的数据快速整合。一位架构师 B 当场表示异议：这样我们不就从微服务退回分布式单体了吗？不同的微服务团队在开发时，我自己业务表结构随便改动一下还得互相通知，微服务从黑盒变白盒了？最后总架构出来定调，各微服务之间还是得保持独立，整合方案不通过，复杂度和性能问题通过其他方案解决，比如保底可以做数据汇聚服务，牺牲一点实时性。

• 第二个案例是一位架构师在拆单体时产生了疑惑，对于跨业务领域的系统，是应该拆细一点，一个领域一个微服务，然后领域之间的协调编排是在前后台中间的 BFF 做；还是拆粗一点，所有领域在微服务中放在不同限界上下文的聚合中，就在微服务的应用层来编排协调领域层（我们用 DDD），这样 BFF 就只是单纯为前端数据提供适配服务。

这个问题其实跟第一个问题是一样的，问题一中，如果抛开各系统统一采用微服务模式这个协定，回到分布式单体就真的不对吗？到底应不应该拆成微服务，拆到什么粒度？

• 第三个案例是一个大型金融核心项目，总架构老专家制定了一套工艺规范，由一条设计平台流水线支撑从业务建模到架构设计到低代码的全流程，强制要求从业务架构到应用架构到部署架构的一比一比一的完全对齐。比如一个产品模型落地成一个微服务，再部署成一个容器应用。

这个方案，你咋一听感觉可行性高吗？

分析

第一个案例中退回单体这个方案让大家感觉不太好，因为 monolith 巨石就像是把所有人绑在一坨，研发上线都得同进同退，这不是我们想要的。它的根本问题在于“耦合度”。我们常说我们要打造高内聚低耦合的系统，微服务牺牲了全本地调用的“一捅到底”的高性能，换来了各个子系统甚至可以技术异构的百花齐放。但就像第二个案例一样，我们拆分了领域，但是要拆子领域吗？“耦合度”到了什么程度才算是达成了高内聚与低耦合？这就是架构精华所在。

有个飞机机长聊过说什么是飞行精华，就是省油，在飞机降落的时候，用非人类的脑算力算出离降落地多远你需要开始以 30 下倾角的航线匀速下降，考虑包括高度，风力，航线密度，机场地形等等所有因素，能 30 度匀速落地最精华。“耦合度”的评判其实也是有计算因子的，比如业务关联性，这个功能是不是必须调那个功能 API；比如数据使用，如果没有公共服务，这个微服务是不是必须冗余那个微服务的数据模型，等等。这个时候开发人员发现，这些知识的理解能力和判断能力其实是业务分析师才懂的啊！怪不得 google 工程师说开发人员不要去瞎折腾，你不懂。

那么怎样做呢？案例三乍一看很不靠谱，哪有限制这么死的？你这样属于是掐死我设计的信念。但是现实里案例三如今已经基本走通了。凭什么？死板优于灵活？

现在设计到微服务拆分的时候，我们都提 DDD，它说在划分领域的限界上下文时，是需要业务专家参与的，是业务专家与技术专家协作，将正确的业务架构解析成应用架构，而这个过程，其实就是业务建模。所以当案例三将业务架构厘清的时候，应用架构照做即可。所以 google 文章的本质说的不是应用架构与部署架构相等就会造成灾难，而是应用架构错了，连带你抄作业的部署架构造成了灾难，如果你业务架构做对了，就算傻瓜式地一比一比一照搬，也能走通。

IT 架构不是如码农们口中简单的“分久必合合久必分”的技术轮回，这句正确的废话说的轮回只是因为做错了重新来调整。那从哪里开始才是正确的视角呢？以前只做开发的时候不知道 EA，没听过 TOGAF、Zachman。基本是跟着技术潮流走，大家吹什么我就搞什么。后来学习企业架构，思考业务架构驱动，才开始跳出代码盒子来思考。

如果是做业务系统的同学，do think out of the box；如果是跟马斯克一样是造火箭的同学，当我没说。

康威定律

上面的案例一还有一个隐含的问题，即使 DB 整合驱动组件整合这个方案就算被批准执行，这位架构也是推进不下去的。这里有一个背景是整个系统已经有不少服务在运行态，方案提出者只是一个微服务的应用架构师，而整合涉及到其他应用团队。可以代入思考，假设你是另一方被整合的微服务的架构师，首先你的系统需要重构，其次你的表设计需要与别系统的技术人员协商，你们两个微服务的设计会相互约束，很多修改都需要同步修改以相互适配。在这种情况下那位架构师来找你，请你配合修改你的系统，而与此同时你的微服务还在迭代开发业务功能，你如何决策？即使那位架构师请来了领导的圣旨，你会凑活了事还是真心配合？

表面上看，这件事是职场博弈，但其实背后是客观规律。康威定律是一个大概率的统计结果，它指出：什么样的团队组织结构，就会产出什么样结构的 IT 系统架构。以前在某保险的科技公司的时候，也是架构委员会里，一位科技总给大家出了一个题目：我司 IT 架构有很多冗余/未维护/挂起等等的系统，领导想做关停并转，大家觉得应该怎么做？我写了一篇文章交上去，后来科技总比较认同，来找我单聊。我说系统关停并转的关键不在系统上，在业务架构和组织架构，而在 TOGAF 理论里，业务架构是包括组织架构的。康威定律的表现是：IT 架构和组织架构是匹配的，只要有人在管理这个系统，那么你要处理这个系统，就得先处理管这个系统的人。如果没有处理好这个系统管理者，你想直接关这个系统，他会找出 N 种理由告诉你，这个系统有多少业务在跑，多少重要数据，你不能关。如果你先把业务线合并，把这个系统管理者并入新业务线的团队，去参与管理另一个系统，待遇不变，那么他并不 care 旧系统关不关，最多有点工作量去迁移。科技总点头如捣蒜说现在就是这样啊！我讲述了在前公司时，全行应用做关停并转伴随的是整个企业的 RE-ORG，业务条线先关停并转，合并后失位的中层 PM 全部走人，那场面可谓是“人头滚滚，血流成河”。他说那你们高管很有魄力，但国企是不能这么搞得。我说至此我确实也没有更多的建议，因为架构变革是需要自上而下的设计，自下而上的建设。一个基层应用的架构师想推动一个影响面很大的架构变革几乎是不可能的，因为决定航向的只能是唯一的船长，而不是几十个水手。

引申 - 架构与架构师

• 对架构工作的理解

开发同学问我这个问题，我说概念到处都有，如果你是问 IT 架构的技术知识范围，你可以去看看国家的架构师软考，它已经帮你框定范围了。如果要抽象出本质，每个人的答案可能都不一样。

七八年前当我还是开发的时候，作为架构师的备胎参加过架构协会的会议，之前我总是想这群抽象的组织里的架构师都在做些什么？第一次参加了以后，看他们吵吵着规范，标准，各种设计决策，准备一堆理论去 sell 自己的观点，去说服别人同意为你的方案买账。我问我的架构师，架构最重要的是什么？他说是 trade-off。Trade-off 不是 balance，不是平衡，平衡出不了好架构，架构是做取舍，你选你更看重的方面。当然这里面还涉及到非技术的博弈。

现在项目上的一个老架构在日常批人的时候喜欢说架构一半是技术，一半是审美。代码的尽头是艺术，没毛病，任何技的尽头都是艺，或者道。但审美是主观的，他的审美才是最好的，我们都是土鳖。

• 对架构能力的理解

IT 市场认为，架构师等于代码大神，技术攻坚者。

之前阿里的一个前架构师李智慧老师，架构课的班上，一堆程序员边听边叫：整点干货！因为他总是先讲 mind-set，讲心法，大家就觉得水。我想起刚工作的时候，一个 PM 说他是写 COBOL 的，现在的 JAVA 不会写了，但是看代码都能看懂，修炼的是“内功”。我当时不太懂什么是“内功”。后来遇到过一些技术同学，技术很好，写代码 6 得飞起，各种 api，设计模式烂熟于心。但是在设计一个完整系统时，一个劲闷头干，沟通 get 不到重点，设计的方案客户也不认可，协作方也不愿意配合，他也不明白问题出在哪。就像智商情商一样，架构师需要一种“架构商”，而不仅是码 code 的能力。甚至“架构商”是更重要能力，包括分析、理解、沟通、设计、协同、推进，以及最重要的-决策能力。

目前在我看来，Artitect 这个词就是对架构师最精准的描述，不是 Builder，不是 Engineer，不是 Designer，或者说不只是这些。Artitect 原义是建筑师，他需要懂力学、材料学、工程学、环境学、设计理论等等，但是他不一定是灰打得最好的、找平最准的、咬一口螺钉就知道刚度的人。架构师同理，他们所做的，是构建一种秩序，一种符合需求的、可行的、合理的、安全的、优美的，结构化秩序。

结尾

从应用架构设计问题聊到架构和架构师，逐渐跑题。以上都是个人观点，不为达成共识，只是希望能激发思考。借用发牌手杰克的座右铭：独立思考，知行合一。