InfoQ 在新兴技术企业大会上对 Lightbend 企业架构师 Kiki Carter 的访谈

Kiki Carter，Lightbend 企业架构师，在 2017新兴技术企业大会（Emerging Technologies for the Enterprise，ETE）上发表了题为“Somm”Lagom: Building Systems That Age Like Wine 的演讲。

“Somm”取自 2012 年的同名电影，电影讲述了四位美国侍酒师如何经过刻苦学习努力拼搏而通过“Master Sommelier”考试的故事。Carter 用这个比喻来阐述软件应用应该如何像好酒一样持久。她介绍了企业开发人员在快速系统建立的新时代所面临的挑战。这些挑战包括：

• 选择太多，陷入分析瘫痪状态
• 难以衡量伸缩架构的完整性
• 需要专家
• 未预计到的复杂性或杂乱问题

她向我们介绍了 Lagom ，Lightbend“自定义”的微服务框架，该框架基于 Akka 框架和 Play 家族产品，并且介绍了 Lagom 如何解决当今企业所面临的挑战。Carter 认为，“快速的变化通常意味着快速老化。”总的来说，她认为“为了与变化保持同样的步伐，并且在发展过程中保持架构的完整性，可以尝试使用能够在应用层面之上——也就是系统层面提供抽象的框架。”

InfoQ：你在 Lightbend 工作多久了？你目前负责的工作是什么？

Kiki Carter：我是去年七月加入 Lightbend 的，等夏天到了就满一年了。其实作为消费者和客户，我与 Lightbend 的合作已经有 5 年了。

我是 Lightbend 的一名架构师。我的大部分工作涉及到与更大的企业公司的互动，我要帮助他们更好地理解我们的技术，当我们有新的特色和软件产品时，要描述给他们，能够传播给他们，并且在那些公司内部增加我们软件的使用和采纳量。也许他们由小项目开始，看到了好处，然后想扩展，并且有了发展。我也会参与这些。让我们的团队能真正地在企业内部发展我们的响应式技术，这才是我工作的核心。

InfoQ：Bold Radius 开发应用并且提供了关于 Lightbend 的咨询服务。OpsClarity 开发了用于监控响应式系统的工具。这两家公司都是最近被 Lightbend 收购的。这一收购会怎样影响 Lightbend 为他们的客户提供服务的方式呢？

Carter：这是个很好的问题。我从 Bold Radius 开始讲吧。首先，收购过程中带来的事情之一在于它让我们能服务更多的客户。我们还在和其他具有同样业务的公司一起合作，包括提供专业服务。如你所知，我们不是一个咨询公司，我们要让公司不仅能使用我们的技术，更重要的是在它们的组织内部传播这些知识，这样我们就可以离开，然后让他们接管，从这一点上来看，收购确实为我们带来了好处。我们更关注让我们的客户和合作伙伴自己去完成所有的工作，而不是凡事亲力亲为，最后来一个草草的“交接”。

再说 OpsClarity，这是另一个有趣的方面，我们能提供给客户更好的方法来可视化他们的远程监控。如你所知，监控异步和响应式应用以及分布式系统不是那么简单的事情。我们用 Lightbend 监测系统提供的远程监控至少在监控那些软件上真的帮到了人们。但是 OpsClarity 所带来的，是这种监控的另一个层面，它通过给人们提供一些很棒的可视化工具，让人们对他们的系统有一个很好的鸟瞰视图。OpsClarity 内建了可视化能力，以及能够用于检测异常的人工智能。我们将它的监控系统进行进一步开发，让企业开发团队真的从中受益，并且以一种更智能的方式去使用它。

InfoQ：微服务在过去几年一直是一个很有意思的话题。根据 2016 年度企业发展趋势报告，各种组织在以下几种情况的分布很平均：（a）在生产环境使用微服务，（b）正在考虑使用微服务，（c）在沙箱环境试验微服务，（d）对微服务完全没有兴趣。还有不少针对使用微服务的开发者的警告标语，包括“微服务的七宗罪”。这传达出的信息似乎是“谨慎使用微服务”。针对这些顾虑，Lightbend 有没有什么能做的呢？

Carter：当然，而且我觉得“谨慎使用微服务”这句话说的没错。在人们使用微服务时，如果不够谨慎，那么在行业生产中会造成巨大的反作用，如果没有正确使用，你会经历混乱，然后退缩，并且抗拒改变。但是，我们需要注意的是，我们需要一个能够在系统构建层面提供抽象的框架，用于封装架构最佳实践。所以，在构建微服务时遇到的错误或让你头疼的地方，推荐你使用我们的框架 Lagom。Lagom 是专为微服务构建的，我们对最佳实践、设计模式、架构原则，甚至是用到的底层技术和工具都进行了编码。只要使用 Lagom 的语法，几乎就能完全担保你正确编写微服务程序。这就是 Lagom 的魅力所在。它能解决技术问题，虽然它是在其他应用、框架、库以及工具上的一个抽象，Lagom 将它们集成以让你用一种便捷的方式解决这些问题，即在保持架构完整性的同时，能够传递不仅仅是技术资产，同时也包括与你的系统设计有关的东西。这其实是 Lagom 的设计原则——确保你正确使用微服务，并且努力帮你避免混乱。

InfoQ：你认为应该怎样使用微服务？

Carter：我认为微服务的用途在于分解一个单体，但其目的不是在于分解一个单体，而是为了能让你更快的向客户和用户实现交付。它们需要更快的交付功能，能够让你的系统容错性更强，具备隔离性，以及能让你的系统随时间变得更强大，随时间发展，以及在系统的寿命周期内变得更加成熟。现在，改变发生的太快，所以快速改变系统，快速构建系统，以及修改它的能力已经成了使用微服务、以及用一致的方式管理微服务者必须注意的一个领域，它能帮助你的系统优雅地走向成熟。

InfoQ：关于你所说的分解一个单体，可以理解为应该使用微服务来开始开发一个新应用吗？

Carter：是的，但是你应该重新使用你的单体系统的某些部分。我不是说为了使用微服务，你就要毁掉整个系统然后重新开始。如果你使用 Lagom，就不需要这样做。你可以按功能特性而不是按特定的技术模块来分解单体。如果你按特征分解，你只需要抽取目前的模块，进行组合，或许再加入一些其他东西，让特征自己变成一个新的服务。这样以来，新服务能够在你继续分解当前的单体时很好地进行互动。

InfoQ：你如何看待接下来的五年之内，SMACK 技术栈在软件开发中将变得更为重要这一说法？

Carter：这是个很好的问题，我认为它会更快地占据主导地位。接下来的五年，肯定会出现别的东西，但是至少现在，在当前数据经济的背景下，我认为 SMACK 技术栈被大量使用的原因在于其数据的丰富性和进行大量计算的能力，并且速度很快。我们在 Lightbend 不说“大数据”，我们说“快数据”。这一概念在于它能够根据系统中现有的数据对系统进行深入了解，并在其老化之前快速地对其进行操作。现在，数据老化速度变得更快了。如果你需要快速地提供一个广告服务，或者是快速地做出，你需要能实时地做出这些决定。而 SMACK 技术栈能让你实现这个目的。在我看来，接下来的五年将是这个技术栈变革的五年。举个例子，当下我们认为占最大主导地位的是 Kafka 。也许在未来，分布式的、提交日志式系统的竞争中还会有其他对手。Uber 的工程师开发了 Cherami ，跟 Kafka 类似，但并不是完全一样。我认为将来技术栈将是非常普遍的，因为人们已经将其组合在一起了。这些是领域内最好的，但我认为随着时间的变化它也会变化，而且你会看到更多的人们加入构建这个技术栈。我发现 Spark 一直以来都很活跃，但我也发现 Flink 和 Beam 的重要性一直在提升。我认为这个快速数据领域在未来一定会有所发展。在某个时刻，我们会看到解决问题的技术出现爆发式的增长。然后在之后某个时刻，又把它拉回到仅有少数技术的情况，说，“我们要以它们为标准”。

InfoQ：你如何看待响应式编程 / 响应式系统在未来五年的变化情况？

Carter：在这一领域我确实看到了一些明确的转变。有一件事，至少在响应式编程领域中，我们还需要缩小一些差距。很多时候，当人们谈论响应式编程时，他们关注的是异步通信，比如异步 I/O 和非阻塞通信。但是，当我们在 Lightbend 谈到响应式系统或响应式编程时，远远不止这些。Reactive Manifesto 说明了人们是如何看待响应式的，响应式还需要处理容错和灵活性问题，而容错和灵活性是在构建系统时必须考虑的问题。当你仅仅进行响应式编程时，如果你在构建一个单体，或者一个响应性单体，或许你可以暂时忽略它，但是你一旦开始将系统组合起来，那些需要相互连接并协同工作的系统的容错能力、弹性和灵活性就是你必须考虑到的。我的意思是，比如说不依赖一个粗粒度灾难恢复类型的解决方案，这种方案一般仅使用容器、VM 或一些东西来说明自己的弹性；而应该在依赖外部容器、或 VM、或云平台之前就多多少少在应用层面具备弹性，这两者之间是有些细微差别的。

InfoQ：我在某处读到，自从 Java8 包含了函数式编程，用 Scala 构建的应用数量有所下降。关于应该选择 Scala 还是 Java 来构建应用，你对开发者有什么建议吗？

Carter：其实 Java8 的发布不一定是人们越来越少地使用 Scala 的原因。同一时间里还有别的事情在发生。也许那些用 Scala 的人们决定试试 Go，或更多地开始使用 JavaScript 框架。这几个事情之间不一定有联系。我认为，这个领域的很多公司一直在推动 lambda 函数式编程，他们已经来到了这个领域，并且给人们提供了尝试使用熟悉语言的空间。

如果有人让我在 Java 和 Scala 之间选择一个，选择结果应该跟你的商业目标有更紧密的关系。你公司的目标是什么？你团队的目标是什么？商业目标是什么？比如说，如果你的工作中有大量数据，或者你工作的环境要求真实数据的连贯性，你应该使用 Spark。在 Scala 中使用不可变结构是很自然的一件事。这差不多是默认的。而使用 java，你必须通过不同的方式来保持数据结构不变性。Java 或许可以给你像 lambda 这样的东西，但它不能真的保证你能在没有任何副作用、没有非不变性数据结构的情况下，获得函数式编程的全部特性。如果你的开发团队已经习惯于使用命令式编程，或习惯于转换对象，而不是创造对象，这基本已经是人们使用 Java 的一种方式的范式转换。如果你不想落后，就应该以一种函数式的方式来使用 Java，而你并不需要去了解 Java 编程习惯的变化。而如果你在使用 Scala，那么你就已经是在那样做了。这确实取决于你的目标是什么。如果你真的想建立一个高度并发并具有良好数据完整性的系统，我会建议你去研究一下将不变性作为关键特性的语言。

这只是一个例子。但是，我会列出一系列人们会优先考虑的事情，甚至包括他们的最终目标。投资总是没坏处的，即使你在培训或学习上投资，或投资于你的最终目标。如果你投资学习 Scala 是因为它能帮助你更轻松地实现特殊的模式，那么这是一个好的投资。但如果说已经知道了 Java，而且你设计应用时实现那些模式很困难，那你就需要考虑一下这个投资是不是值得了。

InfoQ：有意思。而且有趣的是这两个语言都可以编译成字节码在 JVM 上运行。

Carter：如果真的选择不了，那就做你觉得最舒服的事吧。不要封闭思想，对于系统的变化要持一种开放心态，因为 Scala 和 Java 像你所说的都可以编译成字节码在 JVM 上运行。它们的伟大之处，在于你可以朝着某个方向开始，然后随时进行改变。它们都具有良好的互操作性，所以你不会在字节码层面上丢失任何东西。

InfoQ：关于你自己还有什么是想让我们的读者了解的吗？比如你的作品，或者我错过的任何其他内容？

Carter：我喜欢旅游，而且去了很多国家。我喜欢在鸟瞰和跳伞的视角来看风景，但我有恐高症。我会去做我害怕的事情，是因为没有别的办法可以达到我的目的。除了跳伞，我没有别的方式能看到我喜欢的美丽的鸟瞰图，所以即使我恐高，也不能阻止我去玩跳伞。有意思的是，我是在和架构组织一起工作的时候发现这一点的，他们已经进入了“拒绝变化”的模式。成功没有捷径，你必须自己去尝试。

除了这些，我也喜欢社会工作。那是我生活的另一个方面。我喜欢参与阻止人口贩运组织的工作。我和救助组织一起帮忙救助那些被家庭卖掉或者被绑架的女孩。这是我的另一种激情。我一直在尝试研究技术和我们能构建的东西的交互作用，希望能为我们解决那些问题。

查看英文原文： Kiki Carter, Enterprise Architect at Lightbend, Speaks to InfoQ at ETE

感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。