Spring Cloud整体核心架构：Rest服务，在Spring Cloud配置过程中，都是遵循Rest风格规范，在Rest处理中，必不可少两个对象端：服务的提供者（provider）和服务消费者（consumer）
所以整个Spring Cloud的基础结构如下所示：
既然Spring Cloud的核心是Restful架构，那么如果想更好的去使用微服务好需要考虑这些问题：
1、所有的微服务的地址可能非常多，为了统一管理这些地址，也为了能够即时告诉用户哪些服务不可用用，为此必不可少一个分布式注册中心，并且注册中心支持HA机制（High Availability），为了高效且方便的服务注册，Spring Cloud使用Eureka服务注册中心。
2、对于整个的WEB端的架构（Spring Boot实现），可以进行轻松方便的WEB程序编写，而后利用Nginx或Apache实现负载均衡，这是WEB端端的负载均衡，那么业务端呢？应该也提供多个业务端进行负载均衡，这时将所有需要参与到负载均衡的业务端在Eureka之中进行注册。
在进行客户端使用Rest架构调用的时候，都需要有一个调用地址，即使使用了Eureka作为注册中心，也需要有一个明确的调用地址，但是所有的操作都利用访问地址的方式来调用。程序的开发者最方便的应用工具是接口，更好的方式是将所有的Rest服务的内容以接口的方式调用，所以它有提供了feign技术，利用feign可以伪造接口。
3、在进行整体微服务架构设计的时候由于牵扯到的问题还是属于RPC，所以不可避免考虑到熔断处理机制，所谓上的熔断就好比用电安全之中的保险丝，假设现在有若干个微服务，并且这些微服务之间允许相互调用，例如，A服务调用B服务、B服务又调用了C服务。
如果实际开发中没有设计好熔断处理机制，那么就会出现雪崩效应，所以为了防止这样的灾难问题出现，Spring Cloud里面提供有Hystrix熔断处理机制，以保证某一个微服务出现问题之后依然可以正常提供服务信息，但是这个返回的服务信息可能已经不是期望的结果，而是服务故障的信息，让调用方知道该服务出现，避免扩大更大范围的影响。
4、在进行微服务访问的时候还有一点是非常可怕的，客户端调用Rest微服务时需要知道所有微服务的名称信息，如果服务多名称也会多，操作起来非常麻烦，同时增加日后维护成本。
通过Zuul的代理用户只需要知道指定的路由的路径就可以访问指定的微服务的信息，这样更好提现了Java中“key=value”的设计方案，而且所有的微服务通过Zuul进行代理之后也可以更加安全的名称的隐藏。
5、在Spring Boot里面突出“零配置”的概念，原则上不再使用任何配置文件，但是事实上没有完全实现，因为在整体的设计里面，依然会提供application.yml等配置文件，那么在微服务创建之中，一定有成百上千个微服务，于是这些配置文件的管理就成为问题，维护起来就不是件容易的事了。
为了解决这样的问题，Spring Cloud的设计中提供一个SpringCloudConfig的程序组件，利用这个组件就可以直接基于Git或SVN来进行配置文件的管理。
由此可见，在整体设计上SpringCloud更好的实现了RPC的架构设计，而且使用了Rest作为通信的基础，这是它无与伦比之处，同时大量使用了Netflix公司的产品实践技术，所以这些技术也有可靠保证。
作者： xiaogao
出处： http://www.cnblogs.com/tocode/
关于作者：专注Java Web，网络爬虫，请多多赐教！
本文版权归作者和博客园共有，欢迎转载，但务必注明出处，且在文章页面明显位置给出, 原文链接 如有问题请咨询。