初识SpringCloud微服务

最近项目的数据库采用了面向关系型数据库MySQL，整个项目采用了完整的Spring Cloud架构（Spring Cloud 基于 Spring Boot，为微服务体系开发中的架构问题，提供了一整套的解决方案——服务注册与发现，服务消费，服务保护与熔断，网关，分布式调用追踪，分布式配置管理等。Spring Boot 是 Spring 的一套快速配置脚手架，使用默认大于配置的理念，用于快速开发单个微服务）。

RPC和Restful区别

• RPC—Remote Procedure Call，远程过程调用：工作在TCP协议之上。主要是针对系统繁多，业务线复杂的大型企业。 一个完整的RPC服务基本架构包含了四个核心的组件，分别是Client ,Server,Client Stub存根和Server Stub存根：
  

  • 客户端（Client）-----服务的调用方。
  • 服务端（Server）------真正的服务提供者。
  • 客户端存根Client Stub-----存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。
  • 服务端存根Server Stub------接收客户端发送过来的消息，将消息解包，并调用本地的方法。

• Sync同步调用与Async异步调用

  • Sync Call：客户端等待调用完成并返回结果。
  • Async Call： 客户端不等待调用执行完成返回结果，可以通过回调函数等接收到返回结果的通知。

• HTTP—HyperText Transfer Protocol 超文本传输协议：工作在HTTP协议之上（HTTP协议在传输层协议TCP之上）。RPC在效率、吞吐量上更具有优势。
  REST ---- REpresentation State Transfer 是一种架构设计风格/规范，提供了设计原则和约束条件，而不是架构！！！，而满足这些约束条件和原则的应用程序或设计就是 Restful架构或服务。微服务开发将Resource资源【啥是资源？？？答：Java中万物皆对象，那么资源也有大or有小— 大到每个微服务即为资源，小到可以是每个微服务中的每张需求业务表都可以看作为Resource】发布为URI–Uniform Resource Identifier 统一资源标志符，Web端or移动端通过URI + HTTP动词—GET/PUT/POST/DELETE等访问并操作资源。例如：获取用户列表 GET http://{ip:port}/api/users

  • RESTFul架构设计原则：
  1. 资源与URI—如资源员工employee，档案document等和Uniform Resource Identifier（统一资源标志符）
  2. 统一资源接口—HTTP请求（常见类型：GET/PUT/POST/DELETE等）
  3. 资源的表述—包括数据和描述数据的元数据。属于哪一种编码类型，内容是如何编码的，对应的是什么地方的语言。如编码类型Content-type:text/html;charset=utf-8；内容编码Content-encoding:gzip；语言为Content-Languague:zh;en
  4. 资源的链接—即通过URI和统一资源接口进行链接
  5. 状态的转移—HTTP本身是无状态的，但客户端想要操作服务器，必须通过某种手段让服务器发生“状态转化（State Transfer）”。而这种转化是建立在表现层之上的，HTTP请求类型即为“表现层状态转化”。

目前主流的开源RPC框架：

1. gRPC是Google最近公布的开源软件，基于最新的HTTP2.0协议，并支持常见的众多编程语言。 HTTP2.0是基于二进制的HTTP协议升级版本。 这个RPC框架是基于HTTP协议实现的，底层使用到了Netty框架的支持。
2. Thrift是Facebook的一个开源项目，主要是一个跨语言的服务开发框架。它有一个代码生成器来对它所定义的IDL定义文件自动生成服务代码框架。用户只要在其之前进行二次开发就行，对于底层的RPC通讯等都是透明的。不过这个对于用户来说的话需要学习特定领域语言这个特性，还是有一定成本的。
3. Dubbo是Alibaba开源的一个极为出名的RPC框架，在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是及其鲜明的特色。同样的远程接口是基于Java Interface，并且依托于spring框架方便开发。可以方便的打包成单一文件，独立进程运行，和现在的微服务概念一致。

《Spring Cloud VS Dubbo》

Dubbo优点	Spring Cloud优点
支持 RPC 调用，服务之间的调用性能会很好	支持 REST 服务调用，相比于 RPC，更加轻量化和灵活（服务之间只依赖一纸契约，不存在代码级别的强依赖），有利于跨语言服务的实现，以及服务的发布部署。另外，结合 Swagger，也使得服务的文档一体化
支持多种序列化协议，如 Hessian、HTTP、WebService	标准化的将微服务的成熟产品和框架结合一起，Spring Cloud 提供整套的微服务解决方案，开发成本较低，且风险较小
Dubbo Admin后台管理功能强大，提供了路由规则、动态配置、访问控制、权重调节、均衡负载等功能	基于 Spring Boot，具有简单配置、快速开发、轻松部署、方便测试的特点
在国内影响力比较大，中文社区文档较为全面	有强大的 Spring 社区、Netflix 等公司支持，并且开源社区贡献非常活跃。国内外企业应用非常多，经受了大公司的应用考验（比如 Netfilx 公司），以及强大的开源社区支持
阿里2017年重启维护	提供了 Docker 及 Kubernetes 微服务编排支持

Dubbo缺点	Spring Cloud 缺点
Registry 严重依赖第三方组件（zookeeper 或者 redis），当这些组件出现问题时，服务调用很快就会中断	支持 REST 服务调用，可能因为接口定义过轻，导致定义文档与实际实现不一致导致服务集成时的问题（可以使用统一文档和版本管理解决，比如 Swagger）
只支持 RPC 调用。使得服务提供方（抽象接口）与调用方在代码上产生了强依赖，服务提供者需要不断将包含抽象接口的 jar 包打包出来供消费者使用。一旦打包出现问题，就会导致服务调用出错，并且以后发布部署会成很大问题（太强的依赖关系）	REST 服务调用性能会比 RPC 低一些（但也不是强绑定）
要兼容 .NET Core 服务，Dubbo RPC 本身不支持跨语言（可以用跨语言 RPC 框架解决，比如 Thrift、gRPC（重复封装了），或者再封装 REST 服务，提供跨平台的服务调用实现，但相对麻烦很多）	整合了大量组件，相关文档比较复杂，需要针对性的进行阅读
只实现了服务治理框架，其他微服务框架并未包含，如果需要使用，需要结合第三方框架实现（比如分布式配置用淘宝的 Diamond、服务跟踪用京东的 Hydra，但使用相对麻烦些），开发成本较高，且风险较大	–
社区更新不及时（虽然最近在疯狂更新），但也难免阿里以后又不更新了，就尴尬了。主要是国内公司使用，但阿里内部使用 HSF，相对于 Spring Cloud，企业应用会差一些	–

《Spring Cloud 全家桶 和Spring 组件架构》

• 请求统一通过 API 网关（Zuul）来访问内部服务。
• 网关接收到请求后，从注册中心（Eureka）获取可用服务。
• 由 Ribbon 进行均衡负载后，分发到后端具体实例。
• 微服务之间通过 Feign 进行通信处理业务。
• Hystrix 负责处理服务超时熔断。
• Turbine 监控服务间的调用和熔断相关指标。