00:00
好,感谢各位同学的讨论,大家说的都对啊,也找出了其中的一些痛点,那么首先我们来看一眼啊。虽然说现在我们用斯瓦哥各种访问操作没有任何问题,不用compose也绝对OK,那么下面我们会碰上这么一些情况。第一个。先后启动顺序我们是要求固定的,刚才我们已经说过了,我们是先起MYSQL,再起red,再起我们的微服务工程。那么现在。只有这两个数据库先启动了,我们是不是才能够进行我们业务操作,否则你先启动这个微服务,你你连哪个数据库啊,你连哪个啊,没有任何意义,对吧,所以说先后顺序要求要固定,那么请问。如果在实际生产过程当中,你能不能保证每一次执行都OK。我们是人,并不是。AI对吧。第二个,多个run命令。前面说过了这三个,这是一个用户微服务。那么假设现在订单。
01:01
库存、支付、积分等等等等,有这么多微服务,你是不是有一大堆?什么东东?Doer。Run命令。需要执行。且有。加载。顺序要求啊,这么说弟兄们能跟上,那么所以说在在这块的时候,你如何保证呢?这是我们的第二个问题。第三一个。别忘了,现在我们是能够调用成功,我们是解决了问题。容器间do上面某个集装箱出问题了,容器实力启停或者宕机了,有可能导致IP地址对应的服务器。对应的容器实力的变化映射是会出错的,要么生产IP写死你当然可以,但是我不推荐啊,那么要么我们是不是应该非常灵活的要通过服务调用,好比说我们暴露出来这个微服务的名字啊,就叫AAA,我管你下面是什么,我调用AAA,你能给我出数据就行了。
02:04
我们只能是什么写死服务,不能写死IP。我们现在是做成功了,但是请大家回到我们这儿,我这儿干了一件什么事,是不是把IP都固定写死的,哎,所以说故意先这么干,那么然后现在是169,有可能IP被你们的网管固定死了,他永远不会变啊,有这种技术,但是呢,也有可能到后面经常是什么。IP变道,但机理哈。映射一出错麻烦大了。所以说现在。我们就需要引入我们的compose进行容器服务的编排,那么再回到我们之前讲过的核心概念,这个文件干嘛?两要素,工程和服务,相当于说我们先来看服务,一个一个的应用,我就是实例,比如订单啊,用户啊,库存啊,买SQL等等等等。那么现在是不是。结合我们这张图,是不是现在有至少是三个服务容器实例了,那么第二个有一组关联的应用容器组成一个完整的业务单元,在do comp里面定义,那么相当于说回到我们这儿,我们要是用一个doer comp文件,那么就可以把他们干什么统一的全部管理起来,给你一锅端,那么你在这个里面就跟我们前面。
03:20
也说过开,那么在这儿啊,多开R,多开R,多开R,假设三个你按照顺序以及它们的依赖关系排编排好加载情况,那么你不用每次都是run run run,我这儿是不是直接就是一次性。全部里面又写了几个。容器实力一次性给你乱出来写十个。点一下就是十个RA,写了100个,点一下就是100个RA,那么这样是不是真真正正做到了一键部署一键上线啊?哎,所以说这个才是我们用刀开砍pose能够达到的目的。好,那么同学们理论说完,实操开工,那么现在我们呢,就要给大家安排的明明白白,那么服务编排一套带走,首先我们要编写我们的多car comp点样文件。
04:06
好了。那么搁到这儿哇,那么弟兄们这个又怎么看呢?好,这个就是我们现在的一个重点,我们接下来就给大家解读一下这个文件。
我来说两句