微服务架构： idea用maven 开发的一个个独立module,具体是使用spring boot开发的一个个工具。 多个微服务之间通过轻量级的通信架构进行相互协作组成的一个整体。
高内聚，足够小，代码易理解。 开发简单，开发效率高 耦合基地，开发部署都是独立的 微服务能使用不同的语言开发 微服务只是业务逻辑代码，不和HTML, CSS界面混合 每个微服务都可以有自己的数据库
阿里Dubbo/HSF 京东JSF 新浪Motan
框架Netflix/SpringCloudMotangRPCTriftDubbo功能定位完整微服务架构微服务框架，整合zk或consul,实现集群的服务注册/发现RPC框架RPC框架服务框架支持RestY, Ribbon支持多种可插拔的序列化选择NNNN支持RPCNY(Hession2)YYY支持多语言Y(Rest形式)NYYY服务注册发现Y(Eureka 服务注册，Karyon服务框架支持服务自注册和健康检查)Y（Zookeeper/consul）NNY负载均衡Y(服务端zuul+ 客户端Ribbon) zuul服务，动态路由，云端负载均衡Eureka(针对中间层服务器)Y客户端NNY(客户端)配置服务Netxflix Archaius SpringCloud Config Server集中配置NNNN服务调用链监控Y(zuul)zuul提供边缘服务API网关NNNN高可用容错Y(服务端Hystrix+ 客户端Ribbon）Y(客户端)NNY(客户端)典型应用案例NetflixSinaGoogleFacbook社区活跃度高一般高一般重新维护学习难度中等低高高低文档丰富程度高一般一般一般高其他SpirngBus为应用程序带啦更多管理端点支持降级Netflix内部在开发继承gRPCIDL定义实践的公司比较多这种当然看官网才是原汁原味。
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.
两者最大的区别： SpringCloud抛弃了Dubbo的RPC通信，采用的是HTTP的REST方式
HTTP的REST方式，一定程度上牺牲了服务调用的性能，但也避免了原生RPC带来的问题。REST比RPC更加灵活，服务提供发和调用发只依赖约定，不存在代码级别的强依赖。
https://www.springcloud.cc/spring-cloud-netflix.html https://www.springcloud.cc/spring-cloud-dalston.html Spring Cloud中国社区:http://springcloud.cn/ Spring Cloud中文网:https://www.springcloud.cc/
Eureka主管服务注册与发现，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件。功能类似于dubbo的注册中心，如Zookeeper。
Eureka采用C-S的设计架构。Eureka Server作为服务注册功能的服务器，这是服务注册中心。 而系统中的其他微服务，使用Eureka的客户端连接到Eureka Server并维持心跳连接。这样系统的维护人员就可以通过Eureka Server来监控系统中各个微服务是否正常运行。 SpringCloud的一些其他模块（比如zuul) 就可以通过Eureka Server来发现熊中的其他微服务，并执行相关的逻辑。
Euraka和Dubbo的对比
Eureka包含两个组件： Eureka Server和Eureka Client Eureka Server提供服务注册服务 各个节点启动后，会在EurekaServer中注册，EurekaServer中的注册表中将会存储所有可以用服务节点信息，服务节点的信息可以在界面中直观看到。
Eureka Client是yige Java客户端，用于简化Eureka Server的交互，客户端同时也具备一个内置的，使用轮询负载算法的负载均衡器。在应用启动后，将会在Eureka Server发送心跳（默认周期为30s）。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳， Eureka Server将会从服务注册表中把这个服务节点移除（默认90秒）。
Eureka三大组成： Eureka Server提供服务注册和发现 Service Provider 服务提供方将自身服务注册到Eureka,从而是服务消费方能找到 Eureka Consumer服务消费方获取注册服务列表，从而能够消费服务。
Eureka和Zookeeper的区别 传统的A（Atomicity原子性）C（Consistency一致性）I（Isolation独立性）D（Durablity持久性） C（Consistency强一致性）A（可用性）P（Partition Tolerance分区容错性） Eureka遵守的是AP规则 Zookeeper遵的是CP规则
Spring Cloud Ribbon 是基于Netflix Ribbon 实现的一套客户端负载均衡工具
集中式负载均衡（偏向硬件）：Nginx, 硬件F5. 集中式负载均衡：即在服务的消费方和提供方之间使用独立的LB设施（可以是硬件如F5，也可以是软软件如Nginx）由该设施负载把访问请求通过某种策略转发至服务的提供方。 进程内负载均衡（偏向软件）：Ribbon 进程内负载均衡： 将LB逻辑集成到消费方，消费方从服务注册中心获知有那些地址可用，然后自己在从这些地址照顾你选择一个合适的服务器。 Ribbon就是进程内LB， 它只是一个类库，集成与消费方进程，消费方通过它来获取到服务提供方的地址。
RoundRobinRule 轮询策略。Ribbon默认采用的策略。
RandomRule 随机策略，从所有可用的provider中随机选择一个。
RetryRule 先按照RoundRobinRule策略获取provider，若获取失败，则在指定的时限内重试。默认的时限为500毫秒。
BestAvailableRule 选择并发量最小的provider，即连接的消费者数量最少的provider
AvailabilityFilteringRule 该算法规则是：过滤掉处于断路器跳闸状态的provider，或已经超过连接极限的provider，对剩余provider采用轮询策略。
ZoneAvoidanceRule 复合判断provider所在区域的性能及provider的可用性选择服务器。
WeightedResponseTimeRule “权重响应时间”策略。根据每个provider的平均响应时间计算其权重，响应时间越快权重越大，被选中的机率就越高。在刚启动时采用轮询策略。后面就会根据权重进行选择
这个可以参考官网的源码来进行修改。 Ribbon Load Balance Algorithm
Feign 是一个声明式的服务客户点，使得编写Web服务客户端变得容易 如何实现
创建一个接口在主启动类上添加@FeignClient(value = “MICROSERVICECLOUD-DEPT”)Feign是对Ribbon的进一步封装，从而实现面向接口编程。 Feign官网参考
Spring Cloud主要技术就到这里了。所有的内容形成代码放在github上了。 Spring Cloud Config 这个链接只和Spring Cloud Config 相关。 Spring Cloud Main Project
