当你有一个创业的好主意时，应用架构可能是你最后考虑的事情之一。但是，第一次就把你的应用程序架构好，可以在以后的道路上为你节省大量的麻烦。
因此，让我们来看看一个典型的初创企业应用架构，特别关注数据库以及应用架构师在其堆栈的这一部分所做的选择如何影响规模、用户体验等。
单区域架构
从上往下看，现代应用程序从一个面向用户的前端开始，这个前端通常是用网络语言构建的--HTML、CSS、JavaScript等。
应用程序的前端通过负载平衡器与后端连接，负载平衡器将请求分配给应用程序的实例，这些实例是用你选择的编程语言编写的--Node.js、Python、Go等。这些应用程序通常是通过共享服务（例如Netlify或Vercel）建立和部署的，这些服务允许使用无服务器功能等功能，使应用程序后端的弹性扩展不需要购买一堆专用机器的成本。
从后端，数据可以被横向传递到数据仓库进行长期存储和分析处理，通常通过消息队列或Apache Kafka。
关键任务数据（如交易数据）也会从应用程序的后端垂直传递到关系数据库，直接或通过一个中介，如ORM（对象-关系映射器）或类似GraphQL的东西。
在数据库层面，即使是小的应用程序通常也会以某种冗余为目标，因为依赖一个数据库节点意味着如果该节点发生故障，你的整个应用程序就会瘫痪。然而，这通常是一种主动/被动设置，这种方法在可用性和复杂性方面存在一些限制。让我们更详细地了解一下维持数据库高可用性的几个流行选项。
单一区域的数据库考虑
实现合理的高可用性的最简单方法是使用两个数据库节点，使用主动-被动模型进行配置，如上图的 "之前 "部分所描述的。通过主动-被动，一个数据库节点处理所有的读和写，然后与被动节点同步进行备份。如果主动节点发生故障，你可以切换到使被动节点处于主动状态，一旦你让故障节点重新上线，再恢复主动-被动配置。
然而，这种方法需要大量复杂的操作工作来管理和维护，虽然你要为两个数据库节点付费，但你只能获得单节点系统的性能，因为一个节点处理所有的读写请求。如果你想把数据从这个数据库发送到像Kafka这样的系统，例如，你还必须建立一个类似于事务输出箱的东西，以确保Kafka和你的数据库之间的一致性，避免双重写入问题。
在上面的架构中，我们可以看到使用CockroachDB提供了一种替代方法。CockroachDB是一个主动-主动的数据库，所以如果（比如）你在三个节点上运行CockroachDB，你就会得到三个节点的性能优势，因为读和写是分散在各个节点上的，而不是像主动-被动那样全部通过一个节点。
更重要的是，主动-主动数据库提供了固有的弹性，在节点故障的情况下，只需要很少的操作复杂性来确保正常运行时间。数据分布在多个节点上，每个节点都是一个端点，所以所有节点都可以为读和写提供服务。这种主动冗余不仅可以让你在故障中生存下来，还可以在不停机的情况下进行数据库升级和模式改变。
CockroachDB的实现也很容易扩大和缩小，例如，从CockroachDB集群中增加或删除节点。在CockroachDB无服务器的情况下，扩展是完全自动化的，你的数据库资源将根据你的应用需求实时扩大和缩小。
此外，CockroachDB的CDC（Change Data Capture）功能可以让你轻松地在交易型数据库和Kafka中存储相同的数据，而不存在引入不一致的可能性。
将数据库扩展到多个区域
一般来说，一个应用程序从单区域转移到多区域时不会有太大变化。然而，当你的应用程序开始扩展到单一地区之外时，关系型数据库会带来巨大的挑战。
例如，考虑使用上面描述的架构的电子商务应用程序。如果爱达荷州的用户进行了购买，该交易将被存储在应用程序数据库的爱达荷州实例中，但南卡罗来纳州的实例也需要立即获得该信息，这样（例如）南卡罗来纳州的用户就不能购买刚刚断货的商品，因为爱达荷州的用户购买了最后一件。
多地区的数据库考虑
通常情况下，企业将在两个或更多的活动数据库实例之间同步数据，每个区域内一个。然而，这种方法带来了操作上的挑战，并没有提供最佳的性能。保持同步是很困难的，而且连接问题会在存储库中引入不一致的情况。此外，如果一个区域的数据库节点发生故障，性能可能会特别差，因为该区域的所有读写都需要转到另一个区域的节点上，而这个节点突然要处理双倍的工作负荷。
同样，CockroachDB提出了一个非常不同的方法。CockroachDB从一开始就为地理规模而构建，它允许将多区域的部署当作一个单一的逻辑数据库来对待。换句话说：你的应用程序可以把数据库当作一个单一的Postgres实例。CockroachDB会自动处理地理分布问题。
CockroachDB的每个节点（在每个地区）都可以提供读写服务，并访问集群内的所有数据。它不同步数据；它使用分布式共识来确保数据库的写入在任何时候和任何地方都是正确的。
而且，由于CockroachDB的本质是分布式的，所有的数据都在每个区域的多个节点上进行复制，以确保卓越的性能和可用性。如果一个区域的一个节点发生故障，读写请求将由该区域的其他节点处理，而不需要将流量路由到另一个区域，从而带来延迟问题。
你可以以后再扩展，但现在要为扩展进行设计
在扩展关系型数据库意味着处理手动分片的时代，初创公司忽略数据库规模问题是有道理的，直到他们真正可能面临这个问题。
然而，今天，像CockroachDB这样的分布式SQL数据库可以提供轻松的弹性扩展，用它们构建数据库就像用Postgres这样的传统方案一样简单和实惠。有鉴于此，从一开始就使用分布式数据库来构建是有意义的，而不是在你的发展过程中不得不处理从传统解决方案中迁移的挑战和麻烦。
随着CockroachDB Serverless等无服务器选项的兴起，你实际上可以免费获得一个具有自动弹性规模的分布式数据库。有了CockroachDB，即使你以后不需要扩展，现在也可以很容易、很实惠地架构你的应用，以实现扩展。
