[学习微服务] ServiceComb之Java-Chassis启动流程分析

最新推荐文章于 2024-05-13 14:21:17 发布

looook

最新推荐文章于 2024-05-13 14:21:17 发布

阅读量1.6k

点赞数

640?wx_fmt=gif

小蜜蜂又给大家来送干货喽~本篇我们将以官方示例项目pojo-provider来分析Java-Chassis的启动流程。

> > > >

项目网址：

https://github.com/apache/servicecomb-java-chassis/tree/master/samples/pojo-sample/pojo-provider

pojo-provider项目的启动类是PojoProviderMain

查看其代码↓↓↓

640?wx_fmt=png

如上所示，Log4jUtils.init是初始化日志服务。init方法代码如下，默认会从classpath*:config/base/log4j.properties和classpath*:config/log4j.properties两个路径读取log4j配置并合并。

640?wx_fmt=png BeanUtils.init对微服务进行初始化，init方法代码如下

640?wx_fmt=png

默认会从classpath*:META-INF/spring/*.bean.xml路径加载配置文件，并将其传递给Spring框架的ClassPathXmlApplicationContext完成应用上下文加载。

在Spring context加载完成后，通过Spring Framework开源的事件调用机制和反射机制来触发ServiceComb自己的初始化逻辑。类似于观察者模型。

首先我们知道Spring框架的AbstractApplicationContext中的refresh函数是用来加载和刷新spring配置文件。

查看其源码可知道执行了以下步骤：

将配置文件中定义的Spring Bean进行加载；
spring Bean进行注册；
初始化事件广播器；
注册Listener；
初始化其他模型（finishRefresh()）。

接着，在finishRefresh方法中通过publishEvent循环通知所有的观察者（ApplicationEvent的子类）的onApplicationEvent方法执行相应的操作，通过它我们可以定位到CseApplicationListener。

通过onApplicationEvent方法可以分析出以下步骤（绝大部分步骤发生在SCBEngine.doInit方法）：

首先读取配置文件信息cse.handler.xml （HandlerConfigUtils.init()）
然后进行Provider处理，主要是微服务元数据、Schema和契约的处理，并将其添加到RegistryUtils的微服务实例中；（producerProviderManager.init();）
接着启动一个异步无阻塞的网络框架vertx，并将初始化的EndPoint添加到RegistryUtils的微服务实例中；（transportManager.init();）
最后在RegistryUtils中实现微服务在服务管理中心的注册。（RegistryUtils.run();）

总结以上流程如下图

640?wx_fmt=png

在前面的流程分析中，CseApplicationListener类很关键，相当于Spring框架与ServiceComb的桥梁。在Spring初始化之后触发，初始化ServiceComb自身的配置。

CseApplicationListener最终触发SCBEngine.doInit方法，代码结构如下所示，triggerEvent是一种AOP机制。

640?wx_fmt=png

进一步，在HandlerConfigUtils中，可以看到处理链handler实例的初始化。首先获取了handler处理链的配置信息，然后根据这些配置初始化所有的handler实例。

640?wx_fmt=png

> > > >

那么它会从哪里获取配置呢？

源码如下，可以看到其会获取类路径下config/cse.handler.xml的文件。其实断点进去PaaSResourceUtils.getSortedResources方法可知还会获取类路径下config/cse.*.handler.xml文件。 640?wx_fmt=png 在ProducerProviderManager初始化中，我们可以得到微服务的元数据信息microserviceMeta，并把它添加到RegistryUtils中定义的微服务当中↓