微服务概述

微服务

概述

1.单体架构

单体架构 :将业务的所有功能集中在一个项目中开发,打成一个包部署。

单体架构的优缺点如下:

优点:

  • 架构简单
  • 部署成本低

缺点:

  • 耦合度高(维护困难、升级困难)

2.分布式架构

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

分布式架构的优缺点:

优点:

  • 降低服务耦合
  • 有利于服务升级和拓展

缺点:

  • 服务调用关系错综复杂

3.微服务的架构特征:

  • 单一职责:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,做到单一职责
  • 自治:团队独立、技术独立、数据独立,独立部署和交付
  • 面向服务:服务提供统一标准的接口,与语言和技术无关
  • 隔离性强:服务调用做好隔离、容错、降级,避免出现级联问题

服务拆分和远程调用

1.微服务拆分时的几个原则:

  • 不同微服务,不要重复开发相同业务
  • 微服务数据独立,不要访问其它微服务的数据库
  • 微服务可以将自己的业务暴露为接口,供其它微服务调用

cloud-demo:父工程,管理依赖

  • order-service:订单微服务,负责订单相关业务
  • user-service:用户微服务,负责用户相关业务

要求:

  • 订单微服务和用户微服务都必须有各自的数据库,相互独立
  • 订单服务和用户服务都对外暴露Restful的接口
  • 订单服务如果需要查询用户信息,只能调用用户服务的Restful接口,不能查询用户数据库

2.远程调用

修改order-service中的根据id查询订单业务,要求在查询订单的同时,根据订单中包含的userId查询出用户信息,一起返回。

因此,我们需要在order-service中 向user-service发起一个http的请求,调用http://localhost:8081/user/{userId}这个接口。

大概的步骤是这样的:

  • 注册一个RestTemplate的实例到Spring容器
  • 修改order-service服务中的OrderService类中的queryOrderById方法,根据Order对象中的userId查询User
  • 将查询的User填充到Order对象,一起返回

1.注册RestTemplate

1.在order-service服务中的OrderApplication启动类中,注册RestTemplate实例:

2.实现远程调用

修改order-service服务中的cn.itcast.order.service包下的OrderService类中的queryOrderById方法:

提供者与消费者

在服务调用关系中,会有两个不同的角色:

  • 服务提供者:一次业务中,被其它微服务调用的服务。(提供接口给其它微服务)
  • 服务消费者:一次业务中,调用其它微服务的服务。(调用其它微服务提供的接口)
相关推荐
西京刀客40 分钟前
k8s热更新-subPath 不支持热更新
云原生·容器·kubernetes·configmap·subpath
打码人的日常分享1 小时前
智慧城市建设方案
大数据·架构·智慧城市·制造
鲁班大叔_0072 小时前
使用扣子与Dify的业务风险
架构·产品
hello早上好2 小时前
Spring不同类型的ApplicationContext的创建方式
java·后端·架构
Python智慧行囊3 小时前
Python 中 Django 中间件:原理、方法与实战应用
python·中间件·架构·django·开发
HyggeBest4 小时前
Mysql的数据存储结构
后端·架构
冰橙子id4 小时前
centos7编译安装LNMP架构
mysql·nginx·架构·centos·php
爱瑞瑞4 小时前
云原生学习笔记(五) 构建 Docker 镜像与运行容器
云原生
大咖分享课5 小时前
云原生监控体系建设:Prometheus+Grafana的企业级实践
云原生·grafana·prometheus
喵叔哟5 小时前
25.【.NET8 实战--孢子记账--从单体到微服务--转向微服务】--单体转微服务--用户服务接口
微服务·架构·.net