在软件架构的背景下,我们都熟悉“单体”和“微服务”这两个术语,但 Archipelago 到底是什么?更重要的是,如何正确发音?虽然我会把发音练习留给语言学家,但我在这里将指导您了解 daily.dev 独特的系统设计方法。
整体式
在单体架构中,整个代码库被整合到一个项目中,并具有单个可部署单元。该模型拥有高效的内部网络通信,无需远程数据获取。由于其简单性,它是许多项目的绝佳起点,并且在早期阶段可以发挥作用。但是,随着项目扩展和团队成长,坚持使用单体架构可能会变得繁重。代码导航变得复杂,错误的部署可能会导致整个系统崩溃,并且缺乏关注点分离变得显而易见。此外,当多个团队为同一代码库做出贡献时,团队间依赖关系可能会造成同步问题。这正是 daily.dev 作为一个单体项目开始的初衷。
微服务
微服务架构则处于相反的位置,它支持执行单一任务的高度专业化服务。通常,这些服务非常简洁 — 通常只有几百行代码 — 并且封装了业务逻辑的极小部分。虽然这种方法有利于分离关注点,但它严重依赖网络交互,并且可能存在延迟问题。这种依赖还可能推高成本,这一点最近已多次讨论过(示例)。微服务与无服务器计算完美匹配,同样受到欢迎。然而,挑战也随处可见。组织有时会忘记他们的微服务,偶尔会通过创建相同的服务来重复工作。这会导致重复工作并增加运营开销。
群岛
群岛(Archipelago ) 方法在单体架构和微服务架构之间取得了和谐的平衡。在 daily.dev,每项服务负责一个重要的领域。举例来说,我们的 feed 服务、内容管道、搜索功能和 LLM 网关等等。这些服务远非只有几百行代码,它们非常强大。然而,群岛架构的显著特点在于单个服务中包含多个部署单元。这种多样性允许根据不同的指标独立扩展每个单元。这些单元是同一代码库的一部分,并以同步方式部署 — — 大多数情况下,无需同步服务间通信,即可实现直接数据访问。与微服务一样,每项服务都拥有自己的数据并负责自己的基础设施。
部署单位
部署单元是已部署的实体(废话