单体应用和微服务之间的选择是最重要的架构决策之一。没有普遍的答案，这取决于上下文。本指南比较了这些方法并帮助您做出决定。
什么是整体式架构
定义
封装所有逻辑的单一集成应用程序。
特点
- 代码库
- 一次部署
- A [数据库0
- 耦合组件
什么是微服务
定义
应用程序由小型且独立的服务组成。
特点
- 多个代码库
- 独立部署
- 独立座位
- 通过网络通讯
整体式的优点
简单
移动部件更少。容易理解。
快速发展
一开始，效率更高。
测试
更简单的集成测试。
调试
单堆栈跟踪。
交易
银行的原生 ACID。
操作
要监视的服务。
整体式的缺点
可扩展性
缩放全部或不缩放。
部署
小改动重新部署一切。
技术
一个可以容纳一切的堆栈。
大团队
合并冲突，协调。
脆弱性
改变一个可能会破坏另一个。
微服务的优点
独立的可扩展性
仅扩展您需要的内容。
独立部署
更新不影响别人。
韧性
孤立的失败并不会导致一切失败。
灵活的技术
每项服务都尽其所能。
自治团队
所有权清晰，锁更少。
微服务的缺点
操作复杂性
还有更多部件需要管理。
延迟
网络通讯。
调试
跨服务跟踪。
一致性
复杂的分布式事务。
初始开销
生产前的重要设置。
决策标准
团队规模
小→巨石。大型 → 考虑微服务。
域复杂性
简单 → 整体。多个有界上下文→微服务。
必要的可扩展性
统一→整体。不同的部分→微服务。
DevOps 成熟度
低→整体。高 → 可行的微服务。
送货速度
需要快速 → 整体。您可以投资 → 微服务。
模块化整体架构
概念
模块内部分离良好的整体。
优势
整体简单，分体制备。
模式
干净的架构，每个域的模块。
模块化优先方法
策略
启动模块化整体，在需要时提取。
好处
避免过早的复杂化。
何时提取
当出现音阶或速度疼痛时。
迁移路径
绞杀者图案
新制度逐渐取代旧制度。
按域提取
识别有界上下文。
数据库第一个/最后一个
不同的数据策略。
用例
巨石
- 启动[MVP1
- 小团队
- 简单域
- 概念证明
微服务
- 成立公司
- 大型且分散的团队
- 每个组件的可变比例
- 复杂领域
示例
单体应用的成功
Basecamp、Shopify（最初）、大量 SaaS。
微服务的成功
Netflix、亚马逊、Uber（大规模）。
返回巨石
亚马逊 Prime 视频，细分。
混合动力
整体+服务
整体核心，辅助服务。
迷你服务
服务更少，比微服务更大。
实用主义
使用有意义的东西，而不是教条。
常见错误
默认微服务
不必要地采用。
纳米服务
服务太小了。
分布式整体架构
微服务作为整体耦合。
忽略运营成本
低估了分布式操作的复杂性。
结论
不存在普遍更好的架构。从简单的模块化整体开始，必要时进行演变。当环境证明其复杂性合理时，微服务是一个强大的工具。
##常见问题解答
1) 微服务总是更好吗？ 不会。在许多情况下，Monolith 可能是正确的选择。
2) 何时从整体迁移到微服务？ 当规模、速度或团队带来的痛苦出现时。
3) 一个 5 人的团队是否应该使用微服务？ 可能不会。模块化整体架构的生产力更高。
4) 我可以在没有 [Kubernetes2´ 的情况下拥有微服务吗？ 是的。但[Kubernetes3让操作变得更加容易。
5) 采用微服务时最大的错误是什么？ 采用得太早，操作不成熟。
另请阅读
- [应用中的微服务：移动分布式架构4
- [可扩展的软件架构：如何构建可增长的系统5
- [单体与微服务 - 用例与示例6
- [单体与微服务：实践中的用例7
- [可扩展的软件架构 - 扩展的最佳实践8
- [可扩展的软件架构-初创公司的最佳实践9