00:02
前面我们在介绍spring boot的时候,我们提出了一些概念,微服务,分布式等等,那我么就有必要来给大家说一下spring boot现在所处的大时代背景,首先我们来第一个来说微服务,微服务呢,早在一四年marin flow就提出了整个微服务的完整概念,它详细文档呢,是我们这个地址,我们可以打开来看它in short,简而言之微服务呢,就是这一堆东西,我们也将它的英文原文档我们复制到这们一会来详细解释,当然呢,也可以点进去,在这呢有一个简体中文版点进去,大家可以来参照我们简体中文版的解释,仔细来看一下,我们来看一下什么是微服务,那首先呢,它简而言之,我们这个微服务啊,它是一种架构风格,所以这是我们说的第一个微服务是一种架构风格,第二个我们微服务呢,在开发一个单个应用的时候,应该是按suit of small service,如果把一个应用拆分成一组小型服务,就是我们刚才说的要大应用拆分成一个一个的小模块。而且呢,每一个。
01:02
小模块是running its all process,就是运行在自己的进程内,所谓的自己进程内就是我们每一个小模块我都可独立部署到某一个服务器上,我可以独立部署,迭代升级我们都行,就跟以我们之前开发的一个单个应用一样,我们小的一这个微服务也是一个完整的单个应用,然后呢,微服务之间comm,他们是用轻量级,我们这个写通信机制来进行交互,那经常呢,我们推荐使用HTP,因为我们现在把一个大应用拆分成小模块以后,比如我们这个电商应用有订单,购物车,用户信息,那么要结呃结算,我们就要从购物车里边拿到东西,拿到用户信息,那么肯定模块之间都牵扯到互联互调,他们之间呢,又被分发到了不同服务器上,因为我们说可以独立部署升级,那么独立部署到其他服务器上,所以我们就要进行交互,那这些交互呢,我们就推荐使用轻量级的HTP来进行交互,而且呢,我们也推荐我们整个微服务的这个构建是围着。
02:02
知道我们这个业务逻辑的,那我们整个。大型应用我们业务功能有多少,我们就可以将微服拆分出多少,然后呢,我们整个微服务也应该是依赖于我们整个的automaticp deployment,就是我们的自动化部署,因为我们一个大应用全部模块拆分的非常多了,比如我们拆分出了100多个模块,我们将应用要上线部署的时候呢,挺麻烦的,一个一个手动部署很麻烦,所以我们应该后边有全自动部署机制,包括呢,我们微服务是一个去中心化的,我说每一个服务啊,可以用不同的语言开发,也可以使用不同的存储技术,也就是说我们不再局限于语言,我们的后台,后端技术的使用,微服务的这个流行,哎,到感觉我们现在是各种语言的百家争鸣了,当我们以前感觉Java马上要统一天下的时候,我们这种软件架构风格一变,那其他的语言我们PHP开发一个后台管理系统挺快的,那么这个小后台我们就用PHP来开发。那也。
03:06
不方便,所以呢,我们现在整个微服务的出现,一旦将大型软件拆分成各种这些小服务,那么独立部署以后,那么必然就会产生什么分布式,一产生分布式以后呢,我们又会出现各种分布式的问题,比如我们这个A服务被我们部署到了一二三四五六七八九十十台机器上,B服务呢部署到四台机器,C服务呢,部署到这么多台机器,那首先第一个我们要互相远程调用,我们A呢是购物车,我们想要调用订单,订单呢想要调用用户,那想要互相远程调用怎么办?那我们之前微服务指导我们一般我们使用HTTP来进行交互,包括我们现在要调用我们服务发现怎么办?那为什么会有服务发现,那A想要调BB在四台机器都有,也就是说我们随便调哪一台都行,但我也不知道B在这四台机器哪一台是好的,比如我们这四台机器,这个机器呢,出突然出现故障了,然后呢,它一会儿又起来了,这个一会儿又故障。
04:06
一会又起来了,那我们这个服务到底在哪台机器是好的,我们能调,所以我们必须有服务发现机制,那我们发现到服务在这四台机器都有以后呢,我们相当于调哪个都是相同的功能,哎,我们将购物车呢,放在了四台机器,那调哪个都行,所以我们就可以拥有负载均衡机制,那负载均衡又怎么做,又是一个问题,包括呢,我们服务的容错怎么做,因为我们A要调B,如果我们以前全部是写在一个代码里边,我们全部是一个单体应用部署到一台机器,B调用失败了,那我们这个B呢,是一个功能调用失败了,大不了抛个异常,但是呢,我们现在在别的机器,我们的失败有可能不是B,我们代码的失败有可能是我们网络的失败,网络不通了,各种功能,所以我们呢,我们的调用又要出现我们的容错机制,一旦B的网络不通了,我们A怎么办?要重试到其他机器,其他机器都不通了,我们A要怎么要返回一个默认数据等等等等,包括呢,我们的配置管理,A既然在这么几十台机。
05:06
这都有,我们想要修改A的配置,我们不可能把A的模块的源代码我们改了以后,给这十几台机器我们再重新部署一下,我们就应该将所有我们服务的配置放到一个我们成为配置中心里边,我们想要修改呢,我们修改一个配置中心的一块配置,那其他服务呢,自己从这个配置中心把你的最新配置同步过来,那么这样修改是不是会很方便,包括我们后来说的服务监控功能,我们这么多的小服务,我们上到我们整个云平台以后,那我们每一个服务它占的CPU消耗的资源、内存,包括他们的健康状况等等,我们要把整个应用网全部监控起来,所以我们的服务监控又该怎么做,包括链路追踪怎么做,我A调B,调C调D,那我们D一旦出现问题,我们就要搜索我们整个链路是哪一块导致出现了问题,导致我们整个链路失败了,那链路追踪又怎么做?包括我们整个大型的分布式应用网,我们之间的日志又该怎么管理?
06:06
包括任务调度要怎么做,比如我们想要执行一个定时任务,A呢,想要执行定时任务,定时任务呢,一触发是要这十几台同时触发还是某一台触发,那触发是以并行的方式还是串行的方式等等等等,我们现在呢又会出现各种问题,所以这就是我们说的,我们微服务一旦拆分以后,形成了整个大型的应用分布式网,我们产生的分布式问题,那分布式问题又该怎么解决,那我们spring家也有解决方案,Spring boot帮我们可以来够快速的构建出一个应用,这是spring之前官网的一个经典的案例图,我们想要构建出我们的一个应用,我们使用w boot快速的编写出我们应用,那我们应用呢?微服务模块众多,我们w boot创建了非常多的微服务模块了,接下来我们使用w cloud把它们网状的互联互调起来,然后呢,我们网状之间的这个数据流,我们可以使用spring cloud data flow把它做成呢,响应式数据流,我们来整合起来,这都是我们的。
07:06
整套解决方案,所以呢,其实我们只要使用了spring boot,我们就能享有我们spring整个生态圈给我带来的全能力。包括呢,它所处的第三个大时代背景,云原生,那我们服务开发它呢,只是我们开发好了,我们最终要部署,要让大家应用起来,这又牵扯到我们原生开发的这个应用如何上云,也就是说我们最近几年抛出的这个新概念叫cloud nineteen,我们应用想要上云呢,又会牵扯到一大堆的困难,比如服务的自愈,比如我们现在呢,A服务在五台服务器都有。这五台呢都是A,然后呢,这三台呢都是B。假设呢,这两台都是C,然后呢,A要调BB要调C,那我们首先把他们全部部署上去了,但某一天我们这个C部署了两台,C呢,突然有一台给炸了,那我们这个C能不能自愈呢?所谓的自愈就是你既然出问题了,能不能在别台服务器自动又拉起一份C,所以呢,这都是跟我们部署相关的服务的词域,包括呢,我们弹性的伸缩,比如我们突然间流量高峰进来了,A大量的掉掉BB要大量的掉C,而C呢,只部署了两台不够,那我们希望呢,在流量高峰期间,C能自动的再来扩充三台,那流量高峰过去一阵以后呢,我们可以把这三台又下线,这又是我们说的弹性伸缩,包括我们说的服务隔离,那我们C在一号服务器部署的,可能跟C在一号服务器部署的同时有D跟E服务,我们应该希望de等其他服务出现故障以后,别影响人家的C,包括我们的自动化部署。
08:49
因为我们整个微服务,我们要全部部署到云平台以后咋办?那我们不可能人肉运维手工部署,那我们希望会有自动化部署机制,包括我们后来说的灰度发布,比如我们这个B,我们这个模块呢,版本有更新,我们现在呢都是1.0版,对吧,1.0版,那A想要调B呢,先默认掉1.0版,那们现在呢,开发了一个2.0版,如果我们直接把2.0版全部用来替换,那我们有可能会出现故障。
09:19
那我们2.0的代码不稳定,那整个A这个链路就炸了,那我怎么办呢?我可以先把B这三个我先替换一个,我把这个B呢,一个我替换成2.0版,那这样呢,A调B,因为它可能会负载均衡,有可能调到这儿,它调用了一个新版API,那通过长时间的验证,哎,我们这个新版API没问题了,新老板并存了,新版没问题了,我们再把老板慢慢的一个一个下限,我们就完成了,我们称为灰度发布,然后呢,包括我们说的流量智力,那我们现在呢,还是这么多的A,那想要调用这个B了,对吧,B又想要调用C了,那我们这个B呢,我可以来限制我们A,我们比如我们的这个服务器,它的性能本来就不高,那不应该把大量流量打给他,所以呢,我们就可以通过流量治理手段,我们限制这个服务器只接收少量流量,这个服务器呢,接收大量流量,然后呢,等等等等,包括他们流量之间,他们的这些进出率的监控,包括我们。
10:19
根据进出率再来做动态的扩缩容的这些,呃,功能等等等等,这都是我们服务部署到线上以后,我们要解决的各种问题,这就是我们说的云原生,但云原生呢,我们会发现其实大多呢跟我们运维还是有很大的关系的,当然我们想要了解云原生的整个课程呢,我们也可以关注我们上硅谷的大厂学院,我们后来呢,会推出我们整个云原生的一系列课程,从我们认识云原生的基本概念开始,到我们深入我们整个容器化技术,然后呢,再到我们整个Co啊构建集群。一直到搭建我们整个的自动化运维平台,也包括我们拥拥抱我们这个新一代的servicemash架构,用这个service,哎,这是我们之前说的,那spring呢,也可以来开发sola这些服务,我们开发一个函数式服务,直接给我们云平台一部署,它呢有可能只占用一核的CPU 10MB的内存就足够,那它用多少占多少,那这样呢就不会浪费大量的系统资源,那我们整个系统的整个吞吐力又会得到一个质的提升,等等等等,这些课程呢,大家也感兴趣都可以来关注。
我来说两句