摘要由AI智能服务提供本文讨论了苍穹平台服务启动的开放性，特别是在需要集成外部服务（如1688商城消息订阅）时，介绍了如何在苍穹服务启动时注册并运行自定义服务。文章提供了两种方案：应用级启动服务（AppStarter）和系统级启动服务（Service），详细说明了每种方案的原理、配置步骤及实现方式，并通过示例和图解进行说明，旨在帮助读者理解和应用这些服务启动方案。
本篇文章从苍穹的开放性来角度来讲解其中的一点，就是启动服务的开放性。有时我们需要在苍穹服务启动的同时，加入一些自定义的服务，以便完成一些服务的注册与运行。例如：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示例，将两种启动服务的原理和配置方式逐步进行讲解，后续应用过程中有任何疑问和建议，欢迎大家留言、讨论，本人也将第一时间进行回复。
