什么是分布式和集群
分布式
不同模块部署在不同服务器上,
作用：分布式解决网站高并发带来问题
集群
多台服务器部署相同应用构成一个集群
作用：通过负载均衡设备共同对外提供服务
SpringCloud基本概念
传统的http通信是用HTTPClient等等,缺点就是不安全,重复代码特别多,地址管理起来很麻烦.
SpringCloud解决了上面的问题
传统的http通信(RPC远程调用): !!!!不是SpringCloud
远程调用，类似dubbo，
每一个springboot项目起来就是一个项目，多个项目起来就是多个tomcat，
SpringCloud目的是让这些微服务调用起来，实现原理就是给多个SpringBoot项目放在一个盒子里面。
第一个要解决的问题就是让这些微服务互相认识，
第二个要解决的问题就是能让这些微服务互相调用。(调用是通过访问Restful风格的url来实现的,换句话说,我们要调用的时候就是想办法要调用一个RestURL)
第三个问题:比如多个微服务互相乱七八糟调用(A微服务调用B微服务,B微服务调用C微服务,C微服务调用D微服务),假如一个D微服务挂了,那么C微服务也就不能用了(因为C调用D,)如果C微服务不能用了,B微服务也不能用了… 最后所有不能用了,这种情况在工作中不能发生, 你就得想办法去解决这个调用传递引发的雪崩效果 (就是你跺脚,发生震颤,震颤传递后就崩塌了.) 就是一个微服务不能用了最后导致整个微服务都不能用了. 解决办法就是给不能用的微服务剔除出去,让它不影响其它的功能
第四个问题:实际开发是前后端分离开发的,端口太多,记录太混乱,端口在页面只能写死,我们需要统一的入口,让前端只需要这个统一的入口即可(微服务统一入口)前端只需要记住微服务统一入口的端口号.
统一端口怎么知道访问的是A微服务还是B微服务,只需要在访问的路线上,需要提供对应的访问映射,比如A微服务就是 /base B微服务就是 /article C微服务就是 /qa D微服务就是 /search 这些不影响你原来的微服务,这些就叫路由规则,对于前端人员来说不用记住乱七八糟的端口号
第五个问题 这些配置写在xml里面的, xml写在我们的工程里面, 但是我们是团队开发,团队开发存在的问题就是配置文件只有一个,你也改,我也改,他也改,改完之后就提交上去了,提交会冲突,还有可能会把别人的配置顶了.
这种情况不能发生.应该我们改的时候就是同一份,还有就是不能是我们改完了提交成同一份.
我们可以把有具体功能的配置文件放在Git,在修改的时候,所有开发人员都到Git修改.好处就是配置文件始终只有一份.就这一份.
还需要考虑配置文件从本地删除之后,得从Git从网上下载在本地上才行. 如果修改本地配置文件了你还需要同步,不能重启服务来更新配置文件,(互联网项目最忌讳这个问题,因为你重启了项目所有网民的暂时不能使用可能会造成金钱的损失)
思路:修改配置文件需要让微服务知道,发送请求让微服务加载它,选择用异步的思路,用消息队列(发送请求往队列里面写个消息,准备加载配置文件,从消息里面读出来就加载配置文件)
两个应用之间怎么互相调用，如果不用SpringCloud的情况下，就用
1. httpclient(其中之一). 就是发送一个请求,
2. 2.表单自动提交
3. 重定向
这三个相同的地方就是 得知道地址(发请求地址,重定向地址等等,都是地址)
SpringCloud六个部分
1. 注册发现中心Eureka (让微服务互相认识)
2. 调用中心 Feign (让微服务互相认识)
3. 熔断器Hytrix
4. 微服务网关 Zuul
5. 配置中心 Config
6. 消息总线 Bus
SpringCloud组件
SpringCloud就是一个RPC微服务框架,提供注册服务,发现服务,断路器,网关,自动配置.
Eureka(注册中心),Ribbon(负责均衡),Rest,Feign(http协调调用工具),断路器Hystrix ,Zuul(网关系统) 分布式配置中心
底层通过Http Client进行封装.
前面介绍了很多Spring Cloud的组件，本篇按照自己的角度来做一次归纳。
Spring Cloud技术应用从场景上可以分为两大类：润物无声类和独挑大梁类。
润物无声，融合在每个微服务中、依赖其它组件并为其提供服务。
Ribbon，客户端负载均衡，特性有区域亲和、重试机制。
Hystrix，客户端容错保护，特性有服务降级、服务熔断、请求缓存、请求合并、依赖隔离。
Feign，声明式服务调用，本质上就是Ribbon+Hystrix
Stream，消息驱动，有Sink、Source、Processor三种通道，特性有订阅发布、消费组、消息分区。
Bus，消息总线，配合Config仓库修改的一种Stream实现，
Sleuth，分布式服务追踪，需要搞清楚TraceID和SpanID以及抽样，如何与ELK整合。
独挑大梁，独自启动不需要依赖其它组件。
Eureka，服务注册中心，特性有失效剔除、服务保护。
Dashboard，Hystrix仪表盘，监控集群模式和单点模式，其中集群模式需要收集器Turbine配合。
Zuul，API服务网关，功能有路由分发和过滤。
Config，分布式配置中心，支持本地仓库、SVN、Git、Jar包内配置等模式，
每个组件都不是平白无故的产生的，是为了解决某一特定的问题而存在。
Eureka和Ribbon，是最基础的组件，一个注册服务，一个消费服务。
Hystrix为了优化Ribbon、防止整个微服务架构因为某个服务节点的问题导致崩溃，是个保险丝的作用。
Dashboard给Hystrix统计和展示用的，而且监控服务节点的整体压力和健康情况。
Turbine是集群收集器，服务于Dashboard的。
Feign是方便我们程序员写更优美的代码的。
Zuul是加在整个微服务最前沿的防火墙和代理器，隐藏微服务结点IP端口信息，加强安全保护的。
Config是为了解决所有微服务各自维护各自的配置，设置一个统一的配置中心，方便修改配置的。
Bus是因为config修改完配置后各个结点都要refresh才能生效实在太麻烦，所以交给bus来通知服务节点刷新配置的。
Stream是为了简化研发人员对MQ使用的复杂度，弱化MQ的差异性，达到程序和MQ松耦合。
Sleuth是因为单次请求在微服务节点中跳转无法追溯，解决任务链日志追踪问题的。
特殊成员Zipkin，之所以特殊是因为从jar包和包名来看它不属于Spring Cloud的一员，但是它与Spring Cloud Sleuth的抽样日志结合的天衣无缝。乍一看它与Hystrix的Dashboard作用有重叠的部分，但是他们的侧重点完全不同。Dashboard侧重的是单个服务的统计和是否可用，Zipkin侧重的监控环节时长。简言之，Dashboard侧重故障诊断，Zipkin侧重性能优化。
什么是服务
服务其实就是接口
什么是提供服务
其实就是提供接口
什么是消费服务
其实就是调用接口
创建调用关系的微服务
创建存在调用关系的微服务，调用关系如下
服务消费者 调用别的微服务的微服务
服务提供者 提供API的微服务
SpringCloud调用服务有哪些方式
调用服务其实就是调用http协议接口,
调用服务使用 :restTemplate和 feign
什么是微服务？
微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分为一组小的服务，每个服务运行在其独立的自己的进程中，服务之间相互协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API），每个服务都围绕着具体的业务进行构建，并且能够被独立的构建在生产环境、类生产环境等。另外，应避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。
使用 Spring Cloud 有什么优势？
使用 Spring Boot 开发分布式微服务时，我们面临以下问题
与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。
服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在该
目录中注册服务，然后能够查找并连接到该目录中的服务。
冗余-分布式系统中的冗余问题。
负载平衡 —负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，中央
处理单元，或磁盘驱动器的分布。
性能-问题 由于各种运营开销导致的性能问题。
部署复杂性-Devops 技能的要求。
负载平衡的意义什么？
在计算中，负载平衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计算
资源的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源
的过载。使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通
常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。
什么是 Netflix Feign？它的优点是什么？
Feign 是受到 Retrofit，JAXRS-2.0 和 WebSocket 启发的 java 客户端联编程序。Feign 的第一个目标
是将约束分母的复杂性统一到 http apis，而不考虑其稳定性。在 employee-consumer 的例子中，我们
使用了 employee-producer 使用 REST 模板公开的 REST 服务。
若有收获，就点个赞吧
0 人点赞
