舍弃 Python+C，Salesforce 将企业级软件全面迁移到 Go 语言

2019 年 10 月 15 日 InfoQ

作者丨Guillaume Le Stum

译者丨大消费

策划丨蔡芳芳

Python 非常适合快速编写更高级别的应用程序，但并不总是能够提供企业级所需的高性能。C 可以创建高性能的可执行文件，但是添加功能会花费更多时间。这篇文章分享了 Einstein Analytics 企业级软件从 C-Python 混合迁移到完全使用 Go 应用程序的经验。

我们很少有机会直接将两种技术彼此比较以完成同一任务。但是有时就会那么巧遇到星星排成一行的情况，比如从当前技术堆栈中你一直得到的是负面影响，而这时恰巧出现了满足你确切需求的新技术，或者项目的规模和功能集超过了现有技术的能力范围。

在 Salesforce，我们在过去几年中遇到了这种情况。我们将大多数 Einstein Analytics 后端从 Python-C 混合平台移植到了 Go。Go 是 Google 为大规模现代软件工程设计的一种语言。传说中，谷歌工程师想创建一种为大型应用程序设计的语言，并在等待大型 C ++ 项目编译时开始了对 Go 的设计。

这篇文章将分享了我们将企业级软件从 C-Python 混合迁移到（几乎）完全使用 Go 应用程序的经验。

Einstein Analytics 将业务智能处理添加到 Salesforce 实例中。通过基于云的 AI 处理，无论结构和格式如何，它都直接从 Salesforce CRM 数据以及尽可能多的客户外部数据中生成可行的见解或预测、管道报告、性能度量。

在后台，给定的 Salesforce 实例将 Einstein Analytics 功能公开为常规 Salesforce REST API 的一部分。这些链接到一个查询服务器集群，每个查询服务器都提供缓存在内存中的链接数据集的查询，但是它们可以从集群中的任何节点填充缓存的数据。为了管理所有这些请求，我们在每个服务器上都有一个优化的流程，该流程将请求路由到适当的节点，并将响应转发到 API 请求的发起者。对于任何读取数据集的查询服务器，这些调用都看起来是本地的。而本地意味着快速。较大的数据集是分区的，无状态查询协调器聚合来自远程分区子查询的数据。

数据集是使用 ETL（提取，转换，加载）创建的批处理，然后以专有的列式数据库格式存储。最初成为 Einstein Analytics 的产品的查询引擎和数据集创建工具是用 C 编写的，使用 Python 包装器提供高级功能解析查询、REST API 服务器、表达式引擎等等。

从本质上讲，该产品具有两全其美的优势。Python 非常适合快速编写更高级别的应用程序，但并不总是能够提供企业级所需的高性能。C 可以创建高性能的可执行文件，但是添加功能会花费更多时间。

转 Go 初体验

最初，这种组合是起作用的。但是，在开发该软件多年之后，Einstein Analytics 开始出现性能下降问题。这是因为不属于核心查询引擎的很多功能都被添加到了 Python 包装器中。这种方式可以快速开发和部署功能，但是随着时间的流逝，它们会拖累整个系统。Python 的多线程性能不是很好，因此要求包装程序执行的次数越多，其执行效果就越差。

之前的团队已经在考虑将包装器移植到 Go 上，因此我们也做了一些研究。我们很快意识到，在企业级系统上，我们将面临另外两个问题。首先，Python 使用松散类型输入，这对于一个快速开发新想法并将其投入生产的小型团队非常有用，但对于某些客户为此付出数百万美元的企业级应用程序而言，却不太合适。其次，我们预见到一个巨大的依赖噩梦即将来临，因为部署正确的 Python 库、版本和文件是一件苦差事。所以在 2014 年，我们决定移植 Python 包装器到 Go 上。

最初，我们对年轻的 Go 生态系统持谨慎态度，但是当我们研究过该语言的设计目标后（转到 Google：软件工程服务中的语言设计）），它给我们留下了深刻的印象。它是为软件工程而设计的，而不仅仅是语言的复杂性，因此它的优势包括可靠的内置工具，快速的编译和部署以及简单的故障排除。

企业软件面临的现实问题是，与编写代码相比，需要花费更多的时间阅读代码。我们感谢 Go 使代码易于理解。在 Python 中，你可以编写超级优雅的列表推导式和几乎是数学式的漂亮代码。但是，如果你没有参与编写代码，那么这种优雅可能让可读性付出代价。

第一个项目进展顺利。我们对新项目的性能和可维护性感到非常满意。我们遇到的为数不多的抱怨之一是，在选择可伸缩性而不是原始性能来帮助它们进行垃圾回收时，需要在语言上进行权衡：他们决定开始将原始类型作为指针而不是值存储在接口中，这为我们带来了性能开销和额外的分配。

全部迁移到 Go 上

这个体验是相当好的，以至于在 2016 年编写具有更好的优化程序的新查询引擎内核并改进我们的数据集创建工具时，我们决定使用 Go 进行操作。我们获得专业知识的速度与 Go 生态系统成熟的速度差不多，因此减少开销并使我们的代码在单一语言中可重用是有意义的。另外，我们希望消除 CGO 接口的开销。

最大的不确定因素是性能。Go 在其 Goroutines 中使用了异步 IO 的轻量级“ 绿色线程 ”模型，它为我们提供了优于 Python 的多线程优势，但是 C 代码运行的要多快就有多快——它用内置的安全性来换取速度，加上 C 编译器更成熟，有更好的优化。我们的团队创建了一个概念验证（POC），它在性能上几乎与 C 引擎相当，但前提是我们使用正确的编程模式:

缓冲所有 IO，以减少 Go 系统调用的开销。在系统调用中，当前 Goroutines 会让步于该调用。
如果可能发生紧密循环，请使用结构代替接口，以最大程度地减少接口方法的间接开销。
在紧密循环内使用预分配的缓冲区（类似于 io.Reader 的工作方式），以最大程度地减少垃圾收集压力。
批量处理数据行是解决不良编译器内联的一种解决方法，以使实际计算更接近数据，并最大程度地减少每次函数调用的开销。

2017 年我们完成了重写，新的 Go 版本的 Einstein Analytics 在 2018 年正式投入使用。通过将所有内容保持为同一语言，我们可以重用代码并提高工作效率。跨平台和可移植的潜力使移植代码变得容易。如果我们需要在移动应用程序中使用任何这些代码，则可以将其交叉编译到 iOS 或 Android，这样就可以正常工作了。

之前，我说过该版本（几乎）完全用 Go 编写。但我们的集群管理器是一个例外，它看起来似乎有些奇怪，因为 Kubernetes 和其他类型的集群协调应用程序是 Go 的最常见用法，但是负责此服务的团队对使用 Java 感到更自在。让团队掌控自己的组件很重要；你不能强迫人们去做他们不想做的事情。

尽管 Go 有一些必须解决的局限性，但我们对结果感到非常满意。Go 还会继续改进。他们通过将其移至静态单一分配形式来解决其编译器中的某些缺陷，这使得进行花式优化变得更加容易。垃圾回收变得越来越高效，并且编译器通常很智能，可以执行转义分析，以检测何时可以廉价地在堆栈而不是堆上分配变量值。

作为开发人员，如果你想用任何语言编写高性能代码，你需要熟悉编译器的工作方式。这不是语言的全部。Go 有一个非常简单的参考文档——只有两页！但是了解编译器需要收集所有这些零散的知识，它详细说明了你可以在所使用的特定版本的 Go 中使用的所有优化。

经过这些移植之后，我们的团队在 Go 及其编译器技术方面积累了一定的专业知识。但是仍然还是会遇到一些问题。例如，你可以很容易地将数据写入到更便宜的堆栈中，而不是写入到更昂贵的堆中。仅仅通过阅读代码，你甚至都不知道会发生这种情况。因此，与需要高性能的任何新语言一样，你需要密切监视进程并创建有关 CPU 和内存使用情况的基准。然后与社区分享你所学到的知识，以使这些知识变得不那么局部化。

结论

选择一种较新的语言并将其引入企业公司可能是一场赌博。幸运的是，Go 生态系统与我们一同成长。Google 继续支持该语言发展，并已被其他很多大型公司接纳。现在，我们拥有一支全职从事 Go 的工程师团队，并且我们继续获得了一些积极的成果。我们期待与 Go 社区一起成长，并分享我们从经验中学到的更多知识。

Salesforce 相信支持 Go 之类的开源技术可以推动我们的行业向前发展，开启新的职业生涯并建立对我们创建的产品的信任。

原文链接：

https://stackoverflow.blog/2019/10/07/how-salesforce-converted-einstein-analytics-to-go/