微服务之理论

什么是微服务

在介绍微服务时,首先得理解什么是微服务,顾名思义,微服务得从两个方面去理解,什么是 '微' 什么是服务

微狭义来讲就是体积小

服务,一定要区别于系统,服务一个或者一组相对较小且独立的功能单元,是用户可以感知最小功能集

架构的演变

MyAnswer博客

什么需要微服务

早期单体架构带来的问题 : 单体架构在规模比较小的情况下工作情况良好,但是随着系统规模的扩大,它暴露处理的问题也越来越多

     1.复杂性逐渐变高-->比如有的项目有几十万行代码,各个模块之间比较模糊,逻辑比较混乱,代码越来越多复杂性越高,越难解决遇到的问题

     2.技术债务逐渐上升-->单体项目代码量庞大的惊人,留下来的坑很难被发现

     3.阻碍技术创新-->比如以前的某个项目使用的是3.2,由于各个模块之间有着千丝万缕的联系,代码量大,逻辑不够清楚,用t5重构成本大

     4.无法按需伸缩-->比如说电影模块是cpu密集型的模块,而订单模块是IO密集型的模块,由于所有模块都在一个架构下,无法进行扩展

     5.系统高可用性差-->因为所有的功能开发最后都部署到同一个框架里,运行在同一个进程之中,一旦某一功能涉及的代码或者资源有问题,那就会影响整个框架中部署的功能

微服务优势与缺点

特性

1.每个微服务可独立运行在自己的进程里

2.一些列独立,运行的微服务共同构建起了整个系统

3.每个服务为独立的业务开发,一个微服务一般完成某个特定的功能,比如:订单管理,用户管理等

4.微服务之间通过一些轻量级的通信机制进行通信,例如通过REST API或者RPC的方式进行调用

优点

1.易于开发和维护-->由于微服单个模块就相当于一个项目,开发这个模块我们就只需要关系这个模块的逻辑即可,代码量和逻辑复杂度都会降低,从而易于开发和维护

2.启动较快-->这是相对单个微服务来讲的,相比于启动单体架构的整个项目,启动某个模块的服务速度明显是要快很多的

3.局部修改容易部署-->在开发中发现了一个问题,如果是单体架构的话,我们就需要重新发布并启动整个项目,非常耗时间,但是微服务则不同,哪个模块出现了bug我们只需要解决哪个模块的bug就可以了,解决完bug之后,我们只需要重启这个模块的服务即可,部署相对简单,不必重启整个项目从而大大节约时间

4.技术栈不受限-->比如订单微服务和电影微服务原来都是用java写的,现在我们想把电影微服务改成php技术,这是完全可以的,而且由于所关注的只是电影的逻辑而已,因此技术更换的成本也就会少很多

5.按需伸缩-->我们上面说了电梯架构在想扩展某个模块的性能时不得不考虑到其他模块的性能会不会受到影响,对我我们的微服务来讲,完全不是问题,电影模块通过什么方式来提升性能不必考虑其它模块的情况

缺点

1.运维要求较高-->对于单个架构来讲,我们只需要维护好这一个项目就可以了,但是对于微服务架构来讲,由于项目是由多个微服务构成的,每个模块出现问题都会造成整个项目运行出现异常,想知道是哪个模块造成的问题往往是不容易的,因为我们无法一步一步通过debug的方式来跟踪,这就对运维人员提出了很高的要求

2.分布式的复杂性-->对于单体架构来讲,我们可以不使用分布式,但是对于微服务的架构来说,分布式几乎是必会的技术,由于分布式本身的复杂性,导致微服务架构也变得复杂起来,比如分布式事务的解决

3.接口调用成本高-->比如,用户微服务是要被订单微服务和电影微服务所调用的,一旦用户微服务的接口发送大的变动,那么所有依赖它的微服务都要做响应的调整,由于微服务可能非常多,那么调整接口所造成的成本将会明显提高

4.重发劳动-->对于单体架构来讲,如果某段业务被多个模块所有共同使用,我们便可以抽象成一个工具类,被所有模块直接调用,但是微服务却无法这样做,因为我们这个的工具类是不能被其它微服务所直接调用的,从而我们便不得不在每一个微服务上都建这么一个工具类,从而导致代码的重复

微服务与单体架构的区别

1.单体架构所有的模块全部都耦合在一起,代码量大,维护困难,微服务每个模块就相当于一个单独的项目,代码量明显减少,遇到问题也相对来说比较好解决

2.单体架构所有的模块都共用一个数据库,存储方式比较单一,微服务每个模块都可以使用不同的存储方式(比如有的用redis,有的用mysql),数据库也是单个模块对应自己的数据库

3.单体架构所有的模块开发所使用的技术一样,微服务每个模块都可以使用不同的技术开发,开发模式更灵活

什么样的项目适合微服务

1.微服务可以按照业务功能本身的独立性来划分,如果系统提供的业务是非常底层的 如:操作系统内核,存储系统,网络系统,数据库系统等,这类系统都会偏底层,功能和功能之间有着紧密的配合关系,如果强制拆分为较小的服务单元,会让集成工作量急剧上升,并且这种人为的切割无法带来业务上的真正隔离,所以无法做到独立部署和运行,也就不适合做出微服务了

2.能不能做成微服务,取决于四个要素

   小:微服务体积小

   独:能独立的部署和运行

   轻:使用轻量级的通信机制和架构

   送:为服务之间是松耦合的

微服务拆分与设计

1.从单体式结构转向微服务架构中会持续碰到服务边界划分的问题:比如,我们有user服务来提供用户的基础信息,那么用户的头像和图片等是应该单独划分为一个新的service更好还是应该合并到user服务里呢?如果服务的粒度划分的过粗,那就回到了单体式的老路,如果过细,那服务间调用的开销就变得不可忽视了,管理难度也会增加,目前为止还没有一个可以称之为服务边界划分的标准,只能根据不同的业务系统加以调节

2.拆分的大原则是当一块业务不依赖或极少依赖其他服务,有独立的业务语义,那么它就应该被拆分成一个独立的服务模块

设计原则

1.单一职责原则-->意思是每个微服务只需要实现自己的业务逻辑就可以了,比如订单管理模块,它只需要处理订单的业务逻辑就可以了,其它的不必考虑

2.服务自治原则-->意思是每个微服务从开发,测试,运维等都是独立的,包括存储的数据库也都是独立的,自己就有一套完整的流程,我们完全可以把它当成一个项目来对待,不必依赖于其它模块

3.轻量级通信原则-->首先是通信的语言非常的轻量,第二,改通信方式需要是跨语言,跨平台的,之所以要跨平台,跨语言就是为了让每个微服务都足有的独立性,可以不受技术的限制

4.接口明确的原则-->由于微服务之间可能存在着调用关系,为了尽量避免以后由于某个微服务的接口变化而导致其他微服务都做调整,在设计之初就要考虑到所有情况,让接口尽量做的更通用,更灵活,从而尽量避免其他模块也做调整



MyAnswer博客
请先登录后发表评论
  • 最新评论
  • 总共0条评论