|
|
|
步骤 2 : 微服务概念 步骤 3 : 服务注册 步骤 4 : 服务访问 步骤 5 : 分布式概念 步骤 6 : 集群 步骤 7 : 分布式和集群周边服务 步骤 8 : 代码
通过 单体架构例子 ，我们了解到了它把多个功能放在了同一个应用里，如图所示把提供数据部分，和视图部分都放在了一起。
这样做就有其固有的缺点： 1. 如果要修改数据部分的代码， 那么必须把整个项目重新编译打包部署。 虽然展示部分，什么都没变但是也会因为重新部署而暂时不能使用，要部署完了，才能使用。 2. 如果提供数据部分出现了问题，比如有的开发人员改错了，抛出了异常，会导致整个项目不能使用，展示数据部分也因此受到影响。 3. 性能瓶颈难以突破 4. 等等。。。 那么接下来，就要通过分布式和集群的思路，将其改造。
要说springcloud 分布式之前，先引入微服务概念。
微服务简单说，一个 springboot 就是一个 微服务，并且这个 springboot 做的事情很单纯。 比如 product-service 这个项目，就可以拆成两个微服务，分别是 数据微服务，和视图微服务，其实就是俩 springboot, 只是各自做的事情都更单纯~
那么有了微服务，就存在如何管理这个微服务，以及这两个微服务之间如何通信的问题，所以就要引入一个 微服务注册中心概念，这个微服务注册中心在 springcloud 里就叫做 eureka server, 通过它把就可以把微服务注册起来，以供将来调用。
在业务逻辑上， 视图微服务 需要 数据微服务 的数据，所以就存在一个微服务访问另一个微服务的需要。
而这俩微服务已经被注册中心管理起来了，所以 视图微服务 就可以通过 注册中心定位并访问 数据微服务了。 在后续教程里，会演示微服务的相互调用。
系统改造到现在，就是分布式啦~ 简单说，原来是在一个 springboot里就完成的事情，现在分布在多个 springboot里做，这就是初步具备 分布式雏形了。
那么分布式有什么好处呢？ 1. 如果我要更新数据微服务，视图微服务是不受影响的 2. 可以让不同的团队开发不同的微服务，他们之间只要约定好接口，彼此之间是低耦合的。 3. 如果视图微服务挂了，数据微服务依然可以继续使用 等等
原来数据微服务只有这一个springboot, 现在做同样数据微服务的，有两个 springboot, 他们提供的功能一模一样，只是端口不一样，这样就形成了集群。
那么集群有什么好处呢？ 1. 比起一个 springboot, 两个springboot 可以分别部署在两个不同的机器上，那么理论上来说，能够承受的负载就是 x 2. 这样系统就具备通过横向扩展而提高性能的机制。 2. 如果 8001 挂了，还有 8002 继续提供微服务，这就叫做高可用 。 等等
以上是很简单的分布式结构，围绕这个结构，我们有时候还需要做如下事情：
1. 哪些微服务是如何彼此调用的？ sleuth 服务链路追踪 2. 如何在微服务间共享配置信息？配置服务 Config Server 3. 如何让配置信息在多个微服务之间自动刷新？ RabbitMQ 总线 Bus 4. 如果数据微服务集群都不能使用了， 视图微服务如何去处理? 断路器 Hystrix 5. 视图微服务的断路器什么时候开启了？什么时候关闭了？ 断路器监控 Hystrix Dashboard 6. 如果视图微服务本身是个集群，那么如何进行对他们进行聚合监控？ 断路器聚合监控 Turbine Hystrix Dashboard 7. 如何不暴露微服务名称，并提供服务？ Zuul 网关
好，接下来，我们就通过代码来实现上述效果吧，图上得来终觉浅,绝知此事要 coding~
HOW2J公众号，关注后实时获知最新的教程和优惠活动，谢谢。
问答区域
2019-12-31
这套教程吃起来也是挺香的，哈哈
2019-09-23
如果 8001 挂了，还有 8002 继续提供微服务，那么视图微服务不是需要修改Feign代码更改调用接口吗
2 个答案
行走的老熊 跳转到问题位置 答案时间：2020-05-15 eureka负责这个事情，我们调用接口话，只需要写服务的名称即可，而不是通过ip端口调用。
qq1019901646 跳转到问题位置 答案时间：2019-12-12 我想应该是相当于NGINX的负载均衡，不需要更改调用接口
回答已经提交成功，正在审核。 请于 我的回答 处查看回答记录，谢谢
提问之前请登陆
提问已经提交成功，正在审核。 请于 我的提问 处查看提问记录，谢谢
|