让Shopify实现规模化的Pods架构

In 2015, it was no longer possible to continue buying a larger database server for Shopify. We finally had no choice but to shard the database, which allowed us to horizontally scale our databases and continue our growth. However, what we gained in performance and scalability we lost in resilience. Throughout the Shopify codebase was code like this:

在2015年，已经不可能继续为Shopify购买更大的数据库服务器了。我们最终别无选择，只能将数据库分片，这使我们能够横向扩展我们的数据库并继续增长。然而，我们在性能和可扩展性方面所获得的，却失去了弹性。在整个Shopify代码库中，有这样的代码。

Sharding.with_each_shard do

some_action

end

If any of our shards went down, that entire action would be unavailable across the platform. We realized this would become a major problem as the number of shards continued to increase. In 2016 we sat down to reorganize Shopify’s runtime architecture.

如果我们的任何一个分片发生故障，整个平台上的行动都将不可用。我们意识到，随着分片数量的不断增加，这将成为一个大问题。2016年，我们坐下来重新组织Shopify的运行时架构。

Simply sharding the databases wasn't enough, we needed to fully isolate each shard so a failure couldn't spiral out into a platform outage. We introduced pods (not to be confused with Kubernetes pods) to solve this problem. A pod consists of a set of shops that live on a fully isolated set of datastores.

仅仅将数据库分片是不够的，我们需要将每个分片完全隔离，这样故障就不会演变成平台的中断。我们引入了pod（不要与Kubernetes pod混淆）来解决这个问题。一个pod由一组生活在完全隔离的数据存储上的商店组成。

Outside of the isolated datastores, pods also have shared resources such as job workers, app servers, and load balancers. However, all shared resources can only ever communicate to a single pod at a time—we don’t allow any actions to reach across pods.

在孤立的数据存储之外，pod也有共享资源，如作业人员、应用服务器和负载平衡器。然而，所有共享资源在同一时间只能与单个pod通信，我们不允许任何行动跨pod。

Using pods buys us horizontal scalability, we can consider each pod in total independence, and since there no cross-pod communication, adding a new pod won’t cause unexpected interference with other, pre-existing pods.

使用pod为我们赢得了横向可扩展性，我们可以完全独立地考虑每个pod，而且由于没有跨pod的通信，增加一个新的pod不会对其他预先存在的pod造成意外的干扰。

Fully isolated, every datastore buys us capacity and prevents a single shop from sucking up data...