整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
服务架构是互联网很热门的话题，是互联网技术发展的必然结果。它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。虽然微服务架构没有公认的技术标准和规范或者草案，但业界已经有一些很有影响力的开源微服务架构框架提供了微服务的关键思路，例如Dubbo和Spring Cloud。各大互联网公司也有自研的微服务框架，但其模式都于这二者相差不大。
微服务主要的优势如下：
1、降低复杂度
将原来偶合在一起的复杂业务拆分为单个服务，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。每个服务开发者只专注服务本身，通过使用缓存、DAL等各种技术手段来提升系统的性能，而对于消费方来说完全透明。
2、可独立部署
由于微服务具备独立的运行进程，所以每个微服务可以独立部署。当业务迭代时只需要发布相关服务的迭代即可，降低了测试的工作量同时也降低了服务发布的风险。
3、容错
在微服务架构下，当某一组件发生故障时，故障会被隔离在单个服务中。 通过限流、熔断等方式降低错误导致的危害，保障核心业务正常运行。
4、扩展
单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。
本文主要围绕微服务的技术选型、通讯协议、服务依赖模式、开始模式、运行模式等几方面来综合比较Dubbo和Spring Cloud 这2种开发框架。架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台，以此稳妥地实施项目的微服务化改造或开发进程。
一、核心部件
微服务的核心要素在于服务的发现、注册、路由、熔断、降级、分布式配置，基于上述几种必要条件对Dubbo和Spring Cloud做出对比。
1、总体架构
▲Dubbo 总体架构
Spring Cloud总体架构如下图
▲Spring Cloud总体架构
点评：从整体架构上来看，二者模式接近，都需要需要服务提供方，注册中心，服务消费方。
2、微服务架构核心要素
Dubbo只是实现了服务治理，而Spring Cloud子项目分别覆盖了微服务架构下的众多部件，而服务治理只是其中的一个方面。Dubbo提供了各种Filter，对于上述中“无”的要素，可以通过扩展Filter来完善。
例如
1．分布式配置：可以使用淘宝的diamond、百度的disconf来实现分布式配置管理
2．服务跟踪：可以使用京东开源的Hydra，或者扩展Filter用Zippin来做服务跟踪
3．批量任务：可以使用当当开源的Elastic-Job、tbschedule
点评：从核心要素来看，Spring Cloud 更胜一筹，在开发过程中只要整合Spring Cloud的子项目就可以顺利的完成各种组件的融合，而Dubbo缺需要通过实现各种Filter来做定制，开发成本以及技术难度略高。
二、通讯协议
基于通讯协议层面对2种框架支持的协议类型以及运行效率方面进行比较；
（一）、支持协议
1、Dubbo：dubbo使用RPC通讯协议，提供序列化方式如下：
dubbo：Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况
rmi：RMI协议采用JDK标准的java.rmi.*实现，采用阻塞式短连接和JDK标准序列化方式
Hessian:Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现
http:采用Spring的HttpInvoker实现
Webservice:基于CXF的frontend-simple和transports-http实现
2、Spring Cloud：Spring Cloud 使用HTTP协议的REST API
（二）、性能比较
使用一个Pojo对象包含10个属性，请求10万次，Dubbo和Spring Cloud在不同的线程数量下，每次请求耗时（ms）如下：
说明：客户端和服务端配置均采用阿里云的ECS服务器，4核8G配置，dubbo采用默认的dubbo协议
点评：dubbo支持各种通信协议，而且消费方和服务方使用长链接方式交互，通信速度上略胜Spring Cloud，如果对于系统的响应时间有严格要求，长链接更合适。
三、服务依赖方式
Dubbo：服务提供方与消费方通过接口的方式依赖，服务调用设计如下：
因此需要为每个微服务定义了各自的interface接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，开发、测试、集成环境都需要严格的管理版本依赖。
通过maven的install & deploy命令把interface和Model层发布到仓库中，服务调用方只需要依赖interface和model层即可。在开发调试阶段只发布Snapshot版本。等到服务调试完成再发布Release版本，通过版本号来区分每次迭代的版本。通过xml配置方式即可方面接入dubbo，对程序无入侵。
▲Dubbo接口依赖方式
Spring Cloud：服务提供方和服务消费方通过json方式交互，因此只需要定义好相关json字段即可，消费方和提供方无接口依赖。通过注解方式来实现服务配置，对于程序有一定入侵。
点评：Dubbo服务依赖略重，需要有完善的版本管理机制，但是程序入侵少。而Spring Cloud通过Json交互，省略了版本管理的问题，但是具体字段含义需要统一管理，自身Rest API方式交互，为跨平台调用奠定了基础。
四、组件运行流程
下图中的每个组件都是需要部署在单独的服务器上，gateway用来接受前端请求、聚合服务，并批量调用后台原子服务。每个service层和单独的DB交互。
▲Dubbo组件运行流程
▲Spring Cloud 组件运行
Spring Cloud
点评：业务部署方式相同，都需要前置一个网关来隔绝外部直接调用原子服务的风险。Dubbo需要自己开发一套API 网关，而Spring Cloud则可以通过Zuul配置即可完成网关定制。使用方式上Spring Cloud略胜一筹。
五、微服务架构组成以及注意事项
到底使用是dubbo还是Spring Cloud其实并不重要，重点在于如何合理的利用微服务。下面是一张互联网通用的架构图,其中每个环节都是微服务的核心部分。
（一）、架构分解
（二）注意事项
六、总结
Dubbo出生于阿里系，是阿里巴巴服务化治理的核心框架，并被广泛应用于中国各互联网公司；只需要通过spring配置的方式即可完成服务化，对于应用无入侵。设计的目的还是服务于自身的业务为主。虽然阿里内部原因dubbo曾经一度暂停维护版本，但是框架本身的成熟度以及文档的完善程度，完全能满足各大互联网公司的业务需求。如果我们需要使用配置中心、分布式跟踪这些内容都需要自己去集成，这样无形中增加了使用 Dubbo 的难度。
Spring Cloud 是大名鼎鼎的 Spring 家族的产品， 专注于企业级开源框架的研发。 Spring Cloud 自从发展到现在，仍然在不断的高速发展，几乎考虑了服务治理的方方面面，开发起来非常的便利和简单。
Dubbo于2017年开始又重启维护，发布了更新后的2.5.6版本，而Spring Cloud更新的非常快，目前已经更新到Finchley.M2。因此，企业需要根据自身的研发水平和所处阶段选择合适的架构来解决业务问题，不管是Dubbo还是Spring Cloud都是实现微服务有效的工具。
者：moon
原文：https://mp.weixin.qq.com/s/-kVf5qWqcw-4AJF7LL3uWw
虽然金三银四过了，但是金九银十马上就要到了，还不快快准备起来？
今天就开启《面试八股文》系列的第一版-RPC王者Dubbo，moon 在后续的《面试八股文》系列还将继续推出mysql，spring，并发，redis，kafka，zookeeper等一系列文章。
当然大家有什么好的建议也可以通过公众号或者个人微信和我交流。
每天一个知识点
目录
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
RPC（Remote Procedure Call）—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底>层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络>通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发>送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为>止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户>端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。有多种 RPC模式和执行。
我们用一种通俗易懂的语言解释它，远程调用就是本地机器调用远程机器的一个方法，远程机器返回结果的过程。
为什么要这么做？
主要原因是由于单台服务的性能已经无法满足我们了，在这个流量剧增的时代，只有多台服务器才能支撑起来现有的用户体系，
而在这种体系下，服务越来越多，逐渐演化出了现在这种微服务化的RPC框架。
Dubbo的核心功能主要包含:
调用过程图：
责任链模式:
责任链模式在Dubbo中发挥的作用举足轻重，就像是Dubbo框架的骨架。Dubbo的调用链组织是用责任链模式串连起来的。责任链中的每个节点实现Filter接口，然后由ProtocolFilterWrapper，将所有Filter串连起来。Dubbo的许多功能都是通过Filter扩展实现的，比如监控、日志、缓存、安全、telnet以及RPC本身都是。
观察者模式:
Dubbo中使用观察者模式最典型的例子是RegistryService。消费者在初始化的时候回调用subscribe方法，注册一个观察者，如果观察者引用的服务地址列表发生改变，就会通过NotifyListener通知消费者。此外，Dubbo的InvokerListener、ExporterListener 也实现了观察者模式，只要实现该接口，并注册，就可以接收到consumer端调用refer和provider端调用export的通知。
修饰器模式:
Dubbo中还大量用到了修饰器模式。比如ProtocolFilterWrapper类是对Protocol类的修饰。在export和refer方法中，配合责任链模式，把Filter组装成责任链，实现对Protocol功能的修饰。其他还有ProtocolListenerWrapper、 ListenerInvokerWrapper、InvokerWrapper等。
工厂方法模式:
CacheFactory的实现采用的是工厂方法模式。CacheFactory接口定义getCache方法，然后定义一个AbstractCacheFactory抽象类实现CacheFactory，并将实际创建cache的createCache方法分离出来，并设置为抽象方法。这样具体cache的创建工作就留给具体的子类去完成。
抽象工厂模式:
ProxyFactory及其子类是Dubbo中使用抽象工厂模式的典型例子。ProxyFactory提供两个方法，分别用来生产Proxy和Invoker（这两个方法签名看起来有些矛盾，因为getProxy方法需要传入一个Invoker对象，而getInvoker方法需要传入一个Proxy对象，看起来会形成循环依赖，但其实两个方式使用的场景不一样）。AbstractProxyFactory实现了ProxyFactory接口，作为具体实现类的抽象父类。然后定义了JdkProxyFactory和JavassistProxyFactory两个具体类，分别用来生产基于jdk代理机制和基于javassist代理机制的Proxy和Invoker。
适配器模式:
为了让用户根据自己的需求选择日志组件，Dubbo自定义了自己的Logger接口，并为常见的日志组件（包括jcl, jdk, log4j, slf4j）提供相应的适配器。并且利用简单工厂模式提供一个LoggerFactory，客户可以创建抽象的Dubbo自定义Logger，而无需关心实际使用的日志组件类型。在LoggerFactory初始化时，客户通过设置系统变量的方式选择自己所用的日志组件，这样提供了很大的灵活性。
代理模式:
Dubbo consumer使用Proxy类创建远程服务的本地代理，本地代理实现和远程服务一样的接口，并且屏蔽了网络通信的细节，使得用户在使用本地代理的时候，感觉和使用本地服务一样。
可以直接通过Dubbo配置中的version版本来控制多个版本即可。
比如：
<dubbo:service interface="com.xxxx.rent.service.IDemoService" ref="iDemoServiceFirst" version="1.0.0"/>
<dubbo:service interface="com.xxxx.rent.service.IDemoService" ref="iDemoServiceSecond" version="1.0.1"/>
老版本 version=1.0.0, 新版本version=1.0.1
1.通过ServiceConfig解析标签，创建dubbo标签解析器来解析dubbo的标签，容器创建完成之后，触发ContextRefreshEvent事件回调开始暴露服务
2.通过proxyFactory.getInvoker方法，并利用javassist或DdkProxyFactory来进行动态代理，将服务暴露接口封装成invoker对象，里面包含了需要执行的方法的对象信息和具体的URL地址。
3.再通过DubboProtocol的实现把包装后的invoker转换成exporter，
4.然后启动服务器server，监听端口
5.最后RegistryProtocol保存URL地址和invoker的映射关系，同时注册到服务中心
1.首先客户端根据config文件信息从注册中心订阅服务，首次会全量缓存到本地，后续的更新会监听动态更新到本地。
2.之后DubboProtocol根据provider的地址和接口信息连接到服务端server，开启客户端client，然后创建invoker
3.之后通过invoker为服务接口生成代理对象，这个代理对象用于远程调用provider，至此完成了服务引用
Zookeeper、Redis、Multicast、Simple 等都可以作为Dubbo的注册中心
SPI(Service Provider Interface)，是一种服务发现机制，其实就是将结构的实现类写入配置当中，在服务加载的时候将配置文件独处，加载实现类，这样就可以在运行的时候，动态的帮助接口替换实现类。
Dubbo的SPI其实是对java的SPI进行了一种增强,可以按需加载实现类之外，增加了 IOC 和 AOP 的特性，还有自适应扩展机制。
SPI在dubbo应用很多，包括协议扩展、集群扩展、路由扩展、序列化扩展等等。
Dubbo对于文件目录的配置分为了三类。
key=com.xxx.xxx
Java Spi
Dubbo Spi
1.加权随机：比如我们有三台服务器[A, B, C]，给他们设置权重为[4, 5, 6]，然后讲这三个数平铺在水平线上,和为15。
然后在15以内生成一个随机数，0～4是服务器A，4～9是服务器B，9～15是服务器C
2.最小活跃数：每个服务提供者对应一个活跃数 active，初始情况下，所有服务提供者活跃数均为0。每收到一个请求，活跃数加1，完成请求后则将活跃数减1。在服务运行一段时间后，性能好的服务提供者处理请求的速度更快，因此活跃数下降的也越快，此时这样的服务提供者能够优先获取到新的服务请求。
3.一致性hash：
4.加权轮询：比如我们有三台服务器[A, B, C]，给他们设置权重为[4, 5, 6]，那么假如总共有15次请求，那么会有4次落在A服务器，5次落在B服务器，6次落在C服务器。
1.Failover Cluster失败自动切换：dubbo的默认容错方案，当调用失败时自动切换到其他可用的节点，具体的重试次数和间隔时间可用通过引用服务的时候配置，默认重试次数为1是只调用一次。
2.Failback Cluster失败自动恢复：在调用失败，记录日志和调用信息，然后返回空结果给consumer，并且通过定时任务每隔5秒对失败的调用进行重试
3.Failfast Cluster快速失败：只会调用一次，失败后立刻抛出异常
4.Failsafe Cluster失败安全：调用出现异常，记录日志不抛出，返回空结果
5.Forking Cluster并行调用多个服务提供者：通过线程池创建多个线程，并发调用多个provider，结果保存到阻塞队列，只要有一个provider成功返回了结果，就会立刻返回结果
6.Broadcast Cluster广播模式：逐个调用每个provider，如果其中一台报错，在循环调用结束后，抛出异常。
分层图：
从大的范围来说，dubbo分为三层
Service和Config两层可以认为是API层，主要提供给API使用者，使用者只需要配置和完成业务代码就可以了。
后面所有的层级是SPI层，主 要提供给扩展者使用主要是用来做Dubbo的二次开发扩展功能。
再划分到更细的层面，就是图中的10层模式。
服务失效踢出基于Zookeeper的临时节点原理。
Zookeeper中节点是有生命周期的，具体的生命周期取决于节点的类型，节点主要分为持久节点(Persistent)和临时节点(Ephemeral) 。
其实主要就是为了将调用细节封装起来，将调用远程方法变得和调用本地方法一样简单，还可以做一些其他方面的增强，比如负载均衡，容错机制，过滤操作，调用数据的统计。
关于这个问题，其实核心考察点就是你对于RPC框架的理解，一个成熟的RPC框架可以完成哪些功能，其实当我们看过一两个RPC框架后，就可以对这个问题回答个七七八八了，我们来举个例子。
1.首先我们得需要一个注册中心，去管理消费者和提供者的节点信息，这样才会有消费者和提供才可以去订阅服务，注册服务。
2.当有了注册中心后，可能会有很多个provider节点，那么我们肯定会有一个负载均衡模块来负责节点的调用，至于用户指定路由规则可以使一个额外的优化点。
3.具体的调用肯定会需要牵扯到通信协议，所以需要一个模块来对通信协议进行封装，网络传输还要考虑序列化。
4.当调用失败后怎么去处理？所以我们还需要一个容错模块，来负责失败情况的处理。
5.其实做完这些一个基础的模型就已经搭建好了，我们还可以有更多的优化点，比如一些请求数据的监控，配置信息的处理，日志信息的处理等等。
这其实就是一个比较基本的RPC框架的大体思路，大家有没有get到？
服务架构是互联网很热门的话题，是互联网技术发展的必然结果。它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。虽然微服务架构没有公认的技术标准和规范或者草案，但业界已经有一些很有影响力的开源微服务架构框架提供了微服务的关键思路，例如Dubbo和Spring Cloud。各大互联网公司也有自研的微服务框架，但其模式都于这二者相差不大。
微服务主要的优势如下：
1、降低复杂度
将原来偶合在一起的复杂业务拆分为单个服务，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。每个服务开发者只专注服务本身，通过使用缓存、DAL等各种技术手段来提升系统的性能，而对于消费方来说完全透明。
2、可独立部署
由于微服务具备独立的运行进程，所以每个微服务可以独立部署。当业务迭代时只需要发布相关服务的迭代即可，降低了测试的工作量同时也降低了服务发布的风险。
3、容错
在微服务架构下，当某一组件发生故障时，故障会被隔离在单个服务中。 通过限流、熔断等方式降低错误导致的危害，保障核心业务正常运行。
4、扩展
单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。
本文主要围绕微服务的技术选型、通讯协议、服务依赖模式、开始模式、运行模式等几方面来综合比较Dubbo和Spring Cloud 这2种开发框架。架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台，以此稳妥地实施项目的微服务化改造或开发进程。
微服务的核心要素在于服务的发现、注册、路由、熔断、降级、分布式配置，基于上述几种必要条件对Dubbo和Spring Cloud做出对比。
1、总体架构
Dubbo 核心部件（如下图）:
Provider： 暴露服务的提供方，可以通过jar或者容器的方式启动服务
Consumer：调用远程服务的服务消费方。
Registry： 服务注册中心和发现中心。
Monitor： 统计服务和调用次数，调用时间监控中心。（dubbo的控制台页面中可以显示，目前只有一个简单版本）
Container：服务运行的容器。
▲Dubbo 总体架构
Spring Cloud总体架构如下图
Service Provider： 暴露服务的提供方。
Service Consumer：调用远程服务的服务消费方。
EureKa Server： 服务注册中心和服务发现中心。
▲Spring Cloud总体架构
点评：从整体架构上来看，二者模式接近，都需要需要服务提供方，注册中心，服务消费方。
2、微服务架构核心要素
Dubbo只是实现了服务治理，而Spring Cloud子项目分别覆盖了微服务架构下的众多部件，而服务治理只是其中的一个方面。Dubbo提供了各种Filter，对于上述中“无”的要素，可以通过扩展Filter来完善。
例如
1．分布式配置：可以使用淘宝的diamond、百度的disconf来实现分布式配置管理
2．服务跟踪：可以使用京东开源的Hydra，或者扩展Filter用Zippin来做服务跟踪
3．批量任务：可以使用当当开源的Elastic-Job、tbschedule
点评：从核心要素来看，Spring Cloud 更胜一筹，在开发过程中只要整合Spring Cloud的子项目就可以顺利的完成各种组件的融合，而Dubbo缺需要通过实现各种Filter来做定制，开发成本以及技术难度略高。
基于通讯协议层面对2种框架支持的协议类型以及运行效率方面进行比较；
（一）、支持协议
1、Dubbo：dubbo使用RPC通讯协议，提供序列化方式如下：
dubbo：Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况
rmi：RMI协议采用JDK标准的java.rmi.*实现，采用阻塞式短连接和JDK标准序列化方式
Hessian:Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现
http:采用Spring的HttpInvoker实现
Webservice:基于CXF的frontend-simple和transports-http实现
2、Spring Cloud：Spring Cloud 使用HTTP协议的REST API
（二）、性能比较
使用一个Pojo对象包含10个属性，请求10万次，Dubbo和Spring Cloud在不同的线程数量下，每次请求耗时（ms）如下：
说明：客户端和服务端配置均采用阿里云的ECS服务器，4核8G配置，dubbo采用默认的dubbo协议
点评：dubbo支持各种通信协议，而且消费方和服务方使用长链接方式交互，通信速度上略胜Spring Cloud，如果对于系统的响应时间有严格要求，长链接更合适。
Dubbo：服务提供方与消费方通过接口的方式依赖，服务调用设计如下：
interface层：服务接口层，定义了服务对外提供的所有接口
Molel层：服务的DTO对象层，
business层：业务实现层，实现interface接口并且和DB交互
因此需要为每个微服务定义了各自的interface接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，开发、测试、集成环境都需要严格的管理版本依赖。如果想免费学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java进阶群：478030634，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。
通过maven的install & deploy命令把interface和Model层发布到仓库中，服务调用方只需要依赖interface和model层即可。在开发调试阶段只发布Snapshot版本。等到服务调试完成再发布Release版本，通过版本号来区分每次迭代的版本。通过xml配置方式即可方面接入dubbo，对程序无入侵。
▲Dubbo接口依赖方式
Spring Cloud：服务提供方和服务消费方通过json方式交互，因此只需要定义好相关json字段即可，消费方和提供方无接口依赖。通过注解方式来实现服务配置，对于程序有一定入侵。
点评：Dubbo服务依赖略重，需要有完善的版本管理机制，但是程序入侵少。而Spring Cloud通过Json交互，省略了版本管理的问题，但是具体字段含义需要统一管理，自身Rest API方式交互，为跨平台调用奠定了基础。
下图中的每个组件都是需要部署在单独的服务器上，gateway用来接受前端请求、聚合服务，并批量调用后台原子服务。每个service层和单独的DB交互。
▲Dubbo组件运行流程
gateWay:前置网关，具体业务操作，gateWay通过dubbo提供的负载均衡机制自动完成
Service：原子服务，只提供该业务相关的原子服务
Zookeeper：原子服务注册到zk上
▲Spring Cloud 组件运行
Spring Cloud
所有请求都统一通过 API 网关（Zuul）来访问内部服务。
网关接收到请求后，从注册中心（Eureka）获取可用服务。
由 Ribbon 进行均衡负载后，分发到后端的具体实例。
微服务之间通过 Feign 进行通信处理业务。
点评：业务部署方式相同，都需要前置一个网关来隔绝外部直接调用原子服务的风险。Dubbo需要自己开发一套API 网关，而Spring Cloud则可以通过Zuul配置即可完成网关定制。使用方式上Spring Cloud略胜一筹。
到底使用是dubbo还是Spring Cloud其实并不重要，重点在于如何合理的利用微服务。下面是一张互联网通用的架构图,其中每个环节都是微服务的核心部分。
（一）、架构分解
网关集群：数据的聚合、实现对接入客户端的身份认证、防报文重放与防数据篡改、功能调用的业务鉴权、响应数据的脱敏、流量与并发控制等
业务集群：一般情况下移动端访问和浏览器访问的网关需要隔离，防止业务耦合
Local Cache：由于客户端访问业务可能需要调用多个服务聚合，所以本地缓存有效的降低了服务调用的频次，同时也提示了访问速度。本地缓存一般使用自动过期方式，业务场景中允许有一定的数据延时。
服务层：原子服务层，实现基础的增删改查功能，如果需要依赖其他服务需要在Service层主动调用
Remote Cache：访问DB前置一层分布式缓存，减少DB交互次数，提升系统的TPS
DAL：数据访问层，如果单表数据量过大则需要通过DAL层做数据的分库分表处理。
MQ：消息队列用来解耦服务之间的依赖，异步调用可以通过MQ的方式来执行
数据库主从：服务化过程中毕竟的阶段，用来提升系统的TPS
（二）注意事项
服务启动方式建议使用jar方式启动，启动速度快，更容易监控
缓存、缓存、缓存，系统中能使用缓存的地方尽量使用缓存，通过合理的使用缓存可以有效的提高系统的TPS
服务拆分要合理，尽量避免因服务拆分而导致的服务循环依赖
合理的设置线程池，避免设置过大或者过小导致系统异常
Dubbo出生于阿里系，是阿里巴巴服务化治理的核心框架，并被广泛应用于中国各互联网公司；只需要通过spring配置的方式即可完成服务化，对于应用无入侵。设计的目的还是服务于自身的业务为主。虽然阿里内部原因dubbo曾经一度暂停维护版本，但是框架本身的成熟度以及文档的完善程度，完全能满足各大互联网公司的业务需求。如果我们需要使用配置中心、分布式跟踪这些内容都需要自己去集成，这样无形中增加了使用 Dubbo 的难度。
Spring Cloud 是大名鼎鼎的 Spring 家族的产品， 专注于企业级开源框架的研发。 Spring Cloud 自从发展到现在，仍然在不断的高速发展，几乎考虑了服务治理的方方面面，开发起来非常的便利和简单。
Dubbo于2017年开始又重启维护，发布了更新后的2.5.6版本，而Spring Cloud更新的非常快，目前已经更新到Finchley.M2。因此，企业需要根据自身的研发水平和所处阶段选择合适的架构来解决业务问题，不管是Dubbo还是Spring Cloud都是实现微服务有效的工具。
*请认真填写需求信息，我们会在24小时内与您取得联系。
