微服务 & 微服务架构

微服务 & 微服务架构

单体架构 VS 微服务架构

单体架构

一个工程对应一个归档包(war),这个war包 包含了该工程的所有功 能。我们成为这种应用为单体应用,也就是我们常说的单体架构(一个 war包打天下)。 具体描述: 就是在我们的一个war包种,聚集了各种功能以及资源,比 如JSP JS,CSS等。而业务种包含了我们的用户模块,订单模块,支付模块等 。

单体架构图

在这里插入图片描述

单体架构优缺点总结

优点:

1.架构简单明了,没有”花里胡哨“的问题需要解决。
2. 开发,测试,部署简单(尤其是运维人员 睡着都会笑醒)。

缺点:

  1. 随着业务扩展,代码越来越复杂,代码质量参差不齐(开发人员的 水平不一),会让你每次提交代码 ,修改每一个小bug都是心惊胆战的。
  2. 部署慢(由于单体架构,功能复杂) 能想像下一个来自200W+代码部 署的速度 (15分钟)。
  3. 扩展成本高,根据单体架构图 假设用户模块是一个CPU密集型的模 块(涉及到大量的运算)那么我们需要替换更加牛逼的CPU,而我们的订单模块是一个IO密集模块(涉及大量的读写磁盘),那我们需要替换更 加牛逼的内存以及高效的磁盘。但是我们的单体架构上 无法针对单个功能模块进行扩展,那么就需要替换更牛逼的CPU 更牛逼的内存 更牛 逼的磁盘 价格蹭蹭的往上涨。
  4. 阻碍了新技术的发展。。。。。。比如我们的web架构模块 从 struts2迁移到springboot,那么就会成为灾难性

微服务以及微服务架构

在这里插入图片描述

微服务定义

“微服务”与“微服务架构”有着本质的区别:“微服务”强调的是服务的大小,它关注的是某一个点。而“微服务架构”则是一种架构思想,需要从整体上对软件系统进行通盘的考虑。

微服务核心

就是把传统的单机应用,根据业务将单机应用拆分为一个一个的服务,彻底的解耦,每一个服务都是提供特定的功能,一个服务只做一件事,类似进程,每个服务都能够单独部署,甚至可以拥有自己的数据库。这样的一个一个的小服务就是 微服务.①: 比如传统的单机电商应用, tulingshop 里面有 订单/支付/库存/物流/积分等模块(理解为servcie)②:我们根据 业务模型来拆分,可以拆分为 订单服务,支付服务,库存服务,物流服务,积分服务 若不拆分的时候,我的非核心业务积分模块 出现了重大bug 导致系统内存溢出,导致整个服务宕机. ,若拆分之后,只是说我的积分微服务不可用,我的整个系统核心功能还是能使用
在这里插入图片描述

单机架构扩展与微服务扩展图解

单机架构在这里插入图片描述

微服务架构以及扩展

在这里插入图片描述

微服务数据存储

在这里插入图片描述

什么是微服务机构

微服务以及微服务架构的是二个完全不同的概念。微服务强调的是服务的大小和对外提供的单一功能,而微服务架构是指把 一个一个的微服务组合管理起来,对外提供一套完整的服务。
微服务架构是一个架构风格, 提倡
①:将一个单一应用程序开发为一组小型服务。
②:每个服务运行在自己的进程中。
③:服务之间通过轻量级的通信机制(http rest api)。
④:每个服务都能够独立的部署。
⑤:每个服务甚至可以拥有自己的数据库。

优点:

①:每个服务足够小,足够内聚,代码更加容易理解,专注一个业务功能点(对比传统应用,可能改几行代码 需要了解整个系统)。
②:开发简单,一个服务只干一个事情。(加入你做支付服务,你只要了解支付相关代码就可以了。
③:微服务能够被2-5个人的小团队开发,提高效率。
④:按需伸缩。
⑤:前后段分离, 作为java开发人员,我们只要关系后端接口的安全性以及性能,不要去关注页面的人机交互(H5工程师)根据前后端接口协议,根据入参,返回json的回参。
⑥:一个服务可用拥有自己的数据库。也可以多个服务连接同一个数据库。

缺点:

①:增加了运维人员的工作量,以前只要部署一个war包,现在可能需要部署成百上千个war包 (k8s+docker+jenkis )。
②:服务之间相互调用,增加通信成本。
③:数据一致性问题(分布式事物问题)。
④:系能监控等,问题定位等。
在这里插入图片描述

微服务的适用场景

合适:

①:大型复杂的项目…(来自单体架构200W行代码的恐惧)。
②:快速迭代的项目…(来自一天一版的恐惧)。
③:并发高的项目…(考虑弹性伸缩扩容的恐惧)。

不合适:

①:业务稳定,就是修修bug ,改改数据 。
②:迭代周期长 发版频率 一二个月一次。

Spring Cloud Alibaba

什么是什么是SpringCloud?

SpringCloud是程序员用来开发我们微服务的一整套技术解决方案.包含如下服务注册发现,服务容错降级,服务网关,服务调用,服务调用负载均衡,消息等。

功能描述在这里插入图片描述

在这里插入图片描述

什么是Spring cloud Alibaba?

Spring cloud Alibaba是我们SpringCloud的一个子项目,是提供微服务开发的一站式解决方案.包含微服务开发的必要组件。

文档

https://github.com/alibaba/spring-cloud-alibaba/blob/master/README-zh.md

功能描述

在这里插入图片描述

SpringCloud SpringCloudalibaba SpringBoot的生产版本选择

我们的SpringBoot版本 说明选择

1、其中2:表示的主版本号,表示是我们的SpringBoot第二代产品
2、其中1:表示的是次版本号,增加了一些新的功能但是主体的架构是没有变化的,是兼容的
3、其中6:表示的是bug修复版
4、所以2.1.6合起来就是springboot的第二代版本的第一个小版本的 第6次bug修复版本
5、RELEASE:存在哪些取值了 ①:snapshot(开发版本) ②:M1…M2(里程碑版本,在正式版发布之前 会出几个里程碑的版本) ③:release(正式版本)
在这里插入图片描述

Spring cloud的版本说明

第一代版本:Angle。
第二代版本:Brixton。
第三代版本:Camden。
第四代版本:Edgware。
第五代版本:Finchley。
第六代版本:GreenWich。
第七代版本:Hoxton(还在酝酿中,没正式版本)。这种发布的版本是 以伦敦地铁站发行地铁的站。

为什么我们的SpringCloud会以这种方式来发布版本

因为假如我们传统的5.1.5release这种发布的而 SpringCloud会包含很多子项目的版本就 会给人造成混淆在这里插入图片描述
**SNAPSHOT: 快照版本,随时可能修改。在这里插入图片描述
**
M: MileStone,M1表示第1个里程碑版本,一般同时标注PRE,表示预览版 版。
**RC 版本英文版名字叫Release Candidate(候选版本)一般标注PRE表示预览版。在这里插入图片描述
**
**SR: Service Release,SR1表示第1个正式版本,一般同时标注。在这里插入图片描述
**
GA:(GenerallyAvailable),表示稳定版本。
比如还有一种RELEASE版本(正式版本) 比如 Greenwich版本顺序Greenwich.release----->发现bug----->Greenwich.SR1------>发 现bug----> Greenwich.SR2。

SpringCloud的发布计划

https://github.com/spring-cloud/spring-cloud- release/milestones

SpringCloud曾经发布的版本:

https://github.com/spring-cloud/spring-cloud-release/releases

Springboot SpringCloud SpringCloudalibaba 的版本对应关系

https://github.com/alibaba/spring-cloud-alibaba/wiki/%E7%89%88%E6%9C%AC%E8%AF%B4%E6%98%8E
在这里插入图片描述

生产版本选择

a:打死不用 非稳定版本/ end-of-life(不维护)版本。
b:release版本先等等(等别人去探雷)。
c:推荐 SR2以后的可以放心使用。

微服务注册中心Nacos入门

https://nacos.io/zh-cn/docs/what-is-nacos.html在这里插入图片描述

服务的提供者 &服务的消费者是相对的概念比如用户服务是订单服务的消费者,订单服务是用户服务的提供者。但是对于 订单服务---->库存服务,那么订单服务就成为服务消费者.在这里插入图片描述

无注册中心的调用的缺点。

比如现在我的用户服务是占用(User服务)8081端口的服务, 此时我的服务提供方(order服务端口是8080)端口;
我们可以通过RestTemplate 调用方式来进行调用在这里插入图片描述

缺点:

1)从上面看出的缺点就是,我们的在调用的时候,请求的Ip地址和端口是硬编码的若此时,服务提供方(order)服务部署的机器换了端口或者是更换了部署机器的Ip,那么我们需要修改代码重新发布部署。
2) 假设我们的order服务压力过大,我们需要把order服务作为集群,那么意味着 order是多节点部署 比如原来的,我们只有一台服务器,现在有多台服务器,那么作为运维人员 需要在服务消费方进行手工维护一份注册表(容易出错)。
3)有人马上回驳我说,我可以通过ng来做负载均衡,对,我首先认为这是可行的,当时微服务成百上千的服务,难道我们要那成百上千ng么?或者使用一个Ng 那么我们能想一下哪个ng的配置文件有多么复杂。在这里插入图片描述

服务注册发现原理V1架构图:

在这里插入图片描述
在这里插入图片描述

V1版本的架构,存在以下几个问题

①:我们的微服务每次调用,都会去进行对数据库的查询,并发一高,数据库性能就是一个瓶颈问题。
②:若我们的mysql挂了,那么我们所有的微服务调用都不能正常进行。
③:若mysql是正常的,库存微服务挂了,那么也不能正常的调用。

V2版本架构图

在这里插入图片描述

Nacos服务端搭建

下载地址:https://github.com/alibaba/Nacos/releases。在这里插入图片描述

linux环境启停:

①:把我们的Nacos包解压 tar -zxvf nacos-server-1.1.4.tar.gz 在这里插入图片描述
②:cd 到我们的解压目录nacos cd nacos在这里插入图片描述
③:进入到bin目录下 执行命令(启动单机) sh startup.sh -m standalone在这里插入图片描述
④:检查nacos启动的端口 lsof -i:8848在这里插入图片描述
⑤:访问nocas的服务端 http://192.168.159.8:8848/nacos/index.html 默认的用户名密码是 nocas/nocas在这里插入图片描述
⑥:停止nocas 在nocas/bin目录下 执行 sh shutdown.sh 在这里插入图片描述

window环境下 启动nocas server在这里插入图片描述

4:Nacos client服务端的搭建

①:三板斧之:第一板斧 加入依赖在这里插入图片描述
②:三板斧之:第二板斧写注解(也可以不写) @EnableDiscoveryClient在这里插入图片描述
③:第三板斧之:写配置文件 注意server-addr:不需要写协议在这里插入图片描述在这里插入图片描述
④:验证我们的order-center注册到我们的nacos上在这里插入图片描述在这里插入图片描述在这里插入图片描述

5:Nacos 领域模型划分以及概念详解

在这里插入图片描述在这里插入图片描述

5.1)NameSpace(默认的NameSpace是”public“ NameSpace可以进行资源隔离,比如我们dev环境下的NameSpace下的服务是调用不到prod的NameSpace下的微服务)在这里插入图片描述

证明1)我们dev环境下的order-center 调用 prod环境下的product-center ①:order-center所在的namespace为dev

在这里插入图片描述在这里插入图片描述

②:product-center所在的namespace 为prod。在这里插入图片描述
③:测试调用: http://localhost:8080/selectOrderInfoById/1在这里插入图片描述

5.2) Nacos的集群模式在这里插入图片描述

5.2.1)首先 我们需要安装我们的ng在这里插入图片描述
第一步:下载ng (老师下载的是:路径是/usr/local/software)在这里插入图片描述

第二步:解压ngtar -xzvf nginx-1.14.2.tar.gz 得到解压目录

在这里插入图片描述

第三步: 进入解压目录 cd nginx­1.14.2在这里插入图片描述
第四步: 执行命令指定安装目录
./configure ­­prefix=/usr/local/nginx­1.14.2 意思是告诉等会安装的文件要放在哪里
第五步: 接下来通过命令 make 编译执行 make命令
第六步:执行 make install 命令在这里插入图片描述
第七步:还记得第四步我们安装ng的目录么? /usr/local/nginx­1.14.2 进入该目录下的配置目录conf在这里插入图片描述
第八步:修改ng的conf文件 在这里插入图片描述在这里插入图片描述

5.2.2)安装 我们的nacos­server(搭建三个集群端口分别为8849 ,8850,8851)在这里插入图片描述

我们以配置一台为例(8849)为例第一步:修改nacos8849/conf文件 application.properties在这里插入图片描述在这里插入图片描述
第二步:修改nacos8859/conf文件 把原来的cluster.conf.example改为cluster.conf文件在这里插入图片描述
文件内容为如下在这里插入图片描述

到此为止 nacos8849安装完成了 nacos8850 nacos8851同样安装.

5.2.3)最后一步:创建一个数据库(需要自己创建一个数据库) 脚本的位子在 nacos/conf/nacos-mysql.sql

5.2.4)需要修改nacos-server的 启动脚本jvm参数 (怕你们内存参数设置的过小启动不了这么多服务)在这里插入图片描述在这里插入图片描述

5.2.4)分别启动 8849 8850 8851 进入到 nacos的目录下的bin目录在这里插入图片描述

执行./start.sh启动成功的依据
查看日志/usr/local/spring-cloud-alibaba/nacos/nacos8850/logs/start.out在这里插入图片描述
测试:分别登陆地址:

http://192.168.159.8:8849/nacos
http://192.168.159.8:8850/nacos
http://192.168.159.8:8851/nacos
NG测试http://192.168.159.8:8847/nacos/在这里插入图片描述

客户端地址: 直接填写8847ng的地址就可以了在这里插入图片描述

什么是配置管理??在这里插入图片描述

上图缺点:

所有的环境的配置都是明文的 被太多开发人员都知道了。 业务场景:张三开发了一个新功能,业务需要,保留原来老逻辑的代码,所有他抽取了一个 开关变量 isNewBusi来控制,突然新功能上了生产后,发现有bug,怎么做到修改isNewBusi的值不 需要重启。

根据上图我们知道配置管理的作用可以主要总结如下

1)不同环境不管配置
2) 配置属性动态刷新
引入配置中心在这里插入图片描述
根据这幅图,我们微服务需要解决的问题
1)我微服务怎么知道配置中心的地址。
2) 我微服务到底需要连接哪个环境。
3)怎么找到nacos config上的对应的配置文件。

微服务接入配置中心的步骤

①:添加依赖包spring-cloud-alibaba-nacos-config

在这里插入图片描述

②:编写配置文件,需要写一个bootstrap.yml配置文件 配置解释:在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述

现在我们需要不停机改变我们的生产环境isNewBusi的值来控制我们的业务逻辑。我们需要在对应的Controller上添加一@RefreshScope 进行动态刷新

6.2)怎么解决 生产环境,测试环境,开发环境相同的配置。(配置通用)

在这里插入图片描述

比如我们的servlet-context 为order-center 查看工程启动日志在这里插入图片描述

所以我们需要创建一个通用配置文件:order-center.yml配置 那么order-center.yml就是一个通用配置了,不管是启动prod,还是dev 都会有该段配置order-server的 context-path 配置在这里插入图片描述

配置的优先级 精准配置 会覆盖 与通用配置 相同的配置,然后再和通用配置互补。在这里插入图片描述

6.3)不同微服务的通用配置。在这里插入图片描述

6.3.1)通过 shared-dataids 方式比如 每一个微服务都要写服务注册地址等在这里插入图片描述

我们就可以把该配置提取为一个公共配置yml,提供给所有的工程使用在这里插入图片描述在这里插入图片描述在这里插入图片描述

6.3.1)通过 ext-config方式同样配置到越后面的配置 优先级越高在这里插入图片描述在这里插入图片描述

6.3.3)各个配置的优先级 精准配置>不同环境的通用配置>不同工程的(ext-config)>不同工程(shared- dataids)在这里插入图片描述在这里插入图片描述

©️2020 CSDN 皮肤主题: 1024 设计师:上身试试 返回首页