本章内容概览：

微服务的定义及其重要性微服务的优缺点单体架构存在的问题微服务设计基础示例应用程序 FlixTube 概述1.1 管理复杂性微服务架构将复杂应用分解为简单、边界清晰的小部分。每个微服务都应保持小而简单，由单个开发人员或小团队管理。

图 1.1 单体和微服务的复杂性都可以分解为简单的部分，但微服务的这些部分有明确的边界，确保代码不会在部分之间纠缠。1.2 什么是微服务？定义 微服务是一个小型独立的软件进程，它按照自己的部署计划运行，并可以独立于其他服务进行更新。

微服务可对外公开或仅限内部使用，通常可以访问数据库、文件存储或其他状态持久化资源。

图 1.2 单个微服务可能与外界或其他服务连接，并可能拥有数据库和/或其他文件存储。1.3 什么是微服务应用程序？定义 微服务应用程序是由多个小服务组成的分布式程序，这些服务通过网络通信协作实现整个项目的功能。

图 1.3 微服务应用程序由多个独立的小服务组成，在集群中运行。1.4 单体架构的问题是什么？定义 单体架构指的是整个应用程序在单一进程中运行。

单体架构虽然构建简单，适合新项目的起步，但存在以下问题：

部署风险高：更新风险极高，破坏性代码更改可能导致整个应用停摆扩展困难：难以精确扩展，最终会达到物理机器的极限技术债务累积：代码库庞大混乱，难以在未来拆分知识流失问题：开发人员离职带走关键知识图 1.4 单体架构与微服务对比。展示了使用微服务构建相比传统的单体应用程序的诸多优势。1.5 微服务的优势与挑战优势：

精细控制：每个服务可独立配置 CPU、内存等资源，精确控制扩展降低部署风险：独立更新服务，出现问题只影响小部分系统且易回滚技术栈灵活性：每个服务可使用最适合的技术栈易于测试和扩展：小型服务启动快，易于复制负载较重的服务鼓励创新：灵活性和健壮性的组合使应用更易演变和重组挑战：

学习曲线陡峭：需掌握复杂的微技术和分布式应用技术构建难度大：比单体应用复杂得多可扩展性问题：可能放大现有问题，增加管理复杂性需合适的技能、工具和自动化：本书旨在帮助克服这些困难1.6 设计微服务应用程序设计原则：

单一职责原则：每个服务只关注单一业务领域职责分离：避免职责交叉，使微服务更易理解和维护松耦合：最小化服务间直接依赖，尽量不共享信息高内聚：服务内部功能密切相关，专注解决特定问题领域驱动设计（DDD）：

限界上下文是 DDD 的关键概念，定义模型内部的一致性边界，有助于确定每个微服务的功能和责任。

图 1.5 DDD 中的限界上下文相当于微服务的边界。服务的适当规模：

过小的服务可能增加系统间通信和整体复杂性。应基于领域概念和自然服务规模来构建，而非单纯追求大小最小化。

1.7 可能性范围架构选择不只是单体与微服务的二分法，而是存在一系列可能性。

图 1.6 不仅仅是单体架构与微服务：实际上有一系列可能性。大多数现实世界应用处于这两者之间的某个地方。

1.8 示例应用程序 FlixTube本书将构建一个视频流应用 FlixTube，包括：

基于浏览器的前端视频流、存储和上传服务面向客户的前端网关图 1.7 我们的示例应用程序在 Kubernetes 上运行生产。总结微服务是专注于单一功能的小型独立进程微服务应用由多个小进程协作实现整个应用功能相比单体应用，微服务更具灵活性、可扩展性、可靠性和容错性虽然构建更复杂，但现代工具（Docker、Kubernetes、Terraform、GitHub Actions）已极大简化了过程DDD 的限界上下文概念与微服务边界紧密相关单一职责、松耦合和高内聚是微服务设计的关键原则本书示例应用 FlixTube 是基于微服务的视频流平台

上一页

关于本书下一页

第 2 章：创建微服务创建于 2026/01/06

更新于 2026/01/06

1412 字

阅读约 3 分钟提交勘误/建议

加载评论中...

0