众说spring cloud和dubbo、、、

从项目的背景来看，Dubbo 国内用的公司挺多，国内影响力大，Spring Cloud 自然在国外影响力较大，所以这个来看不分伯仲了，毕竟都有大公司在使用。从社区的活跃度来看，可以看下各自的Github托管项目来区分，Dubbo · GitHub 与 Spring Cloud · GitHub ，从更新频率与更新时间来看 Spring Cloud 优于Dubbo，Dubbo基本不维护了。从框架的完整度来看，Dubbo只是实现了服务治理（注册 发现等），而Spring Cloud下面有很多个子项目覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面，一定程度来说，Dubbo只是Spring Cloud Netflix中的一个子集。如果选择Spring Cloud，基本上每个环节都已经有了对应的组件支持，可能有些也不一定能满足你所有的需求，但是其活跃的社区与快速的迭代更新也会让你没有后顾之忧。

spring-boot有pivotal和netfix背书，是一套完整的企业级应用的开发方案，天然集成分布式云架构spring-cloud，重点是有配套的更加完善的软件基础设施，但是实际编码会有侵入性。 Dubbo有阿里巴巴背书，是一套RPC的半完善解决方案，配套的软件基础设施不全，好处是编码环节基本没有侵入性。我们在用dubbo，朋友的公司也有在用的，面临的问题也大致相似，问题定位、熔断和监控方面的问题让人没有那么的放心，最近打算尝试在spring-cloud中寻找答案。

spring-boot有pivotal和netfix背书，是一套完整的企业级应用的开发方案，天然集成分布式云架构spring-cloud，重点是有配套的更加完善的软件基础设施，但是实际编码会有侵入性。 Dubbo有阿里巴巴背书，是一套RPC的半完善解决方案，配套的软件基础设施不全，好处是编码环节基本没有侵入性。我们在用dubbo，朋友的公司也有在用的，面临的问题也大致相似，问题定位、熔断和监控方面的问题让人没有那么的放心，最近打算尝试在spring-cloud中寻找答案。

两者不能直接进行对比，dubbo只是作为服务治理的rpc层，而Spring Cloud 提供了一整套分布式服务开发的工具，从边缘服务的Zuul，到服务发现Eureka ，再到hystrix 熔断机制，是一套完整的生态，但是我觉得这里面最有帮助的可能是hystrix ，它提供了完整的熔断机制，可以很轻易的引入现有系统。

先说应用场景，两者都是分布式服务治理相关的组件。都具备了服务注册、发现、路由、负载均衡等能力。
区别之一就是用的时候感觉springcloud集成了springcboot与docker，用起来很方便，dubbo则是一个中规中矩的服务治理框架。

分布式系统架构中，分布式事务是一个绕不过去的挑战！微服务架构本质上就是分布式服务化架构，微服务架构的流行，让分布式事务问题日益突出！尤其是在订单业务、资金业务等系统核心业务流程中，一定要有可靠的分布式事务解决方案来保证业务数据的可靠性和准确性。目前比较多的解决方案有几个：
    一、结合MQ消息中间件实现的可靠消息最终一致性
    二、TCC补偿性事务解决方案
    三、最大努力通知型方案

    第一种方案：可靠消息最终一致性，需要业务系统结合MQ消息中间件实现，在实现过程中需要保证消息的成功发送及成功消费。即需要通过业务系统控制MQ的消息状态
    第二种方案：TCC补偿性，分为三个阶段TRYING-CONFIRMING-CANCELING。每个阶段做不同的处理。TRYING阶段主要是对业务系统进行检测及资源预留 CONFIRMING阶段是做业务提交，通过TRYING阶段执行成功后，再执行该阶段。默认如果TRYING阶段执行成功，CONFIRMING就一定能成功。CANCELING阶段是回对业务做回滚，在TRYING阶段中，如果存在分支事务TRYING失败，则需要调用CANCELING将已预留的资源进行释放。
  第三种方案：最大努力通知xing型，这种方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。这种方案也是结合MQ进行实现，例如：通过MQ发送http请求，设置最大通知次数。达到通知次数后即不再通知。

总之还是成本的问题。已经到了要构建成一个分布式系统，自然会涉及到缓存、消息、rpc等，以及维护成本。每一个模块要能用好，自然有深入学习，对程序员来说，在<再包装一层>上面去，增加学习成本和维护的不可控性。所以<微服务>不是一套技术组件的包装，更应侧重在研发的流程上，如何能从整体提高效率。

spring cloud整机，dubbo需要自己组装；整机的性能有保证，组装的机子更自由。

、、、、、