问题一：如何实现商业版和开源版在发送可观测数据方面的差异？
如何实现商业版和开源版在发送可观测数据方面的差异？
参考回答：
为了实现商业版和开源版在发送可观测数据方面的差异，定义了开源版的ProfileSender类，并为其提供了虚函数SendToProfileProject用于发送数据。在商业版中，通过ENTERPRISE宏控制实例化EnterpriseProfileSender类，该类继承自ProfileSender并重写SendToProfileProject方法以实现商业版特有的发送逻辑。
关于本问题的更多回答可点击原文查看：https://developer.aliyun.com/ask/627568
问题二：ProfileSender类中的GetInstance方法是如何根据版本返回不同实例的？
ProfileSender类中的GetInstance方法是如何根据版本返回不同实例的？
参考回答：
ProfileSender类中的GetInstance方法通过ENTERPRISE宏来判断当前是商业版还是开源版，并据此返回不同的实例。如果是商业版，则实例化EnterpriseProfileSender类并返回其指针；如果是开源版，则实例化ProfileSender类本身并返回其指针。
关于本问题的更多回答可点击原文查看：https://developer.aliyun.com/ask/627567
问题三：为了分离商业版和开源版代码，进行了哪些代码重组织工作？
为了分离商业版和开源版代码，进行了哪些代码重组织工作？
参考回答：
为了分离商业版和开源版代码，进行了以下重组织工作：将与商业版配置拉取、鉴权、可观测数据发送、特殊指标监控以及非配置级参数管理相关的代码分别从原有的类中剥离出来，形成新的类如EnterpriseConfigProvider、EnterpriseSLSControl、EnterpriseProfileSender、ShennongManager等，并将这些商业版特有的功能代码放在单独的文件中。
关于本问题的更多回答可点击原文查看：https://developer.aliyun.com/ask/627566
问题四：iLogtail新架构应该如何设计？
iLogtail新架构应该如何设计？
参考回答：
虽然知道原有架构不合理，且对发展方向有一个大概的认知，但是新架构究竟如何设计却是一个值得商榷的问题。显然，对于任何领域，没有输入自然就不会有输出。得益于日常对其他主流可观测数据采集器架构的持续调研和学习，笔者对现代可观测流水线的基本理念和设计思想有了一个基本的认知。在设计iLogtail的新架构时，主要采用如下原则：
• 对于可观测流水线的通用概念（如数据类型和流水线定义等），iLogtail要尽量做到和领域内其它竞品保持一致，避免独树一帜给用户迁移带来不便和困惑；
• 对于架构实现，不能简单照搬其他主流可观测数据采集器的架构，而是在吸收其设计思想的前提下，针对iLogtail自身的特点（如双语言实现）进行原创设计，适合自己的才是最好的。
• 对于iLogtail的自身优势（如C++的高性能和配置热加载），在完整保留的同时，还需要将原本阻止优势发挥的限制尽可能地去除，使得自身优势能够在更多的场景中发挥作用，提升产品的核心竞争力。
关于本问题的更多回答可点击原文查看：https://developer.aliyun.com/ask/627565
问题五：iLogtail确定好新架构后，如何分阶段来完成架构升级？
iLogtail确定好新架构后，如何分阶段来完成架构升级？
参考回答：
新架构与原有架构的区别较大，升级涉及到的模块众多，工作量大。显然，一口气完成架构升级是不可行的，必须分阶段分模块进行，在CI的配合下确保每一个模块的重构都是符合预期的。那怎么分阶段呢？这里就走过一些弯路，因为从架构设计的角度，我们会习惯性地从外往里进行思考（即按照上文实践一节从后往前的顺序），但这会陷入一个层层依赖的问题。例如，在重构配置管理模块的时候，会依赖Pipeline类和PipelineManager类。为此，需要优先重构这两个类。但是重构这两个类的时候，又会依赖各种插件类的实现。按照这个顺序进行下去，最终的依赖便是PipelineEvent类。显然，按照这个顺序进行下去，相当于一口气完成架构升级，因此根本不可行。正确的做法是由里向外进行重构，先重构PipelineEvent类，再重构插件类，以此类推最后重构Application类，即按照上文介绍的顺序。借助这个顺序，就可以将整个架构升级过程分成至少6个大阶段，每个阶段都可以单独CI而不会影响既有功能的正常工作。但是，想要正确执行这种顺序，就必须要求对目标架构有一个完整清晰的认知和详细的设计。如果对目标架构的认识只停留在粗框架的层面，那必然无法准确得到各个模块的依赖关系，从而得到并非完全正确的阶段划分，最终影响实际重构的进度和效率。任何时候，想清楚了再做永远是事半功倍的基本前提，对于架构升级来说尤甚。
关于本问题的更多回答可点击原文查看：https://developer.aliyun.com/ask/627564
