00:00
好,同学们,现在呢,我们去总结一下之前我们搭建的in Fla TB报警系统的架构,另外呢,我们来看一下这个架构呢,还有什么可以升级的地方。呃,我们之前呢,做了一个架构呢,就是我们有一个时序数据库啊叫in Fla TB,呃,那么它呢,里面有各种定时任务去检查我们这个鼠标呢,是否合规啊,不合规呢,发现需要报警的话呢,就把这个消息啊通过HTTP告诉我们的瑞向云。有点丑啊,重新画一遍。好,这边呢,就是我们的瑞向云。那么他呢,就是告诉我们报警信息。好,那么现在呢,有个问题啊,假如说今天晚上呢,呃,我们去下班了,人都下班了,哎,突然这个in Fla DB内存爆了,或者这个机器呢,不小心,哎,这个电源线让老鼠啃了,In Fla DB呢,下线了。
01:08
呃,然后这一天呢,刚好有的设备呢,一氧化碳浓度又超标了。哎,Co超标那怎么办呢?啊,你的瑞向云呢,好像没有发出任何的报警信息,但是呢,今天晚上又实实在在的出现了生产安全事故啊,等到第二天呢,大家上班一发现,哎,坏事了,这个一氧化碳呢,昨天晚上超标超的很厉害,哎,但是呢,我们的这个监控系统呢,它失效了,没有正确的发出报警啊,那么这里呢,我们可以去分析一下我们整个报警系统的问题。啊,首先呢,瑞象云啊,那么瑞象云这个东西呢,大家可以把它当做一个24小时运行,不会挂机的啊,一个报警系统,呃,我们去做这个瑞向云的时候呢,虽然说只有一个URL,但是瑞向云他们背后呢,呃,会有一个集群,有好几台机器等着为你服务,当其中一个服务器挂掉之后呢,呃,我们还可以用这个URL呢,去连接别的服务器,那么这个呢,属于瑞向云内部的一个处理,我们呢只是购买它的SaaS服务,所以说呢,我们可以认为瑞向云呢是一个高可用的。
02:14
哎,不会挂机的,那么一个报警系统啊,报警服务。呃,那么问题呢,很显然问题呢,就出现在我们的英拉斯DB,呃,它是一个单节点的,万一呢,他所在的这个机器呢,挂机了,哎,电源断了,或者一系列各种问题,包括比如说啊,有一个人呢,他在这个机器上跑了个死循环,把我们的这个机器诶被给跑崩了,都有可能导致我们的in s DB呢下线。所以说呢,这个in Fla DB呢,它的可用性的就低啊,它不可,它可能呢,不是24小时可以提供服务啊,中间呢,如果说发现一些异常呢,可能整个程序呢就崩掉了。
03:00
所以呢,我们现在啊,看到外面这个大蓝色的圈,我们整个报警系统呢,其实取这个现在的问题呢,就是啊,取决于我们的短板效应,那么可以看到,虽然说呢,瑞向云它高可用,但是英Fla斯DB呢可用性较弱,那么作为整个系统呢,呃,取决于英Fla DB的短板,那么整个系统的可用性呢就较弱,那么这个时候呢,我们有两种解决方案,一个呢是in Fla DB不要再用单节点的版,单节点的版本了啊,上集群。呃,这个时候呢,呃,你就需要去弄上多多弄几台这个物理机,然后呢,让这些英发TB呢跑在不同的机器上啊,当一个机器呢,去挂了之后呢,再去另外一个机器啊继续提供服务,呃,那么这个时候呢,你需要把这个in DB呢改成class版啊,去我们之前说的这个开源项目啊,或者呢,就是购买这个inb的企业版。另外一个方式呢,就是我们从这个系统的这个交互上来看。
04:01
呃,那么我们这里呢,In Fla DB挂了,哎报警信息呢,没有发给瑞向云,其实呢,取决于一个信息的问题,网络信息的问题,就是瑞向云呢,呃,他不知道in Fla DB挂没挂,呃,如果呢,我们在能在这里呢,加上一个功能。In Fla DB,哎,让我们瑞向云呢去访问in Fla DB,然后呢,每隔一段时间呢,瑞向云就去看一下in Fla DB还能不能用,如果说它不能用呢,就立刻发出报警,这个时候呢,整个系统的可用性呢,其实还是弱啊,因为这个in发DB还是单节版的,单节节版的,但是呢,作为整个系统诶,我们的安全性提高了。好,这里呢,敲一下。呃,让预向云呢,得知in Fla DB的活动状态啊,这个时候呢,可能这个服这个in DB呢,还是会挂啊,但是呢,我们可以让人维呢,哎,让让让这个相应的运维的啊,员工或者程序员他呢及时去发现这个问题呢,并进行补救。
05:15
啊,那么这个地方呢,接下来我们给大家演示的呢,呃,并不演示这个in Fla DB的集群版啊,我们去演示让瑞向云的得知in Fla DB的活动状态,也就是我我后面标的这条线。哎,我们把这个呢给它打通。另外呢,需要注意呃,就是英斯TB呢,启用克cluster啊集群模式,还是说这让这个瑞向云呢得知英斯TB的活动状态啊,这两种呢,并不是说是互斥的状态啊,这两个功能呢,你可以都实现,只不过呢是这个in DB呢换成集群版瑞向云呢来得知这个集群的状态啊,让瑞向云呢知道这个in Fla DB的集群可不可用。好,那么这一部分呢,就是我们对呃,上面之前的这个架构的一个总结,以及我们对这个架构呢,接下来要做升级的一个点。
我来说两句