一文读懂-自定义苍穹初始化启动服务

本篇文章从苍穹的开放性来角度来讲解其中的一点，就是启动服务的开放性。有时我们需要在苍穹服务启动的同时，加入一些自定义的服务，以便完成一些服务的注册与运行。例如：1688商城的消息订阅功能。

此功能是苍穹要与1688商城进行系统集成，集成其实就是数据的相互传输与同步。

1688商城的系统完整性相对强一些，包括接收数据和传递数据都有了固定的方案，只需要按照他的要求做即可。

向1688商城传递数据是比较常规的，只需要调用他们对应的api即可；但1688商城向苍穹传递数据时，需要在苍穹服务中，注册一个消费者，也就是客户端，用于接收1688商城传输的数据。

那么上面说的这种场景下该如何做呢？你是否遇到过类似的应用场景？那么此篇文章将会帮到你。

1.   从方案来讲，要在苍穹服务启动的时候注册对应的服务进去，随苍穹服务的启动起来即可。

2.   之后按照1688商城给的客户端消费者注册的例子，写在对应的服务中即可。

苍穹这边有两种方案：系统级别的启动服务，应用级别的启动服务。

         按照例子来说，我们选用应用级别的启动服务就可以解决问题。但是我会将两种方案都讲解一下，以便后面遇到其他场景时，随机应变选择性使用。

方案一

         Appstarter应用级启动服务。

配置过程已经有相关文章介绍，可参考文章：

https://club.kdcloud.com/article/115404082885460480

         这边讲一下原理与配置细节。

原理：苍穹服务启动的时候一共有16个服务，其中一个是AppStarterService服务，如图：

所以只需要写一个类，实现接口kd.bos.framework.lifecycle.appstart.AppStarter，并添加上配置文件即可，

1.   客户自定义的starter类实现接口，demo如图：

2.   在MC中增加配置项：appstarter.config ，内容为appid和对应的appstarter的实现类的键值对，多个以逗号分开，示例如图：

注：图中的kdby_case是应用标识，表示，服务分应用启动时，会在匹配的节点上启动该自定义启动服务。

         由此可以了解该方案是应用级的。

方案二

         Service系统级启动服务。

         上面有讲系统在启动时会启动16个服务，那么此方案就是添加一个同级别的服务即系统级服务。

原理如图：

所以我们只要在适当时机介入即可：

1.   客户自定义Service类实现接口kd.bos.framework.lifecycle.Service，demo如图：

2.   在MC中增加配置项：bos.lifecycle.servicelist，内容为的实现类，多个用换行分开，示例如图：

总结

1.   有几种自定义启动服务方式？

        有2种：

        1)   实现serivce接口，在配置参数bos.lifecycle.servicelist中，增加配置

        2)   实现AppStarter接口，在配置参数appstarter.config中，增加配置

2.   实现Service接口与实现AppStarter接口的两种自定义启动服务有什么区别？

         影响范围不同：

        1)   Service为 所有的mservice 微服务节点

        2)   AppStarter 影响范围为启动服务节点中匹配的应用

写在最后

         本节一文读懂，通过demo示例，将两种启动服务的原理和配置方式逐步进行讲解，后续应用过程中有任何疑问和建议，欢迎大家留言、讨论，本人也将第一时间进行回复。