微服务将系统划分为小的、独立的服务。对于移动应用程序来说，这意味着可扩展且不断发展的 API。本指南介绍了如何为应用程序实施和操作[微服务0]。
什么是微服务
定义
应用程序由小型且独立的服务组成的架构。
特点
- 部署独立性
- 独家负责域名
- 通过网络通讯
- 可能有不同的技术
整体差异
整体：全部在一起。微服务：按职责分离。
优点
独立的可扩展性
每项服务都根据需求进行扩展。
独立部署
更新其中一个不会影响其他。
韧性
失败并不意味着一切都会失败。
多种技术
为每项工作使用最好的工具。
独立团队
所有权清晰，依赖性更少。
缺点
操作复杂性
更多部件需要管理。
网络延迟
服务之间的通信会增加延迟。
硬调试
跟踪跨服务的问题。
数据一致性
分布式事务很复杂。
开销
对于小型系统来说，这可能太多了。
何时使用
适合
- 大型团队
- 复杂领域
- 需要独立的规模
- 频繁的演变
避免
- 小团队
- [MVP1
- 简单的域
分解
按域
有界 DDD 上下文。
按功能
授权、付款、目录等
按用例
独立的用户流程。
API网关
功能
客户的单一入口点。
职责
路由、[身份验证2、、速率限制、聚合。
工具
Kong、AWS API 网关、Nginx。
BFF（前端后端）
概念
客户端类型的特定网关。
用法
BFF 用于移动设备，另一个用于网络。
优势
针对每个客户进行优化。
通讯
同步
休息，gRPC。请求/响应。
异步
消息队列。活动。
权衡
同步很简单，异步则有弹性。
服务发现
问题
服务如何找到彼此？
解决方案
Consul，[Kubernetes3? DNS、AWS 云地图。
可观察性
日志记录
带有相关 ID 的集中日志。
追踪
使用 Jaeger、X-Ray 进行分布式跟踪。
指标
通过服务和聚合。
韧性
断路器
停止调用失败的服务。
重试
使用退避重试。
超时
不要永远等待。
###舱壁
隔离资源。
数据管理
每个服务的数据库
每项服务都有其银行。
最终一致性
避免分布式事务。
活动
通过事件传达变化。
传奇
通过清算进行长交易。
部署
容器
[Docker 4 封装服务。
编排
[Kubernetes5 进行管理。
CI/CD
每项服务的管道。
蓝绿/金丝雀
安全部署。
对于移动设备
优化的API
更少的呼叫，聚合的数据。
缓存
CDN 和 API 缓存。
###离线
网络故障时的恢复能力。
版本控制
版本化 API 以实现兼容性。
测试
###单位
为了服务。
整合
服务之间的通信。
###合约
消费者和提供商就合同达成一致。
端到端
完整的服务流程。
迁移
绞杀者图案
逐渐取代[整体6。
###从小事做起
从服务开始。
###提取
识别明确定义的域。
常见错误
过早分配
在您需要微服务之前就使用它们。
纳米服务
服务太小了。
没有可观察性
无法调试。
忽略延迟
多次网络调用。
结论
微服务提供可扩展性和灵活性，但也很复杂。如有必要，请根据您的情况进行评估，投资于[可观察性7]并按纪律操作。对于移动应用程序，重点关注优化的 API 和弹性。
##常见问题解答
1) 我需要 Kubernetes 来实现 [微服务8? 不一定。但它在规模上有很大帮助。
2) 多少服务太多？ 没有神奇的数字。如果团队无法管理，那就太过分了。
3) 手机端应该直接调用[微服务9? 一般不会。使用 API 网关或 BFF。
4) 微服务总是更好吗？ 不会。在很多情况下，制作精良的整体架构可能会更好。
5) 如何开始[微服务10? 启动[模块化单体11。需要时提取。
另请阅读
- [应用后端：架构、技术和最佳实践12
- [单体 vs 微服务：选择哪种架构13
- [可扩展的软件架构：如何构建可增长的系统14
- [可扩展的软件架构 - 扩展的最佳实践15
- [可扩展的软件架构-初创公司的最佳实践16
- [可扩展的软件架构-小型团队的最佳实践17