为了账号安全,请及时绑定邮箱和手机立即绑定
首页 手记 【九月打卡】第17天 网关与服务发现

【九月打卡】第17天 网关与服务发现

2022.09.21 23:23 43浏览

第一模块:

课程名称:通过自动回复机器人学Mybatis---基础版

章节名称:1-1 ~ 2-3

讲师姓名:David


第二模块:

内容概述:

1-1 ~ 2-3小节,介绍微服务架构的前世今生,用spring cloud微服务架构和dubbo进行了比较,后面重点介绍了网关的相关概念。


第三模块:

学习心得:

企业服务总线的产品:

  • IBM: WESB、WMB、WDP

  • Oracle: OSB、ESB

  • Microsoft: 通过一组产品实现,包括BizTalk、.Net等

  • 开源: Jboss ESB、Mule ESB、ServiceMix/FUSE ESB、Synapse/WSO2 ESB

1-1:微服务的发展历史:

1.微服务架构的发展历史:

https://img3.sycdn.imooc.com/632b2c390001161109250609.jpg


软件架构:

单体架构

SOA(分布式)

微服务(容器化部署)

服务网格(Service Mesh)


开发时采用哪个【架构】需要考虑:

业务、软件目标体量、开发人员的情况等


2.微服务 VS SOA(面向服务的架构——核心思想就是【拆分】)

https://img3.sycdn.imooc.com/632b2c210001835a04550251.jpg


微服务:

  • 模块化

  • 各个模块独立部署

  • 服务之间可以【异构】


SOA(分布式):

  • 通信采用【企业服务总线ESB】

  • 专注于业务功能的重用

  • 共同的治理和标准

  • RPC远程过程调用


3.微服务业界进展及相关技术

微服务在国内分为两个流派:

  • 开源的SpringCloud

  • Dobbu微服务改造(基于SOA)


SpringCloud的生态系统:

https://img1.sycdn.imooc.com/632b2c1700012cc010870490.jpg


一个生态的几个重要指标:

  • 社区活跃度

  • 代码质量

  • 迭代速度


2-1:API网关:

1.API网关应用场景

API网关的核心功能:

统一接入、协议适配、流量管理与容错、安全防护【4大核心功能】

API网关的生态位:

https://img1.sycdn.imooc.com/632b2c050001dcd716460864.jpg


请求统一汇总到API网关,进行统一接入, 然后将请求的协议转换成内部的接口协议,调用 过程中还要有限流、降级、熔断等容错的方式来保护网关的整体稳定, 网关还要做到基本的安全防护(防刷控制),以及黑白名单(比如IP白名单)等基本安全措施。

图解:

https://img2.sycdn.imooc.com/632b2bee00013a2807610517.jpg


网关的整体架构:

https://img2.sycdn.imooc.com/632b2bdf0001ed0417560724.jpg


2.开源网关、商业网关

网关实例:

https://img1.sycdn.imooc.com/632b2bc8000162f207060376.jpg

自研:每个公司对网关的要求不一样,所以,有一部分公司会选择自研网关



3.Spring Cloud API网关实战

基于zull1同步阻塞网关的实现:

https://img2.sycdn.imooc.com/632b2bb50001ce9a05580514.jpg


网关请求转化实例:

https://img3.sycdn.imooc.com/632b2b9e000103a708630199.jpg


微服务是一个【理念】,不是一门具体的业务、功能的开发技术。

正如Spring Cloud和Spring Boot一样,Spring Cloud是服务治理框架,Spring Boot是功能开发框架,两者面向的问题是不一样的。


所以:平时开发时遇到和Spring Cloud相关的问题不会太多;

遇到的最经典的场景就是——调用其他服务时会碰到。


微服务的核心组件(5个):

  • 注册中心--->【可用服务的清单】

  • 网关--->【服务端的负载均衡】

  • Ribbon--->【客户端的负载均衡】

  • 断路器--->【微服务系统级别的防灾器】

  • 配置中心--->【微服务系统级别的配置中心】


在调用其他服务时,一定要先将【注册中心】、【网关】的服务先启动起来,否则,各个服务就是【一盘散沙】,服务与服务之间无法通信,也就无法进行【服务之间的相互配合与协作】

如果上述的一点没有做好,在调用服务时的表现就是——会出现各种奇奇怪怪的问题!!!


理解【负载均衡】:

所谓的【负载均衡】其实就是:让任务/请求能够【均匀】的分配到【服务提供者】身上;

实现【负载均衡】的不同角度:

【软硬件】角度

  • 硬件:F5

  • 软件:微服务的网关、微服务的Ribbon、Nginx


【端到端】角度

  • 客户端负载均衡

  • 服务端负载均衡


理解【客户端负载均衡】和【服务端负载均衡】:

服务端负载均衡图解:

https://img3.sycdn.imooc.com/632b2b7900011a0409560588.jpg

这里的【负载均衡设备】包括但不限于:代理服务器(Nginx)、微服务的网关(gateway、zuul)、硬件请求分发设备(F5);

这些【负载均衡设备】的核心就是:负载均衡的算法/策略;

目前是存在开源的负载均衡实现方式的!!!


服务端负载均衡的经典实现方式就是:Nginx实现

即:客户端只知道Nginx的地址,需要调用【后台服务】时,只需要将请求发送给Nginx,之后Nginx就会根据【负载均衡算法/策略】将请求【真实的】发给对应的Service 



客户端负载均衡图解(客户端负载均衡是相对于“服务端负载均衡”而言的):

https://img3.sycdn.imooc.com/632b2b620001cdd306880407.jpg

常见的客户端负载均衡实现方式:Ribbon


那【客户端负载均衡】和【服务端负载均衡】最大的区别在那呢?

最大的区别就在:谁能够拿到【可用服务的清单】!

是的,不管用那种方式实现负载均衡,其本质上就是两点:

  • 负载均衡的算法

  • 可用服务的清单

这两点,少了任何一点都是行不通的!!!

客户端负载均衡:客户端能拿到【可用服务的清单】

服务端负载均衡:服务端能拿到【可用服务的清单


【可用服务清单】的提供者:服务注册中心


小结:

不管是用那种方式实现负载均衡,他的本质过程都是一样的:

https://img4.sycdn.imooc.com/632b2b580001688f07620109.jpg

负载均衡不是一个新概念,也不应该是一个新概念,他的实现方式,早已被【前人】实现了无数次,总之,很简单就是了。


补充:

在真实的项目中,往往存在多级【负载均衡】,也就是说:请求会经历多次【负载均衡算法】,层层【负载转发】,最终才会到达【真实的请求处理的服务上】!


第四模块:

学习截图:

https://img1.sycdn.imooc.com/632b2a970001b17208220580.jpg

点击查看更多内容
0人点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
全栈工程师
手记
粉丝
3
获赞与收藏
1

关注TA,一起探索更多经验知识

同主题相似文章浏览排行榜

风间影月说签约讲师

50篇手记,涉及Java、MySQL、Redis、Spring等方向

进入讨论

Tony Bai 说签约讲师

146篇手记,涉及Go、C、Java、Python等方向

进入讨论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消