微服务架构的先决条件

下面是我总结的内容,感觉这样会更好理解:

  • 敏捷基础设施
  • 公共基础服务(中间件)
  • 故障反馈机制(监控告警)
  • 流程与自动化工具链(DevOps流水线)
  • 微服务框架(SpringCloud/Dubbo)

快速配置

如果你的开发团队里只有少数几个人可以配置新服务、虚拟环境或其他配套设施,那说明你们还没有为微服务做好准备。你的每个团队里都应该要有几个这样的人,他们具备了配置基础设施和部署服务的能力,而且不需要求助于外部。要注意,光是有一个 DevOps 团队并不意味着你在实施DevOps。开发人员应该参与管理与应用程序相关的组件,包括基础设施。

类似的,如果你没有灵活的基础设施(易于伸缩并且可以由团队里的不同人员来管理)来支撑当前的架构,那么在迁移到微服务前必须先解决这个问题。你当然可以在裸机上运行微服务,以更低的成本获得出众的性能,但在服务的运维和部署方面也必须具备灵活性。

基本的监控

如果你不曾对你的单体应用进行过性能监控,那么在迁移到微服务时,你的日子会很难过。你需要熟悉系统级别的度量指标(比如CPU和内存)、应用级别的度量指标(比如端点的请求延迟或端点的错误)和业务级别的度量指标(比如每秒事务数或每秒收益),这样才可以更好地理解系统的性能。

在性能方面,微服务生态系统比单体系统要复杂得多,就更不用提诊断问题的复杂性了。你可以搭建一个监控系统(如 Prometheus),在将单体应用拆分成微服务之前对应用做一些增强,以便进行监控。

快速部署

如果你的单体系统没有一个很好的持续集成流程和部署系统,那么要集成和部署好你的微服务几乎是件不可能的事。

想象一下这样的场景: 10个团队和100个服务,它们都需要进行手动测试和部署,然后再将这些工作与测试和部署一个单体所需要的工作进行对比。100个服务会出现多少种问题? 而单体系统呢? 这些先决条件很好地说明了微服务的复杂性。

0%