分布式与微服务
简单的说，微服务是架构设计方式，分布式是系统部署方式，两者概念不同
其实个人感觉，二者没有太大的区别，或者说没有必要将二者严格区分，做分布式，也可以说是在做微服务，做微服务，也可以说是在做分布式，关键是要解决的问题，以及所带来的优缺点。
当一台系统无法满足生产要求时，自然想到多台系统联合工作，也就是集群，（其实也就是分布式了），当集群系统中多台系统不完全相同时，比如运行的服务不同，甚至更彻底一点，直接面向服务，即SOA，一台系统上就只运行一个服务，以服务作为对象来进行开发、维护，并结合传输协议，在整个系统中（包括集群）进行业务运作，就形成了微服务。
所以，分布式与微服务，从某种角度来说，是软件发展的必然产物。因为解放了超级计算机的压力，而且提升了系统的可用性、弹性、可维护性、灰度发布等。
框架
Spring Cloud
主要参考大白话入门 Spring Cloud，虽然文章写得很活泼，但是个人并不喜欢这种风格，有点过头了，但说实话，有几张图还是挺有价值的。
Spring Cloud整体架构图：
文章中分模块进行了讲解，个人觉得，显得有些杂乱且不够系统，在需要搭建微服务系统时，还是应该去学习官方资料。
另外，其实文章没有站在第三方的角度对Spring Cloud进行评价，稍显一些缺失。
Dubbo
Dubbo 的架构图解
其实这里可以看出，dubbo所完成的工作是分布式或微服务的核心，也属于Spring Cloud的一部分Dubbo 工作原理
这张图貌似很复杂，其实调理非常清晰和详细，按照图中各模块及流程系统进行学习，收益应该很大。
二者区别
个人认为几个比较重要的区别是：
- 二者采用连接方式和协议不同：
Dubbo ：只支持RPC，使得服务提供方（抽象接口）与调用方在代码上产生了强依赖，并且本身不支持跨语言；采用单一长连接和 NIO 异步通讯（保持连接/轮询处理），使用自定义报文的 TCP 协议，并且序列化使用定制 Hessian2 框架，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况，但不适用于传输大数据的服务调用。
Spring Cloud ：直接使用 HTTP 协议（但也不是强绑定，也可以使用 RPC 库，或者采用 HTTP 2.0 + 长链接方式（Fegin 可以灵活设置））。 - 二者定位不同：
Dubbo ：未来的定位是专注在 RPC 领域，成为微服务生态体系中的一个重要组件，而不是要成为一个微服务的全面解决方案。
Spring Cloud ：提供整套的微服务解决方案，基于 Spring Boot，开发成本较低，且风险较小。 - 社区支持不同：
Dubbo ：社区更新不稳定，阿里内部使用HSF，Dubbo未来的社区更新得不到保障
Spring Cloud ：有强大的 Spring 社区、Netflix 等公司支持，并且开源社区贡献非常活跃。
有人比喻成买电脑，使用Dubbo像组装机，可以搭配不同的配件，达到特定的目的，但是对开发者的要求相应较高；而SpringCloud则更像品牌机。
后记
实践是检验真理的唯一标准，这些看似牛逼的框架、系统，各个模块及相互之间复杂的管理、联系等，都不是凭空出来的，学习时不仅要知道其然，还得知道其所以然，接着为什么、怎么用、创新等等。
参考文档
一分钟弄懂什么是分布式和微服务大白话入门 Spring CloudDubbo 总结：关于 Dubbo 的重要知识点Java 微服务框架选型（Dubbo 和 Spring Cloud？）
