Dubbo 与 Spring Cloud
Spring 全家桶：
因为是spring的一整套架构，所有支持的很好，只有你想不到， 没有它做不到；
Dubbo：
很多企业还在用，可以支持Restful风格的API, 调用远程API像调用本地API一样，同时其基于接口的方式增加了服务间的耦合；
基本工作原理是什么？从服务注册到发现，是怎么运行的？
Spring Cloud 与Dubbo 对比：
总结：
1. 从占用带宽：
Dubbo由于是二进制的传输，占用带宽会很少；
Spring Cloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大；
2. 从开发上： Dubbo的开发难度较大，原因是Dubbo的jar包依赖问题很多大型工程无法解决；
3. Spring Cloud的接口协议约定比较自由且松散，需要有很强有力的行政措施来限制接口无序升级；
4. 注册中心： Dubbo的注册中心可以选择ZooKeeper、Redis等多种，spring cloud的注册中心只能用Eureka或者自研；
5. 从系统结构简易程序：Spring Cloud的系统结构简单，注册中心 + SpringMvc = Spring Cloud, 而Dubbo各种复杂的Url、protocol、register、invocation、dubbofilter、dubboSpi、dubbo序列化。。。。更多一些；
6. 从性能：Dubbo的网络消耗小于Spring Cloud, 但网络消耗不是太大问题，通过压缩、二进制、高速缓存、分段降级等方法恶意 解决；
一. 微服务设计原则：
1. AFK拆分原则
业界对于可扩展的系统架构设计有一个朴素的理念：通过加机器就可以解决容量和可用性的问题,这一理念在“云计算”概念疯狂流行的今天，得到了广发的认可，对于一个规模迅速增长的系统而言，容量和性能问题当然是首当其冲的，但是随着时间的推移，系统规模的增长，除了面对性能和容量的问题外，还需要面对功能与模块数量上增长带来的系统复杂性问题，以及业务变化带来的提供差异化服务问题，对此《The Art of Scalability》一书中提出了一个更加系统的可扩展模型--AFK可扩展立方，这个立方体中沿着三个坐标轴设置分别为X、Y、Z.
一个叫AKF的公司的技术专家抽象总结的应用扩展的三个维度， 理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。
. X轴: 指的是水平复制，将单体系统多运行几个实例，成为集群加负载均衡的模式。
. Y轴： 基于类似的数据分区，比如一个互联网打车应用突然火了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等地多建几个集群。
. Z轴： 就是微服务的拆分模式，基于不同的业务拆分。
场景说明：比如打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现是乘客和车主访问量很大，
就将打车应用拆分成了三个，分别为乘客服务、车主服务、支付服务，三个服务的业务特点不同，独立维护，各自都可以再次按需扩展。
2. 前后端分离原则
。前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果更好。
。前后端分离模式下，前后端交互界面更清晰，就剩下了接口模型，后端的接口简洁明了，更容易维护。
。前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支持多个前端；
例如：微信h5前端、PC前端、安卓前端、IOS前端。
3.无状态服务原则
对于无状态服务，首先说一下什么是状态：
如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之被称为无状态服务。那么这个无状态服务原则并不是说在微服务架构里就不容许存在状态，真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。
场景说明：例如我们以前在本地内存中建立的数据缓存、Session缓存、到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。
也就是对同一个url请求没有上下文关系。
比如空调遥控器，你按上下调整温度时， 空调温度设定值会变化，遥控器信号到空调是单向传输，现在空调显示温度20度，遥控器20度。
如果遥控器与空调之间是有状态的，假设你离开空调接收范围调整了遥控器温度，变成了19度，那回到范围内你按一次升高一度，
基于原先温度状态，遥控器给空调发送一个“提高1度”的指令，就会出现遥控器提高到20度，而空调变成21度。
如果遥控器与空调之间是无状态的，假设你离开空调接收范围调整了遥控器温度，变成了19度，那回到范围内你按一次升高一度，
遥控器给空调发送一个“设定温度值20”的指令，这样两者最终还是相同的值。
4.Rest通讯风格
基于“无状态通信原则”，我们直接推荐一个实践优选的Restful通信风格，因为有很多好处：
。无状态协议HTTP, 具备先天优势，扩展能力很强。例如需要安全加密时，有现成的成熟方案HTTPS可用。
。JSON报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。
。语言无关，各大热门语言都提供成熟的Restful API框架，相对其他的一些RPC框架生态更完善。
RESTful架构应该遵循统一接口原则，统一接口包含了一组受限的预定义的操作，不论什么样的资源，都是通过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET，PUT和POST，并遵循这些方法的语义。
如果按照HTTP方法的语义来暴露资源，那么接口将会拥有安全性和幂等性的特性，例如GET和HEAD请求都是安全的， 无论请求多少次，都不会改变服务器状态。而GET、HEAD、PUT和DELETE请求都是幂等的，无论对资源操作多少次， 结果总是一样的，后面的请求并不会产生比第一次更多的影响。
幂等性：对同一REST接口的多次访问，得到的资源状态是相同的。
安全性：对该REST接口访问，不会使服务器端资源的状态发生改变。
下面列出了GET，DELETE，PUT和POST的典型用法:
GET ： 获取资源
安全且幂等, 获取表示, 变更时获取表示（缓存）
200（OK） - 表示已在响应中发出
204（无内容） - 资源有空表示
301（Moved Permanently） - 资源的URI已被更新
303（See Other） - 其他（如，负载均衡）
304（not modified）- 资源未更改（缓存）
400 （bad request）- 指代坏请求（如，参数错误）
404 （not found）- 资源不存在
406 （not acceptable）- 服务端不支持所需表示
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务端当前无法处理请求
POST ： 新增资源
不安全且不幂等
使用服务端管理的（自动产生）的实例号创建资源
创建子资源
部分更新资源
如果没有被修改，则不过更新资源（乐观锁）
200（OK）- 如果现有资源已被更改
201（created）- 如果新资源被创建
202（accepted）- 已接受处理请求但尚未完成（异步处理）
301（Moved Permanently）- 资源的URI被更新
303（See Other）- 其他（如，负载均衡）
400（bad request）- 指代坏请求
404 （not found）- 资源不存在
406 （not acceptable）- 服务端不支持所需表示
409 （conflict）- 通用冲突
412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）
415 （unsupported media type）- 接受到的表示不受支持
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务当前无法处理请求
PUT ：修改资源
不安全但幂等
用客户端管理的实例号创建一个资源
通过替换的方式更新资源
如果未被修改，则更新资源（乐观锁）
200 （OK）- 如果已存在资源被更改
201 （created）- 如果新资源被创建
301（Moved Permanently）- 资源的URI已更改
303 （See Other）- 其他（如，负载均衡）
400 （bad request）- 指代坏请求
404 （not found）- 资源不存在
406 （not acceptable）- 服务端不支持所需表示
409 （conflict）- 通用冲突
412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）
415 （unsupported media type）- 接受到的表示不受支持
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务当前无法处理请求
DELETE : 删除资源
不安全但幂等 ,
200 （OK）- 资源已被删除
301 （Moved Permanently）- 资源的URI已更改
303 （See Other）- 其他，如负载均衡
400 （bad request）- 指代坏请求
404 （not found）- 资源不存在
409 （conflict）- 通用冲突
500 （internal server error）- 通用错误响应
503 （Service Unavailable）- 服务端当前无法处理请求
二. 微服务核心组件：
2.1 Spring Cloud Netflix 第一代
Netflix 是一家美国公司，在美国、加拿大提供互联网随选流媒体播放、定制DVD、蓝光光碟在线出租业务，
该公司成立于1997年，总部位于加利福尼亚州，1999年开始订阅服务。
针对多种Netflix组件提供的开发工具包， 其中包括Eureka、Hystrix、Ribbon、Zuul、Feign、Archaius等。
。Netflix Eureka : 一个基于Rest服务的服务治理组件，包括服务注册中心、服务注册与服务发现机制的实现，实现了云端负载均衡和中间层服务器的故障转移；
。Netflix Hystrix : 容错管理工具，实现断路器模式，通过控制服务的节点，从而对延迟和故障提供更强大的容错能力；
。Netflix Ribbon : 客户端负载均衡的服务调用组件；
。Netflix Feign : 基于Ribbon 和 Hystrix 的声明式服务调用组件；
。Netflix Zuul : 微服务网关，提供动态路由，访问过滤等服务；
。Netflix Archaius : 配置管理API, 包含一系列配置管理API, 提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能；
2.2 Spring Cloud Alibaba 第二代
Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必须组件，方便开发者通过Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务；
依托Spring Cloud Alibaba , 只需要添加一些注解和少量配置， 就可以将Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统；
具体组件：
。Nacos ： 阿里开源产品， 一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台；
。Sentinel : 面向分布式服务架构的轻量级流量控制产品， 把流量作为切入点， 从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性；
。RocketMQ : 一款开源的分布式消息系统， 基于高可用分布式集群技术， 提供低延时的、高可靠的消息发布与订阅服务；
。Dubbo : Apache Dubbo 是一款高性能Java RPC 框架；
。Seata : 阿里巴巴开源产品， 一个易于使用的高性能微服务分布式事物解决方案；
。Alibaba Cloud ACM : 一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品；
。Alibaba Cloud OSS : 阿里云对象存储服务(Object Storage Service 简称OSS), 是阿里云提供的海量、安全、低成本、高可靠的云存储服务， 可以在任何应用、任何时间、任何地点存储和访问任意类型的数据；
。Alibaba Cloud Schedulerx : 阿里中间件团队开发的一款分布式任务调度产品， 提供秒级、精准、高可靠、高可用的定时（基于Cron表达式）任务调度服务；
。Alibaba Cloud SMS : 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道；
下面是Spring Cloud Netflix 和 Spring Cloud Alibaba 的对比：
