将一个堆栈的不同组件分成几个较小的机器，或者获得1或2个更大的机器，并将多个组件放在同一台机器上，会更好吗？
我的想法是，如果我从几台机器开始，在需要的时候增加每台机器的功率就可以更容易地进行扩展。 现在还没有准备好水平缩放。
我有20美元/月的预算开始。
我select了DigitalOcean，因为它的512MB液滴看起来很灵活，所以这里是我的select：
1, 2, 3 or 4 Machines of 512MB 2 Machines of 1GB 1 Machine of 2GB 1 or 2 Machines of 512MB + 1 Machine of 1GB 这是我的堆栈：
Nginx + Gunicorn with 3 workers (=4 processes, memory footprint: ~50MB/process) + 3 or 4 RQ workers (memory footprint of each worker: ~50MB) + Redis as Cache (limit to 100MB to start) + Redis as DataStore (small size: it is not meant to store a lot of data, mainly used to store the queues for the workers) + PostgreSQL (not sure how much RAM I would need)
我看到使用多个小型机器的主要缺点是，由于操作系统安装在每台机器上，因此每台机器都有一组专用于操作系统的资源，这些资源在应用程序中“丢失”。 我看到的主要优点是，纵向扩展看起来更容易，因为每台机器都可以单独升级。
什么是一个好的折衷？
选项1
512MB: Nginx, Gunicorn, Redis Cache 512MB: RQ Workers, Redis DataStore 1GB or 512MB: PostgreSQL
我不确定是否值得为PostgreSQL提供1GB …也许我应该只使用一个512MB的液滴？ 另外，我想知道Nginx，Gunicorn和Rediscaching的512MB机器是不是太小了。
所以我可以这样做：
选项2
1GB: Nginx, Gunicorn, Redis Cache 512MB: RQ Workers, Redis DataStore 512MB: PostgreSQL
选项3使用2个更大的机器
1GB: Nginx, Gunicorn, (RQ Workers), Redis Cache, (Redis DataStore) 1GB or 512MB: PostgreSQL, (RQ Workers here?), (Redis DataStore here?)
在许多机器上分布应用程序的一种方法是在不同的硬件上运行每一层。 例如，Web服务器和数据库服务器可以运行在单台机器上或不同的机器上。
做一个或另一个不需要在软件堆栈中进行重大的devise更改。 大多数人必须警惕在不同的机器上分开引入的额外通信延迟。 例如，如果您的应用程序使用许多数据库查询来呈现网页，则大量的往返将导致应用程序的可测量的减速。 但这是你可以devise的东西。
在不同的机器上运行不同的图层的缩放量并不多。 软件堆栈中的层数往往比用户数量增长要慢。 所以你根本无法单独通过这种方法进行扩展。
但是，在不同的硬件上分割图层可能会使您准备在另一个方向上进行缩放。
如果您有一台Web服务器与一台数据库服务器进行通信，那么设置两台与一台数据库服务器进行通信的Web服务器并没有太多阻碍。 换句话说，您的软件堆栈的每一层都可以独立地进行缩放。
但是任何维护状态的层都很难在更多的机器上扩展。 特别是数据库可能被certificate是最难扩展的部分。
就个别机器的大小而言，我会把目标放在最大的performance上。 从这个angular度来看，会有一个最佳的尺寸。 更大的机器将过于昂贵，小型机器将不够便宜。
但是现在还是以后是否要devise可伸缩性还有一个问题。 你可能会浪费你的时间来devise可扩展性，这是你永远不会需要的。 另一方面，如果你没有在许多机器上devise可扩展性，你可能会发现自己争先恐后地find一个足够大的系统来托pipe你的系统的一部分，这是你无法展开的（数据库可能是某个点需要一个巨型机器的部分）。
这是一个有趣的问题，@ kasperd所做的最后一点是最相关的（所以+1）。 国际海事组织（以及许多其他组织） – 这种types的问题是一个很好的问题，但绝对不是你应该做的事情，除非你真的期望增长 – 否则你是在浪费时间和现金。 这就是说这里有一些考虑和select。
这个问题实际上有几个问题，其中主要问题是是扩大还是扩大（以成本为代价）。 如果你需要冗余的话，扩展通常会更有限（如果你需要冗余的话，成本会更高），扩展的PaaS选项的扩展比过去要复杂得多，但是你需要看看你正在交付的应用程序的目的是为了得出什么是最好的具体结论。
数字海洋目前没有任何自动缩放function，所以如果您设想需求高峰，您将手动执行此操作 。
在体系结构方面，系统中的许多瓶颈将是数据库，但这实际上取决于你的应用程序如何“数据驱动”，而不知道应用程序究竟是什么，或者我不能真正推荐你的数据库有一个更大的实例。
在某些情况下，pipe理多个小实例（修补/维护等）增加了复杂性，但是，如果所有应用程序层被分离出来，它可能会在很多情况下更容易地find瓶颈（注意：它也可能使它更多如果它最终成为一个networking性能问题，则会变得复杂）。
我的最终build议是尽可能小，将整个堆栈放在一个小实例上，并在需要时使用Forge等工具来pipe理堆栈。 没有什么能阻止你在稍后阶段分离你的层，扩展和closures给定的盒子上不需要的服务（一旦层被分开）。
这样就可以灵活地select纵向或横向扩展，如果有必要的话，可以让您轻松分离问题，我想最重要的是因为您没有任何指标可以解决问题，所以您可以有效地处理未知问题。