springcloud怎么读音SpringCloud整体构架设计
SpringClound整体核⼼架构只有⼀点：Rest服务，也就是说在整个SpringCloud配置过程之中，所有的配置处理都是围绕着Rest完成的，在这个Rest处理之中，⼀定要有两个端：服务的提供者（Provider）、服务的消费者（Consumer），所以对于整个SpringCloud基础的结构就如下所⽰：
既然SpringCloud的核⼼是Restful结构，那么如果要想更好的去使⽤Rest这些微服务还需要考虑如下⼏个问题。
1、所有的微服务地址⼀定会⾮常的多，所以为了统⼀管理这些地址信息，也为了可以及时的告诉⽤户哪些服务不可⽤，所以应该准备⼀个分布式的注册中⼼，并且该注册中⼼应该⽀持有HA机制，为了⾼速并且⽅便进⾏所有服务的注册操作，在SpringCloud⾥⾯提供有⼀个Eureka的注册中⼼。
对于整个的WEB端的构架（SpringBoot实现）可以轻松⽅便的进⾏WEB程序的编写，⽽后利⽤Nginx或Apache实现负载均衡处理，但是你WEB端出现了负载均衡，那么业务端呢？应该也提供有多个业务端进⾏负载均衡。那么这个时候就需要将所有需要参与到负载均衡的业务端在Eureka之中进⾏注册。
在进⾏客户端使⽤Rest架构调⽤的时候，往往都需要⼀个调⽤地址，即使现在使⽤了Eureka作为注册中⼼，那么它也需要有⼀个明确的调⽤地址，可是所有的操作如果都利⽤调⽤地址的⽅式来处理，程序的开
发者最⽅便应⽤的⼯具是接⼝，所以现在就希望可以将所有的Rest服务的内容以接⼝的⽅式出现调⽤，所以它⼜提供了⼀个Feign技术，利⽤此技术可以伪造接⼝实现。
在进⾏整体的微架构设计的时候由于牵扯的问题还是属于RPC，所以必须考虑熔断处理机制，实际上所有的熔断就好⽐⽣活之中使⽤保险丝⼀样，有了保险丝在⼀些设备出现了故障之后依然可以保护家庭的电器可以正常使⽤，如果说现在有若⼲的微服务，并且这些微服务之间可以相互调⽤，例如A微服务调⽤了B微服务，B微服务调⽤了C微服务。
如果在实际的项⽬设计过程之中没有处理好熔断机制，那么就会产⽣雪崩效应，所以为了防⽌这样的问题出现，SpringCloud⾥⾯提供有⼀个Hystrix熔断处理机制，以保证某⼀个微服务即使出现了问题之后依然可以正常使⽤。
通过Zuul的代理⽤户只需要知道指定的路由的路径就可以访问指定的微服务的信息，这样更好的提现了java中的“key=value”的设计思想，⽽且所有的微服务通过zuul进⾏代理之后也更加合理的进⾏名称隐藏。
在SpringBoot学习的时候⼀直强调过⼀个问题：在SpringBoot⾥⾯强调的是⼀个“零配置”的概念，本质在于不需要配置任何的配置⽂件，但是事实上这⼀点并没有完全的实现，因为在整个在整体的实际⾥⾯，依然会提供有l配置⽂件，那么如果在微服务的创建之中，那么⼀定会有成百上千个
微服务的信息出现，于是这些配置⽂件的管理就成为了问题。例如：现在你突然有⼀天你的主机要进⾏机房的变更，所有的服务的IP地址都可能发⽣改变，这样对于程序的维护是⾮常不⽅便的，为了解决这样的问题，在SpringCloud设计的时候提供有⼀个SpringCloudConfig的程序组件，利⽤这个组件就可以直接基于GIT或者SVN来进⾏配置⽂件的管理。
在整体设计上SpringCloud更好的实现了RPC的架构设计，⽽且使⽤Rest作为通讯的基础，这⼀点是他的成功之处，由于⼤量的使⽤了netflix公司的产品技术，所以这些技术也有可靠的保证。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。