ServiceComb 设计揭秘:标准与开放

内容来源:2017年12月7日,华为开源项目ServiceComb开发工程师刘姗姗在“ServiceComb在线直播”进行《ServiceComb设计揭秘:标准与开放》演讲分享。IT 大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。

阅读字数:1125 | 4分钟阅读

摘要

本次演讲主要是分享ServiceComb对标准与开放的追求。

ServiceComb开发框架

上图是ServiceComb的开发框架。编程模型目前支持jaxrs、pojo、springmvc。运行模型其实就是handlers的组成。通信模型目前是支持restful和highway。最底下的服务契约就是服务接口定义文件,目前我们的服务契约可支持OpenAPI,也就是说它和具体的编程语言是解耦的。

基本概念

SchemaMeta

服务接口定义元数据(服务契约):一个微服务可以拥有多个schema文件,在同一个微服务当中每个schema文件都有唯一Schema-Id与之对应。

MicroService

微服务元数据:包括应用名、微服务名称、微服务Id、版本、描述、Schema信息等。

MicroServiceInstance

微服务实例:一个独立的拥有自IP端口的微服务实例(通常为进程),与service id的关系为n:1,即Service ID可以拥有多个微服务实例。

上图是ServiceComb系统的模块图。这里的模块主要是以代码模块为主。

Foundation是框架的基础,包括配置管理、通信以及通信相关等。

上面是common模块,它放置了一些公共组件的功能。比如处理字节码、处理protobuf的编码以及协议相关。

Swagger主要是处理服务契约相关。这里又包含了两个部分,generator和invocation。Generator负责接口定义相关,而invocation处理调用相关。

CSECore模块是微服务框架核心功能的抽象接口。在上面的部分主要有三个内容,编程模型包括consumer和producer的部分,运行模型就是handle的部分,第三个就是通信模型transport部分。

再往上就是针对这几块的具体实现。比如consumer的编程模型包括了springMVC和透明RPC。Produce包含了springMVC、jaxrs和透明RPC三种方式。Handle支持多个实现,目前我们已经实现的有打点的模块、限流、负载均衡。Transport部分支持了highway和restful,restful还可细分为基于vertx的restful和基于servlet的restful。

除了这些之外还有一个registry模块,它主要是负责与注册中心进行交互。

整个ServiceComb框架也可以做一个starters,与springboot进行集成。

框架的启动与停止主要是看三个java文件。第一个是处理日志系统的参考类log4jUtils,日志系统初始化功能。日志支持对接log4j/log4j2/logback,大家只要按照标准实现对接slf4j即可,可以不使用框架提供的log4jUtils。第二个是BeanUtils文件,负责spring的拉起,这个类也是提供的参考类。第三个是负责核心功能初始化的CseAppllcationListener,该类是启动的核心类。

服务消费端

当业务代码发起一次调用的时候,到达框架层之后会根据微服务调用的请求构造出一个请求的元数据,然后这个请求元数据会通过消费端所有的handlers。被消费端所有的handlers处理完之后,它会来到协议层进行编码传输。

服务提供端

经过以上这三步核心的动作之后,请求就从消费端发出,来到了服务提供端。

服务提供端首先会对请求进行解码,解码之后会生成请求的元数据,请求元数据又会被生产端的handlers进行一步步的处理。全部处理完成后,就由框架进行业务代码的映射。最终这个请求就会映射到业务代码当中进行处理。

如何参与到ServiceComb社区

线上

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20171221A0VAH000?refer=cp_1026

同媒体快讯

相关快讯

扫码关注云+社区