关注
微服务【分布式架构&认识微服务&SpringCloud】第1章

目录

1,认识微服务

1.1,单体架构

1.2,分布式架构

1.3,微服务

1.4,SpringCloud

1.5,总结


  • 💂 个人主页: 爱吃豆的土豆
  • 🤟 版权: 本文由【爱吃豆的土豆】原创、在CSDN首发、需要转载请联系博主
  • 💬 如果文章对你有帮助、欢迎关注、点赞、收藏(一键三连)和订阅专栏哦
  • 🏆人必有所执,方能有所成!

  • 🐋希望大家多多支持😘一起进步呀!

1,认识微服务

1.1,单体架构

单体架构:将业务的所有功能集中在一个项目中开发,打成一个包部署。(意思就是说,所有的功能在一个项目中进行实现,不用管复杂的架构设计,只需要创建一个项目,有功能就往这个项目里面加代码就ok了)

优点:

1,架构简单:不需要搞复杂的架构设计理念

2,部署成本低:把写好的项目打成包,在tomcat服务器上面部署一下,用户就可以访问了,如果用户访问多了,那就在加两个服务器,形成负载均衡的集群。

缺点:

1,耦合度高:在大型项目的开发中,像拼多多,淘宝这些,一个大型项目里面有很多的功能模块,代码量十几万行甚至于几十万行代码,如果使用单体架构。
第一:打包部署就可以需要很久,效率太低。
第二:项目中的功能模块的代码你中有我,我中有你,假设其中一个模块中出现问题,其他模块也会受到影响,代码的边缘化也越来越模糊。所以在大型项目中基本上都是采用分布式架构

1.2,分布式架构

分布式架构:根据业务功能对系统做拆分,每个业务功能模块作为独立项目开发,称为一个服务

 

分布式架构的优缺点:

优点:

  • 降低服务耦合:每个功能模块,都成为了单独的项目,大家各写各的项目,没有过多的牵扯耦合度就会大大的降低,两外像打包速度,代码量都会减少。

  • 有利于服务升级和拓展:像以后功能模块项目/服务进行升级维护也影响不了别的功能模块项目的正常进行。

缺点:

  • 服务调用关系错综复杂:一个大型的项目被拆分许多的服务,各个服务的功能模块该如何调用?许多的服务部署起来也是比较麻烦。

分布式架构虽然降低了服务耦合,但是服务拆分时也有很多问题需要思考:

  • 服务拆分的粒度如何界定?(就是说一个大型项目被拆分为许多的服务,该如何拆分哪几个服务作为单独的模块,那些业务不需要拆分,这个拆分的粒度需要把握

  • 服务集群地址如何维护?(就像下面一个支付功能的服务,就部署了两台机器,如果是个大型项目需要部署上百台的,这些服务集群的地址该如何的维护和调用,总不能把地址写死吧!如果部署上线地址变了怎么办,维护起来很麻烦

  • 服务之间如何实现远程调用(各个服务之间该如何进行远程调用呢?)?

  • 服务健康状态如何感知?(加入用户功能这个服务调用商品功能这个服务,刚好这个商品服务出问题了挂了,这边一调用也导致用户功能服务也出问题了,这样就造成了级联失败)

为了解决这些问题,人们需要制定一套行之有效的标准来约束分布式架构。出现了各种各样的技术(如下图)去解决这些问题:但是近几年运用最广泛的最火的莫过于微服务

1.3,微服务

 

微服务是一种经过良好架构设计的分布式架构方案,微服务架构特征(微服务它还是一种分布式架构只不过人们在设计分布式过程中踩坑,不断的总结经验,得到了良好的分布式架构实践方案):

  • 单一职责:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,做到单一职责(什么是单一职责我举个例子加入一个商城项目里面有用户模块,用户里面又有会员模块,积分模块什么的,把每个模块都拆分为一个服务,这就是拆分的力度更小,一个服务就对应一个一个业务功能,一对一的效果)

  • 面向服务:服务提供统一标准的接口,与语言和技术无关(这个服务该如何调用,肯定不能像单体架构中直接调用,这就需要这个服务提供这个功能的接口,这样别的服务就可以远程调用你这个服务中的接口从而实现想要实现的功能)

  • 自治:1,团队独立(就是交给你们五个人或者八个人做这个服务,你们分工有前端,运维,后端,测试,什么的,非常高效的把该服务开发出来,以后技术升级或者服务升级直接找到你们这个团体着手去做,很高效方便)
    2,技术独立(因为服务与服务之间互不影响,你们这个团队的服务可以自己选择自己想用的技术或者适合本次业务的技术,术业有专攻嘛
    3,数据独立(每个服务有单独的数据库),独立部署(用户可以根据自己的需求去访问自己想要的服务)和交付

  • 隔离性强:服务调用做好隔离、容错、降级,避免出现级联问题(这个就是服务调用过程中做了隔离,调用你这个服务发现你挂了,但是我不能挂做出一定的容错性,避免出现级联问题

微服务的上述特性其实是在给分布式架构制定一个标准,进一步降低服务之间的耦合度,提供服务的独立性和灵活性。做到高内聚,低耦合。

因此,可以认为微服务是一种经过良好架构设计的分布式架构方案

但方案该怎么落地?选用什么样的技术栈?全球的互联网公司都在积极尝试自己的微服务落地方案。

其中在Java领域最引人注目的就是SpringCloud提供的方案了。

1.4,SpringCloud

SpringCloud是目前国内使用最广泛的微服务框架。官网地址:Spring Cloud

SpringCloud集成了各种微服务功能组件,并基于SpringBoot实现了这些组件的自动装配,从而提供了良好的开箱即用体验

其中常见的组件包括:

 

另外,SpringCloud底层是依赖于SpringBoot的,并且有版本的兼容关系,如下:

 

1.5,总结

  • 单体架构:简单方便,高度耦合,扩展性差,适合小型项目。例如:学生管理系统

  • 分布式架构:松耦合,扩展性好,但架构复杂,难度大。适合大型互联网项目,例如:京东、淘宝

  • 微服务:一种良好的分布式架构方案

    ①优点:拆分粒度更小、服务更独立、耦合度更低

    ②缺点:架构非常复杂,运维、监控、部署难度提高

  • SpringCloud是微服务架构的一站式解决方案,集成了各种优秀微服务功能组件

最后:

        如果文章对您有帮助,就拿起小手赶紧给博主点赞💚评论❤️收藏💙 一下吧! 

       愿我们在未来的日子里。熠熠生辉!!!

转载自CSDN-专业IT技术社区

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。

原文链接:https://blog.csdn.net/m0_64550837/article/details/125325426

评论

赞0

评论列表

微信小程序
QQ小程序

关于作者

点赞数:0
关注数:0
粉丝:0
文章:0
关注标签:0
加入于:--