微服务SOADubbo 和 Spring Cloud

Posted 程序员创业记

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了微服务SOADubbo 和 Spring Cloud相关的知识，希望对你有一定的参考价值。

什么是微服务

  • 微服务的概念源于 2014 年 3 月 Martin Fowler 所写的一篇文章 Microservices。

  • 微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。

  • 每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通(通常是基于 HTTP 的 RESTful API)。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。

  • 应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

  • 系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个任务代表着一个小的业务能力。

微服务的优势

  1. 复杂度可控：每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。将应用分解的同时，规避了原本复杂度无止境的积累。

  2. 独立部署：微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，
    使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。

  3. 技术选型灵活：微服务架构下，技术选型是去中心化的；完全重构一个微服务也是可行的。

  4. 容错：当某一组件发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用；在微服务架构下，故障会被隔离在单个服务中。
    若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。

  5. 扩展：每个服务可以根据实际需求独立进行扩展。

微服务 vs SOA

  • 某些领域 “专家” 比较多，因为这些领域比较神秘，如玄学，云计算、大数据等。SOA 曾经就是重灾区，言必称SOA，云里雾里说的全是高（假）大上（空）。微服务经常被误认成SOA 。
    其实，这两者有很大的区别。SOA的重要标签，ESB、WS- , 这些微服务全没有。 SOA是一个一直在希望变灵活的胖子。

架构方式 微服务 SOA
架构思想 智能终端，哑管道 智能管道，哑终端
聚合方式 能拆就拆 能放一起就放一起
拆分方式 纵向按业务切分 水平分多层
技术组织 单一组织负责 按层级划分不同部门的组织负责
粒度 细粒度 粗粒度
复杂度 两句话可以解释清楚 几百个字只是目录
业务组织 独立的子公司 划分为很多个BU
组件 组件小 复杂的组件
业务逻辑 业务逻辑在每一个服务中 业务逻辑横跨多个业务领域
通信方式 轻量级通讯方式如HTTP ESB充当服务间通信的角色

RPC vs Rest

  • Unix 中，文本流之于工具，就如同面向对象中消息之于对象，文本流的简洁性加强了工具的封装性。
    许多精致的进程间通讯方法，比如远程调用，都存在牵扯过多各程序间内部状态的倾向。 （摘自：《Unix编程艺术》P15）

Dubbo

  • Dubbo 是阿里巴巴开发的一个非常优秀的服务治理框架，在服务治理、灰度发布、流量分发这方面做的非常好，由于阿里巴巴的影响力，该框架被广泛应用于中国各互联网公司

  • Dubbo 刚出来的那会技术理念是非常先进的，解决了各大互联网公司服务治理的问题，各中小公司也从中受益不少。

  • 但是，经过了这么多年的发展，互联网行业也是涌现了更多先进的技术和理念，尤其是微服务的概念出现。

  • 虽然 Dubbo 架构相较于单体架构有模块化解耦、可独立部署、技术多样性等诸多优点，但是由于分布式环境下解耦还不是非常彻底，带出了不少测试与运维复杂度。

  • 比如 Dubbo的服务调用是通过RPC实现的，如果仔细拜读过Martin Fowler的 microservices一文，其定义的服务间通信是HTTP协议的REST API。那么这两种有何区别呢？

  • 先来说说，使用 Dubbo 的 RPC 来实现服务间调用的一些 痛点：

    • 调用方应用对微服务提供的抽象接口存在强依赖关系，这样的依赖关系会成为开发团队的一大噩梦。而REST接口相比RPC更为轻量化，服务提供方和调用方的依赖是协议级的。

    • 服务对平台敏感，难以简单复用，在Dubbo中我们要提供REST接口时，不得不实现一层代理，用来将RPC接口转换成REST接口进行对外发布，相信这些痛点也是为什么当当网在dubboX中增加了对REST支持的原因之一。

    • Dubbo实现了服务治理的基础，但是要完成一个完备的微服务架构，还需要在各环节去扩展和完善以保证集群的健康，以减轻开发、测试以及运维各个环节上增加出来的压力，这样才能让各环节人员真正的专注于业务逻辑。

Dubbo vs Spring Cloud

功能  Dubbo Spring Cloud XXX公司
服务注册中心 Zookeeper Spring Cloud Netflix Eureka Zookeeper
服务调用方式 RPC REST API REST API
服务网关 无 Spring Cloud Netflix Zuul nginx（运维） ，FeServer （大前端）
REST 支持 dubboX（当当 ） Spring Boot jersey （jersey-support）
断路器 不完善 Spring Cloud Netflix Hystrix Service Fallback （开发中）
分布式配置 Diamond（淘宝） Spring Cloud Config NolyConf （配置中心）
服务跟踪 EagleEye（淘宝） Zipkin（Twitter） Spring Cloud Sleuth 跟踪：ELK 
监控：Foresight
消息总线 无 Spring Cloud Bus RocketMQ（Nono-MQ）
数据流 无 Spring Cloud Stream Spark Streaming（大数据团队猎豹平台）
批量任务 TBSchedule（淘宝 ） Spring Cloud Task TBSchedule

Dubbo 中文文档
Spring Cloud 中文文档

从两个公司的背景来谈

  • 阿里巴巴是一个商业公司，虽然也开源了很多的顶级的项目，但从整体战略上来讲，仍然是服务于自身的业务为主。

  • Spring 专注于企业级开源框架的研发，不论是在中国还是在世界上使用都非常广泛，开发出通用、开源、稳健的开源框架是他们的主业。

从社区活跃度这个角度来对比

  • 在使用过程中出现问题，开发者提交到 GitHub 的 Issue 也少有回复。相反 Spring Cloud 自从发展到现在，仍然在不断的高速发展。

  • 从 GitHub 上提交代码的频度和发布版本的时间间隔就可以看出，现在 Spring Cloud 即将发布 2.0 版本，到了后期会更加完善和稳定。

  • spring cloud 中文文档 已经非常完善

  • 大家可以看看上面一些项目在 github 上的最后更新时间

从整个大的平台架构来讲

  • Dubbo 框架只是专注于服务之间的治理，如果我们需要使用配置中心、分布式跟踪这些内容都需要自己去集成，这样无形中增加了使用 Dubbo 的难度。

  • Spring Cloud 几乎考虑了服务治理的方方面面，更有 Spring Boot 这个大将的支持，开发起来非常的便利和简单。

从技术发展的角度来讲

  • Dubbo 刚出来的那会技术理念还是非常先进，经过了这么多年的发展，互联网行业也是涌现了更多先进的技术和理念，Dubbo 一直停滞不前。

  • 我们现在访问 Spring 官网，会发现 Spring Boot 和 Spring Cloud 已经放到首页最重点突出的三个项目中的前两个，可见 Spring 对这两个框架的重视程度。

Spring Cloud 的核心功能

  • 分布式/版本化配置

  • 服务注册和发现

  • 路由

  • 服务和服务之间的调用

  • 负载均衡

  • 断路器

  • 分布式消息传递

Spring Cloud 组件架构

  • 所有请求都统一通过 API 网关(Zuul)来访问内部服务。

  • 网关接收到请求后，从注册中心(Eureka)获取可用服务。

  • 由 Ribbon 进行均衡负载后，分发到后端的具体实例。

  • 微服务之间通过 Feign 进行通信处理业务。

  • Hystrix 负责处理服务超时熔断。

  • Turbine 监控服务间的调用和熔断相关指标。

Spring Cloud 工具框架：

  • Spring Cloud Config，配置中心，利用 git 集中管理程序的配置。

  • Spring Cloud Netflix，集成众多 Netflix 的开源软件。

  • Spring Cloud Bus，消息总线，利用分布式消息将服务和服务实例连接在一起，用于在一个集群中传播状态的变化 。

  • Spring Cloud for Cloud Foundry，利用 Pivotal Cloudfoundry 集成你的应用程序。

  • Spring Cloud Foundry Service Broker，为建立管理云托管服务的服务代理提供了一个起点。

  • Spring Cloud Cluster，基于 Zookeeper、Redis、Hazelcast、Consul 实现的领导选举和平民状态模式的抽象和实现。

  • Spring Cloud Consul，基于 Hashicorp Consul 实现的服务发现和配置管理。

  • Spring Cloud Security，在 Zuul 代理中为 OAuth2 rest 客户端和认证头转发提供负载均衡。

  • Spring Cloud Sleuth Spring Cloud，应用的分布式追踪系统和 Zipkin、HTrace、ELK 兼容。

  • Spring Cloud Data Flow，一个云本地程序和操作模型，组成数据微服务在一个结构化的平台上。

  • Spring Cloud Stream，基于 Redis、Rabbit、Kafka 实现的消息微服务，简单声明模型用以在 Spring Cloud 应用中收发消息。

  • Spring Cloud Stream App Starters，基于 Spring Boot 为外部系统提供 Spring 的集成。

  • Spring Cloud Task，短生命周期的微服务，为 Spring Boot 应用简单声明添加功能和非功能特性。

  • Spring Cloud Task App Starters。

  • Spring Cloud Zookeeper，服务发现和配置管理基于 Apache Zookeeper。

  • Spring Cloud for Amazon Web Services，快速和亚马逊网络服务集成。

  • Spring Cloud Connectors，便于 PaaS 应用在各种平台上连接到后端像数据库和消息经纪服务。

  • Spring Cloud Starters，项目已经终止并且在 Angel.SR2 后的版本和其他项目合并。

  • Spring Cloud CLI，插件用 Groovy 快速的创建 Spring Cloud 组件应用。

如何进行微服务架构演进

  • 当我们将所有的新业务都使用 Spring Cloud 这套架构之后，就会出现这样一个现象：公司的系统被分成了两部分，一部分是传统架构的项目;另一部分是微服务架构的项目，如何让这两套配合起来使用就成为了关键。

  • 这时候 Spring Cloud 里面的一个关键组件解决了我们的问题，就是 Zuul。在 Spring Cloud 架构体系内的所有微服务都通过 Zuul 来对外提供统一的访问入口，所有需要和微服务架构内部服务进行通讯的请求都走统一网关。

  • 随着近几年微服务架构和 Docker 容器概念的火爆，也会让 Spring Cloud 在未来越来越“云”化的软件开发风格中立有一席之地。


以上是关于微服务SOADubbo 和 Spring Cloud的主要内容，如果未能解决你的问题，请参考以下文章

云原生的方式：DevOpsMicroservices和Kubernetes

基于consul的服务注册(含踩坑过程)

Spring Cloud：构建微服务 - Spring Boot

在五分钟内创建，运行和部署Spring微服务

使用 Spring Boot 和 Spring Cloud 的微服务项目结构

Dubbo和Spring Cloud微服务架构‘