在软件开发领域，选择适当的应用程序架构对于实现功能，提高性能和可扩展性都至关重要。但是，不同的应用程序架构适用于不同类型的应用程序，因此需要深入了解不同的应用程序架构类型以及它们的优缺点。本文将分析三个不同类型的应用程序架构案例，分别是Stack Overflow的单体应用程序架构、Shopify的模块化单体应用程序架构以及Levels.fyi的简单后端架构。通过对这些案例的分析，我们可以更好地了解不同类型的应用程序架构的优缺点和适用场景。
Stack Overflow 架构
Stack Overflow 是一个非常流行的技术问答社区，其架构被设计用于处理高流量的Web请求。他们每秒处理超过6000个请求，每月处理20亿个页面浏览量，并且他们设法在约12毫秒内呈现页面。然而，他们的解决方案并不是一个运行在Kubernetes上的微服务解决方案。
Stack Overflow采用了一个15年历史的单体应用程序。这个单体应用程序在IIS上运行，可以运行200个站点，由9个Web服务器和单个SQL Server（加上一个热备份）组成。他们还使用了两级缓存，一个位于具有大内存（1.5TB）的SQL Server上，另外两个是Redis服务器。此外，他们还有三个标记引擎服务器和三个Elasticsearch服务器，用于处理每天的3400万次搜索。这一切都由一个由50名工程师组成的团队处理，他们能够每天多次在4分钟内部署到生产环境。
Stack Overflow的完整技术栈包括
- C# + ASP.NET MVC
- Dapper ORM
- StackExchange Redis
- MiniProfiler
- Jil JSON Deseliazier
- 异常记录器（用于 SQL）
- Sigil，一个 .Net CIL 生成助手（用于当 C# 不够快时）
- NetGain，一个高性能的 Web 套接字服务器
- Opserver，监控仪表板轮询大多数系统并从 Orion、Bosun 或 WMI 中提取数据。
- Bosun，用 Go 编写的后端监控系统
如果您想了解更多关于他们的架构的内容，可以查阅Nick Craver在2016年写的一系列文章。尽管这些文章有点过时，但架构应该是相同的。
Shopify 架构
Shopify架构采用了模块化单体应用程序方法，将所有代码保存在一个代码库中，但进行模块化处理。这种单体架构是最容易理解和实现的架构之一。由于单体设计简单易建，使团队能够在早期快速地移动，因此它可以将应用程序推向更远的地方，使其能够更早地将其产品展示给客户。
集中应用程序部署和代码库维护有许多好处。所有功能都将在一个文件夹中可访问；您只需要管理一个存储库。此外，这意味着必须维护一个测试和部署流水线，这可能会节省大量工作。与依赖于Web服务API不同，调用不同组件的能力是单体架构比其他几种服务更具吸引力的优势之一。
Shopify使用Ruby on Rails实现了模块化单体应用程序的一个版本。他们将代码库组织在围绕现实世界概念（例如订单、运输、库存和账单）的基础上，使得标记代码和理解代码的人更容易。每个组件都是一个小型Rails应用程序（即模块），可将业务域与其他业务域隔离开来。每个组件都声明对相关数据的独立所有权，并通过公共API定义一个简单直接的界面，以实现域边界的通信。
在最近的黑色星期五，Shopify成功处理了每秒1.27百万个请求，这证明了他们的架构可以扩展到处理大量的请求。
Levels.fyi架构
Levels.fyi架构非常简单，仅使用了Google Sheets作为后端。他们是一个面向专业人士的职业网站，每月有100-200万个独特用户访问量。
当他们开始时，他们希望快速前进并专注于重要事项，因此他们需要一个后端。他们使用了一种无代码方法，使用Google Forms + Google Sheets（再加上AWS Lambda和API Gateway）。这也使他们节省了开发人员的时间，降低了复杂性并节省了基础架构成本。
然而，随着用户基数的增长，他们的架构在24个月内表现良好，但开始遇到问题，因此他们决定转移到具有数据库和API服务器的新后端。他们将写入查询复制到新数据库，并从新API中读取，因此Google Sheets被停用。
总结
以上三个例子展示了不同类型的架构。Stack Overflow采用了传统的单体应用程序架构，但使用了两级缓存和多个服务器来处理大量请求。Shopify使用了模块化单体应用程序架构，将所有代码保存在一个代码库中，但进行模块化处理。Levels.fyi则使用了简单的Google Sheets作为后端，但随着用户基数的增长，他们不得不转移到具有数据库和API服务器的新后端。每个架构都有其优点和缺点，具体取决于您的需求和资源。