1.单体架构存在的问题:
1、并发量的问题
2、资源隔离问题:所有的业务共享资源,一旦某个业务出现问题,可能会连带其他的业务不可用
集群的问题:
没有负载均衡器相当于有多个服务器但还是把所有的资源只给一台服务器,导致服务器浪费成本高,
1、可以局部的解决并发量的问题,但是并不完美
2、资源隔离的问题仍然存在
优势:
1、按照模块进行拆分,分布到不同的机器上,处理不同的业务,这样如果某个业务有问题,不会影响其他业务的正常工作。
2、可以很灵活的根据业务的并发大小,弹性的调整每个业务的集群规模
问题:
1、模块和模块之间完全没有联系吗?- 不是,实际开发过程中,往往很多模块之间是需要互相依赖和调用的,这里就牵扯了服务间的互调(Http协议)
当订单服务调用支付服务和用户服务本质上用的是http请求调用的,既然是通过http请求调用就要知道被调用者的ip地址,每个服务有可能都是集群,这又该怎么调用谁呢?
这个时候我们可以用到一个服务注册中心,当前每个微服务都会去注册中心服务注册把ip地址给他管理,这样服务之间的调用就可以去服务注册中心拿到IP地址,如果被调用者是一个集群,那么调用者就会拿到集群数量的ip地址,我们可以在调用者的本地的和加ribbon实现负载局衡器的作用。