访谈文章|Interview

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

作者 李冬梅 审校 蔡芳芳

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

SOA的概念最早由Gartner公司在1994年提出，由于当时的技术水平和市场环境尚不具备真正实施SOA的条件，因此当时SOA架构并没有被广泛采用。情况直至2006年才有所改变：由IBM、Oracle、SAP等公司共同成立了OSOA联盟（Open Service Oriented Archi tecture），用于联合制定和推进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的访谈实录，经编辑。

视频地址：https://www.infoq.cn/article/h1BYRQgH4zZqhLPVZArS

一项技术想要普世化，使用门槛不能太高，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》，一本由Rob inson、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年间永远重复同一年的阅历？我觉得最重要的价值，就是把这份阅历跟乐于倾听的同理心结合起来，彻底理解对方的观点。这真的很重要。