当我们构建MVP或标准应用时，我们通常会思考一个单独的数据库、干净的后端和平滑的前端。但是，当你必须在同一秒钟内为数百万名活跃用户提供服务时会发生什么？

像Duolingo和LinkedIn这样的应用在完全不同的层面上运作。 在他们的规模下，所有事情都从“使其工作”只是转变为处理大规模的可扩展性、高可用性和疯狂的性能。

以下是这些技术巨头如何结构他们的系统以及他们实际上使用什么的分解：

  1. 后端：微服务架构

你几乎不会在企业级应用中发现一个单一的代码库。相反，他们使用微服务架构，其中每个主要功能都在自己的隔离服务器上运行。

API网关：这作为所有移动请求的单个入口点，路由它们到正确的微服务，同时处理身份验证和速率限制。

消息代理（例如Apache Kafka）：这是LinkedIn的骨干。 当你喜欢一条帖子或触发一个通知时，这个动作不会立即击中主数据库。它进入Kafka，缓冲和处理每秒百万个事件而不会崩溃系统。

数据库分片和多语言持久性：他们不仅依赖于一个数据库类型。 高速聊天或RSS可能使用NoSQL数据库，如Cassandra或MongoDB，而敏感用户数据则安全地位于结构化系统中，如PostgreSQL，分片在多个服务器上（分片）。

  1. 前端和移动：本机选择

虽然跨平台框架对于初创公司来说很棒，但大多数大型技术公司都非常重视他们核心产品的完全本机开发，以挤出每一丝性能。

Duolingo（游戏化和重UI）

技术栈：Swift（UIKit/SwiftUI）用于iOS，Kotlin（Jetpack Compose）用于Android。

丰富的动画：为了让应用保持轻量级，同时运行重度动画，他们依赖工具如Lottie和Rive，通过代码渲染矢量动画。

乐观UI（前端预测）：Duolingo经常预测你的答案或预取下一课的状态。UI立即更新之前服务器即响应，创造出一个超快的离线友好用户体验。

LinkedIn（数据密集型和复杂的RSS）

技术栈：同样是完全本机（Swift和Kotlin）用于移动，React.js / Ember.js用于网络。

激进的缓存：他们的移动架构重点是本地缓存机制，以便即使在不稳定或慢速网络连接时，RSS也可以快速加载。

  1. 工程文化和组织

一个大型应用不是由一个大团队构建的。它是由数十个较小、自治的团队组成的，通常被称为小队或功能团队。

功能优先的所有权：在Duolingo中，一独立小队可能只负责排行榜，而另一个小队则负责每日强度。每个小队都有自己的iOS、Android和后端工程师，以及UI/UX设计师。

强大的CI/CD管道：代码永远不会手动上传。自动化管道（如Jenkins或GitHub Actions）在每个代码提交上运行数千个自动化测试。如果找到一个微小的bug，构建会被阻止在真正的用户设备上之前。

结论：

是什么使这些应用在快速增长的几年内保持高可维护性的是严格遵循清晰架构和SOLID原则。它允许数百名开发者每天推送代码而不会破坏应用程序的其他部分。

你有什么想法？对于那些在企业环境中工作的人，是否认为完全本机总是值得付出相对于现代跨平台解决方案的开销以适应大型企业？让我们讨论！