今天无聊逛逛百度论坛，发现百度一小编曝光了百度杀毒目前本身的基本结构，我也没看懂，转载过来 希望牛人能分析介绍一下到底说了什么
原文地址：http://anquan.baidu.com/bbs/thread-210377-1-1.html
为了响应上层具体业务的快速发展变化，同时提供针对第三方的动态扩展需求，对于相对复杂的系统设计，我们一般会采取插件的机制来保证具体子业务的独立性和可扩展性。 如果此时只是一个独立进程级别的应用，架构会相对简单一些，但是一旦底层基础框架本身也是个多进程组成的服务体系，具体插件又存在多进程间的业务耦合，这时候插件 机制的需求就会立刻复杂起来，如何清晰的保证整个系统作用域内的业务插件的全局任务调度，任务状态同步，业务插件本身动态部署的独立性等等会是一个比较复杂的问题， 下面介绍一下我们在开发杀毒应用过程中底层使用的一套方案，希望可以和大家一起讨论精进。 首先说明一下目前杀毒产品本身的基本结构。 杀毒应用的总体结构是采用多进程配合方式，主要包括服务，托盘，客户端三部分，之所以这样划分也是从各自的业务特性来考虑的； 服务：提权、样本上传、加载查杀引擎，文件监控，主动防御等核心功能模块； 托盘：后台心跳、版本升级、单文件更新，用户风险气泡提示等； 主界面：主UI，查杀具体操作，配置更改，隐私保护日志查询等； 每个独立业务进程的底层核心就是插件管理器，所有核心功能模块都是按照插件规范动态加载的； 插件管理器在设计上主要经历了两个主要版本 V1主要是为了满足以下需求出现的： • 为上层业务提供统一组件工作机制(各业务容器插件统一实现标准) • 支持业务插件手动，同步，异步延迟加载； • 支持业务插件的独立云控； • 支持业务容器内各业务插件共享基础服务； • 支持UI类子业务插件； • 支持各业务插件可执行环境控制； • 支持容器级业务插件单键控制； V2随着后续业务的不断扩展，又增加了新的需求： • 增加子业务组件动态部署机制（精简初始包，个性化子工具增加用户黏性）； • 支持业务插件下载，安装，更新，修复功能； • 支持业务插件部署手动，静默，强制方式更新； • 保证全局任务执行序列化执行和信息同步； • 支持单一任务的多observer定制； • 支持业务容器间共享全局服务； • 支持第三方业务插件接入； 根据以上的产品需求，目前的插件管理器基本结构如下图： 
由上图可见，整体结构主要包含如下几点： 1. 对于每个独立进程，上层业务主要包括业务容器和业务插件两大类，业务插件通过IPluginContext查询获取容器内基础服务； 2. 具体业务插件的加载动态配置生效，可实时云控，支持手动，同步，异步延迟加载等不同加载方式； 3. 各业务插件配置是物理独立的，可以完全独立云控，用以支持多个不同业务插件在同一时刻的各自灰度策略， 插件管理器会对落地的各独立配置进行汇总merge生成本地的一个全局插件状态配置； 4. 各业务进程存在独立PluginManager管理本进程内的具体加载的业务插件，同时保存有全部业务插件的静态配置信息； 5. 各业务进程存在独立TaskManager用于执行具体插件相关任务，如Active，Download，Install，Restore…等等，TaskManager通过IPC彼此打通， 构成一个系统级的全局任务调度体系，通过global_mutex机制保证关键任务的序列化执行并通过ipc机制实时同步任务状态； 6. 不同的业务进程执行的具体任务是有区别的，这也与一开始的进程划分目的一致，比如托盘进程统一进行下载任务， 服务进程会进行核心插件的加载任务等等； 7. 任务的触发者并不一定是具体的执行者，但对上层业务是完全透明的；上层业务统一看到的只有PluginManager， 而最终任务会由PluginManager交由TaskManager决策具体执行，如果非本业务进程应做的工作，实际会进行相关参数序列化打包 最后IPC投递到具体业务进程执行并作为此任务的Observer接收任务的实时执行状态； 8. 全局服务管理器和容器作用域的服务管理器是为了提供进程作用域和容器作用域的基础服务共享而创建的，基于进程内的Com机制实现，完成组件创建，引用计数维护相关工作； 9. 对于UI类型插件的Active进行了专门的处理，由于UI插件本身的启动要求在主消息循环线程，因此统一采取queuserapc机制，内部封装同步机制支持上层需求； 10. 第三方应用接入工作量会很简单，只需要关注自身的proxyplugin足以；
以上就是杀毒应用现阶段采用的内部核心插件加载调度机制，有兴趣的同学可以一起讨论一下，多谢！
| 
发表于 2015-5-6 18:27:51
你太真相了
