下面是我总结的内容，感觉这样会更好理解：
- 敏捷基础设施
- 公共基础服务（中间件）
- 故障反馈机制（监控告警）
- 流程与自动化工具链（DevOps流水线）
- 微服务框架（SpringCloud/Dubbo）
快速配置
如果你的开发团队里只有少数几个人可以配置新服务、虚拟环境或其他配套设施，那说明你们还没有为微服务做好准备。你的每个团队里都应该要有几个这样的人，他们具备了配置基础设施和部署服务的能力，而且不需要求助于外部。要注意，光是有一个 DevOps 团队并不意味着你在实施DevOps。开发人员应该参与管理与应用程序相关的组件，包括基础设施。
类似的，如果你没有灵活的基础设施(易于伸缩并且可以由团队里的不同人员来管理)来支撑当前的架构，那么在迁移到微服务前必须先解决这个问题。你当然可以在裸机上运行微服务，以更低的成本获得出众的性能，但在服务的运维和部署方面也必须具备灵活性。
基本的监控
如果你不曾对你的单体应用进行过性能监控，那么在迁移到微服务时，你的日子会很难过。你需要熟悉系统级别的度量指标(比如CPU和内存)、应用级别的度量指标(比如端点的请求延迟或端点的错误)和业务级别的度量指标(比如每秒事务数或每秒收益)，这样才可以更好地理解系统的性能。
在性能方面，微服务生态系统比单体系统要复杂得多，就更不用提诊断问题的复杂性了。你可以搭建一个监控系统(如 Prometheus)，在将单体应用拆分成微服务之前对应用做一些增强，以便进行监控。
快速部署
如果你的单体系统没有一个很好的持续集成流程和部署系统，那么要集成和部署好你的微服务几乎是件不可能的事。
想象一下这样的场景: 10个团队和100个服务，它们都需要进行手动测试和部署，然后再将这些工作与测试和部署一个单体所需要的工作进行对比。100个服务会出现多少种问题? 而单体系统呢? 这些先决条件很好地说明了微服务的复杂性。