Dubbo和SpringCloud认识

微服务架构

微服务架构提倡将单一应用程序划分成为一组小的服务，服务之间互相协调，互相配合，为用户提供最终价值。常见的微服务框架有Dubbo和SpringCloud

微服务的主要优势

1. 降低复杂度
   将原来耦合在一起的复杂业务拆分成为单个服务，规避了原来复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表达服务的边界。每个服务开发者只专注于服务本身，通过使用缓存，DAL等各种技术手段来提升系统的性能，而对于消费方来说是完全透明的。
2. 可独立部署
   由于微服务具备独立的运行进程，所以每个微服务可以独立部署。当业务迭代时只需要发布相关服务的迭代即可，降低了测试的工作量同时也降低了服务发布的风险
3. 容错
   在微服务架构下，当某一组件发生故障时，故障会被隔离在单个服务中。通过限流，熔断等方式降低错误导致的危害，保障核心业务的正常运行。
4. 扩展
   单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展上需求上存在差异时，微服务架构便体现了灵活性。

Dubbo和SpringCloud的核心部件

Dubbo总体架构

- Provider：暴露服务的提供方，可以通过jar或者容器的方式
- Consumer：调用远程服务的消费方
- Registry：服务注册中心和发现中心
- Monitor：统计服务和调用的次数，调用时间监控中心。
- Container：服务运行容器。

SpringCloud总体架构

- Service Provider：暴露服务的提供方
- Service Consumer：调用远程服务的服务消费方
- EureKa Server：服务注册中心和服务发现中心

微服务架构核心元素

核心元素 Dubbo SpringCloud
服务注册中心 Zookeeper，Redis SpringCloud Netflix Eureka
服务调用方式 RPC REST API
服务网关 无 SpringCloud Netflix Zuul
断路器 不完善 SpringCloud Netflix Hystrix
分布式配置 无 SpringCloud Netflix Config
分布式追踪系统 无 SpringCloud Netflix Sleuth
消息总线 无 SpringCloud Netflix Bus
数据流 无 SpringCloud Stream
批量任务 无 SpringCloud Task

通讯协议

1. Dubbo：dubbo使用RPC通讯协议，提供序列化方式如下：

   • dubbo：Dubbo缺省协议采用单一长连接和NIO异步通讯，适合小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。
   • rmi：RMI协议采用了JDK标准的java.\rmi实现，采用阻塞式短路连接和JDK标准序列化方式
   • Hessian：Hessian协议用于集成Hessian的服务，Hessian底层采用http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现
   • http：采用Spring的HttpInvoker实现
   • WebService：基于CXF的fronten-simple和transports-http实现

2. SpringCloud：Spring Cloud 使用HTTP协议的REST API

服务依赖方式

Dubbo：服务提供方与消费方提供接口的方式依赖，服务调用设计如下：

• interface层：服务接口层，定义了服务对外提供的所有接口；
• Model层：服务的DIO对象层
• business层：业务实现层，实现interface接口并且和DB交互
  因此需要为每个微服务定义了各自的interface接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，测试，集成环境都需要严格的管理版本依赖。
  通过maven的install$deploy命令把interface和model层发布到仓库中，服务调用方只需要依赖interface和model1层即可。在开发调试阶段只发布Snapshot版本。等到服务调试完成后再发布Release版本，通过版本号来区分每次迭代的版本。通过xml配置方式即可连接dubbo，对程序无入侵。
  Dubbo:接口依赖方式

Spring Cloud:服务提供方和服务消费方通过json方式交互，因此只需要定义好相关json字段即可，消费方和提供方无接口依赖。通过注解方式来实现服务配置，对程序有一定入侵。

组件运行流程

Dubbo组件

• gateWay：前置网关，具体业务操作，gateWay通过dubbo提供的负载均衡机制自动完成。
• Service：原子服务，只提供该业务相关的原子服务
• Zookeeper：原子服务注册到zk上

Spring Cloud组件

• 所有请求都统一通过API网关（Zuul）来访问内部服务。
• 网关接收到请求后，从注册中心（Eureka）获取可以服务。
• 有Ribbon进行负载均衡后，分发到后端具体实例。
• 微服务之间通过Fegin进行通信业务。

二者业务部署方式相同，都需要前置一个网关来隔绝外部直接调用原子服务的风险。Dubbo需要自己开发一套API网关，而Spring Cloud则可以通过Zuul配置即可完成网关定制。使用方式上 Spring Cloud 略胜一筹。

微服务架构组成以及注意事项

1. 架构分解

   • 网关集群：数据的聚合，实现对接入客户端的身份认证，防报文重放与数据篡改，功能调用的业务鉴权，响应数据的脱敏，流量与并发控制等
   • 业务集群：一般情况下移动端访问和浏览器访问的网关需要隔离，防止业务的耦合。
   • local cache：由于客户端访问业务可能需要调用多个服务聚合，所以本地缓存有效的降低了服务调用的频次，同时也提示了访问的速度。本地缓存一般使用自动过期方式，业务场景中运行有一定的数据延时。
   • 服务层：原子服务层，实现基础的增删改查功能，如果需要依赖其他服务需要在service层主动调用
   • Remote Cache：访问DB前置一层分布式缓存，减少DB交互次数，提示系统的TPS
   • DAL：数据访问层，如果单表数据量过大则需要通过DAL层做数据的分库分表处理。
   • MQ：消息队列用户解耦服务之间的依赖，异步调用可以通过MQ的方式来执行。
   • 数据库主从：服务化过程中必经的阶段，用来提升系统的TPS

2. 注意事项

• 服务启动方法建议使用jar方式启动，启动速度快，更容易监控。
• 缓存，缓存，缓存，系统中能使用缓存的地方尽量使用缓存，通过合理的使用缓存可以有效的提供系统的TPS
• 服务的拆分要合理，尽量避免引服务拆分而导致的服务依赖循环
• 合理的设置线程池，避免设置过大或过小导致系统异常。