微服务必须选择SpringCloud的三大理由详解同时，支持微服务的技术栈也是五花八门。这篇文章主要讲述了我们为什么选择SpringCloud以及它的技术概述。1、微服务架构为什么需要SpringCloud？简单来说，服务化的核心就是把传统的一站式应用按照业务一个一个拆分成服务，微服务要在这个基础上更彻底的解耦（不共享DB，KV，去掉重量级的ESB），并强调DevOps和快速发展。这就需要我们采用不同于一站式时代和泛SOA时代的技术栈，而SpringCloud就是其中的佼佼者。DevOps是英语Development和Operations的结合。需要开发、测试、运维一体化协作，更小、更频繁、更自动化的应用发布，围绕应用架构构建基础设施。这就要求应用有足够的内聚性，同时也便于运维和管理。这个概念与微服务的概念不谋而合。接下来，我们从服务架构演进的角度来看一下为什么SpringCloud更适合微服务架构。2、从使用nginx开始，最初的服务解决方案是为同一个服务提供一个统一的域名，然后服务调用者向这个域名发送HTTP请求，由Nginx负责分发和重定向要求。这种架构存在很多问题：Nginx作为中间层，将服务调用的逻辑耦合在配置文件中，弱化了微服务的完整性，也在一定程度上让Nginx成为了一个重量级的ESB。业务信息分散在各个系统中，无法统一管理和维护。每个服务调用都是一次尝试，服务消费者并不知道哪些实例在向他们提供服务。这不符合DevOps的理念。无法直观地看到服务提供者和服务消费者当前的运行状态和通信频率。这也不符合DevOps的理念。消费者故障重传、负载均衡等没有统一的策略，增加了各个服务的开发难度，不利于快速演进。为了解决以上问题，我们需要一个现成的中心组件来集成服务，汇总每个服务的信息，包括服务的组件名称、地址、数量等。服务调用者请求服务时，首先通过中心组件获取提供服务的实例的信息（IP、端口等），然后通过默认或自定义的策略选择服务的提供者直接访问.所以，我们引入了Dubbo。3、基于Dubbo实现微服务Dubbo是阿里巴巴开源的SOA服务治理解决方案。它有丰富的文档，在中国被广泛使用。使用Dubbo构建的微服务可以更好的解决上述问题：调用中间层成为可选组件，消费者可以直接访问服务提供者。服务信息集中到注册表中，形成服务治理的中心组件。通过Monitor监控系统，可以直观的展示服务调用的统计信息。消费者可以在负载平衡和服务降级之间进行选择。但是对于微服务架构，Dubbo并不完美：Registry严重依赖第三方组件（zookeeper或redis），当这些组件出现问题时，服务调用很快就会中断。Dubbo主要使用RPC调用。这就使得服务提供者和调用者对代码产生了很强的依赖，服务提供者需要不断的打包包含公共代码的jar包供消费者使用。一旦包装出现问题，就会导致服务调用出错。4.最佳选择——SpringCloud是新一代的服务框架。SpringCloud提出的口号是开发“面向云的应用”，为微服务架构提供更全面的技术支持。结合我们开头提到的微服务需求，我们将SpringCloud与Dubbo进行对比：SpringCloud摒弃了Dubbo的RPC通信，采用了基于HTTP的REST方式。严格来说，这两种方法各有利弊。后者虽然在一定程度上牺牲了服务调用的性能，但也避免了上述原生RPC带来的问题。而且，REST比RPC更灵活。服务提供者和调用者仅依赖一纸契约，不存在代码层面的强依赖。这在强调快速演化的微服务环境中比较合适。Eureka后续版本虽然不开源，但是有很多替代品可以选择，比如Consul等。很明显，SpringCloud比Dubbo更强大，覆盖面更广，而且作为Spring的拳头项目，还可以和SpringFramework、SpringBoot、SpringData、SpringBatch等其他Spring项目完美集成。这些非常重要，对于微服务来说至关重要。如前所述，微服务背后的一个重要理念是持续集成和快速交付，在服务内部使用统一的技术框架显然比将分散的技术组合起来效率更高。更重要的是，相对于Dubbo，它是一个持续维护的开源项目，拥有更火爆的社区，这保证了使用它构建的系统能够持续得到开源力量的支持。
