前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >ServiceComb综述及Java Chassis

ServiceComb综述及Java Chassis

作者头像
IT大咖说
发布2019-09-04 15:36:20
1.9K0
发布2019-09-04 15:36:20
举报
文章被收录于专栏:IT大咖说IT大咖说

1.1 ServiceComb综述

1.1.1 什么是ServiceComb

ServiceComb是华为云PaaS部门在2017年开源的微服务开发框架,它提供了Java和Go语言的微服务开发框架、微服务注册中心,还提供了基于Sagas的数据一致性实现的ServiceComb Saga。

ServiceComb微服务开发框架和注册中心已经在华为内部多个系统中广泛应用。同时,作为第一个进入Apache基金会做微服务框架项目,ServiceComb期望有更多的用户使用和参与到项目中,为传统企业的微服务化转型贡献力量。读者可以在本书资源列表中找到ServiceComb的主页,相关代码库以及文档。

ServiceComb目前已经开源的项目包括:

  • Java Chassis SDK Java微服务开发框架。
  • Go Chassis SDK Go微服务开发框架。
  • ServiceCenter注册中心。
  • Saga数据一致性解决方案。

ServiceComb后续会开源更多的项目,包括Service Mesh的工具Mesher等。

Chassis(中文为底盘的意思)是由Chris Richardson提出的一种微服务模式。它强调用户并不需要自己去处理构建微服务过程中外部配置、日志、健康检查、分布式追踪等横切关注点(Crosscutting Concern),而是通过专门的框架来处理。从而可以更聚焦于业务逻辑本身,简单、快速地开发微服务。

1.1.2 为什么选择ServiceComb

“造轮子”对于开发人员个人而言可能是磨练技术的好机会,但是对于公司而言却是耗时耗力,是吃力不讨好的事情。那么为什么ServiceComb团队要开发新的微服务开发框架,而不是直接使用现有的微服务开发框架呢?

随着微服务架构的不断发展,微服务开发框架也一直在不断演进,以现代企业微服务架构的需求去重新审视一些老牌的微服务开发框架,比如Spring Cloud和Dubbo,会发现其存在一些局限性:

  • Spring Cloud过于厚重,使用旧版本的Spring的代码迁移成本较高。
  • Spring Cloud前几个版本只支持基于Servelet的REST通信方式,无法满足业务需求。
  • 基于Dubbo开发,限定了语言(Java)、协议(RPC),限制了微服务技术的异构性。
  • 大部分框架并不支持高级的微服务治理功能,比如灰度发布等。

注:当当网的开发人员基于Dubbo改造出了DubboX,支持REST,而Dubbo在沉寂多时后,也重新开始维护。不过Dubbo 3.0和旧版并不能有效地兼容。

所以从性能、可维护性、可移植性、微服务治理的功能等纬度出发,ServiceComb团队选择自研微服务开发框架。当然也不是一切重头开始,他们重用了开源项目中优秀的组件,比如Netflix OSS、Netty等。同时,重新设计了注册中心,并且实现了基于Saga的分布式事务解决方案Sagas。

此外,对于某些特定领域的系统,需要运行在资源受限的环境中,基于JVM的某些框架无法满足。而Golang对与资源、性能和开发效率的兼顾,除了可以开发高性能的服务,也便于移植原来基于C语言的系统。这也是ServiceComb开发了Go Chassis SDK的原因。了解了ServiceComb团队造轮子背后的原因,接下来进入正题,揭开ServiceComb神秘的面纱。

1.1.3 ServiceComb Java Chassis框架

ServiceComb Java Chassis框架架构,如图1-1所示。

图1-1 ServiceComb Java Chassis框架架构

就微服务开发框架而言,ServiceComb Java Chassis提供了其他微服务开发框架,诸如服务注册发现、REST和高性能RPC通信、服务治理的常见功能。除此之外,还具备以下五方面的特点。

  • 分层解耦:如图1-1所示,整个框架分为编程模型、运行模型、通信模型,业务层只关心编程模型和契约定义,而运行模型、通信模型对业务透明。这样通过对统一契约的加持,可以做到在通信模型变化的时候,代码可以零改动,只需通过简单的配置即可,同时各个层都可分别扩展。
  • 内置API-First支持:框架内部使用OpenAPI(Swagger)作为统一的契约描述方式,微服务开发时需使用契约描述的接口进行通信。对于不习惯先进行契约开发的用户,同时提供Code-First的开发模式,先写接口代码,微服务在启动时框架会自动生成契约并保存在服务管理中心。
  • 多种开发方式:ServiceComb支持用户以SpringMVC、JAX-RS或透明RPC的方式开发微服务,可以进一步降低使用和学习的门槛。
  • 开放性:支持Spring Boot和Spring Cloud,可以在Spring Boot上使用ServiceComb的组件,和其他Spring Cloud的相关组件一起工作。
  • 高性能:整个框架内部全部采用reactive方式实现,内部处理全程无阻塞点,大幅提升处理性能。同时对外提供同步的开发接口,方便上层业务逻辑地开发。

对比当前流行的微服务开放框架Spring Cloud,ServiceComb提供了集成度更高的封装,以及更容易的开发门槛。用户不必像Spring Cloud那样对运行中所需要的组件一个个集成。另外,如果用户希望同Spring Boot和Spring Cloud组件一起使用,也可以直接以Starter的方式引用ServiceComb的能力。

1.1.4 Go Chassis框架

除了Java SDK外,ServiceComb还提供了Go SDK-Go Chassis。Go Chassis是快速实现微服务的Go语言开发框架,作为微服务开发框架,提供服务之间轻量级的通信机制是框架基本功能。Go Chassis默认支持RESTful和RPC两种通信方式,支持JSON和Protobuf两种序列化方式,支持配置TLS证书。除此之外,和Java Chassis类似,Go Chassis也提供了服务注册发现、动态配置、服务治理、监控日志数据上报等功能。

  • 通信协议:可配置自己的协议,默认支持RESTful和RPC,序列化方式支持JSON和Protobuf。
  • 服务注册发现:该插件化模块用于实现服务注册发现,目前支持对接ServiceCenter或文件系统。
  • 热更新:支持对接Config Center实现动态配置,可运行时更改负载均衡、熔断、容错、限流等策略。
  • 处理链:提供了在服务端和客户端服务调用时加载处理模块的机制。
  • 负载均衡:默认提供RoundRobin,会话黏滞策略。另外提供Filter过滤服务实例。
  • 熔断:运行时监控维护每个执行过程的状态和结果,达到一定阈值时触发熔断机制并降级,保护服务提供者不会出现级联式的雪崩错误。
  • 限流:提供Server端和Client端的限流,支持通过配置来限制每秒允许多少请求发出或接受。
  • 认证:支持配置TLS证书或AKSK。
  • 监控:默认情况,prometheus收集监控的API,也支持主动上报到CSE DashBoard。
  • 日志:支持写文件和标准输出,可自行配置日志writer上报日志。
  • 追踪:支持对接Zipkin上报tracing数据。

1.1.5 注册中心ServiceCenter

注册中心是微服务系统中非常重要的组件,主要用于解决微服务的注册发现的动态路由问题。市面上可以用作注册中心的工具也有很多,比如Zookeeper、Consul、Eureka、ETCD等。然而在一个大型的微服务系统中,除了这些动态路由信息外,还需要管理微服务自身的元数据。因此,服务管理中心需要包含微服务静态元数据定义的功能。并通过其提供的接口可以很方便地检索微服务信息。这样的需求是现有的注册中心无法满足的。

所以,ServiceComb团队重新开发了注册中心,并称之为ServiceCenter。ServiceCenter是一个具有微服务实例注册/发现能力的微服务组件,它提供一套标准的RESTful API对微服务元数据进行管理。ServiceComb的微服务注册及动态发现能力也是依赖其实现的。ServiceCenter基于Go语言实现,其后端存储使用了ETCD。为了方便使用,ServiceCenter还提供了Web界面,可视化的去管理和查询在注册中心上登记的微服务、接口信息。

微服务元数据包含哪些内容?除了微服务本身信息属于静态元数据外,ServiceCenter还扩展了微服务依赖关系、黑白名单、Tag标签和契约信息等元数据。这些微服务元数据不仅把实例信息分组管理起来,同时也满足了用户对微服务管理的需要。比如微服务的黑白名单,而业界的服务注册中心大多仅实现了consumer服务依赖的服务实例发现,但没法对一些安全要求高的服务设置白名单访问控制,ServiceCenter支持给这类provider服务设置黑白名单过滤规则,防止恶意服务并发现DDoS攻击。

除了以上描述的微服务动态发现外,ServiceCenter还具有以下特性:

  • 支持逻辑多租的微服务实例隔离管理。
  • 支持微服务黑白名单管理。
  • 支持长连接监听微服务实例状态变化。
  • 支持Open API规范微服务契约管理。
  • 支持微服务依赖关系管理。
  • 提供Web portal展示微服务管理界面。
  • 高可用的故障处理模型(自我保护机制)。
  • 高性能接口和缓存数据设计。

1.1.6 数据一致性框架Saga

通常微服务的分布式特性,决定了在对事务处理时,不能像过去单体应用下,在单个RDMS内去完成事务。在“3.1.6数据一致性”小节中介绍了数据一致性的解决方案,如2PC、3PC、TCC和Saga。并介绍了Saga相比2PC和TCC的好处,即比2PC 提交更易扩展,对于事务可补偿的应用,Saga相比TCC几乎不需要改动业务逻辑,性能更好。同时,集中式的Saga设计解耦了服务与数据一致性逻辑及其持久化设施,并使排查事务中的问题更容易被解决。

ServiceComb团队基于Saga,使用实现了数据一致性解决方案Saga,在“7.5 数据一致性框架Saga”小节中将解释了Saga的架构以及处理机制。本节简要的介绍了ServiceComb各个组件的特性,接下来的章节将逐一详解每个组件的原理。

1.2 Java Chassis

从7.1节中关于ServiceComb介绍不难看出,ServiceComb的设计理念在于一方面连接组织和开发人员,另一方面连接异构系统。组织和开发人员的复杂性来源于技能的多样性,大家使用不同的开发语言,即便是相同的开发语言也会存在多个开发方式,多种通信协议。

在连接组织和开发人员方面,ServiceComb有Java和Go微服务SDK,并且Java SDK支持三种开发方式,同时通过中立的机制——统一标准的契约来促进团队之间的高效沟通,通过支持Open API规范使得跨语言、跨开发方式的设计都能真正落地。在连接异构系统方面,ServiceComb重构了REST底层通信实现,使用基于Netty的异步框架重新实现,性能强大,而基于RPC的Highway的性能要更好。通信协议和业务代码的解耦,也满足了新旧系统兼容的通信场景。

Java Chassis系统模块和代码结构

Java Chassis提供了灵活的编程、通信以及运行模型,在实际的项目中,用户可以按照需求通过模块化的形式引入自己需要的组件,如下表所示,任意选择RPC/ SpringMVC/JAX-RS的编程模型,以及REST或者Highway的通信模型,对于运行模型,根据自己的需求,选择引入负载均衡模块、微服务治理及调用链。

类型

artifact id

是否可选

功能说明

编程模型

provider-pojo

提供RPC开发模式

编程模型

provider-jaxrs

提供JAX RS开发模式

编程模型

providerspringmvc

提供Spring MVC开发模式

通信模型

transport-restvertx

运行于HTTP之上的开发框架,不依赖WEB容器,应用打包为可执行jar

通信模型

transport-restservlet

运行于WEB容器的开发框架,应用打包为war包

通信模型

transport-highway

提供高性能的私有通信协议,仅用于Java之间互通

运行模型

handlerloadbalance

负载均衡模块。提供各种路由策略和配置方法。一般客户端使用

运行模型

handler-bizkeeper

和服务治理相关的功能,比如隔离、熔断、容错

运行模型

handler-tracing

调用链跟踪模块、对接监控系统、吐出打点数据

如图所示,Java Chassis核心代码大概分为7个模块。

  • Foundation:基础模块,包括公共、配置、通信、认证、运维等。
  • Common:通用模块,包括传输编解码、字节码处理等。
  • Swagger:服务契约模块基于Swagger进行开发,一部分处理接口与代码映射;另一部分处理运行时调用。目前通过对OpenAPI的支持,可以和具体实现语言解耦。
  • ServiceComb Core:核心模块,包括通信协议、运行模型、编程模型等接口抽象。
  • Implementation:ServiceComb Core模块的具体实现。Producer 编程模型对应的有SpringMVC、JAX RS、透明RPC实现;Consumer编程模型对应的有SpringMVC以及透明RPC。笔者认为这些编程模型并没有绝对的优劣之分,读者可按照个人习惯、团队风格进行选择。ServiceComb并不限定提供者和消费者的编程模型必须保持一致,例如使用透明RPC的方式来调用使用SpringMVC方式发布的接口。编程模型支持用户自己扩展,但以上几种开发方式已基本满足主流Java微服务的开发需求。

图1-2 ServiceComb代码模块图(注:图中Vertx即Vert.x)

Handler运行模型对应的调用跟踪、流控、负载均衡等实现,可自行扩展实现,并配置Handler链的顺序。Handler链就是一系列的invocation.next()调用过程,可以设计请求经过的代码逻辑,内置回调的过程。相比Servlet的Filter,Handler链具备更强的开发灵活性。

通信模型对应REST、Highway RPC两种协议,都是基于Vert.x开发的,Vert.x本身又是基于异步通信框架Netty。REST 协议使用JSON编解码,Highway协议使用Protobuf编解码。

  • Registry:处理与注册中心交互的功能的模块,包括服务的注册、发现、推送、更新、心跳的维护等。
  • SpringBoot Starters:Java Chassis支持与Spring Cloud进行集成,此模块负责将ServiceComb作为Spring Starter进行发布。

了解了Java Chassis的组件以及代码结构,读者可能迫不及待地想通过实例动手体验。推荐读者访问本书资源列表中提到的“ServiceComb Java Chassis BMI微服务案例”,通过体质指数微服务的开发来体验使用Java Chassis带来的好处,也可以直接阅读“10.1 使用Java Chassis实现商品服务”部分,跟随SockWorks的开发团队一起使用Java Chassis开发微服务。更多关于ServiceComb Java Chassis的内容,可以访问本书资源列表中的ServiceComb网站、博客、代码库等。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-08-30,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 IT大咖说 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
微服务引擎 TSE
微服务引擎(Tencent Cloud Service Engine)提供开箱即用的云上全场景微服务解决方案。支持开源增强的云原生注册配置中心(Zookeeper、Nacos 和 Apollo),北极星网格(腾讯自研并开源的 PolarisMesh)、云原生 API 网关(Kong)以及微服务应用托管的弹性微服务平台。微服务引擎完全兼容开源版本的使用方式,在功能、可用性和可运维性等多个方面进行增强。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档