单体应用伸缩性差,而且随着应用规模的扩大,业务逻辑和开发部署过程都变得极其复杂。牵一发而动全身,任何一个微小的改动都有可能影响整个应用,新技术的更新换代对于单体应用来说几乎是个不可能的任务。
相比单体应用,微服务灵活自由,伸缩性强,近年来深受软件开发者的热捧。不过,微服务虽然没有了单体应用的某些局限,但却对开发运维和整个组织提出了更高的要求。在采用微服务架构之前开发者要先想清楚自己的项目是否适合采用微服务架构,以及是否有足够的能力运维一个微服务生态系统。
微服务概念的提出者Martin Fowler其实在很早之前就说明了 使用微服务需要具备的三个核心能力 ,分别是服务器的快速扩容、监控和应用的快速部署。下面是具体介绍。
硬件资源是否能够快速到位
为了避免资源竞争和服务间的相互影响,微服务一般是部署在单独的硬件资源上。当有新的微服务加入系统,或者需要对微服务进行伸缩时,必需能足够快地为其准备相应的硬件资源。如果使用了云服务,在获取新资源时会相对容易一些。但在没有云服务的情况下,那么至少需要有一个自动化或者半自动化的系统能够满足快速分配资源的需求。
是否具备了微服务监控能力
微服务生态系统可能会很庞大,服务间相互依赖,个体微服务的可用性会影响整个系统的可用性。对微服务进行监控可以及时地发现微服务的运行状况,如果有些服务出现故障(可能有些在测试阶段没有被测出来的缺陷进入了生产环境),需要及时回滚到之前的稳定版本,避免对系统的整体可用性造成影响。
是否具有快速的开发部署流程
微服务变化很快,一个微服务在一天之内可能需要部署多次,因此需要一个快速的开发、部署以及测试流程。可以在整个流程中引入 部署管道 ,部署管道规定了一系列严格的自动化部署过程,可以加快部署的速度。
微服务系统通常涉及多个团队之间的合作,除了开发团队之间的合作之外,还有开发团队和运维团队之间的合作。运维团队需要保证开发团队能够活得足够的资源,当发生问题时,运维团队能够快速向开发团队暴露问题,开发团队能够及时地解决问题。 DevOps 是开发和运维之间的粘合剂,可以促进团队之间的合作。
微服务系统比我们想象的要复杂得多。微服务给我们带来了诸多好处,同时也对我们提出了更高的要求。必要的时候,我们需要通过调整组织结构来更好地支持微服务系统的发展。所以在转向微服务架构时,需要先考虑好这些问题,并想清楚微服务是否真的适合自己。