为什么选择微服务？

本章内容概览：

• 微服务的定义及其重要性
• 微服务的优缺点
• 单体架构存在的问题
• 微服务设计基础
• 示例应用程序 FlixTube 概述

1.1 管理复杂性

微服务架构将复杂应用分解为简单、边界清晰的小部分。每个微服务都应保持小而简单，由单个开发人员或小团队管理。

1.2 什么是微服务？

定义 微服务是一个小型独立的软件进程，它按照自己的部署计划运行，并可以独立于其他服务进行更新。

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

1.3 什么是微服务应用程序？

定义 微服务应用程序是由多个小服务组成的分布式程序，这些服务通过网络通信协作实现整个项目的功能。

1.4 单体架构的问题是什么？

定义 单体架构指的是整个应用程序在单一进程中运行。

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

• 部署风险高：更新风险极高，破坏性代码更改可能导致整个应用停摆
• 扩展困难：难以精确扩展，最终会达到物理机器的极限
• 技术债务累积：代码库庞大混乱，难以在未来拆分
• 知识流失问题：开发人员离职带走关键知识

1.5 微服务的优势与挑战

优势：

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

挑战：

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

1.6 设计微服务应用程序

设计原则：

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

领域驱动设计（DDD）：

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

服务的适当规模：

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

1.7 可能性范围

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

大多数现实世界应用处于这两者之间的某个地方。

1.8 示例应用程序 FlixTube

本书将构建一个视频流应用 FlixTube，包括：

• 基于浏览器的前端
• 视频流、存储和上传服务
• 面向客户的前端网关

总结

• 微服务是专注于单一功能的小型独立进程
• 微服务应用由多个小进程协作实现整个应用功能
• 相比单体应用，微服务更具灵活性、可扩展性、可靠性和容错性
• 虽然构建更复杂，但现代工具（Docker、Kubernetes、Terraform、GitHub Actions）已极大简化了过程
• DDD 的限界上下文概念与微服务边界紧密相关
• 单一职责、松耦合和高内聚是微服务设计的关键原则
• 本书示例应用 FlixTube 是基于微服务的视频流平台