1、什么是微服务?
微服务是分布式架构的一种,分布式架构其实就是要把服务做一个拆分,而springcloud只是解决了拆分过程中的服务治理问题。
在单体架构中,我们把所有的服务都写在一起,随着业务的复杂代码的耦合度就会越来越高,不便于将来的升级维护。
所以往往需要拆分这些服务,微服务在拆分的时候,会根据业务功能模块把一个单体的应用拆分成许多个独立的项目,每个项目完成一部分的业务功能,然后独立开发和部署。这些独立的项目就成为一个微服务。进而构成一个服务集群。
举例:
一个商城系统就得提供相当多的服务, 比如订单服务,用户功能,商品服务,支付服务等等,这些模块如果使用单体架构来实现,那么耦合度会相当高,开发难度也会很大。如果使用微服务开发,把每一个服务都当成一个单体应用来开发,那么订单服务,用户服务,商品服务,支付服务等模块,每一个就成为一个微服务。
由这些微服务构成整个的商城系统。这样明显是更加合理的。每个服务也可以根据业务的需要去进行集群部署。一方面降低了服务的耦合,一方面有利于服务的维护升级。
2、微服务的相关技术栈:
2.1 注册中心:
一个业务往往就需要多个服务来共同完成,比如一个请求发送过来,先是调用了服务a,然后服务a调用服务b,服务b调用服务c;
然而,当业务越来越复杂的时候,这些服务之间的调用关系就错综复杂,所以这个时候需要一个注册中心,用来记录每一个服务的ip,端口,以及它能完成的功能,然后这些服务之间要互相调用的时候,不用去记录服务的ip,只要到注册中心找就可以了。
2.2 配置中心:
每个服务都有自己的配置文件,而一个上线的项目可能会有成百上千的服务,这些配置文件,我们不可能一个一个去修改,这个时候需要一个配置中心,它主要用来统一管理整个服务集群成千上百的配置,我们要变更某些配置,只要找到配置中心就可以了,它就会去找到对应的配置,实现配置的热更新。
2.3 网关:
所有的请求进来,并不能直接就去访问对应的服务,而是要通过一个网关服务,由它来路由到对应的服务。
2.4 分布式缓存:
数据库层,由于数据库即使是集群部署,也很难抗住高并发,往往还需要一个缓存集群,把数据库的数据搬到内存中以提高访问效率。请求先查询缓存,缓存未命中的时候再去查询数据库。
2.5 分布式搜索:
对于一些复杂的数据的搜索、统计、分析,我们还需要使用搜索集群。
2.6 消息队列:
在分布式架构中,还需要消息队列,因为一个业务往往会调用多个服务,但我们不能等到所有的服务都执行完成再返回响应数据,因为这样操作就类似串行执行,响应速度有所下降。这个时候可以使用消息队列,让服务发送消息通知其他服务去执行指定的任务,而自己则可以结束运行,提高响应速度。
2.7 分布式日志服务:
分布式日志服务:主要用来统计成百上千的服务的运行日志,方便系统出问题时的定位。
2.8 系统监控链路追踪:
系统监控链路追踪:可以实时监控整个服务集群的所有节点的运行状态。
3、单体架构和微服务的区别:
3.1 单体架构:
将业务的所有功能集中在一个项目中开发,打成一个包部署。
架构简单,部署成本低,但是代
码的耦合度搞,所有的模块都耦合在一起。
3.2 分布式架构:
根据业务功能对系统进行拆分,每个业务模块都作为独立的项目来开发,成为一个服务。
降低服务之间的耦合度,有利于服务升级拓展;
4、微服务的特征:
4.1 单一职责:
微服务拆分粒度更小,每一个服务都对应唯一的业务能力,做到单一职责,避免重复业务开发;
4.2 面向服务:
微服务对外暴露业务接口;
4.3 自治:
团队独立,技术独立,数据独立,部署独立;
4.4 隔离性强:
服务调用做好隔离、容错、降级、避免出现级联问题。
5、服务拆分及远程调用:
5.1 服务拆分的原则:
-
不同微服务,不要重复开发相同的业务;
-
微服务数据独立,不要访问其他微服务的数据库;
-
微服务可以将自己的业务暴露为接口,供其他微服务调用。
5.2 服务的远程调用:
1、服务的远程调用:类比浏览器发送http请求给服务,可以获取到对应的json,那么在java代码中,我们也可以发送一个http请求给另一个服务以获取对应的json数据。
2、在java中,我们要发送http请求,可以使用restTemplate;
先自我介绍一下,小编13年上师交大毕业,曾经在小公司待过,去过华为OPPO等大厂,18年进入阿里,直到现在。深知大多数初中级java工程师,想要升技能,往往是需要自己摸索成长或是报班学习,但对于培训机构动则近万元的学费,着实压力不小。自己不成体系的自学效率很低又漫长,而且容易碰到天花板技术停止不前。因此我收集了一份《java开发全套学习资料》送给大家,初衷也很简单,就是希望帮助到想自学又不知道该从何学起的朋友,同时减轻大家的负担。添加下方名片,即可获取全套学习资料哦