salesforce_为Salesforce中的大量读取而设计

salesforce

One of the first lessons that architects learn when working with Salesforce is the impact of governor limits on performance. The multitenant architecture of Salesforce affords tremendous flexibility and scalability, but its shared nature requires all of us to be good neighbors. Depending on how we are integrating with Salesforce, different techniques can be used to best ensure we provide the scale that we need. As API demand increases, the risk of reliability problems grows, and this can have consequences for the business. It is important to understand the business needs around all requests for data to ensure that the requests are responded to in a timely manner. “Timely” can have differing meanings, as some business processes may require data in near real time whereas others can afford greater latency. Once you clearly understand the business needs for the data, you can employ different strategies to meet those needs. This post explores issues to consider when the system you are architecting needs to make a large volume of API calls to read data from the Salesforce Platform. As the considerations are slightly different between high-volume reads and high-volume writes, high-volume writes will be explored separately in a future post.

架构师在与Salesforce一起工作时所学的第一课是调控器限制对性能的影响。 Salesforce的多租户架构提供了极大的灵活性和可伸缩性，但是其共享的性质要求我们所有人都必须成为好邻居。 根据我们与Salesforce集成的方式，可以使用不同的技术来最好地确保我们提供所需的规模。 随着API需求的增加，可靠性问题的风险也会增加，这可能会对业务造成影响。 了解所有数据请求周围的业务需求非常重要，以确保及时响应请求。 “及时”的含义可能有所不同，因为某些业务流程可能需要近乎实时的数据，而其他业务流程可能会带来更大的延迟。 一旦清楚地了解了数据的业务需求，就可以采用不同的策略来满足这些需求。 本文探讨了当您正在构建的系统需要进行大量API调用以从Salesforce平台读取数据时要考虑的问题。 由于高容量读取和高容量写入之间的考虑略有不同，因此在以后的文章中将单独探讨高容量写入。

通过可扩展性建立信任 (Building Trust Through Scalability)

When technology is unable to keep up with the data demands of the business, problems inevitably arise. Most commonly this is experienced as slow-downs, with users experiencing long delays as data is retrieved. For example, in a customer service center, poor data performance leads to longer call handling times. Beyond this though, even the quality of the data can be affected. Data synchronization processes that aren’t fast enough can lead to distributed systems having incorrect or even corrupted data.

当技术无法满足业务数据需求时，不可避免地会出现问题。 最常见的是，这种情况会导致速度变慢，用户在检索数据时会经历很长的延迟。 例如，在客户服务中心，不良的数据性能会导致更长的呼叫处理时间。 除此之外，甚至数据的质量也会受到影响。 不够快的数据同步过程可能导致分布式系统的数据不正确甚至损坏。

As these problems grow, confidence and trust in the system deteriorates, which can affect the entire business. The resulting confusion and miscommunication can undermine the confidence of business users and customers alike. The mounting frustration can lead to lost customers, low employee morale, and higher turnover. To build trust, you must address scalability issues that are affecting platform performance. Before addressing these issues, you must first fully understand the business need. This understanding will enable you to make informed decisions when tradeoffs — in which performance in one area is sacrificed to improve performance in another — are necessary.

随着这些问题的增加，对系统的信心和信任也会下降，这可能会影响整个业务。 由此产生的混乱和沟通不畅会破坏业务用户和客户的信心。 不断增加的挫败感可能导致客户流失，员工士气低落和营业额增加。 为了建立信任，您必须解决影响平台性能的可伸缩性问题。 解决这些问题之前，您必须首先完全了解业务需求。 这种理解将使您能够在需要权衡时做出明智的决策，在权衡中，必须牺牲一个领域的绩效以提高另一个领域的绩效。

扩展Salesforce API (Scaling Salesforce APIs)

When building API integrations with Salesforce, the most obvious place to start is with the native Salesforce REST and SOAP APIs. Both APIs support high-volume reads, subject to governor limits. These limits have changed over time, so before designing a scalable solution be sure to review the latest developer documentation. For APIs, the two key limits are concurrent API requests and total API requests. You can work around those limits through changes to your design, but these tradeoffs can lead to other limits becoming a factor. For example, rather than make multiple independent API requests, you can use custom Apex REST APIs to consolidate a request. Requests for several different related elements of data can be written as a single request. This tradeoff reduces the risk of hitting the limit for the total number of API requests but increases the risk of other limits such as concurrent API request limits, Apex CPU time limits, and Apex heap size limits.

与Salesforce建立API集成时，最明显的起点是使用本机Salesforce REST和SOAP API。 两种API均支持大容量读取，但受调控器限制。 这些限制已随着时间而改变，因此在设计可扩展解决方案之前，请确保查看最新的开发人员文档 。 对于API，两个关键限制是并发API请求和API总数请求 。 您可以通过更改设计来解决这些限制，但是这些折衷可能导致其他限制成为一个因素。 例如，您可以使用自定义的Apex REST API合并请求，而不是发出多个独立的API请求。 对数据的几个不同相关元素的请求可以写为单个请求。 这种权衡降低了达到API请求总数限制的风险，但增加了其他限制的风险，例如并发API请求限制，Apex CPU时间限制和Apex堆大小限制。

Here is a simple example. Three API calls are made in sequence against native Salesforce REST APIs. If you begin to run into the limit on total API requests, with this integration you could redesign it to use a single custom REST API call.

这是一个简单的例子。 针对本地Salesforce REST API依次进行了三个API调用。 如果您开始遇到API请求总数的限制，那么通过这种集成，您可以重新设计它以使用单个自定义REST API调用。

The getFullAccount API call orchestrates the Salesforce data, before returning it to the client. This reduces three API calls down to one, helping to avoid the limit on total API requests. However, you can expect this one call will require more time to execute, potentially risking the concurrent API request limit.

在将数据返回给客户端之前， getFullAccount API调用将协调Salesforce数据。 这样可以将三个API调用减少到一个，从而避免了API请求总数的限制。 但是，您可以预期这一调用将需要更多时间来执行，从而可能会冒着并发API请求限制的风险。

The flexibility to balance between different governor limits can achieve greater scale, but only up to a point. If you’re receiving enough API traffic even a very short transaction can lead to concurrent API request limit issues. To achieve the next level of scale it you’ll need to use a different architecture, leveraging other aspects of the Salesforce Platform or expanding beyond the platform.

在不同的调速器限制之间进行平衡的灵活性可以实现更大的规模，但只能达到一定程度。 如果您接收到足够的API流量，那么即使是很短的交易也会导致并发的API请求限制问题。 为了达到更高的规模，您将需要使用其他架构，利用Salesforce平台的其他方面或扩展到该平台之外。

Salesforce流事件 (Salesforce Streaming Events)

Salesforce provides a streaming event architecture that provides a different approach for handling high-volume data. Rather than synchronously requesting data from Salesforce, data can be pushed out from Salesforce to other systems. PushTopic, Change Data Capture (CDC), platform, and generic events all provide slightly different capabilities for streaming data. The event type you choose will be dependent on your specific use case, but the overall architectural pattern is similar between them. For example, Changed Data Capture (CDC) events provide a way to notify external systems of data changes in Salesforce as changes occur. Because CDC events are fundamentally asynchronous, there’s no guarantee that any given change will be immediately available on the external system. However, by supplying data to external systems and using those systems to handle data requests, you can reduce the need to read large volumes of data directly from Salesforce.

Salesforce提供的流事件架构提供了一种用于处理大量数据的不同方法。 可以从Salesforce将数据推送到其他系统，而不是从Salesforce同步请求数据。 PushTopic，更改数据捕获(CDC)，平台和通用事件都为流数据提供了稍有不同的功能。 您选择的事件类型将取决于您的特定用例，但是它们之间的总体架构模式是相似的。 例如， 更改数据捕获(CDC)事件提供了一种在发生更改时向外部系统通知Salesforce中的数据更改的方法。 由于CDC事件基本上是异步的，因此无法保证任何给定的更改将立即在外部系统上可用。 但是，通过将数据提供给外部系统并使用这些系统来处理数据请求，您可以减少直接从Salesforce读取大量数据的需求。

In this example, an Account record is inserted into Salesforce. Upon insertion, a CDC event is created and subscribers to that event can react to it. In this case, an external subscriber gets the latest copy of the event, and inserts that event into an external database.

在此示例中，一个客户记录被插入到Salesforce中。 插入后，将创建一个CDC事件，该事件的订阅者可以对此做出React。 在这种情况下，外部订户获取事件的最新副本，并将该事件插入到外部数据库中。

With this approach, other systems can query for the account data against the external database without needing to directly access Salesforce.

通过这种方法，其他系统可以针对外部数据库查询帐户数据，而无需直接访问Salesforce。

This scalability advantage does come with some complexity. Message delivery isn’t always guaranteed, so in rare cases, a change in Salesforce could be lost, leading to synchronization issues with the external system. It’s important to have a process to reconcile any such data synchronization issues that may develop over time. Even with a reconciliation process in place, streaming events cannot provide the same guarantees as a synchronous transactional approach. However, if your business need can be fulfilled given these limitations, platform events offer tremendous gains in scalability.

这种可伸缩性优势确实带来了一些复杂性。 消息传递不一定总是得到保证，因此在极少数情况下，Salesforce的更改可能会丢失，从而导致与外部系统的同步问题。 重要的是要有一个过程来协调可能随时间推移而发展的任何此类数据同步问题。 即使已建立对帐过程，流事件也无法提供与同步事务处理方法相同的保证。 但是，如果在这些限制条件下可以满足您的业务需求，那么平台事件将在可伸缩性方面带来巨大的收益。

用Heroku扩展 (Extend With Heroku)

As part of the Salesforce Platform, Heroku is well suited to handling large volumes of API requests and is frequently used to improve scalability. For example, a common pattern is to use Heroku Connect to enable synchronization between Salesforce and Heroku Postgres.

作为Salesforce平台的一部分，Heroku非常适合处理大量API请求，并且经常用于提高可伸缩性。 例如，一种常见的模式是使用Heroku Connect在Salesforce和Heroku Postgres之间启用同步。

Here, a large number of client systems can access Heroku to retrieve data that is kept in sync with Salesforce. As the clients scale, the number of Postgres databases and the number of Heroku dynos can be scaled to meet the increased demand. Meanwhile, the demand on Salesforce itself remains unaffected. As with platform events, this scalability comes with some added complexity. External clients will either need to query the Postgres database or connect through a custom API implemented on Heroku web dynos. Heroku Connect has strong management tools, but you’ll need to consider how sandbox refreshes work with your integration testing environment. Also, as with platform events there is some risk that data can get out of sync in rare circumstances. Security is another factor to consider because the ownership structures in Salesforce are not carried into Heroku. If you have complex security requirements, you may face additional complexity in the Heroku implementation. For many businesses, this approach offers the best of both worlds. Salesforce provides a flexible base architecture, with the steady scale that a business needs day to day, and Heroku complements this with the ability to scale up to meet the needs of high-volume processes that would be affected by governor limits if run directly against Salesforce.

在这里，大量的客户端系统可以访问Heroku来检索与Salesforce保持同步的数据。 随着客户的扩展，可以扩展Postgres数据库的数量和Heroku dynos的数量，以满足不断增长的需求。 同时，对Salesforce本身的需求不受影响。 与平台事件一样，这种可伸缩性也带来了一些额外的复杂性。 外部客户端将需要查询Postgres数据库或通过在Heroku Web dynos上实现的自定义API进行连接。 Heroku Connect具有强大的管理工具，但您需要考虑沙盒刷新如何与集成测试环境一起使用。 此外，与平台事件一样，在极少数情况下，数据也可能会失去同步 。 安全是要考虑的另一个因素，因为Salesforce中的所有权结构没有纳入Heroku中。 如果您有复杂的安全要求，则在Heroku实施中可能会面临更多的复杂性。 对于许多企业而言，这种方法可以兼得两全。 Salesforce提供了灵活的基础架构，并具有企业日常所需的稳定规模，而Heroku通过扩展能力来满足大批量流程的需求，如果直接针对Salesforce运行会受到监管者限制的影响，从而对其进行补充。

MuleSoft (MuleSoft)

MuleSoft’s Anypoint Platform (along with CloudHub) supports highly scalable integrations with an architecture similar to the Heroku architecture just described. Cloud-based workers can take on the demands of incoming read requests and scale dynamically as needed. Additionally, the tooling of the Anypoint platform simplifies much of the work to configure these integrations.

MuleSoft的Anypoint平台 (以及CloudHub )支持高度可扩展的集成，其架构类似于刚才描述的Heroku架构。 基于云的工作者可以满足传入读取请求的需求，并根据需要动态扩展。 此外，Anypoint平台的工具简化了配置这些集成的许多工作。

For example, to support high-volume reads, MuleSoft Anypoint can act as an API gateway in front of Salesforce data. On its own, this doesn’t address the concerns of high-volume reads, however, the Anypoint platform provides caching capabilities as well. Depending on the nature of the data, this cache capability can greatly reduce the demand on Salesforce while minimizing custom code.

例如，为了支持大批量读取，MuleSoft Anypoint可以充当Salesforce数据前面的API网关。 它本身并不能解决大容量读取的问题，但是，Anypoint平台也提供了缓存功能 。 根据数据的性质，此缓存功能可以极大地减少对Salesforce的需求，同时最大程度地减少自定义代码。

结论 (Conclusion)

Salesforce provides tremendous scalability out-of-the-box, but being a shared system, governor limits will always create a performance ceiling. For business needs that require high-volume reads you may want to consider an architecture that includes Heroku, MuleSoft, or external systems updated via Salesforce streaming events. In subsequent posts we will explore several integration patterns that Salesforce customers have used to meet these scaling challenges.

Salesforce开箱即用地提供了巨大的可伸缩性，但是作为一个共享系统，调控器限制将始终创建性能上限。 对于需要大量读取的业务需求，您可能需要考虑一种包含Heroku，MuleSoft或通过Salesforce流事件更新的外部系统的体系结构。 在后续文章中，我们将探讨Salesforce客户用来应对这些扩展挑战的几种集成模式。

关于作者 (About the Author)

Steve Stearns is a Regional Success Architect Director who has been with Salesforce for over 10 years and has over 20 years of experience implementing scalable integrations. This post was a collaborative effort by a scalable architecture team within the Salesforce Customer Success Group. Collaborators include Manish Aggarwal, Tia Harrington, Samuel Holloway, Tushar Jadhav, Ravikumar Parasuram, Maha Ramakrishnan, Ramesh Rangaiah, Suchin Rengan, Paul Roth, and Mukul Singh.

Steve Stearns是区域成功架构师总监，他在Salesforce工作已有10年以上，并且在实施可伸缩集成方面拥有20多年的经验。 这篇文章是由Salesforce客户成功小组内部的可伸缩体系结构团队共同合作完成的。 合作者包括Manish Aggarwal，Tia Harrington，Samuel Holloway，Tushar Jadhav，Ravikumar Parasuram，Maha Ramakrishnan，Ramesh Rangaiah，Suchin Rengan，Paul Roth和Mukul Singh。

翻译自: https://medium.com/salesforce-architects/designing-for-high-volume-reads-in-salesforce-103dbc242bb3

salesforce