大规模的最后一英里配送

Salesforce于20年前在旧金山的一间小公寓里成立，在过去的20年里，Salesforce已经发展壮大，在28个不同的国家设有67个办事处。Salesforce建立在三个核心差异化的基础上。一、基于云的多租户解决方案。二、订阅式商业模式。第三，关注慈善事业。
Salesforce在过去的20年里一直做得很好，在我们所属的社区里也做得很好。我们的核心价值观推动我们在2020财年的收入达到171亿美元。
根据福布斯，我们是世界上最具创新力的公司。我们在《人物》杂志评选的50家关心企业中排名第一。我们还被《巴伦周刊》评为最具可持续性的公司。我们在文化和创新方面一直是慈善事业的领导者。我们的111模式是为我们服务的社区捐赠1%的时间，1%的股权和1%的产品，在过去的20年里，这转化为寻找和志愿服务的时间，3.1亿美元的赠款，超过45,000个非营利机构和教育机构免费使用我们的产品。现在，让我们看看Salesforce生命中的24小时。
Salesforce支持数万亿的B2B和B2C交互。从金融服务到制造业，从医疗保健到零售等等，Salesforce改变了企业。这一转变的中心是一群工程师，他们正在推动这一转变。我的团队的任务是为这支工程师大军提供最好的体验。我的团队支持的角色是开发人员。
开发人员可以来自产品工程，可以来自基础设施工程，可以来自数据库工程，可以来自质量工程和/或安全工程。对于所有这些人，我们想要的工具可以被认为是一个单一的事实来源，可以管理工件的生命周期，也可以使我们能够部署在多个基板上，并提供灵活性，以适应多个推出策略。这些都是对工具的需求但是哪些因素决定了我们选择的工具呢?是Salesforce开发人员每天在全球范围内构建工件并多次部署的增长和规模。开发者经验对我们来说非常重要。开发人员应该担心核心功能，而不应该担心部署策略或底层。工件的安全性、遵从性和安全传输非常重要。
工件的可用性和全球范围内的一致性对所有Salesforce的成功至关重要。因此，考虑到所有这些重要的因素和我们开发社区的需求，我们选择JFrog的Artifactory作为我们的解决方案。Artifactory的性能对我们的研发环境至关重要，Artifactory的复制能力对我们在全球的部署至关重要。
Chekri将详细介绍我们的运营规模，以及如何在Salesforce中设置Artifactory的系统架构概述。好了，现在，让我们详细了解在选择像JFrog Artifactory这样的工具来支持我们的用例时对我们有影响的因素。在整个Salesforce中，我们有超过200个人工部署实例，这200个实例支持研发环境、DMZ环境和生产环境。生产实例分布在全球各地，支持Salesforce在全球所有数据中心的部署。在所有这200个实例中，我们每天看到9200万个请求。
这些请求是看跌请求，然后是获取请求，它们是请求帮助，所有类型的请求，包括这9200万个请求。我们支持Docker，我们支持RPM和通用的repo类型。每天我们通过Artifactory的复制在全球范围内传输4TB的数据。在Salesforce中，每天有20,000次构建来支持工程生态系统。在这2万个被构建的工件中，每天大约有150个工件在生产中被提升和消耗。当藏物在全球范围内运输时复制是非常关键的。终端用户体验无论在北美还是在亚太地区都应该是一致的。因此，如果复制不起作用，或者有基于位置的延迟这不是一个适合我们的解决方案。这就是Salesforce目前的运营规模。另一个重要的问题是安全性。 According to our security, R&D environments and production environments should be isolated. They cannot communicate with each other.
研发环境只能发起一个与任何其他环境的通信——这是受控的。另一方面，生产环境也是孤立的，只能单向通信，起始点应从生产环境到不同的环境。所以现在，研发环境和生产环境应该发起呼叫，但它们不能相互交谈。这就是为什么我们有一个DMZ环境，我将在下一张幻灯片中讨论它。但是，安全的另一个方面是我们为政府客户提供的支持。政府环境，应该在物理上和逻辑上隔离。所以，现在，我们有这个研发数据中心，在那里产生了人工制品，但需要进入政府环境。只有通过对Artifactory的复制，工件才能被推送到政府环境中。这就是安全的主要目标和要求。现在我们有多种推出策略。 Apart from the roll-out strategy, there’s one thing that we are very distributed across the globe and across different substrates. So we have bare metal first party data centers, and we have public cloud solutions as well. So our roll-out strategy should accommodate whether it’s a bare metal first party data center, or it’s a public cloud data center.
这是一个要求。第二个要求是金丝雀部署。金丝雀部署非常有趣，它只适用于我们作为代码进行的基础设施更改。因此，我们的基础设施构件被部署到一个金丝雀环境中，变得更大，并进行一两周的测试，然后将更改推广到所有其他生产数据中心。
所以这些数据中心应该是隔离的，不应该影响我们的客户，但应该提供类似的流量。另一个方面是交错发布。因此，Salesforce不想在所有数据中心进行大规模测试。他们想要在特定的数据中心尝试特定的功能或特定的产品。因此，数据中心可以在亚太地区，可以在北美，也可以在亚太地区和北美。因此，我们应该有一种机制，能够将工件仅推出到产品团队需要的数据中心。
因此，Artifactory提供的回购级复制支持这一点，这有助于我们实现交错发布。另一方面是基于地理位置的发布。这对我们来说很重要，因为我们不想在发布游戏时影响用户，而这是一个重要的时刻。所以我们希望在非高峰时段发布。基于地理位置，比如亚太地区，我们在亚洲的非高峰时段做，在北美，我们在北美的非高峰时段做。这是关于推出策略，下一个是开发者体验。对我们来说，确保我们的开发人员专注于核心功能，而不是被所有的推出策略、部署基础等等所困扰，这一点非常重要。所以，我们希望为开发者提供最好的体验，不用担心这些事情。所以我们也有不同的客户群。所以我们需要支持不同类型的软件包。 And we were looking for a tool that can do that and Artifactory was one of the tools that we really liked the extensive support for different packet types.
在Salesforce，在过去的6-7年里，微服务得到了发展。它呈指数级增长，每个人都开始转向微服务，我们有一个庞然大物，但新的功能是作为微服务构建的，所以每天2万次部署或构建都来自这些微服务。就像我提到的，每天有150个促销活动。因此，我们如何持续整合，如何持续交付，对我们来说是一个重要的方面或因素。
所以这些因素帮助我们决定什么是适合我们的工具。我们之所以选择JFrog的Artifactory，主要是因为它不仅是一个二进制存储库，而且还是一个可以帮助我们实现扩展策略、安全需求和规模的工具，还可以帮助我们在全球范围内分发工件的复制。下一张幻灯片基本上是一个功能概述，关于我们如何建立我们的人工工厂，使它能够解决我们必须坚持的所有需求。在屏幕的左边，你可以看到第一个是工程师。
工程师既读又写Artifactory。他们构建生成工件的代码，但是他们也读取由其他平台团队构建的工件。因此，典型的用例是工程师在工件的基础上进行构建，他签入自己的代码，CI系统获取该代码，并使用代码中的新更改构建新工件，该工件将被推回到Artifactory中。在研发环境中，每天大约有20,000个构建发生，这是对Artifactory的读写。因此，在构建工件之后，团队决定何时发布该工件。因此，如果一个团队决定发布一个工件，那么我们将重新生成一个工件，并由我们的安全系统进行签名。
我们的安全系统不仅验证，而且还验证一些必须完成的基本验证。因此，一旦我们的安全流程完成了验证和确认，工件就被签名了。现在，藏物准备好了。团队可能还没有准备好将工件推向生产，他们希望在特定的时间对其进行计时，他们可能有一个特定的推出策略，他们可能只想在金丝雀中部署，看看特定的更改是否如预期的那样运行。这就是晋升过程开始发挥作用的时候。因此，一旦工件生成，产品基础结构团队就会创建一个触发推广过程的PR。
现在，它提醒我们，团队选择的推出策略是什么，并且基于该推出策略，工件被移动到Artifactory中的不同仓库中。我将在下一张幻灯片中讨论我们与Artifactory一起使用的所有不同类型的repo，但现在我们假设推广过程是将一个repo中的工件从研发环境移动到另一个repo。现在，Artifactory中的每个repo都有一组特定的复制属性，我们在Salesforce中大量使用这些属性。
在深入讨论复制之前，我想回顾一下，我在上一张幻灯片中谈到的安全性。所以正如我提到的，研发环境不应该与生产环境通信，生产环境也不应该与研发环境通信。同样，研发环境只能发起会话，生产环境只能发起会话。因此，我们需要一种不同类型的复制来支持这个用例。因此，侦听研发和生产的环境是我们的DMZ环境。所以研发环境使用的是每个仓库复制机制是推送复制。
它将工件推入DMZ工件实例。一旦工件进入DMZ环境，它将驻留在那里，生产数据中心将调用一个调用。生产如何调用调用?目前，我们有一种机制用于基于时间设置的复制。因此，每个生产数据中心都会周期性地从DMZ中的Artifactory提取工件。因此，正如我所提到的，研发环境中的回购级复制设置有助于执行转出策略，而推送复制有助于将工件从研发转移到DMZ。生产数据中心上基于Chron的复制允许我们定期从DMZ中提取工件，一旦工件移动到生产数据中心，就会有一个流程触发所有应用服务器，与Artifactory对话并获取工件并进行部署。因此，这就是整个端到端流程，工件如何在研发中生成，如何移动到DMZ，以及如何移动到生产中。
因此，围绕Salesforce内部的部署有很多逻辑和策略，有很多团队，很多工程团队，需要不同的灵活性和不同的推出策略。因此，人工拉式复制、推式复制、基于事件的复制、基于时间的复制在我们的基础设施中被大量使用。所以，Artifactory帮助我们的规模是惊人的，我们真的很感谢我们得到的所有支持，以及Artifactory在这个产品上不断进行的升级和功能增强，以帮助像Salesforce这样的客户。下一张幻灯片是我们在全球范围内部署的系统架构。所以，在右边，你可以看到生产数据中心。
因此，我们有多种不同的生产数据中心，我们有多种基底，例如，在我们的第一方数据中心的裸机实例。我们在一些地理位置有公共云存在，我们需要尊重该位置要求的安全合规性。我们处于HA和非HA模式，原因是政府数据中心的需求，我们也应该在应用程序级别上进行隔离，这样就会限制我们拥有公共数据库和公共存储。与此同时，我们还有老化的数据中心，不支持某些基础设施。所以我们也需要能够为这些数据中心提供服务。
因此，当我们在寻找能够解决许多问题的工具时，人工地支持HA和非HA模式也是一个关键方面。现在在左边，在左边的上方有不同的CI系统。它是微服务、单体、基础架构CI、数据库CI、包流程以及推广流程。所有这些都与PtoP实例和Artifactory的Dev实例交互。因此PtoP实例实际上是通向产品的路径，因此生成和签名的任何工件都将进入PtoP Artifactory。
由于PtoP Artifactory是在HA模式下使用公共数据库和共享存储设置的。因此，开发人员与R&D Dev实例交互，这个主要用例将是一个读取。我们也有远程存储库，我们使用远程存储库，我们使用本地存储库，我们使用虚拟存储库。我们使用远程存储库的原因是，为发布而构建的任何工件都应该对我们的开发人员用例可用。
因此，包过程希望将工件推送到P2P，该工件将通过我们的工程师的研发开发环境可用。然后我们使用本地存储库基本上是任何我们可以写入的存储库，主要是P2P，大部分是本地存储库。我们有虚拟存储库。我们使用虚拟存储库的原因基本上是能够在不知道完整回购的实际路径的情况下查询工件。
因此，我们将产品组合在一起，这样消费者就不必担心在哪里可以找到特定的工件。现在，研发环境(P2P)有了一个可以部署的工件，并根据推出策略将其推送到DMZ环境。现在，推送是基于事件的，所以一旦工件被签名并提升，它就会被推送。在生产端，我们使用拉式复制，拉式复制是基于时间的，它会周期性地触发并从Artifactory中提取工件。现在，本地应用服务器、基础设施服务器或数据库服务器从生产数据中心的本地Artifactory中提取工件，并根据推广过程定期部署工件，同样是生产数据中心。
所以我们在Artifactory方面的经验以及我们需要为Salesforce的需求规模提供的支持是巨大的。因此，Artifactory一直是改善我们开发人员体验的关键，同时也支持我们在全球不同基础上的推出策略，从安全的角度来看，Artifactory的复制确实支持了我们的需求。
所以，总的来说，Artifactory在Salesforce中是非常适合的工具，它是我们向生产数据中心交付工件的主要工具之一。所以，总的来说，我们从JFrog那里得到的支持是惊人的，我们期待着更多的功能到来，我们也在推进路线图上的一些界限。我们希望我们的伙伴关系将继续下去，我们将共同取得成功。感谢大家聆听我的演讲，我希望我的一些输入能够在您在自己的环境中部署Artifactory的方式上引发一些新的想法。非常感谢大家，如果你们有任何问题，我们愿意回答。