我做过SpringBoot和SpringCloud的项目。我们项目中使用很多技术来构建我们的项目。
SpringBoot来构建我们的项目，使用SpringCloud相关技术来实现微服务架构。
SpringBoot是一个基于maven的项目构建工具。目前我们使用版本比较稳定的1.5.6.项目后期我们项目组使用STS，Spring集成eclipse。
使用SpringCloud微服务框架，我们项目组之前还有dubbo+zookeeper。微服务框架内容非常广泛，我们项目中使用Eurka注册中心，Ribbon前端负载均衡(在本地有缓存-转向服务的列表-该列表随着Eurka更新)。
Hystrix断路器或者熔断器，Zuul实现api网关，SideCar实现异构开发语言支持。SpringCloud原生ConfigServer配置中心，Git作为分布式配置中心的数据存储的地方。
我们项目中使用Eurka作为注册中心。而没有使用dubbo使用的zookeeper作为注册中心。
我们基于分布式系统设计的定理，CAP原则。C一致性，A可用性（可用性不等于可靠性），P分区容错性。基于分布式的系统必须实现P分区容错性，一般设计要么侧重AP,要么侧重CP。
Zookeeper和Eureka的区别？
1Zookeeper侧重CP设计，强调一致性。Zookeeper结构是主从结构，有leader,其他节点都是follower。当在Zookeeper节点宕机个数超过一半时和zookeeper集群在选举时，zookeeper是不推荐使用的。
2Eureka侧重AP设计，强调可用性。Eurka结构点对点。每个节点互为主从，即是主节点，又是从节点。每个节点都会同步所有的数据。Eurka数据都在内存中，底层就是concurrentHashMap,防止高并发线程安全。多级缓存，4级。应对高并发。Eureka心跳机制，心跳从client端，每隔30s向服务端发起心跳请求，顺便检查数据是否变化。如果没有变化，等待下一个周期来发起心跳。如果服务列表变化，就从Eurka中同步列表。即使所有的节点都宕机，服务依然可用，client在发起端，它是EurkaClient，本地缓存之前路由，直接转向。
Feign封装Rest支持，对外体现是一个接口，目前来说比RestTemplate方式好用。具体Feign就是写一个接口。但是这个接口的坑非常多。
1SpringCloud号称整合Feign之后完全兼容SpringMVC.实际不是完全兼容，差异很大
2@RequestMapping,@Get,@Post,Feign目前不支持
3@RequestMapping("/aaa/bbb")controller中可以分成两个段，但是Feign类上就不能写了
4简单参数，@PathVariable("name")必须写全，controller可以省略
5对象参数，controller直接支持对象参数，Feign不支持，@RequestBody以json接参，内部才能动态传入到对象中。
6时间bug+ObjectMapper(jackson没做可配置)，两个解决方案，feign接参字符串，拦截器单独写。
Ribbon前端负载均衡
1nginx后端负载均衡，nginx按配置转向，它不能感知服务死活，直接转向，有可能超时。
2ribbon有本地客户端，转向信息保存在本地缓存中，直接从这个缓存中选中路径，转向(没到服务端就选择路径-按轮询算法选择)。Ribbon能感知服务死活，因为它Eureka，Eureka是动态维护服务列表的。(Ribbon从Eurka更新，只要Eurka正常，不正常的服务就通过心跳被去掉，没有那个列表就不会导致导向错误甚至超时)
请求-》Zuul网关-》nginx-》ribbon
Hystrix断路器能实现限流，降级-不重要的服务少导向，甚至停止，走断路器返回默认值。
Hystrix三种状态:关闭，半开，打开。
断路器在业务正常访问时，处于"关闭"状态，当业务访问失败时，超过预期值阀值，然后才切换打开状态。回调fallback断路器方法，这个方法返回默认值(预案)，返回json对象。不是一直失败，一直打开。当用户发现微服务异常，修复异常。微服务章程访问。它每次失败时先试试能否正常访问，一旦测试业务访问正常，会毫不犹豫地从半开状态切换到关闭状态。
和Zuul整合后，必须按照Zuul方法去调用，实现接口。
传统编程中以前没有这方面的内容，抛出异常。
Zuul gataway API网关，认证授权，类似shiro。转发类似nginx。
1所有用户的请求都必须通过它来中转。
2三条通路:服务提供者，服务消费者，Zuul。实际开发中部署，Zuul在外网暴露，提供者和消费者不暴露(内网)。
消费者可以增强我们的程序，无需自己写.
SpringCloudConfig配置中心(轻量级,速度快)
1替代本地属性文件解决方案，如果服务器个数非常多，100+。如果每台服务都去手动修改，在很长的时间内数据不一致。手动修改，会遗漏。配置中心就把单机的配置升级到分布式的环境中。每台机器都能访问配置中心。SpringCloudConfig是利用git存储，天然就是分布式。
2ZooKeeper配置中心，它内部是小的树形结构，称为数据字典，字典很小。这个结构会在不同的节点，自动地同步，zookeeper主节点的数据从节点自动备份，所有节点数据互相联通。因为量小，zookeeper同步速度非常快。Hadoop的配置信息就是由Zookeeper来管理的。
SpringCloud和dubbo比较
1.SpringCloud 内容繁多，形成SpringCloud全家桶，利用SpringBoot来构建程序更跨界。SpringCloud基于http协议,(纯文本)RESTFul+json(序列化json)返回
2.Dubbo阿里开源，2003年在双11的产品，这个产品是经过极大实际使用的，而且在阿里运行6年。一开源，当当提升spring版本和rest支持dubbox.携程使用dubbo。Dubbo只是SOA的最佳实践，是微服务框架。底层基于TCP协议，RPC（基于二进制,谷歌的protobuf/thirft-性能更高的压缩二进制协议）方式-也叫二进制序列化(把对象转为可传输的东西)。
性能上SpringCloud不如dubbo。而json天然异构。
3.远期谷歌gRPC的要颠覆网络协议。谷歌先是默认https协议，现在要完全基于新的rpc方式。(Http协议不如RPC快)
4.目前为止，dubbo宣称是SpingCloud的一个子集，专注于RPC的传输方式。
面向？
1面向过程，日常搭建开发的代码都是面向过程的为了兼顾性能没有完全面向对象。mybais开发基于sql，面向过程。
2面向对象，开发中需求变更时能减少代码修改量，不能完全克服需求变更。
3面向函数，大数据的思考方式:面向对象+面向函数。jdk8也推出函数式编程。
4面向架构，SOA面向架构编程。SOA有一个重要概念:BUS总线，BUS最早想实现所有的按照标准的模业务模块式插入BUS总线中。如办公自动化和订单还有物流都可以接入总线。各个业务模块通过总线通信。梦想：一个大大的软件系统就OK。用友的u8,金蝶是中国财务软件底层构建了soa,但是自身性能不足。
5面向服务，微服务兴起，基于SOA概念，是SOA的降级。没有那么庞大。微服务是一个标准。它的标准是:Rest+JSON或RPC,springCloud选择前者(Rest+JSON+MQ),dubbo走了后者(基于RPC)
6Dubbo是SOA的最佳实践
