微服务概念详细介绍

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/xingbaozhen1210/article/details/89531515

目录

一、单机服务到微服务的演变

二、微服务的定义

三、微服务为我们解决了哪些问题

四、当前微服务面临的挑战

五、结语


一、单机服务到微服务的演变

微服务,顾名思义就是“微小的服务”。主要就是从两个方面进行理解,什么是“微”?什么是“服务”?当然,服务的意思很好理解,就是实际工作中的一个完整的生产项目,例如淘宝网站,微信软件等等。然后再让我们通过下文来理解为什么要细化到“微”这个量级。

在认识微服务之前,我们先来看一下在微服务未出现时的传统单体架构服务(即单机服务)。

如上图所示,在单机服务中,一个项目所有的功能服务全部集中在一起,所有的开发人员都在这个项目中开发各自的模块,除了容器以外基本没有其他的依赖。在发布到生产环境时,将所有文件集中打在一个war包里,整个部署在tomcat或其他容器里。在这个里面,包含了页面展示、业务处理,数据交互等所有的模块。

单机服务是早期主流的架构系统,适用于开发周期短,规模不大的项目。在传统互联网环境中,这种单机架构工作情况良好,且由于代码的高度集中,还有以下几个优点 :

  • 集中管理,开发简单
  • 功能业务耦合在一起,不会有重复作业
  • 部署简单方便,一次构建启动所有模块

在传统的IT行业,大多数都是各种独立系统的堆砌,所以单机服务适用于这样的场景。但随着互联网的发展,项目的规模越来越大,各个模块更新迭代的速度越来越快,以及对系统扩展性稳定性的追求越来越高,单机服务就很难应付了,出现了各种各样的问题。

  • 开发效率缓慢;当项目代码多达几十万行或者开发人员达到一定量级时,所有的编码作业都在一个项目中完成。就导致代码的提交相互等待,而且代码冲突频发
  • 代码维护困难;业务逻辑过度耦合,更新迭代无从入手
  • 部署不灵活;任何小的变更,都需要重新构建整个应用,相应时长增加。并且重启时需要停机,对高流量网站又是极大的牺牲
  • 缺乏足够的健壮性;项目中的任意模块的一个问题(死循环、内存泄露等),就会影响到项目整体,导致应用直接瘫痪
  • 扩展性欠佳;无法满足高并发场景中,对单一模块进行水平扩展。以电商平台为例,浏览商品信息的流量肯定是远远大于下单的流量的,如果相对商品模块进行单独扩展,则单机服务施行起来就非常困难

通俗的来讲,单机服务就是把所有鸡蛋放在一个篮子中,便利与风险共存。当篮子摔了或者篮子里的任意一个“鸡蛋”出现问题时,其他“鸡蛋”都会受到殃及。

在以上问题越来越影响整体项目的时候,就迫切地需要新的技术新的架构来提供解决方案。在微服务兴起之前,项目架构又逐渐演进为mvc前后端分离架构,rpc分布式架构,soa流动计算架构等等,这几个架构的目的就是将原本多余集中的“鸡蛋”分散开来,降低整体带来的风险,直到现在发展为当下最新的微服务架构。

二、微服务的定义

微服务,最早是有Martin Fowler与James Lewis于2014年共同提出的一个概念。是当前比较主流的一种软件设计架构。

简而言之,就是将一个大型的单机应用系统拆分成若干个小的服务,这些小的服务独立部署,服务与服务之间采用rpc/http轻量协议传输数据,服务间不具有强耦合性,从而实现了单个服务的高内聚,服务与服务之间低耦合的效果。这些一个一个细分的小服务就称之为微服务。

微服务的架构图如下 :

 

如图所示,除了视图层的拆分外,主要是服务层和数据层的细纬度划分,每个服务都可以看作一个微小版的单机服务,每个微服务都可以单独对上游请求发起响应,同时他们之间又是相互隔离的,不会因为某一个的服务故障导致事故传播。

相比于单机服务与其他架构,微服务架构的主要特征是组件化、松耦合、独立、去中心化。主要表现在如下几个方面:

  • 细粒度的服务分解;将项目中每个模块/每个职责拆分出来,专注做好一件事情。
  • 独立部署运行和扩展;每个微服务又是一个单独的项目,独立运行在自己的进程里。它可以不依赖于其他服务进行单独使用和灵活扩展。这种运行和部署方式能够赋予系统灵活的代码组织和发布节奏,使得快速交互和应对变化成为可能。
  • 服务间轻量通讯;各个服务之间相互独立又通过协议进行通讯,协作完成更复杂的业务。
  • 去中心化,独立开发与自治;技术选型灵活,服务之间可以用不同的技术甚至不同的语言。

三、微服务为我们解决了哪些问题

相对于传统单机服务,微服务不仅解决了之前存在的问题,还拥有一些单机服务所不具备的优点:

  • 便于开发,降低复杂度;各个团队中分别维护各自服务,不会出现等待的无用功的间隙

并且更新迭代的时候,不必再学习整个项目的业务代码,仅关注所在的服务模块即可

  • 业务解耦;各个服务间通过协议互相通讯,代码没有强耦合性,互不干扰
  • 独立部署;每个模块都可以单独部署,所以在上线新功能的时候只需发布相应的模块即可,既降低测试的工作量也降低了服务发布的风险(单服务情况下,新增需求可能就得把整个的流程测试再回归一下,并且上线失败的话整个项目都要回滚,而微服务则只需要回滚相应的模块即可)
  • 稳定性强;单个服务出现问题,其他服务仍可继续工作,这在技术潮流中是非常重要的一个进步,结合集群部署,我们完美的实现不停机更新

例如订单服务故障,用户仍然通过商品服务可以浏览商品信息,查看评价等

  • 扩展性强;可以根据不同服务的流量和压力,进行自主扩展

即商品服务流量高,而订单服务流量低,则可以部署两个商品服务,一个订单服务,更加灵活 

四、当前微服务面临的挑战

在当前的场景中,微服务也不是万能的一种方案。至少在现阶段,它还存在着如下几个问题:

  • 运维成本增加;需要部署N个项目,对于单机服务来讲,只需要维护一个项目就行了。但是对于微服务来讲,由于项目是多个微服务构成的,每个模块都需要进行维护
  • 问题追踪难度增加;需要分析整个请求的调用链,逐步查看各个服务的状况,依此来定位和解决问题
  • 内容重复;对部分业务,流程大致相同时,如果不能很方便的将代码封装,就可能导致在多个服务中有些重复性的代码

除此外还有日志重复,一个调用链可能要调用N个服务,在追踪问题时,每个服务都要对参数和响应进行记录。这样就导致同样一份内容在多个地方重复出现

  • 增加开支成本 , 标准的的微服务部署方案,应该是每一个服务部署到一个服务器上,各个服务器之间互不干扰,但这样的话无疑就需要更高的服务器成本

当前的主流方案是利用docker采用单服务器多镜像隔离,但docker镜像并没有传统虚拟机的高度资源隔离水平,它仍然需要很多共享的东西。这就导致了如果其中一个docker内核崩溃或占用共享资源,其他容器也会受到影响

五、结语

相对于传统单机服务,微服务的灵活独立可用性高等特性,更适合当前主流互联网的发展需求,也是现下技术领域中更可靠的一种技术方案,已经有很多的大型项目及技术团队采用微服务的架构。

随着微服务生态及社区的发展,越来越丰富的组件方案为微服务提供了更方便的运维和监控,同时随着docker技术的趋于成熟,也降低了微服务自身的负面问题影响,可以预见未来微服务仍有很大的发展空间,它已逐渐成为当前最流行的一种设计架构。

展开阅读全文

没有更多推荐了,返回首页