springcloud（SpringCloud简介）

重新选举出leader之前会导致C***ul 服务不可用,Zookeeper 不能保证服务可用性,而不会像zookeeper那样使得整个注册服务瘫痪 与 Eureka 有所不同,不会出现数据不一致的情况,但是 Zookeeper 不能保证每次服务请求都是可达的,目前的情况来看都不会被淘汰,用于实现分布式系统的服务发现与配置,spring cloud和dubbo哪个会被淘汰个人觉的两者都不会被淘汰。

本文目录

• SpringCloud简介
• SpringCloud的核心能力有哪些
• spring cloud和dubbo哪个会被淘汰
• springcloud四个注册中心的比较

SpringCloud简介

SpringCloud是基于SpringBoot基础之上开发的微服务框架，SpringCloud是一套目前非常完整的微服务解决方案框架，其内容包含服务治理、注册中心、配置管理、断路器、智能路由、微代理、控制总线、全局锁、分布式会话等。 SpringCloud包含众多的子项目 SpringCloud config 分布式配置中心 SpringCloud netflix 核心组件： Eureka:服务治理 注册中心 Hystrix:服务保护框架 Ribbon:客户端负载均衡器 Feign：基于ribbon和hystrix的声明式服务调用组件 Zuul: 网关组件,提供智能路由、访问过滤等功能。 上海每特教育科技有限公司|苏州特每信息科技有限公司版权所有 SpringCloud中文翻译： https://springcloud***/spring-cloud-dalston.html

SpringCloud的核心能力有哪些

SpringCloud核心能力如下：- 服务注册与服务发现- 服务路由- 端到端的服务调用- 负载均衡- 熔断器- 分布式事务- 分布式消息- 分布式配置中心- 链路追踪SpringCloud已经奠定了自己在微服务领域的领导地位，其中涵盖了我们所需要的几乎全部组件；如果你想掌握时下热门微服务技术栈，跟上时代技术步伐，就去黑马程序员官网视频库看免费视频。

spring cloud和dubbo哪个会被淘汰

个人觉的两者都不会被淘汰，但是在未来分布式微服务解决方案中或者架构中，springCloud会占主导地位。 springCloud： 1.springCloud提供了完成的分布式解决方案，基础解决方案以及组件比较健全，而且最近几年围绕springCloud边缘服务组件越来越多，例如：nacos。 2.springCloud是基于springboot的，spring的使用部署太方便了。 dubbo： 1.dubbo更多解决的是服务间的调用，也就是服务通讯协议rpc，也会是dubbo没有完整的分布式解决方案基础设施。例如：注册中心需要借助Zookeper，链路追踪：zipkin。 要说Dubbo，算是Spring Cloud的一个子集好了,大致相当于Spring Cloud里的 Eureka + Feign + 1/2Hystrix另外 现在大公司也在慢慢想springCloud服务过度，还有面试中文springCloud问题越来阅读，dubbo越来越少。 dubbo生态圈没有spring cloud好，会被先淘汰掉。现有架构都会优先选择Spring cloud，毕竟使用起来更简单一点。 微服务现在是一阵风而已，实际来说，很多系统不适用，综合算下来，微服务成本比原来大多了。不是所有系统都是互联网，都是弹缩性很强。有的系统就是固定数据量，稳定运行，可能几个大一点服务器就足够了。 真正需要微服务的不会像现在看到的那么多。 慢慢沉淀，估计会把一些不需要的改回去，套壳的改回去。 如果简化方式，感觉dubbo这种轻便的有优势，开发运维都简单。或者替代品也是轻便为主。 剩的可能真的需要微服务，一般都是中等规模以上的，或者巨头，一般都有自己的内部框架。这种用也得全套完善的。 它们都淘汰也是早晚的事 事实上，很多系统根本就没必要用什么所谓微服务。目前过度设计已经泛滥，明明是一个用户数量有限，功能并不复杂的系统，也要套用所谓的微服务架构，或者要大搞所谓中台，既浪费时间，又浪费金钱，最后系统运维还比较复杂，需要持续投入运维。 以服务调用的方式，固然可以有更好的复用性，也可以解耦复杂系统。但实际上，我认为微服务也仅仅是组件化的一种实现方式。对于组件化，广义的讲，有多种实现方式： 第一种，最原始的方式就是以静态函数库或者包的形式存在。这种形式优点是开发方式简单，调用效率高，数据以参数方式进行传递，但耦合度也高，底层组件函数一旦发生变化，则需要重新编译整个工程。通常对于不经常发生变化的基础函数库，可以用这种形式进行开发，形成所谓的公共函数库，供大家使用。 第二种，称之为动态函数库，在windows环境下以dll形式存在，linux环境下以so形式存在。动态函数库相对于静态函数库，优势在于可以在运行时动态加载，可以在不用重新启动整个应用的情况下进行更新。缺点是动态函数不能共享原应用程序的存储空间，导致动态函数调用有时需要传递大量参数，导致一些不便。动态函数库也具有一定耦合度，函数名和参数必须严格按照约定调用，否则会报错。在早期单体架构下，动态函数库还是有大量使用的。 第三种，就是目前所谓的微服务架构了。微服务事实上也是可以看作是一种函数调用方式，提供基于RPC和restful远程调用方式。调用时需要传递调用的服务名称及数据报文。这种方式耦合度自然是比较低一些的，但是调用效率肯定低于函数调用方式，主要是数据传输和报文解析方面消耗的时间。此外还需要考虑通讯流量控制，超时机制，服务寻址，服务可用性等方面的问题。因而降低耦合度，事实上是以增加了系统的整体复杂度和降低调用效率为代价的。个人认为不应该过度解耦，或者仅仅强调可复用性。要知道，任何事情都是有代价的，必须要充分评估这种代价是否值得。 第四种，就更进一步，即以独立的系统存在，该系统具有独立性和完备性，可以不过于依赖其他外部系**立运行，对外部以服务或api的形式进行交互。例如，单点登录系统，信贷系统，核心系统等。 因而，在系统架构设计和建设过程中，必须认真进行评估，不应该过分侧重于某一方面特性的实现，否则就是过犹不及，最后导致整体出现问题。 个人认为，目前大部分所谓基于微服务的中台系统就是陷入了过于强调解耦的误区，导致过度的解耦设计，而忽略了由此带来的弊端，最后陷入了泥潭。 分层是计算机科学永恒的主题，service mesh是微服务的未来，这样看来这两个以后都会被取代，只有spring boot能够继续存活。 这是两个作用和使用场景不同的框架，目前的情况来看都不会被淘汰。 springcloud用于微服务，dubbo用于服务治理，各有各的适用场景。 在国外springcloud使用的多，在国内dubbo使用的多。 springcloud由国外的spring团队开发维护，热度和可靠性不用多说，dubbo由国内的阿里巴巴开发，现交由Apache孵化器，可靠性也很高。 Spring cloud是当前主流的微服务架构，轻便，插件式的设计理念很赢得当前开发及企业的青睐，在很多方面优于dubbo的架构设计，我认为dubbo最终会被淘汰，但短时间内不会，因为很多金融机构之前很多系统用的是dubbo架构，金融机构在短时间内考虑系统和业务的稳定性不会立刻就更新换代 dubbo 对内rpc，对外http，dubbo效率比httpclient高很多

springcloud四个注册中心的比较

springcloud是一个非常优秀的微服务框架，要管理众多的服务，就需要对这些服务进行治理，也就是我们说的 服务治理 , 服务治理 的作用就是在传统的rpc远程调用框架中，管理每个服务与每个服务之间的依赖关系，可以实现服务调用、负载均衡、服务容错、以及服务的注册与发现。 ​ 如果微服务之间存在调用依赖，就需要得到目标服务的服务地址，也就是微服务治理的 服务发现 。要完成服务发现，就需要将服务信息存储到某个载体，载体本身即是微服务治理的 服务注册中心 ，而存储到载体的动作即是 服务注册 。 ​ springcloud支持的注册中心有 Eureka 、 Zookeeper 、 C***ul 、 Nacos Spring Cloud Netflix 在设计 Eureka 时就紧遵AP原则,Eureka Server 也可以运行多个实例来构建集群，解决单点问题，但不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构，无 master/slave 之分，每一个 Peer 都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。 在集群环境中如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点上，当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会在节点间进行复制（replicate To Peer）操作，将请求复制到该 Eureka Server 当前所知的其它所有节点中。 Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况: 因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使得整个注册服务瘫痪 与 Eureka 有所不同，Apache Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。从 Zookeeper 的实际应用情况来看，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了 ，节点二也检测到节点三挂了，那这个节点才算是真的挂了），那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。 C***ul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。C***ul 使用 Go 语言编写，因此具有天然可移植性（支持Linux、windows和Mac OS X）。C***ul 内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其他工具（比如 ZooKeeper 等），使用起来也较为简单。 C***ul 遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 C***ul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 ；在leader挂掉了之后，重新选举出leader之前会导致C***ul 服务不可用。 Nacos是阿里开源的，Nacos 支持基于 DNS 和基于 RPC 的服务发现。Nacos除了服务的注册发现之外，还支持动态配置服务。动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。 一句话概括就是Nacos = 注册中心 + 配置中心。 这四个组件虽然都实现了注册中心的功能，但是他们的功能和实现方式都有不同的地方，也各有各的优点,单从注册中心方面来比价四个注册中心(如果不了解 CAP定理 可先阅读下一章节): CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。 因此在进行分布式架构设计时，必须做出取舍。当前一般是通过分布式缓存中各节点的最终一致性来提高系统的性能，通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。通常使用类似 memcached 之类的 NO**L 作为实现手段。虽然 memcached 也可以是分布式集群环境的，但是对于一份数据来说，它总是存储在某一台 memcached 服务器上。如果发生网络故障或是服务器死机，则存储在这台服务器上的所有数据都将不可访问。由于数据是存储在内存中的，重启服务器，将导致数据全部丢失。当然也可以自己实现一套机制，用来在分布式 memcached 之间进行数据的同步和持久化，但是实现难度是非常大的 例如，根据CAP定理将NoSql数据分成了满足CA原则、满足CP原则和满足AP原则的三大类: