Java 微服务框架选型（Dubbo 和 Spring Cloud？）

微服务（Microservices）是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。 系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件 任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

以往我们开发应用程序都是单体型（可以看作是一个怪兽?），虽然开发和部署比较方便， 但后期随着业务的不断增加，开发迭代和性能瓶颈等问题，将会困扰开发团队， 微服务就是解决此问题的有效手段，市面上有很多的微服务框架， 比如最著名的两个 Dubbo 和 Spring Cloud，我们该如何选择呢？

为什么 Dubbo 比 Spring Cloud 性能要高一些？

因为 Dubbo 采用单一长连接和 NIO 异步通讯（保持连接/轮询处理），使用自定义报文的 TCP 协议， 并且序列化使用定制 Hessian2 框架，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于 服务提供者机器数的情况，但不适用于传输大数据的服务调用。而 Spring Cloud 直接使用 HTTP 协议 （但也不是强绑定，也可以使用 RPC 库，或者采用 HTTP 2.0 + 长链接方式（Fegin 可以灵活设置））。

Martin Fowler 的 MicroServices 一文，其定义的服务间通信是 HTTP 协议的 REST API。

Dubbo 是一个分布式服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案， 以及 SOA 服务治理方案。简单的说，Dubbo 就是个服务框架，说白了就是个远程服务调用的分布式框架。

模块注解：

Provider: 暴露服务的服务提供方。

Consumer: 调用远程服务的服务消费方。

Registry: 服务注册与发现的注册中心。

Monitor: 统计服务的调用次调和调用时间的监控中心。

Container: 服务运行容器。  

流程详解：

0 服务容器负责启动，加载，运行服务提供者（Standalone 容器）。

1 服务提供者在启动时，向注册中心注册自己提供的服务（Zookeeper/Redis）。

2 服务消费者在启动时，向注册中心订阅自己所需的服务。

3 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用， 如果调用失败，再选另一台调用。

5 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心 （根据数据可以动态调整权重）。

 

Java开发微服务为什么一定要选spring cloud?

现如今微服务架构十分流行，而采用微服务构建系统也会带来更清晰的业务划分和可扩展性。 同时，支持微服务的技术栈也是多种多样的，本系列文章主要介绍这些技术中的翘楚——Spring Cloud。

1、为什么微服务架构需要Spring Cloud

简单来说，服务化的核心就是将传统的一站式应用根据业务拆分成一个一个的服务， 而微服务在这个基础上要更彻底地去耦合（不再共享DB、KV，去掉重量级ESB）， 并且强调DevOps和快速演化。

DevOps是英文Development和Operations的合体，他要求开发、测试、运维进行一体化的合作， 进行更小、更频繁、更自动化的应用发布，以及围绕应用架构来构建基础设施的架构。 这就要求应用充分的内聚，也方便运维和管理。这个理念与微服务理念不谋而合。

1.1 从使用nginx说起

最初的服务化解决方案是给提供相同服务提供一个统一的域名，然后服务调用者向这个域名发送HTTP请求， 由Nginx负责请求的分发和跳转。

这种架构存在很多问题：

Nginx作为中间层，在配置文件中耦合了服务调用的逻辑，这削弱了微服务的完整性， 也使得Nginx在一定程度上变成了一个重量级的ESB。

服务的信息分散在各个系统，无法统一管理和维护。每一次的服务调用都是一次尝试， 服务消费者并不知道有哪些实例在给他们提供服务。这不符合DevOps的理念。 无法直观的看到服务提供者和服务消费者当前的运行状况和通信频率。这也不符合DevOps的理念。 消费者的失败重发，负载均衡等都没有统一策略，这加大了开发每个服务的难度，不利于快速演化。

为了解决上面的问题，我们需要一个现成的中心组件对服务进行整合，将每个服务的信息汇总， 包括服务的组件名称、地址、数量等。服务的调用方在请求某项服务时首先通过中心组件 获取提供这项服务的实例的信息（IP、端口等），再通过默认或自定义的策略选择 该服务的某一提供者直接进行访问。所以，我们引入了Dubbo。

1.2 基于Dubbo实现微服务

Dubbo是阿里开源的一个SOA服务治理解决方案，文档丰富，在国内的使用度非常高。

使用Dubbo构建的微服务，已经可以比较好地解决上面提到的问题：

对于微服务架构而言，Dubbo也并不是十全十美的：

Registry严重依赖第三方组件（zookeeper或者redis），当这些组件出现问题时，服务调用很快就会中断。

DUBBO只支持RPC调用。使得服务提供方与调用方在代码上产生了强依赖，服务提供者需要不断 将包含公共代码的jar包打包出来供消费者使用。一旦打包出现问题，就会导致服务调用出错。

最为重要的是，DUBBO现在已经停止维护了，对于技术发展的新需求，需要由开发者自行拓展升级。

这对于很多想要采用微服务架构的中小软件组织，显然是不太合适的。

目前Github社区上有一个DUBBO的升级版，叫DUBBOX，提供了更高效的RPC序列化方式和REST调用方式。 但是该项目也基本停止维护了。

1.3 新的选择——Spring Cloud

Spring Cloud提出的口号是开发“面向云环境的应用程序”，它为微服务架构提供了更加全面的技术支持。

Spring Cloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。

Eureka相比于zookeeper，更加适合于服务发现的场景 Spring Cloud的功能比DUBBO更加强大，涵盖面更广，而且作为Spring的拳头项目， 它也能够与Spring Framework、Spring Boot、Spring Data、Spring Batch等 其他Spring项目完美融合，这些对于微服务而言是至关重要的。

更重要的是，相比于Dubbo，它是一个正在持续维护的、社区更加火热的开源项目， 这就保证使用它构建的系统，可以持续地得到开源力量的支持。

服务治理：这是Spring Cloud的核心。

目前Spring Cloud主要通过整合Netflix的相关产品 来实现这方面的功能（Spring Cloud Netflix），包括用于服务注册和发现的Eureka， 调用断路器Hystrix，调用端负载均衡Ribbon，Rest客户端Feign，智能服务路由Zuul。

分布式链路监控：Spring Cloud Sleuth提供了全自动、可配置的数据埋点， 以收集微服务调用链路上的性能数据，并发送给Zipkin进行存储、统计和展示。

消息组件：Spring Cloud Stream对于分布式消息的各种需求进行了抽象，包括发布订阅、分组消费、消息分片等功能， 实现了微服务之间的异步通信。Spring Cloud Stream也集成了第三方的RabbitMQ和Apache Kafka作为消息队列的实现。 而Spring Cloud Bus基于Spring Cloud Stream，主要提供了服务间的事件通信（比如刷新配置）。

安全控制：Spring Cloud Security基于OAUTH2这个开放网络的安全标准， 提供了微服务环境下的单点登录、资源授权、令牌管理等功能。

命令行工具：Spring Cloud Cli提供了以命令行和脚本的方式来管理微服务及Spring Cloud组件的方式。

集群工具：Spring Cloud Cluster提供了集群选主、分布式锁（暂未实现）、一次性令牌（暂未实现） 等分布式集群需要的技术组件。 

 

Java——微服务

1、什么是微服务？

微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分一组小的服务， 每个服务运行在其独立的自己的进程中，服务之间相互协调、互相配合，为用户提供最总价值。 服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）,每个服务都 围绕着具体的业务进行构建，并且能够被独立的构建在生产环境、类生产环境等。

2、SpringCloud和Dubbo有哪些区别？

最大区别：SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。

品牌机与组装机的区别：很明显SpringCloud比dubbo的功能更强大，覆盖面更广，而且 能够与SpringFramework、SpringBoot、SpringData、SpringBatch等其他Spring项目 完美融合，这些对于微服务至关重要。

使用Dubbo构建的微服务架构就像组装电脑、 各环节我们选择自由度高，但是最总可能会因为内存质量而影响整体，但对于高手这也就不是问题。

而SpringCloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试， 保证了机器拥有更高的稳定性。

3、SpringBoot和SpringCloud

1）、SpringBoot专注于快速方便的开发单个个体微服务。

2）、SpringCloud是关注全局的微服务协调、整理、治理的框架，它将SpringBoot开发的单体 整合并管理起来。

3）、SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot， 属于依赖关系。

4、什么是服务熔断？什么是服务降级？

熔断机制是应对雪崩效应的一种微服务链路保护机制。

某个微服务不可用或者响应时间太长时，会进行服务降级，进而熔断该节点微服务的调用， 快速返回“错误”的响应信息。检测到该节点微服务调用响应正常后恢复调用链路。

在SpringCloud框架里熔断机制通过Hystrix实现，Hystrix会监控微服务间调用的状况， 当失败的调用到一定阈值，缺省是5秒内调用20次，如果失败，就会启动熔断机制。 熔断机制的注解是@HystrixCommand 服务降级，一般是从整体负荷考虑。就是当某个服务熔断之后，服务器将不再被调用， 此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。这样做，虽然水平下降， 但好歹可用，比直接挂掉强。

5、微服务的优缺点

优点：

1）、每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求。

2）、开发简单，开发效率提高，一个服务可能就是专一的只干一件事。

3）、微服务能够被小团队开发，这个团队可以是2到5个开发人员组成。

4）、微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。

5）、微服务能使用不同的语言开发。

缺点：

1）、开发人员要处理分布式系统的复杂性。

2）、多服务运维难度，随着服务的增加，运维的压力也在增加。

3）、系统部署依赖。

4）、服务间通讯成本。

5）、数据一致性。

6）、系统集成测试。

微服务的技术栈（各项功能的实现所使用的技术）具体如下：

服务开发 SpringBoot、Spring、SpringMVC

服务注册与发现 Eureka、Zookeeper

服务调用 RPC、Rest

服务熔断器 Hystrix

负载均衡 Nginx、Ribbon

消息队列 Kafka、RabbitMQ、ActiveMQ等

服务路由（API网关） Zuul等

服务监控 Zabbix

服务部署 Docker、OpenStack、Kubernetes等

数据流操作开发包 SpringCloud Stream

事件消息总线 Spring Cloud Bus

6、Eureka和zookeeper的区别

Zookeeper保证了CP（C：一致性，P：分区容错性），Eureka保证了AP（A：高可用）

（1）当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的信息， 但不能容忍直接down掉不可用。也就是说，服务注册功能对高可用性要求比较高， 但zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新选leader。 问题在于，选取leader时间过长，30 ~ 120s，且选取期间zk集群都不可用，这样就会导致选取期间 注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事， 虽然服务能够恢复，但是漫长的选取时间导致的注册长期不可用是不能容忍的。

（2）Eureka保证了可用性，Eureka各个节点是平等的，几个节点挂掉不会影响正常节点的工作， 剩余的节点仍然可以提供注册和查询服务。而Eureka的客户端向某个Eureka注册或发现是发生连接失败， 则会自动切换到其他节点，只要有一台Eureka还在，就能保证注册服务可用，只是查到的信息可能 不是最新的。除此之外，Eureka还有自我保护机制，如果在15分钟内超过85%的节点没有正常的心跳， 那么Eureka就认为客户端与注册中心发生了网络故障，此时会出现以下几种情况：

• ①Eureka不在从注册列表中移除因为长时间没有收到心跳而应该过期的服务。
• ②Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点仍然可用）
• ③当网络稳定时，当前实例新的注册信息会被同步到其他节点。

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像Zookeeper那样使整个微服务瘫痪。

 

Java微服务架构

传统的整体式架构

传统的整体式架构都是模块化的设计逻辑，如展示（Views）、应用程序逻辑（Controller）、业务逻辑（Service）和数据访问对象（Dao），程序在编写完成后被打包部署为一个具体的应用。
 
系统的水平扩展
如果要对系统进行水平扩展，通常情况下，只需要增加服务器的数量，并将打包好的应用拷贝到不同的服务器，然后通过负载均衡器（Nginx）就可以轻松实现应用的水平扩展。
 
整体式架构的缺点
应用可靠性低。
不利于技术更新。
 
面向服务的架构SOA（Service-Oriented Architecture）
OA的思路是把应用中相近的功能聚合在一起，以服务的形式提供出去。
 
多数情况下，SOA中相互独立的服务仍然会部署在同一个运行环境中。和整体式架构类似，随着业务功能的增多，SOA的服务会变得越来越复杂。本质上看，整体式架构的问题并没有因为使用SOA而变得更好。

微服务架构

微服务架构是一种架构风格和架构思想，它倡导我们在传统软件应用架构的基础上，将系统业务按照功能拆分为更加细粒度的服务，所拆分的每一个服务都是一个独立的应用，这些应用对外提供公共的API，可以独立承担对外服务的职责，通过此种思想方式所开发的软件服务实体就是“微服务”，而围绕着微服务思想构建的一系列结构（包括开发、测试、部署等），我们可以将它称之为“微服务架构”。
 
缺点
开发人员必须处理创建分布式系统的复杂性。
部署的复杂性。 

如何构建微服务架构

微服务架构的组件
（1）服务注册中心：注册系统中所有服务的地方。
（2）服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。
（3）服务发现：服务调用方从服务注册中心找到自己需要调用服务的地址。
（4）负载均衡：服务提供方一般以多实例的形式提供服务，使用负载均衡能够让服务调用方连接到合适的服务节点。
（5）服务容错：通过断路器（也称熔断器）等一系列的服务保护机制，保证服务调用者在调用异常服务时能快速地返回结果，避免大量的同步等待。
（6）服务网关：也称为API网关，是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、负载限流等功能。
 
微服务架构的技术选型
（1）微服务实例的开发：SpringBoot
（2）服务的注册与发现：Spring Cloud Eureka
（3）负载均衡：Spring Cloud Ribbon
（4）服务容错：Spring Cloud Hystrix
（5）API网关：Spring Cloud Zuul
（6）分布式配置中心：Spring Cloud Config
（8）部署：Docker

 

---------------------
作者：Leon_Jinhai_Sun
来源：CSDN
原文：https://blog.csdn.net/Leon_Jinhai_Sun/article/details/87170708
版权声明：本文为作者原创文章，转载请附上博文链接！
内容解析By：CSDN,CNBLOG博客文章一键转载插件