IMGZ的体系结构

每天上班时，成千上万的客户问我们＆＃34;我能买一杯大的卡布奇诺咖啡吗？＆＃34;。后来，我们回到家，用本钱在真正的硅谷精神下，为最好的图像主机IMGZ工作时，避免饥饿。我们认为在构建服务时遇到的一些架构挑战会使其他人感兴趣，因此决定撰写有关这些挑战的文章，以帮助我们的读者并改变世界。

如果您不熟悉IMGZ，那就是图片托管服务商，您会有所不同：您为托管图片支付费用，从而确保我们始终牢记您的最大利益，并且不会成为社交网站网络。从本质上讲，我们翻转了传统的“初创公司”，向用户赠送了VC资金。从用户那里赚钱。如果这对您来说听起来不错，您可以在我们的主页上注册，我们只会让您感到惊讶。

在IMGZ，我们对两件事充满热情：提供图片，并以复数形式谈论自己，所以看起来它不是一个人的项目，而我们却不这样做。 ； t甚至不十分在意投放图片。不过，今天，我们将讨论前者，并深入探讨每天提供超过一百万字节图像的技术细节，同时保持难以捉摸的“九五”。可靠性保证是我们钟爱的产品，通常会坚持使用。

我们的体系结构非常简单，是一个相当成熟的，草率的启动SaaS体系结构，您无疑会在之前看到过无数次：

在设计IMGZ存储和服务模型时，我们希望可扩展性和可靠性成为我们的首要考虑。经过几个月的设计和艰苦的研究，我们最终在多租户，分布式，弹性微服务架构上设计了基于Kafka的地理复制图像处理管道，其中，每个图像的元数据都保存在地理复制的MongoDB实例中，图像本身存储在AWS上的DynamoDB中，以确保可伸缩性和低延迟。

当我们意识到自己没有给投资者留下深刻印象时，我们就放弃了该计划，因为听起来好像工作量太大了。我们意识到当今的架构设计主要是出于抱负，但在某个时候，一家初创公司需要与事实上它现在没有一千万个用户，它可能很快不会有一千万个用户，并且可能永远不会有十个用户。相反，我们将图像存储在一个小的Postgres中数据库（是的，实际的图像数据本身），以及一个处理业务逻辑的小型Django应用。好性感

当用户上传图像时，我们会对其进行处理，创建缩略图以在网站的各种视图中显示，并将其连同元数据一起存储在数据库中，至少在理论上是这样。当用户请求图像时，请求首先经过我们的CDN，该CDN会从我们的服务器中获取图像，然后将其永久缓存，因此每个图像最多只能由我们提供一次。对于我们的CDN（用于服务，缓存，地理复制等），我们免费使用CloudFlare级别，这非常好。我们通过提供无人支付的有偿服务来确保始终保持免费。

像上面的图像一样，图像是我们服务的核心，但请不要离题。硬件是Hetzner VM的$ 5 / mo的虚拟机，可服务约10个其他项目，因此它非常强大。我们最喜欢的谚语是，当您所有的内容都是静态的并且不需要其他资源免费服务时，您就不需要大量的资源。

如果更多的用户加入该服务，我们对扩展基础架构的能力非常有信心，因为我们的VPS提供商拥有一个按钮，我们可以按此按钮来增大服务器的体积，从而一劳永逸地解决所有可扩展性问题。

这篇文章有点无聊，不是吗？那是由设计决定的：您的体系结构不必激动人心地工作，尤其是在公司的早期阶段。做最简单的事情（注意不要把自己画在角落里）通常是最好的开始方法，因为您通常甚至不知道自己最终会去哪里。

总而言之，我们的架构遵循久经考验的硅谷方法：通过ing带每个人的免费套餐来构建您可以做的最简单的事情，而他们希望您有一天能成功并付给他们不菲的金钱作为回报。使其聪明的策略很简单：