OSGI与微服务架构（C++）_osgi4cpp

本篇将介绍OSGi的历史渊源

首先澄清一件事情，OSGi是一种指导软件设计的方式，而不是某种特定语言与框架，它能指导你更好的设计软件。OSGi只是一种规范，更像设计模式这种知道如何编程。而微服务架构是OSGi的一个特例应用，指明了Service Core与Extension Bundles（先有OSGi，后有微服务）。虽然现在OSGi规范由Java全权负责，但是OSGi并不是Java的特性、它适用于所有语言！！！

OSGi的概念与软件工程

由于没有查阅相关OSGi首次提出的文献，以下是OSGi的实例框架发展点，此处仅做参考：

• 2006年OSGi Apach Felix 成为Apach项目（Java）
• 2007年Eclipse Concierg项目成立（物联网OSGI项目）
• 2014年1月22日Knopflerfish OSGi框架的维护版本 框架7.0.2
• OSGi官网强调了使用模块化从而降低软件复杂程度，并引用了早起软件设计中的思维，大概如下
  1. 盖尔定律（1975）：总是可以找到一个有效的复杂系统，它是从一个有效的简单系统演变而来的。从头开始设计的复杂系统永远无法运行，也无法进行修补以使其正常运行。您必须重新开始，首先要使用一个简单的系统。
  2. 雷曼定律（1974）：随着系统的发展，除非进行维护或降低工作，否则其复杂性会增加。
     面向对象阶段（1990年至今）。
  3. 以及OSGi总结OOD等设计方式的缺陷：https://www.osgi.org/resources/modularity/ （里面提供了模块复杂度的量化指标，以及模块化降低复杂度的科学依据）

结论：OSGi大概是2000前后的产物，是OOD设计方法的延伸与解决OOD方式下软件复杂程度的技术。（很难标明其与OOD的关系，而且现有OSGi与其名称“Open Service Gateway Initiative”一点关联都没有）。面向OOD的设计原则形成的Classes模块，会产生很多的Classes关联从而增加组合Classes的软件的复杂程度。而OSGi更像以动态组合的方式划分模块，从而指导各个Classes组合提供功能，从更高的层级指导整体软件降低复杂程度。当然OSGI也可以不基于Classes（完全取决于你的心情）。

OSGi规范的现状

关于OSGi不提及“Open Service Gateway Initiative”，这本应是组合各种网络设备的规范。其早期具有的特性：

• 良好扩展性：设备节点可自由卸载，从而不会影响整体框架的稳定性。（嵌入式模块化特性、网络动态扩展特性）
• 更好的兼容性：不受任何平台限制，节点可以在任何运行环境下（x86、Arm等）取决于通信
• 模块的批量复用：设备节点部署可批量生产、部署（例如网络节点中的PC、共享单车节点）
• 整体系统的稳定性：单一模块故障不会影响整体框架的运行（汽车mcu和各个控制器的组合关系）

2000年左右Java将此规范引入到开发框架中，其中最重要的概念：仿照OSGi网络设备规范，通过的软件功能的划分实现不同服务目标的模块，通过组合功能模块实现整体软件的思维。引入OSGi规范的软件便有了如下特点：

• 产品优势：
  • 底层由OOD支持Classes，可快速支持模块化构造，适应需求变更（需求快速变更）。
  • 基于构造复用的模块组件仓库，可快速组合软件功能并发布软件版本（快速部署与发布）。
  • 支持远程模块服务，适应并发场景需求与特殊业务管理（服务集中管理）。
• 开发优势：
  • 解决在传统OOD设计模式下开发的软件，随着软件不断迭代开发、缓解熵增问题（健壮性）
  • 软件有效的模块复用，防止重复开发，节约开发成本（重用性）
  • 软件通过固定的框架格式与服务抽象，屏蔽了其他模块功能细节，只需关心己模块的内部聚合，方便开发（易用性）
  • 通过网络通信支持，达到跨平台跨语言的目标（横向兼容）
  • 重构成本低，面向功能模块的版本重构，只需要关注需要重构的模块（纵向兼容）

现有OSGi规范架构图如下：

Native Operating System：本地操作系统。
Java VM：Java虚拟机平台环境。
Execution Environment：基于平台特性的运行环境。
Modules：Classes模块基础库层。
Life Cycle：Bundles生命周期管理层。
Service：提供Bundles的访问服务。
Security：框架安全层，负责整个框架的安全。
Bundles：功能业务捆绑包。

C++中的OSGi

• QtCreator PluginFramework（tQtCretorPlugin），剥离的QtCreator插件框架（仅本地的OSGi）

  • 优势：实现较为简单，实现了对元数据解析与通过身份标识的插件阶段性初始化，包括依赖加载。
  • 劣势：元数据等字段与QtCreator紧密相连，其Service的注册方式通过先定义的方式进行实现，不适用于敏捷开发。对于事件驱动则依赖于插件内部的实现（外部仅仅实现了从main的args参数初始化传递）。关于插件初始化后事件驱动与通信的Service层，QtCreator内部实现为QLocalSocket通信，没有真正把Service层列入框架范畴。

• CTK PluginFramework（CtkCreator），剥离的CTK插件框架（仅本地的OSGi）。

  • 优势：框架趋于稳定，符合OSGI的层级划分，具有QtCreator插件框架的所有功能，同时插件通信通过插件的Context作为事件驱动，完善的Service层注册与发布机制（适用于敏捷开发）。

• CppMicroService，Cpp微服务框架（支持本地OSGi，远端模块实验性功能）

  • 优势：提供非动态库的Bundles（跨进程）构建模块外，其他与CTK相同（由于是新框架稳定差于CTK），内部代码实现更为简单。

共有天生缺陷：

• 由于模块隔离，使得流程调试困难。
• 在仅本地OSGi中，模块中指针clash将直接使主程序崩溃。
• 强语言关联，导致无法通过C++的映射符号表等手段调用函数进一步隔离代码耦合。

CTK框架图如下：

支持的层级：

• Native Operating System：本地操作系统。
• Modules：Cxx的Classes模块（通常以Cxx动态库方式存在）。
• Life Cycle：Bundles的生命周期管理。
• Service：提供Bundles的访问服务（通常以Cxx动态库的方式存在）。
• Security：框架安全层，负责整个框架的安全。
• Bundles：功能业务捆绑包。

缺失的层级：

• Java VM：由于Cxx语言特性被抛弃。
• Execution Environment：面向Module层的类不具有Java特性的Import与Export特性，被抛弃。