本文主要围绕微服务的技术选型、通讯协议、服务依赖模式、开始模式、运行模式等几方面来综合比力Dubbo和Spring Cloud 这2种开发框架。架构师可以凭据公司的技术实力并联合项目的特点来选择某个合适的微服务架构平台，以此稳妥地实施项目的微服务化革新或开发历程。

微服务架构是互联网很热门的话题，是互联网技术生长的一定效果。它提倡将单一应用法式划分成一组小的服务，服务之间相互协调、相互配合，为用户提供最终价值。

虽然微服务架构没有公认的技术尺度和规范或者草案，但业界已经有一些很有影响力的开源微服务架构框架提供了微服务的关键思路，例如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接口，并通过连续集成公布到私有堆栈中，挪用方应用对微服务提供的抽象接口存在强依赖关系，开发、测试、集成情况都需要严格的治理版本依赖。

通过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都是实现微服务有效的工具。本文标题：阿里P8架构师谈：微服务Dubbo和SpringCloud架构设计、优劣势比力转载请保留页面地址：https://youzhixueyuan.com/comparison-of-dubbo-and-springcloud-architecture-design.html。

本文来源：威斯尼斯wns888入口app-www.ah-tianbao.com