搜狐首页 科技 楚乔传

手机搜狐

SOHU.COM

一个运维老鸟眼中的DevOps和微服务

单体应用VS微服务

让我们先从运维的真实场景出发,来看一下单体应用存在的问题。这里先分享两个真实的生产案例:

案例一是某核心业务系统,所有的业务逻辑代码都打包在同一个WAR包里部署,运行了将近几百个同构的实例在虚拟机上。某次因为应用包中的一个功能模块出现异常,导致实例挂起,整个应用都不能用了。因为它是一个单体,所以尽管有几百个实例在运行,但是这几百个实例都是异常的。业务系统是经过多年建设起来的,排查起来也很复杂,最终整个业务系统瘫痪了近六个小时才恢复。同时,因为有多个前台系统也调用了这个后台系统,导致所有要调用的前台系统也都全部瘫痪了。设想一下,如果这个场景使用的是微服务架构,每个微服务都是独立部署的,那影响的也只是有异常的微服务和其他相关联的服务,而不会导致整个业务系统都不能使用。

另外的案例是一个客服系统,这个系统有一个特点,早上八点的时候会有大量的客服登录。这个登录点是全天中业务并发量最高的时间点,登录时系统需要读取一些客户信息,加载到内存。后来一到早上客服登录时,系统经常出现内存溢出,进而导致整个客服系统都用不了。当时系统应对这种场景做架构冗余时,并不是根据单独的业务按需进行扩展,而是按照单体应用的长板进行冗余。比如说早上八点并发量最高,单点登陆模块业务需求非常大,为适应这个时间点这个模块的业务压力,系统会由原来的八个实例扩展到十六个实例,这时的扩展是基于整个系统的。但事实上,在其他时间段,这个单点登陆模块基本不使用,且监控的数据显示,主机的资源使用情况基本在40%以下,造成了很大的资源浪费。所以在一个大型的业务系统中,每个服务的并发压力不一样,如果都按压力最大的模块进行整体扩展,就会造成资源的浪费,而在微服务的模式下,每个服务都是按自身压力进行扩展的,就可以有效的提高资源利用率。

从这两个例子中,我们可以看出,单体应用存在如下两个问题:一个是横向扩展时需要整体扩展,资源分配最大化,不能按需扩展和分配资源;另一个是如果单体中有一个业务模块出现问题,就会是全局性灾难,因为所有业务跑在同一个实例中,发生异常时不具备故障隔离性,会影响整个业务系统,整个入口都会存在问题。

因此,我们当时考虑把综合业务拆分,进行更好的资源分配和故障隔离。

图 1

下面我们看一下单体应用和微服务的对比,如图1所示。这里从微服务带来的好处和额外的复杂性来讲。

微服务的好处:

精选