CppMicroServices 微服务机制实现原理基于Modules/CppMicroServices/core/src/源码逐层分析一、定位与基础思想CppMicroServices 是 C 版的OSGi 微服务规范实现Apache License 2.0独立开源项目。核心思想模块 A 注册一个接口的实现 → 模块 B 只凭接口类型查询 → 双方零编译依赖与 CTK 插件框架完全无关——core/目录下没有任何#include ctk...引用可在纯命令行程序中独立运行。二、核心数据结构CoreModuleContext所有状态集中在一个全局单例CoreModuleContextusCoreModuleContext_p.hclassCoreModuleContext{public:ServiceListeners listeners;// 所有服务事件监听器ServiceRegistry services;// 所有已注册服务ServiceHooks serviceHooks;// 服务钩子过滤/拦截ModuleHooks moduleHooks;// 模块钩子};ModuleRegistry::coreModuleContext()是进程级静态单例US_GLOBAL_STATIC所有模块共享同一个CoreModuleContext——这是框架范围服务可见性的基础。三、模块生命周期从 .so 加载到服务注册1. 自动注册宏usModuleInitialization.h: L57每个参与微服务的动态库在源文件末尾放一行US_INITIALIZE_MODULE// 展开为一个文件作用域的静态对象宏展开后生成一个ModuleInitializer_XXX类的静态实例其构造函数在 .so 被 dlopen 时由 C 运行时自动调用// 宏展开核心逻辑usModuleInitialization.h: L57-120classModuleInitializer_XXX{public:ModuleInitializer_XXX(){// 1. 通过自身地址获取 .so 的磁盘路径moduleInfoPtr()-locationModuleUtils::GetLibraryPath(moduleInfoSym);// 2. 向全局 ModuleRegistry 注册ModuleRegistry::Register(moduleInfo());}~ModuleInitializer_XXX(){ModuleRegistry::UnRegister(moduleInfo());// .so 卸载时自动注销}};staticModuleInitializer_XXX _InitializeModule_XXX;// 文件作用域静态对象关键不需要任何显式调用——.so 加载即注册卸载即注销。2. ModuleRegistry::RegisterusModuleRegistry.cpp: L75// 全局模块表name → Module*US_UNORDERED_MAP_TYPEUS_GLOBAL_STATIC_WITH_DELETER(ModuleMap,modules,ModuleDeleter)US_GLOBAL_STATIC(Mutex,modulesLock)// 保护 modules 表voidModuleRegistry::Register(ModuleInfo*info){// 检查是否重载同 location name 的模块// 若是新模块new Module() → 分配自增 id → 插入 modules 表module-Init(coreModuleContext(),info);module-Start();// 触发 Activator::Load}3. Module::StartusModule.cpp: L119voidModule::Start(){d-moduleContextnewModuleContext(this-d);// 创建该模块的上下文句柄// 通过符号查找 Activator 工厂函数dlsym 等价std::string activator_func_us_module_activator_instance_d-info.name;void*activatorHookSymModuleUtils::GetSymbol(d-info,activator_func.c_str());// ...d-moduleActivatoractivatorHook();// 获取 Activator 实例d-moduleActivator-Load(d-moduleContext);// 回调 Activator::Load// 发出 LOADED 事件d-coreCtx-listeners.ModuleChanged(ModuleEvent(ModuleEvent::LOADED,this));}US_EXPORT_MODULE_ACTIVATOR(MyActivator)宏生成那个 C 符号函数使ModuleUtils::GetSymbol能找到它。4. Activator::Load —— 服务注册的入口// 典型 Activator如 mitkDisplayActionEventBroadcast.cpp: L48classMyActivator:publicModuleActivator{voidLoad(ModuleContext*ctx)override{// 在这里注册服务ctx-RegisterServiceIMyInterface(newMyImpl(),props);}voidUnload(ModuleContext*ctx)override{/* 服务自动注销 */}};四、服务注册ServiceRegistry核心数据结构usServiceRegistry_p.h: L63-80classServiceRegistry{mutableMutexType mutex;// 服务对象 → 它注册的接口名列表MapServiceClasses services;// unordered_mapServiceRegistration, vectorstring// 接口名 → 按 ranking 排序的服务注册列表最高 rank 在前MapClassServices classServices;// unordered_mapstring, vectorServiceRegistrationstd::vectorServiceRegistrationBaseserviceRegistrations;// 全量列表};RegisterService 流程usServiceRegistry.cpp: L87ServiceRegistrationBaseServiceRegistry::RegisterService(ModulePrivate*module,constInterfaceMapservice,constServicePropertiesproperties){// 1. 检查是否 ServiceFactory工厂模式按需创建实例boolisFactoryservice.count(org.cppmicroservices.factory)0;// 2. 收集接口名列表InterfaceMap 的 keystd::vectorstd::stringclasses;for(autoi:service)classes.push_back(i.first);// 3. 创建 ServiceRegistration含自增 SERVICE_ID、OBJECTCLASS、SERVICE_SCOPEServiceRegistrationBaseres(module,service,CreateServiceProperties(properties,classes,isFactory,...));// 4. 加锁写入两张表MutexLocklock(mutex);services.insert({res,classes});for(autocls:classes){autosclassServices[cls];s.insert(lower_bound(s,res),res);// 按 ranking 有序插入}// 5. 发出 REGISTERED 事件通知所有匹配的监听器ServiceEventregisteredEvent(ServiceEvent::REGISTERED,res.GetReference());module-coreCtx-listeners.GetMatchingServiceListeners(registeredEvent,listeners);module-coreCtx-listeners.ServiceChanged(listeners,registeredEvent);returnres;}五、服务查询ModuleContext → ServiceRegistry// ModuleContext::RegisterServiceusModuleContext.cpp: L78ServiceRegistrationUModuleContext::RegisterService(constInterfaceMapservice,constServicePropertiesproperties){returnd-module-coreCtx-services.RegisterService(d-module,service,properties);}// ModuleContext::GetServiceReferenceusModuleContext.cpp: L98ServiceReferenceUModuleContext::GetServiceReference(conststd::stringclazz){returnd-module-coreCtx-services.Get(d-module,clazz);}ServiceRegistry::GetusServiceRegistry.cpp: L167ServiceReferenceBaseServiceRegistry::Get(ModulePrivate*module,conststd::stringclazz)const{MutexLocklock(mutex);std::vectorServiceReferenceBasesrs;Get_unlocked(clazz,,module,srs);// 按接口名查 classServices 表if(!srs.empty())returnsrs.back();// 返回 ranking 最高的back 最高 rankreturnServiceReferenceBase();// 未找到返回空引用}支持LDAP 过滤器usLDAPExpr.cppGetServiceReferences(clazz, (keyvalue))可按属性过滤。六、服务事件与监听ServiceListeners注册服务时自动触发ServiceEvent::REGISTERED注销时触发ServiceEvent::UNREGISTERING。消费方可用ServiceTrackerusServiceTracker.h: L231自动跟踪// 典型用法如 QmitkAbstractView 中的 DataStorage 服务跟踪ServiceTrackerIMyInterfacetracker(context);tracker.Open();// 开始跟踪自动处理 Add/Remove/ModifyIMyInterface*svctracker.GetService();// 获取当前最高 rank 服务tracker.Close();ServiceTracker内部实现了ServiceTrackerCustomizer三个回调AddingService新服务出现时ModifiedService服务属性变更时RemovedService服务注销时七、模块卸载自动清理Module::StopusModule.cpp: L173→ModulePrivate::RemoveModuleResourcesusModulePrivate.cpp: L118voidModulePrivate::RemoveModuleResources(){coreCtx-listeners.RemoveAllListeners(moduleContext);// 移除所有监听器// 注销该模块注册的所有服务std::vectorServiceRegistrationBasesrs;coreCtx-services.GetRegisteredByModule(this,srs);for(autosr:srs)sr.Unregister();// 释放该模块使用的所有服务引用coreCtx-services.GetUsedByModule(q,srs);for(autosr:srs)sr.GetReference().d-UngetService(q,false);}模块卸载时无需手动清理——框架自动注销该模块的全部服务和监听器。八、完整流程时序图消费模块ServiceListenersServiceRegistryModuleActivatorModuleModuleRegistry 全局表ModuleInitializer 静态对象操作系统 dlopen消费模块ServiceListenersServiceRegistryModuleActivatorModuleModuleRegistry 全局表ModuleInitializer 静态对象操作系统 dlopen查询服务.so 卸载.so 加载 C静态初始化Register moduleInfonew Module InitStart 创建 ModuleContextGetSymbol activator_func dlsymactivatorHook 获取实例Load moduleContextRegisterService InterfaceMap properties写入 services 和 classServices 表 加锁ServiceChanged REGISTERED 事件通知 ServiceTracker AddingServiceGetServiceReference clazzclassServices 按接口名查找 返回最高 rankServiceReferenceGetService reference服务对象指针析构函数UnRegisterStopUnloadRemoveModuleResources 自动注销所有服务ServiceChanged UNREGISTERING 事件九、设计要点小结设计点实现方式零编译依赖消费方只#include接口头文件不#include实现头文件自动注册US_INITIALIZE_MODULE宏生成静态对象.so 加载即注册全局单例上下文US_GLOBAL_STATIC(CoreModuleContext)进程级唯一服务按 ranking 排序classServices中lower_bound有序插入Get返回back()线程安全ServiceRegistry::mutexMutexLock保护所有读写事件驱动注册/注销自动触发ServiceEventServiceTracker响应自动清理模块卸载时RemoveModuleResources自动注销服务和监听器LDAP 过滤GetServiceReferences(clazz, filter)支持属性表达式查询ServiceFactory注册时检测org.cppmicroservices.factorykey支持按需创建实例与 CTK 零关系core/目录无任何 CTK 头文件引用可脱离插件框架独立运行关键源码文件索引功能文件Modules/CppMicroServices/core/src/下关键行全局上下文module/usCoreModuleContext_p.h全文自动注册宏../include/usModuleInitialization.hL57-120模块注册表module/usModuleRegistry.cppL39-74数据结构L75Register模块生命周期module/usModule.cppL119StartL173Stop模块资源清理module/usModulePrivate.cppL118-146模块上下文 APImodule/usModuleContext.cppL78RegisterServiceL98GetServiceReference服务注册表结构service/usServiceRegistry_p.hL63-80服务注册实现service/usServiceRegistry.cppL87RegisterServiceL167GetLDAP 过滤器module/usLDAPExpr.cpp-服务跟踪器../include/usServiceTracker.hL231附录CTK 也提供微服务机制 —— 两套服务框架对比一、CTK 确实内置完整的微服务机制CTK 是 OSGi 规范的完整 C 实现服务机制是其插件框架的内置组成部分。MITK 中的实际用法源码实证注册服务ctkPluginContext::registerService// berryCTKPluginActivator.cpp:256registryServiceRegcontext-registerServiceIExtensionRegistry(registry);// berryWorkbenchPlugin.cpp:418context-registerServiceberry::IQtStyleManager(styleManager.data());跟踪/消费服务ctkServiceTracker// QmitkAbstractView.cpp:36,146#includectkServiceTracker.hctkServiceTrackermitk::IDataStorageService*m_DataStorageServiceTracker;二、CTK 服务 vs CppMicroServices 对比维度CTK 服务ctkPluginContextCppMicroServicesus::所在层Plugins 层BlueBerry/CTK 插件框架内Modules 层独立于插件框架生命周期绑定绑定到 CTK 插件的 Start/Stop绑定到动态库加载/卸载静态初始化注册 APIcontext-registerServiceT(impl)context-RegisterServiceT(impl)跟踪器ctkServiceTrackerTus::ServiceTrackerT依赖关系需要 CTK 插件框架运行零外部依赖命令行程序可用MITK 中用途框架级服务IExtensionRegistry、IDataStorageService、IQtStyleManager算法级服务IO 读写器、InteractionEventObserver、渲染服务三、是否可以统一为一套机制技术上可行但不建议——两套机制的存在是有意为之的分层设计。方案一全部换成 CTK 服务代价Modules 层必须引入 CTK 头文件打破算法层不依赖插件框架的分层原则CoreCmdApps纯命令行工具无法运行因为没有 CTK 插件框架每个 Module 都要变成 CTK 插件有 plugin.xml、有 Activator构建复杂度大幅上升结论破坏 MITK 最核心的设计原则——算法可脱离 GUI 复用。方案二全部换成 CppMicroServices代价CTK 插件的生命周期Start/Stop与us::模块的生命周期dlopen/dlclose不对齐——CTK 插件可以在 .so 已加载的情况下被 Stop此时us::服务仍然存在造成状态不一致IExtensionRegistry、IDataStorageService这类框架级服务需要在特定插件激活后才有意义用us::无法表达插件级的生命周期语义结论生命周期语义对不上框架级服务会出现服务存在但插件未激活的问题。正确结论两套分工是最优设计Modules 层 → us:: 服务 理由零依赖、命令行可用、生命周期 .so 生命周期 Plugins 层 → CTK 服务 理由生命周期 插件 Start/Stop、框架级服务语义清晰在 Plugins 层统一用 CTK 服务因为 Plugins 层本来就依赖 CTK同时保留 Modules 层的us::不动——这正是 MITK 现在的做法已经是最优分工。