微服务先行者 James Lewis：别纠结单体还是微服务，面向服务才是正解

SOA 架构（Service-Oriented Architecture）是指面向服务的架构，是一次具体地、系统性地解决分布式服务主要问题的架构模式。

SOA 的概念最早由 Gartner 公司在 1994 年提出，由于当时的技术水平和市场环境尚不具备真正实施 SOA 的条件，因此当时 SOA 架构并没有被广泛采用。情况直至 2006 年才有所改变：由 IBM、Oracle、SAP 等公司共同成立了 OSOA 联盟（Open Service Oriented Architecture），用于联合制定和推进 SOA 相关行业标准。

伴随着互联网的浪潮，越来越多的企业将业务转移到互联网领域，带动了电子商务的蓬勃发展。为了能够将公司的业务打包成独立的、具有很强伸缩性的基于互联网的服务，人们提出了 Web 服务的概念，这可以说是 SOA 的发端。 

在SOA架构中，所有组件都是独立自主的，并能为其它组件提供服务。要替换掉系统中的某些部分而不对整个系统造成较大的影响，本是个难题，然而只要维护好系统各模块之间的低耦合，该难题便能迎刃而解。大体上，SOA 与近些年流行起来的微服务架构非常相似，换句话说，微服务也可以认为是更细颗粒度的 SOA 组件。

某种程度上讲，微服务架构是面向服务的架构 SOA 继续发展的产物。

但在刚刚过去不久的 2022 年，一直被广泛采用的微服务领域发生了几件值得关注的大事儿。

其一，在掌管 Twitter 不久后，Elon Musk 对 Twitter 的开发团队 “批判” 了一番。他表示自己为 Twitter 在许多国家的极慢运行速度感到抱歉。之所以如此慢是因为 App 需要执行 1000 多个 “糟糕” 的批处理 RPC，而这只是为了渲染主页的时间线。Musk 表示 “现阶段的部分工作将是关闭臃肿的‘微服务’ 。实际上，只有不到 20% 的微服务是 Twitter 需要的。”

其二，GitHub 前 CTO Jason Warner 在社交媒体上表示：“我确信过去十年中，最大的架构错误之一就是全面使用微服务。” “任何构建过大型分布式系统的人都知道他们并不真的那样工作，但还必须适应它。”那么，微服务架构是否是一个错误，或者微服务是否已经过时了呢？

那么，微服务架构到底过没过时？除了微服务，还有哪些架构选型值得关注？架构师在做选型时该如何做出最“好”的抉择？带着这些问题，InfoQ 近期采访了 Thoughtworks 资深架构师 James Lewis，他也是国际公认的软件架构和设计专家。James 在Thoughtworks工作超过 17 年，时至今日，他仍然奋斗在编程一线上。

2014 年，微服务架构兴起之后，James 的工作重点是帮助组织制定技术战略、设计分布式系统和采用 SOA。多年来，James 一直在研究新兴技术，并通过技术雷达峰会推介这些技术。他坦言，只有站在巨人的肩膀上，他才能为这个行业做出更大的贡献。

在此次访谈中，James 谈及了他对技术开发的热忱以及技术如何改变了我们的生活。

在谈及从业以来他所观察到的技术演进时，他表示“微服务和持续交付是最深刻的两大技术变革。”

在被问及什么样的企业应该选择微服务架构时，James 称，“产品开发之初，没必要选择面向服务架构或者微服务这种强调无限扩展的选项。从结构良好的模块化单体架构起步，才是最明智的选择。等到需求迅速扩展之后再考虑微服务”。

以下为 InfoQ 与 James Lewis 的访谈实录，经编辑。

一项技术想要普世化，使用门槛不能太高，ChatGPT 就是如此

InfoQ：James，最近您在关注哪些技术？有关注最近热度爆炸的 ChatGPT 吗？

James Lewis：我自己一直在研究跟机器学习或者机器学习算法（即基于智能体的模型）相关的东西，但这跟 ChatGPT 并不完全是一回事。ChatGPT 非常有趣，人们也都在关注它。

之所以引起如此广泛的关注，是因为它的访问门槛很低。不只是像我这样的极客或者技术爱好者，技术社区中的所有人都能以非编程的方式来体验。

我还认识一位教师好友，他甚至开始在学校专门拿出时间，告诉学生们 ChatGPT 可以用来做什么、不能用来做什么。总之，ChatGPT已经在自上而下改变我们整个社会。从开发的角度，或者说开发者的角度看，我觉得应该考虑 ChatGPT 会不会被集成到 Visual Studio Code 这类环境中了。大到微软 Azure，小到各类搜索引擎，各方都在像拥抱自动驾驶那样拥抱 ChatGPT。

所以在我看来，这绝对是接下来几年的最大热点。而且新版本不是很快就要出来了吗，在 4.0 版本亮相后，相信会更有趣。

InfoQ：您亲自体验过 ChatGPT 了吗？

James Lewis：我还没试过。很遗憾，我一直没腾出时间来。

InfoQ：那等您试过我们再来聊聊感受吧。众所周知，ChatGPT 大火后，AI 热度再次高涨。那您认为云计算和 AI 的崛起对 Thoughtworks 的技术发展将会带来哪些影响？

James Lewis：我觉得有趣的进展正在出现，也诞生了不少非常有趣的成果。未来还会有哪些惊喜在等着我们目前仍是未知的。我认为，机器学习的崛起和在线机器学习的可访问性的发展趋势已逐渐明朗。

ChatGPT 无疑也是这波浪潮中的一个助推力。除此之外，我们将有能力在手机上运行TensorFlow之类，或者深入访问到原本只有数据科学家和从事项目工作的开发人员才能接触的技术。

所以我觉得，这肯定是个令人兴奋且值得探索的方向。另外，Thoughtworks 在芬兰赫尔辛基设有办公室，在那里工作的是一群机器学习专家。他们正在努力开发机器学习酿造威士忌的第二个大版本，就是用机器学习算法来帮助威士忌设计风味组合，有很多创意是人类根本想不到的。

到目前为止，他们已经赢下两项大奖。所以这挺有意思的，包括机器学习和数据科学的实际应用。再有，我对Kuberentes的持续崛起也很感兴趣，如今 Kubernetes 和容器化几乎已经无处不在，甚至成了目前最普遍的客观运行时标准。我觉得这股趋势还将持续下去。

2015 到 2020 年间，Java 曾经承诺提供广泛可移植性。而直到多年之后，这种可移植性才由 Docker 和 Kubernetes 真正实现。

“微服务和持续交付是最深刻的两大技术变革”

InfoQ：技术总是瞬息万变的，在过去一年，Thoughtworks 发生了哪些让您印象深刻的事？

James Lewis：我觉得这期间最有趣的一件事，就是 Thoughtworks 向着可持续性、特别是可持续计算的真正转变。这种转变不再是单纯跟风，而是主动求变。

如今，各个行业都在讨论可持续性问题，讨论如何编写更多可持续软件，如何将更多可持续软件交付至生产当中。我们的CTO Rebecca Parsons博士就很关注这个问题，而且投入了很多时间。我们的广泛云迁移其实加深了这个问题的现实意义，因为我们已经能随时随地使用计算和存储资源，不太用考虑资源边界的问题。但这也衍生出来了新的问题，就是开发者在编写代码时不太重视对机器、硬件和软件的充分利用。

比如说，我们遇到的一个现实问题就是机械同感。提出这个概念的人叫 Martin Thompson，机械同感是指所编写的代码要能完全利用硬件资源。也就是说，如果负载在一、两台机器上就能运行，那就别用 10 台甚至是 50 台机器。这样，我们可以大大节约耗电量。

虽然我们 Thoughtworks 还没有在这方面倾注全部精力，但很多客户确实都在咨询。市场上似乎出现了一种普遍情绪，所以我们也是时候认真考虑手头工作的可持续性了。

InfoQ：所以您想说的是，想让代码能够完全利用硬件资源，就要优化旧的代码，对吗？但优化代码可并不容易，您能分享一些对优化代码的思路吗？

James Lewis：这是个很好的问题。没错，这事绝不简单，特别是在当下。也许我说得有失公允，但整整一代软件开发者其实是把大量时间花在了拼接上，他们主要用JavaScript做开发。

但突然之间，你去要求他们优化代码来匹配芯片和裸片上的 L2 或者 L3 缓存，从而实现特定的数据结构、应用数据原理，或者是把数据聚合在一起，这对他们都是前所未有的新技术。实际上这些技术并不新，但对他们来说很新。而只有这样，才有可能真正充分利用硬件。举个例子，LMAX 有种模式叫 disrupter pattern，我们在 Tech Radar 上用过，大概是六、七年前的事了。那里面就体现了真正的优化和机械同感思路，能让用户在一台笔记本电脑上运行大量并发工作负载，从而通过单一线程每秒运行数亿条消息。真的很棒。

如今我们跟大家交谈，他们总会说需要大量云端资源才能实现某个目标。但实际上，如果大家真的熟悉硬件、理解底层技术，就会知道代码完全可以跑得更快。在本质上，就是使用更少资源，创造更健康的自然环境。

InfoQ：听说您已经在 Thoughtworks 工作了 14 年以上，这么多年的工作经历中，您感受最深的技术变革是什么？

James Lewis：其实我在 Thoughtworks 已经不止 14 年了。这是很长一段时间，感受深刻的变革也太多了。我在这里接触过太多工作类型、见过太多出色的人，也感受过无数影响深远的变革。但如果纵观整个技术发展历程，就会发现其中大部分成果诞生在过去 10 年之内。

我最先想到的应该是持续交付与持续部署。其实相关概念早在 2011 年前后就出现了，但现在每个人都在对从构思到生产的整个编码路径做优化。我的好友 Daniel 就说过，他特别喜欢自己的灵感能化为客户的一句“谢谢”。他特别喜欢那种“你很好地完成了工作，谢谢”的感觉，既友善又温暖。我觉得这挺好，但应该不止于此。随着持续交付，基础设施也成了代码，于是我们开始将基础设施定义为可应答的成本要素。同时，Docker也掀起了新的革命，意味着我们能以基础设施即代码的形式全面实现可移植性。

同样，大概是在 2012-2015 年间，Docker 容器化也开始崛起，之后就是微服务。这是一组相互补充、彼此强化的要素，而且能在基础设施即代码所定义的容器运行软件中作为一个整体。它们会被不断部署和分配到生产流程当中。大家可以看看如今软件应用的广泛程度，这就是所谓持续交付时代的基本面貌。

所以在我看来，印象最深的变革就是两个，持续交付再加上微服务。大概就是这样。

InfoQ：持续交付和微服务这两个技术话题也在 Tech Radar 上被多番讨论过。我了解到您其实最初参与创建了技术雷达峰会，当时创建该峰会的初衷是怎样的？现在来看峰会的发展与您预期的一样吗？

James Lewis：问得好，技术雷达峰会确实值得聊一聊。其实我不是最早加入的人，大概过了两年才开始参与。但我之后确实参与了很久，我觉得当初的想法应该是为了适应 Thoughtworks 内部的规模扩展。我们在 2010 年的时候经历了一波业务大扩张。我入职的时候是 2005 年，当时公司才 600、700 人。但 2010 年的大扩张让员工数量一下子增长到好几千。

我们希望了解哪些机制有助于把握大家都在做什么，毕竟待在伦敦的我很难理解深圳那边的同事每天做了什么、用了哪些技术或者做了哪些创新。所以不只是我本人，还有公司 CTO Rebecca Parsons 博士。她决定成立一个小组，大家每 6 个月聚在一起分享知识和内部传播结论。

初衷就是这样，但最终技术雷达峰会一路发展成了行业中广为人知的形式。其实很多理想的结果都是这样，源自一个小小的、美好的意外。

SOA 架构和微服务架构各有利弊

InfoQ：除了技术雷达峰会，SOA 架构算是您重度参与的另一项工作了吧。您从事软件架构工作很多年了，最初为什么想要在某些项目中引入 SOA 架构？

James Lewis：没错，我从事架构设计已经很多年了，在 SOA 方面也有丰富的经验。我觉得 SOA 的有趣之处，在于它确实跟我们的软件构建思路高度一致。

长久以来，我们一直认为在提供软件时，一定要以小的、垂直切块的形式交付。就这样，一块、一块提供相应的软件功能。我最近听到个很好的表述，这里分享一下。架构这就像一块三层蛋糕，从下向上分别代表着底层数据库功能、UI 和服务。要想吃这块蛋糕，那三层都不能少，口味叠加起来才是最美妙的。没人会一次只吃横向的一层。我们也是这样，想让软件构建像蛋糕那样提供垂直上的组合效果。

目前整个行业的问题在于，咨询公司和供应商确实都在积极推销这类解决方案。他们先是提出问题，然后给出看起来很美的 SOA，之后几年里他们不是交付产品而是彻底消失了。他们可能会拿一年来设计，再消失三年慢慢做开发，而客户这边把钱交出去然后慢慢等。这要投入巨额资金，而且至少要等 4 年才能看到成果。整个期间没有产出、没有影响也没有价值，更要命的是这段时间里世界一刻没有停止变化。因此，我发现面向服务架构才是真实、可行且有价值的软件构建方式。让我意识到这一点的是一位叫 Jim Weber 的同事，他现在在 Neo4j 工作。Jim 提出了 Guerrilla 面向服务架构的思路，从各方面来说他就是微服务架构的先驱。

Guerrilla面向服务架构基于之前提到的垂直切块原理，所以不需要苦等 3 年才得到一点软件成果。正确的答案，是通过服务构建切块，并通过短期增量、价值交付和业绩提升等方式体现回报。这才是对软件意义的证明，也让 SOA 开始真正改变游戏规则，帮助大家以分步迭代的方式进行交付。另外还有一点，当时我正从事多个项目，并从中发现了 REST 等多种特殊的集成模式。面对 Web 服务、SOAP、WSSTAR 等重量级协议时，开发人员往往难以把它们真正用起来。

于是我开始寻求其他可行的选择。后来我接触到了《REST in Practice》，一本由 Robinson、Jim Weber 两位同事与微软专家合作撰写的书，并意识到 RESTful 架构就是答案。

对我来说，这就是颠覆性的时刻，因为使用 REST 的各远程系统间能够更轻松、更便捷地实现集成。另外，还可以在更小的有价值组件之上部署和构建，让小东西也发挥经济、功能或社会价值。软件的意义不就在这里吗？

InfoQ：在起步之初，您的团队规模是怎样的？

James Lewis：已经过去很多年了，我可能记不太清，但我从各 SOA 团队中学到了很多东西。我觉得 SOA 的最大优势，就是让大家只面对为期 12 到 18 个月的单一项目，负担不会过重。所以从 2005 年到 2014 年，我们作为咨询公司发表了关于微服务的论文。我也接触过很多客户，而且一直在跟最睿智的头脑一起工作。

我接触过很多真正的思想领袖，包括 Daniel、Jim Weber、Ian Robinson、Dave Farley 和他的持续交付日、Rebecca Parsons，还有 Martin Fowler 等等。所有这一切，促成了我们在 2014 年创立微服务这个概念。

现在回忆起来，我们的大部分思路是在 2011 年确定下来的。当时我们正为大型零售商打造忠诚度管理平台，需要构建一套面向服务架构。大家去超市或者商场应该都见过那类会员卡吧，当时开发团队大概有 60、70 人。顺带一提，我们在美国的合作出版商就是 InfoQ，所以我们第一次讨论微服务就是在旧金山的 QCon 峰会上。当时是 2013 年，所以我们把它形容成“Unix 式的 Java”。演讲内容就是如何用这些小东西构建软件，如果让各组件彼此通信，这就是后来的微服务和SOA这类东西。

InfoQ：与其他架构相比，您认为 SOA 有哪些优势和缺点？

James Lewis：问得好。其实不好讲，因为之前我也提到过，像 SOA 这样由小服务构成的微服务架构正在占领整个世界。目前大多数软件都是以微服务作为主架构的，这非常有趣。之所以能吸引到那么多人用这种架构方式构建软件，肯定是因为它有做对了的地方。

同时，我记得之前在内部邮件中也讨论过构建方面的具体需求。如果你只需要构建一个简单的 Web 应用程序，而且面向的只是公司内部用例，那要不要使用微服务？我的答案肯定是别用。最好是用简单的办法构建一个单体式架构。甚至选择服务器端渲染，连 JavaScript 框架都没必要，单纯做做 CSS 和服务渲染之类。因为微服务架构的核心优势，就是能沿多个角度进行扩展，对吧？微服务架构是唯一能够实现垂直扩展的选项，匹配的也是那种体量更大的项目。

也可以横向扩展；或者每次添加一项微服务来按业务功能进行扩展，专注于特定业务需求。这就形成了三条可扩展轴，非常强大。另外，微服务和 SOA 也给了我们实现人员扩张的能力，也是我早期进行研究的动因之一。我们该怎么解决团队规模扩大的问题？团队越大，能完成的工作就越多，对吗？但大家应该听说过，Fred Brooks 在《人月神话》里提到过，如果在项目后期再添加人力，那么人数越多沟通成本就越高，协调难度就越大，反而提高不了产出。

到了特定的临界点上，为了保证人们朝正确方向努力的协调成本，就会超过增加人手所带来的生产力提升，导致扩张没有任何效果。

那该怎么办，有没有可行的方案？通过分析，可以发现扩大人力规模的办法就是构建很多小东西，让团队分别构建小东西。最后再把这些小东西组合起来。这样，就能显著提升团队的规模上限，最终水平会远高于所有人都做同一项工作的方式。

这就是两个最大的优势。还有其他优势，但我觉得这两点最重要。至于缺点嘛，事实证明当很多小组件彼此通信时，必须要借助网络。但人们经常忘记这种对网络的依赖，忘记分布式计算本身的难度很高。这就是 Martin Fowler 提出的分布式计算第一定律，即我们很难理解不同事物间一致性模型上的权衡。能不能只保持最终一致性？我们得运行分布式事务，协调难度很大，也不容易做好。很遗憾，我听说过很多服务失败的故事，那可以说是很多人一辈子见过的最混乱的场景。现在“分布式模型”已经成了有名的硬骨头。

但好处是，这么多相互独立的东西可以被分别部署给各个团队。每个团队将其中一项部署到生产流程当中，专门对其负责。他们可以根据适合自己的速度做出变更。

但现在，很多团队并没有真正理解这个思路。他们构建出一套紧密纠缠的架构，部署的仍然是完整的流程。这样的方案其实继承了单体式架构的所有缺点，因为所有内容还是一次性部署的。另外，它也有着 SOA 的所有缺点，因为一切协调都得经过网络进行，各自的内容还受到一致性和 Tap 理论之类的干扰。

所以对我来说，SOA 架构的三大优点就是良好的人员扩展支持，沿垂直、水平和商业功能的灵活延伸能力，还有强大的可独立部署性。至于缺点嘛，就是依赖于网络。大家一定要意识到，分布式计算很难。另外就是各组件之间经常会处于纠缠状态，逼迫我们一次性部署所有内容，最终导致架构优势的丧失。

InfoQ：您能介绍下最初 SOA 架构采用过程是什么样的？过了这么多年，在您看来，当初的 SOA 架构跟现在的 SOA 架构之间有什么差异？

James Lewis：这个问题很好。我之前也提到了一些，最初的 SOA 其实就是把组织结构分成几大块，再封装起来。这里我说的是 2005 年甚至更早的情况。我们认真审视了各种业务功能，并把这些业务封装在一个个大块的服务当中，之后再让各服务间相互通信。前面也提到，其中很多环节是由流程驱动的，包含很多分析元素并最终发生了质变。

所以在我看来，最大的进步就是按照价值构建成果、部署成果这个基本思路。

这是我想说的一方面。这是个很大的变化。在多数人、多数组织当中，这代表着颠覆性的心态转变。事实上，组织之所以要用 SOA 来交付软件或者服务，是因为我们当时并没有固定的构建团队。而其他很多组织是有这样一支团队的。当时大家习惯了签份合同，然后三年后交付成果并希望不出乱子，对方能顺利付钱。但现在的情况已经不同了，随着时间推移，我们的团队开始转向逐步交付。另外一个方面，就是伴随着开源的崛起，我们在集成方面有了很大进步。开源集成技术确实具有轻量化的特点，开源集成技术也改变了我们构建面向服务架构的方式。现在，我们不再依赖 WS、SOAP 之类的 Web 服务规范，也不再依赖各种协调和编排协议。这些协调和编排协议体量都很大，是由 schema 驱动的而且之前很长一段时间都在被广泛应用。

所以我认为通过 RESTful 服务、GraphQL 还有 grpc 和 Google rpc 之类的成果，我们已经可以享受到免费的开源标准。

对我来说，这其中代表着很大的差异。今年的差异又体现在哪里呢？我之前也提到过，目前最重要的是大型企业正在巩固软件状态，并尝试对遗留系统或者说传统系统做现代化改造。他们会向那些专门提供大型企业服务总线的厂商求助，参考他们的指导。企业服务总线支持下的 Web 服务，其实就形成了 SOA 架构。我认为现在的主流，就是大多数组织要么打算对遗留系统进行现代化改造，要么就是像 Netflix 和 Twitter 那样打造全新产品。而这一切，用的都是微服务 SOA 架构。

除了对原有体系进行现代化，还可以探索扩展性更好的新架构。

SOA 架构演进到新阶段了吗？

InfoQ：您认为 SOA 架构发展了这么多年后，已经演进到新的阶段了吗？

James Lewis：我觉得是的，微服务也一直在发展。所以作为一种特定的 SOA 类型，微服务在刚诞生时虽然有着明确的概念，但却并没有对“微”是多大做出定义。不好说是因为我们有先见之明还是干脆先不管它，反正那时候我们没有硬性约束微服务的大小。

所以多年以来，对于微服务是什么、能用来干什么的具体理解一直在变。我的同事 Martin Fowler 发明了一个新词，叫“语义扩散”。他说的就是随着时间推移，单词的含义会发生变化。在刚刚被造出来的时候，这个词对应的就是某种特定的事物。但随着时间推移，单词的含义会有所改变。敏捷就是个例子，敏捷软件开发在刚诞生时指向的范围很窄，但现在敏捷软件开发的范围已经很宽泛了。我觉得微服务也是这样，而且对于任何重要的概念，比如说 SOA，其含义都会随时间推移发生改变。

InfoQ：在您看来，什么样的企业适合 SOA 架构，小型初创公司还是大型企业？或者说其实都可以？

James Lewis：这个问题我得谨慎回答，不然以后人们会说“James 建议人人都用微服务”。其实并不是这样，我觉得用不用取决于需要解决什么问题，达成怎样的结果，还有什么时候需要得到这个结果。比如说我是一家掌握大量遗留系统的组织，正打算进行现代化改造，那么要不要考虑使用微服务架构？

这种情况下我会推荐用微服务，因为摆脱遗留系统的稳妥途径，就是从遗留软件中提取出稳定的业务能力，之后找到所谓的“接缝”，之后再把功能迁移到新软件和新应用当中。这时候微服务往往是合适的。

所以我觉得这是个好办法，但这要求你对自己的业务拥有清晰的认识。

你知道你自己在做什么，目前有什么。如果你是一家零售商，主营业务就是把货品送到大家门前。那你就可以建立一套明确稳定、以配送交付为核心的系统。

但如果是在构建新产品，那大多数组织其实并不受历史因素的约束。在这方面，Netflix 是个很好的例子。再说亚马逊，他们不是从面向服务架构起步的。亚马逊从大型数据库和大型传统 NTS 架构起家，但随着不断发展，他们意识到除非转向微服务，否则业务就无法进一步扩展。所以 Netflix 的前技术负责人 Adrian Cockcroft 毫不犹豫，果断决定协调亚马逊迁移上云。他也借此成为细粒度面向服务架构（也就是微服务）的先驱之一。可这也绝非冲动之举，因为无论是 Netflix 还是亚马逊，都从多年之前就已经在以这种方式构建软件了。所以迁移上云不会是太大的问题。这里我想到哪就说到哪，语言可能有点乱，多多包涵。

概括来讲，就是对于一家初创公司，你的目标就是赚大钱，想成为新的 Twitter、新的 TikTok 之类。在这种情况下，到底要不要从微服务架构起步？我觉得这个也有待商榷。

我个人甚至更倾向于反对。谷歌有位架构师提出过很好的建议，他说在初步设计时按当前用户规模的 10 倍规划，等业务增长到 100 倍时再重新设计。所以别考虑什么无限扩展的问题，你可能永远都没有那么多用户。按目前的实际情况构建，能扩展到现有负载的 10 倍就足够了。

而一旦到了这个节点上，再重新设计更合适的架构，通过整体重建支撑起更大的规模。因此，我的建议基本是在产品开发之初，没必要选择面向服务架构或者微服务这种强调无限扩展的选项。从结构良好的模块化单体架构起步，才是最明智的选择。等到需求迅速扩展之后再考虑微服务，之前我们已经具体讨论过它的利弊了。

软件开发和软件架构的选型确实很难，我讲得可能太具体了。幸好到我这个岁数，就不用再亲自做那方面工作了。

一名优秀的架构师应具备哪些核心能力？

InfoQ：您有超过 20 年的架构师从业经验。想成为一名优秀的架构师应该具备哪些核心能力呢？

James Lewis：这是个非常非常好的问题。现在我会从 SOA 的角度来看待这个问题。总体来讲，我们强调的是角色的概念、而不是人。所以我经常扮演架构负责人的角色，而架构被普遍视为一种活动。团队必须保证项目能够跑通，而负责保障目标达成的就是负责人，你可以称其为架构师、首席工程师或者高级工程师，意思是一样的。

对我来说，我对这样的场景非常熟悉，因为我一直在跟特别优秀的人们合作。我觉得最重要的技能应该是沟通。我的理由是，这个角色需要跨多个部门开展沟通，包括跟负责软件的开发人员沟通、跟客户沟通，还得跟组织中的其他同事沟通。

还有运营安全，所有这一切都得上下打点。Greg Hohpe 在《The Architect Elevator》中提到过，架构师必须有能力坐电梯直通企业“顶端”。就是说，你得有能力跟董事会成员打交道，而且要学会使用他们熟悉的语言。沟通永远是其中的关键。

另外一点就是同理心。我觉得同理心是一种很好的特质，友善就是它的典型特征。

面对他人对你自己或团队提出的要求，你要理解他们为什么要这样提、他们是哪个部门的。我自己就经常跟客户、业务还有运营那边的同僚们吵架。这不好，我们必须得能理解彼此的出发点，这样才能找到通往最佳结果的解决方案。

我觉得一切技术工作都遵循此理。我可以列出一大堆书，大家可以去读、去学、去理解。我觉得编写代码也很重要，直到今天我也一直没停止过编程。但相比之下，我感觉软技能仍然是最重要的部分。

InfoQ：我很好奇，优秀的架构师给公司创造的核心价值是什么？为什么同理心很重要？

James Lewis：我认为可以说是同理心。毕竟在这样的场景下，你会期待从别人那边得到什么呢？

除了同理心之外，另一大核心价值就是经验。他们有阅历，而且这种阅历不是 20 年间重复做相同的事。有个老笑话，你有多少阅历？是那种 10 年间持续积累的阅历，还是 10 年间永远重复同一年的阅历？我觉得最重要的价值，就是把这份阅历跟乐于倾听的同理心结合起来，彻底理解对方的观点。这真的很重要。

嘉宾征集：

什么是技术情怀？在很多人看来，是热爱、是思考、是卓越。这个时代或许有人功利、或许有人内卷，但我们依然愿意相信更多人依然怀揣着用技术改变世界的初心。《The Great Geek》（了不起的极客）是 InfoQ 重磅推出的全新内容栏目，全年共 8 期。自栏目推出至今，我们专访了 MySQL 数据库和 Maria DB 创建者 Michael “Monty” Widenius、iPod“之父”Tony Fadell、Thoughtworks 全球 CTO Rebecca Parsons、《代码大全》作者 Steve McConnell，如果你身处的企业中有这样的技术领袖想让我们报道或你希望看到哪位技术大佬的采访，请在评论区留言联系我们。