上图是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社区线上
关注微信公众号获取信息；加入微信群进行交流；通过邮件列表参不讨论；通过Github发起PR。
线下
有兴趣的还可以参加我们的月度Meetup，以及不定期沙龙探讨。