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社区

线上