我们在 Sky Betting＆Gaming 中使用 Redis 作为共享内存缓存，用于那些需要跨 API 服务器或者 Web 服务器鉴别令牌之类的操作。在 Core Tribe 内，它用来帮助处理日益庞大的登录数量，特别是在繁忙的时候，我们在一分钟内登录数量会超过 20,000 人。这在很大程度上适用于数据存放在大量服务器的情况下（在 SSO 令牌用于 70 台 Apache HTTPD 服务器的情况下）。我们最近着手升级 Redis 服务器，此升级旨在使用 Redis 3.2 提供的原生集群功能。这篇博客希望解释为什么我们要使用集群、我们遇到的问题以及我们的解决方案。

在开始阶段（或至少在升级之前）

我们的传统缓存中每个缓存都包括一对 Redis 服务器，使用 keepalive 确保始终有一个主节点监听 浮动 IP floating IP 地址。当出现问题时，这些服务器对需要很大的精力来进行管理，而故障模式有时是非常各种各样的。有时，只允许读取它所持有的数据，而不允许写入的从属节点却会得到浮动 IP 地址，这种问题是相对容易诊断的，但会让无论哪个程序试图使用该缓存时都很麻烦。

新的应用程序

因此，这种情况下，我们需要构建一个新的应用程序，一个使用 共享内存缓存 shared in-memory cache 的应用程序，但是我们不希望对该缓存进行迂回的故障切换过程。因此，我们的要求是共享的内存缓存，没有单点故障，可以使用尽可能少的人为干预来应对多种不同的故障模式，并且在事件恢复之后也能够在很少的人为干预下恢复，一个额外的要求是提高缓存的安全性，以减少数据泄露的范围（稍后再说）。当时 Redis Sentinel 看起来很有希望，并且有许多程序支持代理 Redis 连接，比如 twemproxy。这会导致还要安装其它很多组件，它应该有效，并且人际交互最少，但它复杂而需要运行大量的服务器和服务，并且相互通信。

将会有大量的应用服务器与 twemproxy 进行通信，这会将它们的调用路由到合适的 Redis 主节点，twemproxy 将从 sentinal 集群获取主节点的信息，它将控制哪台 Redis 实例是主，哪台是从。这个设置是复杂的，而且仍有单点故障，它依赖于 twemproxy 来处理分片，来连接到正确的 Redis 实例。它具有对应用程序透明的优点，所以我们可以在理论上做到将现有的应用程序转移到这个 Redis 配置，而不用改变应用程序。但是我们要从头开始构建一个应用程序，所以迁移应用程序不是一个必需条件。

幸运的是，这个时候，Redis 3.2 出来了，而且内置了原生集群，消除了对单一 sentinel 集群需要。

它有一个更简单的设置，但 twemproxy 不支持 Redis 集群分片，它能为你分片数据，但是如果尝试在与分片不一致的集群中这样做会导致问题。有参考的指南可以使其匹配，但是集群可以自动改变形式，并改变分片的设置方式。它仍然有单点故障。正是在这一点上，我将永远感谢我的一位同事发现了一个 Node.js 的 Redis 的集群发现驱动程序，让我们完全放弃了 twemproxy。

因此，我们能够自动分片数据，故障转移和故障恢复基本上是自动的。应用程序知道哪些节点存在，并且在写入数据时，如果写入错误的节点，集群将自动重定向该写入。这是被选的配置，这让我们共享的内存缓存相当健壮，可以没有干预地应付基本的故障模式。在测试期间，我们的确发现了一些缺陷。复制是在一个接一个节点的基础上进行的，因此如果我们丢失了一个主节点，那么它的从节点会成为一个单点故障，直到死去的节点恢复服务，也只有主节点对集群健康投票，所以如果我们一下失去太多主节点，那么集群无法自我恢复。但这比我们过去的好。

向前进

随着使用集群 Redis 配置的新程序，我们对于老式 Redis 实例的状态变得越来越不适应，但是新程序与现有程序的规模并不相同（超过 30GB 的内存专用于我们最大的老式 Redis 实例数据库）。因此，随着 Redis 集群在底层得到了证实，我们决定迁移老式的 Redis 实例到新的 Redis 集群中。

由于我们有一个原生支持 Redis 集群的 Node.js Redis 驱动程序，因此我们开始将 Node.js 程序迁移到 Redis 集群。但是，如何将数十亿字节的数据从一个地方移动到另一个地方，而不会造成重大问题？特别是考虑到这些数据是认证令牌，所以如果它们错了，我们的终端用户将会被登出。一个选择是要求网站完全下线，将所有内容都指向新的 Redis 群集，并将数据迁移到其中，以希望获得最佳效果。另一个选择是切换到新集群，并强制所有用户再次登录。由于显而易见的原因，这些都不是非常合适的。我们决定采取的替代方法是将数据同时写入老式 Redis 实例和正在替换它的集群，同时随着时间的推移，我们将逐渐更多地向该集群读取。由于数据的有效期有限（令牌在几个小时后到期），这种方法可以导致零停机，并且不会有数据丢失的风险。所以我们这么做了。迁移是成功的。

剩下的就是服务于我们的 PHP 代码（其中还有一个项目是有用的，其它的最终是没必要的）的 Redis 的实例了，我们在这过程中遇到了一个困难，实际上是两个。首先，也是最紧迫的是找到在 PHP 中使用的 Redis 集群发现驱动程序，还要是我们正在使用的 PHP 版本。这被证明是可行的，因为我们升级到了最新版本的 PHP。我们选择的驱动程序不喜欢使用 Redis 的授权方式，因此我们决定使用 Redis 集群作为一个额外的安全步骤 （我告诉你，这将有更多的安全性）。当我们用 Redis 集群替换每个老式 Redis 实例时，修复似乎很直接，将 Redis 授权关闭，这样它将会响应所有的请求。然而，这并不是真的，由于某些原因，Redis 集群不会接受来自 Web 服务器的连接。 Redis 在版本 3 中引入的称为“保护模式”的新安全功能将在 Redis 绑定到任何接口时将停止监听来自外部 IP 地址的连接，并无需配置 Redis 授权密码。这被证明相当容易修复，但让我们保持警惕。

现在？

这就是我们现在的情况。我们已经迁移了我们的一些老式 Redis 实例，并且正在迁移其余的。我们通过这样做解决了我们的一些技术债务，并提高了我们的平台的稳定性。使用 Redis 集群，我们还可以扩展内存数据库并扩展它们。 Redis 是单线程的，所以只要在单个实例中留出更多的内存就会可以得到这么多的增长，而且我们已经紧跟在这个限制后面。我们期待着从新的集群中获得改进的性能，同时也为我们提供了扩展和负载均衡的更多选择。

未来怎么样？

我们解决了一些技术性债务，这使我们的服务更容易支持，更加稳定。但这并不意味着这项工作完成了，Redis 4 似乎有一些我们可能想要研究的功能。而且 Redis 并不是我们使用的唯一软件。我们将继续努力改进平台，缩短处理技术债务的时间，但随着客户群体的扩大，我们力求提供更丰富的服务，我们总是会遇到需要改进的事情。下一个挑战可能与每分钟超过 20,000次 登录到超过 40,000 次甚至更高的扩展有关。

via: http://engineering.skybettingandgaming.com/2017/09/25/redis-2-to-redis-3/

作者：Craig Stewart 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

围绕云计算的概念和术语仍然很新，但是也在不断的改进。

不管怎么看，云计算也只有十多年的发展时间。一些我们习以为常的云计算的概念和术语仍然很新。美国国家标准与技术研究所（NIST）文档显示，一些已经被熟悉的术语定义在 2011 年才被发布，例如基础设施即服务（IaaS），而在此之前它就以草案的形式广泛流传。

在该文档中其它定义中，有一个叫做 混合云 hybrid cloud 。让我们回溯一下该术语在这段期间的变化是很有启发性的。云基础设施已经超越了相对简单的分类。此外，它还强调了开源软件的使用者所熟悉的优先级，例如灵活性、可移植性、选择性，已经被运用到了混合云上。

NIST 对混合云最初的定义主要集中于 云爆发 cloud bursting ，你能使用内部的基础设施去处理一个基本的计算负荷，但是如果你的负荷量暴涨，可以将多出来的转为使用公有云。与之密切联系的是加强私有云与公有云之间 API 的兼容性，甚至是创造一个现货市场来提供最便宜的容量。

Nick Carr 在 The Big Switch 一书中提出一个概念，云是一种计算单元，其与输电网类似。这个故事不错，但是即使在早期，这种类比的局限性也变得很明显。计算不是以电流方式呈现的一种物品。需要关注的是，公有云提供商以及 OpenStack 一类的开源云软件激增的新功能，可见许多用户并不仅仅是寻找最便宜的通用计算能力。

云爆发的概念基本上忽略了计算是与数据相联系的现实，你不可能只移动洪水般突如其来的数据而不承担巨大的带宽费用，以及不用为转移需要花费的时间而操作。Dave McCrory 发明了 “ 数据引力 data gravity ”一词去描述这个限制。

那么既然混合云有如此负面的情况，为什么我们现在还要再讨论混合云？

正如我说的，混合云的最初的构想是在云爆发的背景下诞生的。云爆发强调的是快速甚至是即时的将工作环境从一个云转移到另一个云上；然而，混合云也意味着应用和数据的移植性。确实，如之前 2011 年我在 CNET 的文章中写到：“我认为过度关注于全自动的工作转换给我们自己造成了困扰，我们真正应该关心的是，如果供应商不能满意我们的需求或者尝试将我们锁定在其平台上时，我们是否有将数据从一个地方到另一个地方的迁移能力。”

从那以后，探索云之间的移植性有了进一步的进展。

Linux 是云移植性的关键，因为它能运行在各种地方，无论是从裸机到内部虚拟基础设施，还是从私有云到公有云。Linux 提供了一个完整、可靠的平台，其具有稳定的 API 接口，且可以依靠这些接口编写程序。

被广泛采纳的容器进一步加强了 Linux 提供应用在云之间移植的能力。通过提供一个包含了应用的基础配置环境的镜像，应用在开发、测试和最终运行环境之间移动时容器提供了可移植性和兼容性。

Linux 容器被应用到要求可移植性、可配置性以及独立性的许多方面上。不管是预置的云，还是公有云，以及混合云都是如此。

容器使用的是基于镜像的部署模式，这让在不同环境中分享一个应用或者具有全部基础环境的服务集变得容易了。

在 OCI 支持下开发的规范定义了容器镜像的内容及其所依赖、环境、参数和一些镜像正确运行所必须的要求。在标准化的作用下，OCI 为许多其它工具提供了一个机会，它们现在可以依靠稳定的运行环境和镜像规范了。

同时，通过 Gluster 和 Ceph 这类的开源技术，分布式存储能提供数据在云上的可移植性。 物理约束限制了如何快速简单地把数据从一个地方移动到另一个地方；然而，随着组织部署和使用不同类型的基础架构，他们越来越渴望一个不受物理、虚拟和云资源限制的开放的软件定义储存平台。

尤其是在数据存储需求飞速增长的情况下，由于预测分析，物联网和实时监控的趋势。2016 年的一项研究表明，98% 的 IT 决策者认为一个更敏捷的存储解决方案对他们的组织是有利的。在同一个研究中，他们列举出不恰当的存储基础设施是最令他们组织受挫的事情之一。

混合云表现出的是提供在不同计算能力和资源之间合适的移植性和兼容性。其不仅仅是将私有云和公有云同时运用在一个应用中。它是一套多种类型的服务，其中的一部分可能是你们 IT 部门建立和操作的，而另一部分可能来源于外部。

它们可能是软件即服务（SaaS）应用的混合，例如邮件和客户关系管理（CRM）。被 Kubernetes 这类开源软件协调在一起的容器平台越来越受新开发应用的欢迎。你的组织可能正在运用某一家大型云服务提供商来做一些事情。同时你也能在私有云或更加传统的内部基础设施上操作一些你自己的基础设施。

这就是现在混合云的现状，它能被归纳为两个选择，选择最合适的基础设施和服务，以及选择把应用和数据从一个地方移动到另一个你想的地方。

相关阅读: 多重云和混合云有什么不同？

作者简介：

Gordon Haff 是红帽云的布道者，常受到业内和客户的高度赞赏，帮助红帽云组合方案的发展。他是《Computing Next: How the Cloud Opens the Future》的作者，除此之外他还有许多出版物。在红帽之前，Gordon 写了大量的研究简报，经常被纽约时报等出版物在 IT 类话题上引用，在产品和市场策略上给予客户建议。他职业生涯的早期，在 Data General 他负责将各种不同的计算机系统，从微型计算机到大型的 UNIX 服务器，引入市场。他有麻省理工学院和达特茅斯学院的工程学位，还是康奈尔大学约翰逊商学院的工商管理学硕士。

via: https://opensource.com/article/17/7/hybrid-cloud

作者：Gordon Haff (Red Hat) 译者：ZH1122 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

你有没有想过，之所以能够根据自己不同兴趣的组合搜索到需要的视频，是因为有那些每日浏览无数视频内容且对它们进行分类和标记的可怜人存在，然而这些看不见的英雄们却在人工智能面前变得英雄无用武之地。

世界上最大的 XXX 电影分享网站 Pornhub 宣布，它将推出新的 AI 模型，利用计算机视觉技术自动检测和识别 XXX 明星的名字。

根据 X-rated 网站的消息，目前该算法经过训练后已经通过简单的扫描和对镜头的理解，可以识别超过 1 万名 XXX 明星。Pornhub 说，通过向此 AI 模型输入数千个视频和 XXX 明星的正式照片，以让它学习如何返回准确的名字。

为了减小错误，这个成人网站将向用户求证由 AI 提供的标签和分类是否合适。用户可以根据结果的准确度，提出支持或是反对。这将会让算法变得更加智能。

“现在，用户可以根据自身喜好寻找指定的 XXX 明星，我们也能够返回给用户尽可能精确的搜索结果，” PornHub 副总裁 Corey Price 说。“毫无疑问，我们的模型也将在未来的发展中扮演关键角色，尤其是考虑到每天有超过 1 万个的视频添加到网站上。”

“事实上，在过去的一个月里，我们测试了这个模型的测试版本，它（每天）可以扫描 5 万段视频，并且向视频添加或者移除标签。”

除了识别表演者，该算法还能区分不同类别的内容：比如在 “Public” 类别下的是户外拍摄的视频，以及 “Blonde” 类别下的视频应该至少有名金发女郎。

XXX 公司计划明年在 AI 模型的帮助下，对全部 500 万个视频编目，希望能让用户更容易找到与他们的期望最接近的视频片段。

早先就有研究人员借助计算机视觉算法对 XXX 电影进行描述。之前就有一名开发者使用微软的人工智能技术来构建这个机器人，它可以整天观察和解读各种内容。

Pornhub 似乎让这一想法更进一步，这些那些遍布全球的视频审看员的噩梦。

虽然人工智能被发展到这个方面可能会让你感觉有些不可思议，但 XXX 业因其对搜索引擎优化技术的狂热追求而闻名。

事实上，成人内容服务一直以来都有广泛市场，且受众不分年龄，这也是这些公司盈利的重要组成部分。

但是，这些每日阅片无数、兢兢业业为其分类的人们可能很快就会成为自动化威胁的牺牲品。但从好的一面看，他们终于有机会坐下来让自动化为他们工作。

via: https://thenextweb.com/artificial-intelligence/2017/10/11/pornhub-ai-watch-tag/

作者：MIX 译者：东风唯笑 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Flashback 用于测试目的来模拟 HTTP 和 HTTPS 资源，如 Web 服务和 REST API。

在 LinkedIn，我们经常开发需要与第三方网站交互的 Web 应用程序。我们还采用自动测试，以确保我们的软件在发布到生产环境之前的质量。然而，测试只是在它可靠时才有用。

考虑到这一点，有外部依赖关系的测试是有很大的问题的，例如在第三方网站上。这些外部网站可能会没有通知地发生改变、遭受停机，或者由于互联网的不可靠性暂时无法访问。

如果我们的一个测试依赖于能够与第三方网站通信，那么任何故障的原因都很难确定。失败可能是因为 LinkedIn 的内部变更、第三方网站的维护人员进行的外部变更，或网络基础设施的问题。你可以想像，与第三方网站的交互可能会有很多失败的原因，因此你可能想要知道，我将如何处理这个问题？

好消息是有许多互联网模拟工具可以帮助。其中一个是 Betamax。它通过拦截 Web 应用程序发起的 HTTP 连接，之后进行重放的方式来工作。对于测试，Betamax 可以用以前记录的响应替换 HTTP 上的任何交互，它可以非常可靠地提供这个服务。

最初，我们选择在 LinkedIn 的自动化测试中使用 Betamax。它工作得很好，但我们遇到了一些问题：

• 出于安全考虑，我们的测试环境没有接入互联网。然而，与大多数代理一样，Betamax 需要 Internet 连接才能正常运行。
• 我们有许多需要使用身份验证协议的情况，例如 OAuth 和 OpenId。其中一些协议需要通过 HTTP 进行复杂的交互。为了模拟它们，我们需要一个复杂的模型来捕获和重放请求。

为了应对这些挑战，我们决定基于 Betamax 的思路，构建我们自己的互联网模拟工具，名为 Flashback。我们也很自豪地宣布 Flashback 现在是开源的。

什么是 Flashback?

Flashback 用于测试目的来模拟 HTTP 和 HTTPS 资源，如 Web 服务和 REST API。它记录 HTTP/HTTPS 请求并重放以前记录的 HTTP 事务 - 我们称之为“ 场景 scene ”，这样就不需要连接到 Internet 才能完成测试。

Flashback 也可以根据请求的部分匹配重放场景。它使用的是“匹配规则”。匹配规则将传入请求与先前记录的请求相关联，然后将其用于生成响应。例如，以下代码片段实现了一个基本匹配规则，其中测试方法“匹配”此 URL的传入请求。

HTTP 请求通常包含 URL、方法、标头和正文。Flashback 允许为这些组件的任意组合定义匹配规则。Flashback 还允许用户向 URL 查询参数，标头和正文添加白名单或黑名单标签。

例如，在 OAuth 授权流程中，请求查询参数可能如下所示：

oauth_consumer_key="jskdjfljsdklfjlsjdfs",
oauth_nonce="ajskldfjalksjdflkajsdlfjasldfja;lsdkj",
oauth_signature="asdfjaklsdjflasjdflkajsdklf",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="1318622958",
oauth_token="asdjfkasjdlfajsdklfjalsdjfalksdjflajsdlfa",
oauth_version="1.0"

这些值许多将随着每个请求而改变，因为 OAuth 要求客户端每次为 oauth_nonce 生成一个新值。在我们的测试中，我们需要验证 oauth_consumer_key、oauth_signature_method 和 oauth_version 的值，同时确保 oauth_nonce、oauth_signature、oauth_timestamp 和 oauth_token 存在于请求中。Flashback 使我们有能力创建我们自己的匹配规则来实现这一目标。此功能允许我们测试随时间变化的数据、签名、令牌等的请求，而客户端没有任何更改。

这种灵活的匹配和在不连接互联网的情况下运行的功能是 Flashback 与其他模拟解决方案不同的特性。其他一些显著特点包括：

• Flashback 是一种跨平台和跨语言解决方案，能够测试 JVM（Java虚拟机）和非 JVM（C++、Python 等）应用程序。
• Flashback 可以随时生成 SSL/TLS 证书，以模拟 HTTPS 请求的安全通道。

如何记录 HTTP 事务

使用 Flashback 记录 HTTP 事务以便稍后重放是一个比较简单的过程。在我们深入了解流程之前，我们首先列出一些术语：

• Scene ：场景存储以前记录的 HTTP 事务 (以 JSON 格式)，它可以在以后重放。例如，这里是一个Flashback 场景示例。
• Root Path ：根路径是包含 Flashback 场景数据的目录的文件路径。
• Scene Name ：场景名称是给定场景的名称。
• Scene Mode ：场景模式是使用场景的模式, 即“录制”或“重放”。
• Match Rule ：匹配规则确定传入的客户端请求是否与给定场景的内容匹配的规则。
• Flashback Proxy ：Flashback 代理是一个 HTTP 代理，共有录制和重放两种操作模式。
• Host 和 Port ：代理主机和端口。

为了录制场景，你必须向目的地址发出真实的外部请求，然后 HTTPS 请求和响应将使用你指定的匹配规则存储在场景中。在录制时，Flashback 的行为与典型的 MITM（中间人）代理完全相同 - 只有在重放模式下，连接流和数据流仅限于客户端和代理之间。

要实际看下 Flashback，让我们创建一个场景，通过执行以下操作捕获与 example.org 的交互：

1、 取回 Flashback 的源码：

git clone https://github.com/linkedin/flashback.git

2、 启动 Flashback 管理服务器：

./startAdminServer.sh -port 1234

3、 注意上面的 Flashback 将在本地端口 5555 上启动录制模式。匹配规则需要完全匹配（匹配 HTTP 正文、标题和 URL）。场景将存储在 /tmp/test1 下。

4、 Flashback 现在可以记录了，所以用它来代理对 example.org 的请求：

curl http://www.example.org -x localhost:5555 -X GET

5、 Flashback 可以（可选）在一个记录中记录多个请求。要完成录制，关闭 Flashback。

6、 要验证已记录的内容，我们可以在输出目录（/tmp/test1）中查看场景的内容。它应该包含以下内容。

在 Java 代码中使用 Flashback也很容易。

如何重放 HTTP 事务

要重放先前存储的场景，请使用与录制时使用的相同的基本设置。唯一的区别是将“场景模式”设置为上述步骤 3 中的“播放”。

验证响应来自场景而不是外部源的一种方法，是在你执行步骤 1 到 6 时临时禁用 Internet 连接。另一种方法是修改场景文件，看看响应是否与文件中的相同。

这是 Java 中的一个例子。

如何记录并重播 HTTPS 事务

使用 Flashback 记录并重放 HTTPS 事务的过程非常类似于 HTTP 事务的过程。但是，需要特别注意用于 HTTPS SSL 组件的安全证书。为了使 Flashback 作为 MITM 代理，必须创建证书颁发机构（CA）证书。在客户端和 Flashback 之间创建安全通道时将使用此证书，并允许 Flashback 检查其代理的 HTTPS 请求中的数据。然后将此证书存储为受信任的源，以便客户端在进行调用时能够对 Flashback 进行身份验证。有关如何创建证书的说明，有很多类似这样的资源是非常有帮助的。大多数公司都有自己的管理和获取证书的内部策略 - 请务必用你们自己的方法。

这里值得一提的是，Flashback 仅用于测试目的。你可以随时随地将 Flashback 与你的服务集成在一起，但需要注意的是，Flashback 的记录功能将需要存储所有的数据，然后在重放模式下使用它。我们建议你特别注意确保不会无意中记录或存储敏感成员数据。任何可能违反贵公司数据保护或隐私政策的行为都是你的责任。

一旦涉及安全证书，HTTP 和 HTTPS 之间在记录设置方面的唯一区别是添加了一些其他参数。

• RootCertificateInputStream： 表示 CA 证书文件路径或流。
• RootCertificatePassphrase： 为 CA 证书创建的密码。
• CertificateAuthority： CA 证书的属性

查看 Flashback 中用于记录 HTTPS 事务的代码，它包括上述条目。

用 Flashback 重放 HTTPS 事务的过程与录制相同。唯一的区别是场景模式设置为“播放”。这在此代码中演示。

支持动态修改

为了测试灵活性，Flashback 允许你动态地更改场景和匹配规则。动态更改场景允许使用不同的响应（如 success、time_out、rate_limit 等）测试相同的请求。场景更改仅适用于我们已经 POST 更新外部资源的场景。以下图为例。

能够动态更改匹配规则可以使我们测试复杂的场景。例如，我们有一个使用情况，要求我们测试 Twitter 的公共和私有资源的 HTTP 调用。对于公共资源，HTTP 请求是不变的，所以我们可以使用 “MatchAll” 规则。然而，对于私人资源，我们需要使用 OAuth 消费者密码和 OAuth 访问令牌来签名请求。这些请求包含大量具有不可预测值的参数，因此静态 MatchAll 规则将无法正常工作。

使用案例

在 LinkedIn，Flashback 主要用于在集成测试中模拟不同的互联网提供商，如下图所示。第一张图展示了 LinkedIn 生产数据中心内的一个内部服务，通过代理层，与互联网提供商（如 Google）进行交互。我们想在测试环境中测试这个内部服务。

第二和第三张图表展示了我们如何在不同的环境中录制和重放场景。记录发生在我们的开发环境中，用户在代理启动的同一端口上启动 Flashback。从内部服务到提供商的所有外部请求将通过 Flashback 而不是我们的代理层。在必要场景得到记录后，我们可以将其部署到我们的测试环境中。

在测试环境（隔离并且没有 Internet 访问）中，Flashback 在与开发环境相同的端口上启动。所有 HTTP 请求仍然来自内部服务，但响应将来自 Flashback 而不是 Internet 提供商。

未来方向

我们希望将来可以支持非 HTTP 协议（如 FTP 或 JDBC），甚至可以让用户使用 MITM 代理框架来自行注入自己的定制协议。我们将继续改进 Flashback 设置 API，使其更容易支持非 Java 语言。

现在为一个开源项目

我们很幸运能够在 GTAC 2015 上发布 Flashback。在展会上，有几名观众询问是否将 Flashback 作为开源项目发布，以便他们可以将其用于自己的测试工作。

Google TechTalks：GATC 2015 - 模拟互联网

我们很高兴地宣布，Flashback 现在以 BSD 两句版许可证开源。要开始使用，请访问 Flashback GitHub 仓库。

该文原始发表在LinkedIn 工程博客上。获得转载许可

致谢

Flashback 由 Shangshang Feng、Yabin Kang 和 Dan Vinegrad 创建，并受到 Betamax 启发。特别感谢 Hwansoo Lee、Eran Leshem、Kunal Kandekar、Keith Dsouza 和 Kang Wang 帮助审阅代码。同样感谢我们的管理层 - Byron Ma、Yaz Shimizu、Yuliya Averbukh、Christopher Hazlett 和 Brandon Duncan - 感谢他们在开发和开源 Flashback 中的支持。

作者简介：

Shangshang Feng - Shangshang 是 LinkedIn 纽约市办公室的高级软件工程师。在 LinkedIn 他从事了三年半的网关平台工作。在加入 LinkedIn 之前，他曾在 Thomson Reuters 和 ViewTrade 证券的基础设施团队工作。

via: https://opensource.com/article/17/4/flashback-internet-mocking-tool

作者： Shangshang Feng 译者：geekpi 校对：jasminepeng

本文由 LCTT 原创编译，Linux中国 荣誉推出

2017云栖大会，阿里巴巴集团 CTO 兼阿里云 CTO 行癫就开源谈了一番他的看法。

行癫在阿里历经了从技术到商业，又从商业到技术的过程，十多年的阿里生涯，让他对开源、技术和商业有了深刻了解。

开源的核心是连接，社区的根本是连接

行癫说，阿里巴巴的平台将“消费者和商家连接在了一起，这个平台不仅是个渠道，也从消费者获得了非常多一些反馈，能够快速的根据消费者的需求，来做出满足消费者要求的一些产品。我们回过头来想一下，开源社区，非常像这个模式。”

这个商业模式，其实就是将相关的人、物、关系连接到了一起，与开源的道理是一致的。

行癫认为“开源要做好，它最重要、最核心的一点，是把相关的一些开发者、用户，通过软件、工具和平台连接在一起了。”

纵观那些发展的比较好的开源软件，都是通过开源软件、通过开源的模式和开源的平台，将最优秀的开发者联系起来，将最有价值的软件用户连接起来。

互联网的本质是连接。没有互联网之前，所有的行为、所有的商业都是单向的；有互联网之后，非常非常多的连接就产生了。所以对于开源，行癫认为它“是根植于互联网的，有了互联网技术平台之后，开源能够做得更好。”

开源是生长于社区土壤中的，而社区就是一种将参与者连接起来的机制。首先通过将人连接起来，然后才能逐步考虑将来的发展，考虑如何发展和进行商业化发展。

一个开源软件在诞生之初，有可能只是表达一下对技术的理解和看法，也有可能只是解决某个痛点——大多数情况下是自己的痛点，还有可能只是好玩。至于将来能走多远，能否得到社区的迎合，能否发展出一个生态，甚至成为商业新动力，在最初往往并没有很远的计划和远景。

但是，在建立连接后，有了一个社区的土壤之后，就有了成长为一棵大树、一片森林的可能。“把人连接在一起，然后后面才是讨论核心问题，和怎么样进行商业化”。

而现在的云栖大会“也是一个连接”，通过网上直播，中国大概会有一千万左右的开发者会来参加这个云栖大会，所以“云栖大会把中国最具有活力的一群开发者，全部连接在一起了。今天这种形式的大会，本身就是一个对开发者来说，一个最重要的纽带。”

阿里为何拥抱开源

阿里巴巴最初是采用商用软件做解决方案，基于小型机、企业级的基础设施。阿里巴巴的平台三个比较大的特点，“互联网级的规模、金融级的稳定性、企业级的复杂程度。”在这种情况下，一方面，如果继续用 IOE 基础设施，随着业务规模的扩大，将来根本无法覆盖剧增的成本。另外一方面，商用软件的支持情况也难以满足业务的增长带来的各种需求。

因此，阿里巴巴发起了去 IOE 行动，全面投向开源解决方案，用开源软件构建了满足其体量和需求的基础设施。在这个过程中，阿里巴巴一方面大量采用开源软件替代传统的 IOE 基础设施，另外一方面也要面临一些前所未有的需求。

“阿里巴巴应该是最早把这么复杂的一个应用系统，全部放到开源社区的应用上的。”因此，在规模扩大了到开源软件原来很少涉及的数量级时，就会发现很多之前隐藏的场景问题。在这其中解决了无数的问题，因为面临的环境跟别人不一样，面临的要求也跟别人不一样。阿里做了非常多的工作，把他们的互联网的架构中现在社区不具备的一些功能，都纷纷补上去。自己开发了很多的中间件去满足这些功能需求。

积极回馈开源

在全面投入开源的怀抱后，阿里也积极回馈开源社区，真正使自己成为开源社区的一份子。这可以从近年来阿里加大对开源社区的赞助、代码的贡献、开源社区的扶持，以及鼓励技术人员走出去等举措上可以看出来。

在本次云栖大会上，阿里巴巴宣布了正式发布了 OpenMessaging 和 ApsaraCache 两个开源项目。此前，阿里巴巴捐赠的开源的 RocketMQ 已被 Apache 基金会接纳为全球顶级项目。

“开源和阿里巴巴都根植于互联网，有了互联网技术平台之后，开源和商业将在未来相当长的时间内保持平衡的发展。”行癫表示。

据悉， OpenMessaging 项目是由阿里巴巴发起，与雅虎、滴滴出行、 Streamlio 公司共同参与创立的分布式消息中间件、流处理领域的应用开发标准，目前已正式入驻 Linux 基金会，这也是国内首个在全球范围内发起的分布式消息领域的国际标准。

该标准可以不受编程语言限制，能满足企业对扩展性、伸缩性、隔离和安全的要求，可提供大规模的工业级支持，支持标准参照点的添加与标准化测试，开放接口便于对其他不同标准的接入，适用于金融、电商、物联网、工业互联网等行业。

“OpenMessaging 希望成为全球化、无国界、无公司边界、面向云和大数据、多行业领域的一站式方案标准，这也是阿里巴巴第一次在国际社区进行的主导和探索。” 项目负责人蒋江伟表示。

同时，在云栖大会现场，阿里云数据库负责人余锋与 Redis 创始人 Salvatore 共同宣布 ApsaraCache 在 Github 上正式开放下载。ApsaraCache 是阿里云数据库 Redis 版的分支，适用于更大的数据规模和更多的应用场景。

“ApsaraCache 项目开源是一件非常好的事情，将能够吸引全世界更多 Redis 核心专家参与，进一步提升产品的稳定性和可用性。” Salvatore 表示。

Mysql 之父、 MariaDB 创始人 Michael Widenius 已经连续三年参加云栖大会，年过 50 的他依然奋斗在代码第一线，Widenius 表示：“很多 MariaDB 的运用源自我们的开发者，维基百科用的就是 MariaDB，我们也从阿里巴巴中获得了很多开源的支持和贡献，确保能给大家提供功能丰富的数据库产品。”

图为 Mysql 之父、 MariaDB 创始人 Michael Widenius

近年来，阿里巴巴在技术领域投入不断加强，拥抱开源也由来已久，积极加入了包括自由软件基金会、Apache 软件基金会和 Linux 基金会在内的多家国际知名开源组织。目前，阿里巴巴开源和维护的开源项目超过 150 个，涵盖中间件、开发框架、数据库和各种工具类软件。在开源中国公布的“2016 年度最受欢迎中国开源软件评选 TOP20”榜单中，阿里巴巴独占 4 席。其中 Weex、Ant Design、Dubbo、Fastjson 在 GitHub 上的星标数已经破万，“Alibaba”组织在 GitHub 上星标数超过 170,000，组织排名进入前十。

开源之路

行癫认为，“开源我觉得有几个层次”，刚开始可能只是做了一个工具，这个工具做得非常好，可以解决一个非常确定性的问题。逐渐地，这个工具可能会变成一个产品、变成一个系统，慢慢延伸出一堆工具。“开源要成功，第一步要做好一个工具，第二步会变成全链的产品，我觉得最成功的就是变成新的一个生态。” 开源软件组成了一个生态，无数人为这个生态贡献了新的智慧、新的工具。融入这个生态的人，或许只用非常少的代价，就能够找到跟他的工作场景、业务场景相匹配的模式。到这个程度，“这个社区就发展得比较成熟了。这个可能是大多数开源软件必须要去走的一些路径。”

“今天要开源的其实不仅是软件，还有很多硬件”，行癫说。“今天的开源比以前的更复杂，有可能是端跟云端的结合。……互联网第一阶段的开源，是基于互联网的端建成的；互联网的第二个阶段是 IoT，我们希望所有的设备能够串起来。所以我认为接下去开源软件会与硬件结合，这就是从单纯的互联网向 IoT 时代发展非常重要的一个过程。”

结语

在近来几届云栖大会上，开源已经成为了永恒的主题，除了开源专场之外，在各个会场和论坛，充斥着各种热烈的开源气息，无数建筑于开源之上的产品、服务源源不断的开发出来，无数的技术人员和开源爱好者投身于开源世界。让我们期待云栖大会成为开源的大会，成为中国开源界和世界开源接轨的枢纽。

对于家用 WiFi 路由器和接入点来说，OpenWrt 项目可能是最广为人知的 Linux 发行版；在 12 年以前，它产自现在有名的 Linksys WRT54G 路由器的源代码。（2016 年）五月初，当一群 OpenWrt 核心开发者 宣布 他们将开始着手 OpenWrt 的一个副产品 （或者，可能算一个分支）叫 Linux 嵌入开发环境 （LEDE）时，OpenWrt 用户社区陷入一片巨大的混乱中。为什么产生分裂对公众来说并不明朗，而且 LEDE 宣言惊到了一些其他 OpenWrt 开发者也暗示这团队的内部矛盾。

LEDE 宣言被 Jo-Philipp Wich 于五月三日发往所有 OpenWrt 开发者列表和新 LEDE 开发者列表。它将 LEDE 描述为“OpenWrt 社区的一次重启” 和 “OpenWrt 项目的一个副产品” ，希望产生一个 “注重透明性、合作和权利分散”的 Linux 嵌入式开发社区。

给出的重启的原因是 OpenWrt 遭受着长期以来存在且不能从内部解决的问题 —— 换句话说，关于内部处理方式和政策。例如，宣言称，开发者的数目在不断减少，却没有接纳新开发者的方式（而且貌似没有授权委托访问给新开发者的方法）。宣言说到，项目的基础设施不可靠（例如，去年服务器挂掉在这个项目中也引发了相当多的矛盾），但是内部不合和单点错误阻止了修复它。内部和从这个项目到外面世界也存在着“交流、透明度和合作”的普遍缺失。最后，一些技术缺陷被引述：不充分的测试、缺乏常规维护，以及窘迫的稳固性与文档。

该宣言继续描述 LEDE 重启将怎样解决这些问题。所有交流频道都会打开供公众使用，决策将在项目范围内的投票决出，合并政策将放宽等等。更详细的说明可以在 LEDE 站点的规则页找到。其他细节中，它说贡献者将只有一个阶级（也就是，没有“核心开发者”这样拥有额外权利的群体），简单的少数服从多数投票作出决定，并且任何被这个项目管理的基础设施必须有三个以上管理员账户。在 LEDE 邮件列表， Hauke Mehrtens 补充到，该项目将会努力把补丁投递到上游项目 —— 这是过去 OpenWrt 被批判的一点，尤其是对 Linux 内核。

除了 Wich，这个宣言被 OpenWrt 贡献者 John Crispin、 Daniel Golle、 Felix Fietkau、 Mehrtens、 Matthias Schiffer 和 Steven Barth 共同签署，并以给其他有兴趣参与的人访问 LEDE 站点的邀请作为了宣言结尾。

回应和问题

有人可能会猜想 LEDE 组织者预期他们的宣言会有或积极或消极的反响。毕竟，细读宣言中批判 OpenWrt 项目暗示了 LEDE 阵营发现有一些 OpenWrt 项目成员难以共事（例如，“单点错误” 或 “内部不和”阻止了基础设施的修复）。

并且，确实，有很多消极回应。OpenWrt 创立者之一 Mike Baker 回应 了一些警告，反驳所有 LEDE 宣言中的结论并称“像‘重启’这样的词语都是含糊不清的，且具有误导性的，而且 LEDE 项目未能揭晓其真实本质。”与此同时，有人关闭了那些在 LEDE 宣言上署名的开发者的 @openwrt.org 邮件入口；当 Fietkau 提出反对， Baker 回复账户“暂时停用”是因为“还不确定 LEDE 能不能代表 OpenWrt。” 另一个 OpenWrt 核心成员 Imre Kaloz 写到，他们现在所抱怨的 OpenWrt 的“大多数[破]事就是 LEDE 团队弄出来的”。

但是大多数 OpenWrt 列表的回应对该宣言表示困惑。邮件列表成员不明确 LEDE 团队是否将对 OpenWrt 继续贡献，或导致了这次分裂的架构和内部问题的确切本质是什么。 Baker 的第一反应是对宣言中引述的那些问题缺乏公开讨论表示难过：“我们意识到当前的 OpenWrt 项目遭受着许多的问题，”但“我们希望有机会去讨论并尝试着解决”它们。 Baker 作出结论：

我们想强调，我们确实希望能够公开的讨论，并解决掉手头事情。我们的目标是与所有能够且希望对 OpenWrt 作出贡献的参与者共事，包括 LEDE 团队。

除了有关新项目的初心的问题之外，一些邮件列表订阅者提出了 LEDE 是否与 OpenWrt 有相同的使用场景定位，给新项目取一个听起来更一般的名字的疑惑。此外，许多人，像 Roman Yeryomin，对为什么这些问题需要 LEDE 团队的离开（来解决）表示了疑惑，特别是，与此同时，LEDE 团队由大部分活跃核心 OpenWrt 开发者构成。一些列表订阅者，像 Michael Richardson，甚至不清楚谁还会继续开发 OpenWrt。

澄清

LEDE 团队尝试着深入阐释他们的境况。在 Fietkau 给 Baker 的回复中，他说在 OpenWrt 内部关于有目的地改变的讨论会很快变得“有毒，”因此导致没有进展。而且：

这些讨论的要点在于那些掌握着基础设施关键部分的人精力有限却拒绝他人的加入和帮助，甚至是面对无法及时解决的重要问题时也是这样。

这种像单点错误一样的事已经持续了很多年了，没有任何有意义的进展来解决它。

Wich 和 Fietkau 都没有明显指出具体的人，虽然在列表的其他人可能会想到这个基础设施和 OpenWrt 的内部决策问题要归咎于某些人。 Daniel Dickinson 陈述到：

我的印象是 Kaloz (至少) 以基础设施为胁来保持控制，并且根本性的问题是 OpenWrt 是不民主的，而且忽视那些真正在 OpenWrt 工作的人想要的是什么，无视他们的愿望，因为他/他们把控着要害。

另一方面， Luka Perkov 指出 很多 OpemWrt 开发者想从 Subversion 转移到 Git，但 Fietkau 却阻止这种变化。

看起来是 OpenWrt 的管理结构并非如预期般发挥作用，其结果导致个人冲突爆发，而且由于没有完好定义的流程，某些人能够简单的忽视或阻止提议的变化。明显，这不是一个能长期持续的模式。

五月六日，Crispin 在一个新的帖子中写给 OpenWrt 列表，尝试着重构 LEDE 项目宣言。他说，这并不是意味着“敌对或分裂”行为，只是与结构失衡的 OpenWrt 做个清晰的划分并以新的方式开始。问题在于“不要归咎于一次单独的事件、一个人或者一次口水战”，他说，“我们想与过去自己造成的错误和多次作出的错误管理决定分开”。 Crispin 也承认宣言没有把握好，说 LEDE 团队 “弄糟了发起纲领。”

Crispin 的邮件似乎没能使 Kaloz 满意，她坚持认为 Crispin（作为发行经理）和 Fietkau（作为领头开发者）可以轻易地在 OpenWrt 内部作出想要的改变。但是讨论的下文后来变得沉寂；之后 LEDE 或者 OpenWrt 哪边会发生什么还有待观察。

目的

对于那些想要探究 LEDE 所认为有问题的事情的更多细节的 OpenWrt 成员来说，有更多的信息来源可以为这个问题提供线索。在公众宣言之前，LEDE 组织花了几周谈论他们的计划，会议的 IRC 日志现已发布。特别有趣的是，三月三十日的会议包含了这个项目目标的细节讨论。

其中包括一些针对 OpenWrt 的基础设施的抱怨，像项目的 Trac 工单追踪器的缺点。它充斥着不完整的漏洞报告和“我也是”的评论，Wich 说，结果几乎没有贡献者使用它。此外，他们也在 Github 上追踪 bug，人们对这件事感到困惑，这使得工单应该在哪里讨论不明了。

这些 IRC 讨论也定下了开发流程本身。LEDE 团队想作出些改变，以使用会合并到主干的阶段开发分支为开端，与 OpenWrt 所使用的“直接提交到主干”方式不同。该项目也将提供基于时间的发行版，并通过只发行已被成功测试的二进制模块来鼓励用户测试，由社区而不是核心开发者在实际的硬件上进行测试。

最后，这些 IRC 讨论也确定了 LEDE 团队的目的不是用它的宣言吓唬 OpenWrt。Crispin 提到 LEDE 首先是“半公开的”并渐渐做得更公开。 Wich 解释说他希望 LEDE 是“中立的、专业的，并打开大门欢迎 OpenWrt 以便将来的合并”。不幸的是，前期发起工作并不是做得很好。

在一封邮件中， Fietkau 补充到 OpenWrt 核心开发者确实在任务中遇到瓶颈，像补丁复审和基础设施维护这些事情让他们完成不了其他工作，比如配置下载镜像和改良构建系统。在 LEDE 宣言之后短短几天内，他说，团队成功解决了镜像和构建系统任务，而这些已被搁置多年。

我们在 LEDE 所做的事情很多是基于转移到 Github 的去中心化软件包开发经验，并放弃了软件包应如何被维护的许多控制。这样最终有效减少了我们的工作量，而且我们有了很多更活跃的开发者。

我们真的希望为核心开发做一些类似的事，但是基于我们想作出更大改变的经验，我们觉得在 OpenWrt 项目内做不到。

修复基础设施也将收获其他好处，他说，就比如改进了用于管理签署发布版本的密码的系统。团队正在考虑在某些情况下非上游补丁的规则，像需要补丁的描述和为什么没有发送到上游的解释。他也提到很多留下的 OpenWrt 开发者表示有兴趣加入 LEDE，相关当事人正试图弄清楚他们是否会重新合并该项目。

有人希望 LEDE 更为扁平的管理模式和更为透明的分工会在困扰 OpenWrt 的方面取得成功。解决最初的宣言中被诟病的沟通方面的问题会是最大的障碍。如果那个过程处理得好，那么，未来 LEDE 和 OpenWrt 可能能够求同存异并协作。否则，之后两个团队可能一起被迫发展到比以前拥有更少资源的方向，这也许不是开发者或用户想看到的。

via: https://lwn.net/Articles/686767/

作者：Nathan Willis 译者：XYenChi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出