运维是如何看待微服务和容器的

　　微服务在带来良好的设计和架构理念的同时，也带来了运维上的额外复杂性，尤其是在服务部署和服务监控上。那么，运维是如何看待微服务和容器的呢？传统的单体应用又该如何完成微服务拆分？如何进行微服务之间的依赖关系管理？对此，陈爱珍带来了她的分享。以下是正文：

　　单体应用 VS 微服务

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

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

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

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

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

　　图 1

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

　　微服务的好处：

　　局部修改，局部更新。当运维对一个单体应用进行修改时，可能要先把整个包给停了，然后再去修改，而微服务只需逐步修改和更新即可；

　　故障隔离，非全局。单体应用是跑在一起，所以只要一个模块有问题，其他就都会有问题。而微服务的故障隔离性、业务可持续性都非常高；

　　资源利用率高。单体应用的资源利用率低，而使用微服务，可以按需分配资源，资源利用率会非常高。

　　微服务带来的复杂性：

　　微服务间较强的依赖关系管理。以前单体应用是跑在一起，无依赖关系管理，如果拆成微服务依赖关系该如何处理，比如说某个微服务更新了会不会对整个系统造成影响。

　　部署复杂。单体应用是集中式的，就一个单体跑在一起，部署和管理的时候非常简单，而微服务是一个网状分布的，有很多服务需要维护和管理，对它进行部署和维护的时候则比较复杂。

　　如何更好地利用资源。单体应用在资源分配时是整体分配，扩展时也是整体扩展，数量可控，而在使用微服务的情况下，需要为每一个微服务按需分配资源，那么该为每个微服务分配多少资源，启动多少个实例呢，这也是非常大的问题。

　　监控管理难。以前我们用Java，就是一个单体应用，监控和管理非常简单，因为它就是一个1，但是使用微服务它就是N个，监控管理变得非常复杂。另外是微服务之间还有一个协作的问题。

　　基于容器构建微服务架构

　　使用微服务，第一步是要构建一个一体化的DevOps平台，如图2。如果你不使用DevOps做微服务的话，整个环境会变得非常的乱、非常的糟糕。它会给你的整个开发、测试和运维增加很多成本，所以第一步我们是提高DevOps的能力，能够把它的开发、部署和维护进行很完美的结合，才可以说我们真正能够享受到微服务架构的福利。