聊聊springcloud和dubbo那些事（一）

微服务项目上线好久了，在这里想复盘一下，顺便做个总结。（在心里搞个仪式弄个欢送会，因为接下来可能要搞别的技术去了）

1，从技术角度理解微服务？
微服务的核心就是将传统的一站式应用，根据业务拆分（你要是不按业务拆分，我也没意见的）成一个一个的服务，彻底的去耦合，每一个微服务提供单个功能的服务，一个服务做一件事情，从技术角度来看就是一种小而独立的处理过程，类似进程，能够自行单独启动或者销毁，拥有自己独立的数据库（是重点要记住）

2，微服务架构提出者是马丁福勒，地址放上去，有兴趣的去瞅瞅，

https://martinfowler.com/articles/microservices.html

戴帽子才是作者，不要搞错了。（温馨提示，哈哈哈）
个人总结他说的的重点：
1，分布式系统，各个模块服务独立运行，
2，各自微小的进程，让专业的人搞专业的模板，做专业的事
3. 独立部署
4. 拆分
5. 各自独立的进程
6. 用友自己独立的数据库
7.分割线 ---------------------------------------------------------------------

3，微服务和微服务架构？
微服务：强调的是微服务的大小，它关注的是某一个点，是具体解决某一个问题，提供落地对应服务的一个服务应用。可以看作Eclipse里面的一个个微服务工程

微服务架构：是一种架构模式，提倡将单一的应用程序划分为一组小的服务，服务之间互相协调，互相配合，为用户提供最终价值，每个服务运行再其他独立的进程中，服务与服务之间采用轻量级的通信机制，互相协作，通常基于http协议的restful API，每个服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言

4，微服务的有点和缺点？
优点盘点七项。
part1，每个服务足够内聚，足够小，代码容易理解这样能聚集一个指定的业务功能或业务需求。
part2，开发简单，开发效率提高，一个服务可能就是专一的干一件事。
part3，微服务能够被小团队单独开发，这个团队是2到5人的开发人员组成
part4，微服务是来松耦合的，是有内能意义的服务，无论是在开发阶段还是部署阶段都是独立的。
part5，微服务能使不同的语言开发
part6，易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，jenkins
part7，微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果，

缺点盘点7点
part1，开发人员要理解分布式系统的复杂性
part2，多服务运维难度，随着服务的增加，运维的压力也在增大
part3，系统部署依赖
part4，服务间通信成本
part5，数据一致性
part6，系统集成测试
part7，性能监控

5，微服务的基础栈有哪些？

6，为什么选springcloud为微服务架构？
阿里dubbo：停更了团队解散了传闻老大去天猫了（说散就散）
京东JSF：想跟马云爸爸作对
新浪：Motan
当当网：dubbox（老把公司卖了）
根据以上情况，知道原因了吧

7，springboot和springcloud是什么关系？
springboot专注于快速方便的开发单个个体微服务
springcloud是关注全局的微服务协调治理框架，它将springboot开发的一个一个单体微服务整合并管理起来，为各个微服务之间提供配置管理，服务发现，断路器，路由，微代理，事件总线，决策竞选，分布式会话等架构组成服务。
springboot可以离开springcloud独立使用开发项目，但是springcloud离不开springboot，属于依赖关系，springboot专注于快速，方便的开发单个微服务个体，springcloud关注全局的服务治理框架

8，dubbo和springcloud区别有哪些？
我认为最大的区别就是：springcloud抛弃了dubbo的RPC的通信，采用的是基于http的rest方式，严格来说，其实这两种方式各有优势，虽然从一定程度上来说，后者牺牲服务调用的性能，但是也避免了上面提到的原生RPC带来的问题，而REST相对RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码别的依赖，这在强调快速演化的微服务环境下，显得更加合适。

品牌机和组装机的区别：
很明显，springcloud的功能比dubbo更加强大，涵盖更广，而且作为spring的拳头项目，它也能与springFramework，springboot，springdata，springBatch，等与其他spring项目完美融合，这些对于微服务而言是至关重要的，使用dubbo构建微服务就像是组装电脑，各个环节自由度比较高，但是最终结果可能因为一条内存质量不行就over了，总是让人不放心，但是如果你是一名高手，那这些都不是问题，而springcloud就像是品牌机，在spring source的整合下，做了大量的兼容性测试，保证机器拥有更高的稳定性，但是如果要使用非原装组件的东西，就需要对其基础有足够的了解。

社区支持和更新:
最重要的是，dubbo停止了5年左右的更新，（用阿里的技术，要考虑好，技术可能会黄掉，团队可能会解散，然而小公司还无法维持这个技术）虽然2017年重启了，对技术发展的新需求，需要由开发者自行拓展升级，这对很多想要采用微服务架构的中小型组织，显然是不合适的，中小型公司没有这么强大的技术能力，去修改dubbo的源码和周边的一整套解决方案，并不是每一个公司都有阿里的大牛，真实的线上环境测试过程。

我们听听dubbo重启维护开发的人物：刘军，主要负责人之一.
采访者：RPC服务框架dubbo在重启维护后，是否还能跟上时代？dubbo和springcloud相比又有何优势和差异？

（允许我散发一个脑洞，像不像记者采访一个退圈5年的女明星D，问D女星，你和S女星相比，体力和演技还能跟得上吗？你觉得你比她有什么优势呢？呵呵）

（经纪人刘军发言）：首先关于D女星和S女星之间的关系，我们在开源中国年终盛典（复出大会，哈哈）的dubbo分享中也做了简单的阐述，首先确定的是两个人不是完全的竞争关系（不是才怪），两者解决的问题是不一样的（言下之意是我们dubbo更高贵呢），dubbo的定位始终是一款RPC框架（我们dubbo定位可是国际女星），而微服务的目标是微服务架构下的一站式解决方案(说S女星就知道演那些婆婆妈妈的电视剧)，如果非要比较，dubbo可以类比Netfixoss技术栈，而springcloud集成了Netfixoss作为分布式服务治理解决方案，
（我们D女星可是和玛丽莲梦露比肩的，S女星最多是个玛丽莲梦露接班人，还是粉丝自封的）。

当前由于RPC协议，注册中心元数据不匹配等问题，在面临微服务基础框架选型时dubbo与springCloud是只能二选一（休想让我们在一部剧出现）dubbo之后会积极寻求适配到springcloud生态，（都是谦虚的场面话）比如作为cloud的二进制通信方案来发挥dubbo的性能优势，或者dubbo通过模块化以及对http的支持适配到springcloud。
未完待续…