活动预告:
        本文相关内容将于3月26日腾讯大讲堂Q+开放平台技术沙龙中由专家Wisonlee做详细分享,敬请关注腾讯大讲堂近期活动专题。

 

专家简介:Wisonlee李斌

 


  天津大学自动化学院硕士 2004年毕业加入腾讯,一直致力于大型客户端软件的架构设计与研发工作,深度参与公司几大核心重大平台QQ、微博以及Q+产品的研发工作,先后负责了第二代QQ与TM产品研发、第三代Hummer架构设计与研发、微博客户端架构、微博开放平台架构与中心建设以及第四代Q+开放平台的研发、设计与运营工作,见证了QQ客户端从第二代、第三代以及第四代的逐步开放发展的整体过程,同时也见证了QQ在线从800万到1.4亿的整个过程。
  获得腾讯第一专利发明人称号,提交近200件发明专利,国家授权近100件,现任腾讯即通应用部平台产品中心总监、腾讯软件通道客户端方向负责委员。
一、前言
  腾讯Q+开放平台是一个开放的标准化的互联网社区化平台,以人的核心需求出发在整个互联网社区之上铺设了一个统一的平台,一个人性化的开放平台。Q+将帮助第三方更好的管理和调用所有互联网的资源,包括帐号、关系链、信息、通讯能力、支付体系,从而降低了互联网第三方应用的开发成本,也减少用户使用的PC电脑的复杂度,极大的便利了用户操作路径。
  Q+作为腾讯推出的第一款基于PC客户端架构的开放平台,在技术架构上不但需要坚实有力的提供类OS化与平台化的架构能力,而且需要基于PC客户端架构基础上,在保证安全、稳定、可靠与高性能的前提下,提供了非常强大的互联网社区化核心能力支撑体系,因此Q+技术架构成为开放平台核心基础设施,而Q+采用的微内核多进程架构成为Q+开放平台中最核心的技术架构之一,下面将详细从Q+中类OS微内核多进程角度架构方面深入讲解如何架构客户端类型的开放平台。
二、OS微内核架构
  微内核(microkernel)是一个小型的操作系统核心,它为模块化扩展提供基础。
  微内核体系结构:微内核的基本原理是,只有最基本的操作系统功能才能放在内核中。不是最基本的服务和应用程序在微内核之上构造,并在用户模式下执行。许多传统上属于操作系统的一部分功能都是外部子系统,包括设备驱动程序、文件系统、虚存管理程序、开窗口系统和安全服务,它们可以和内核交互,也可以互相交互。内核体系结构如下:

  
  微内核结构用一个水平分层的结构代替了传统的纵向分层的结构。在微内核外部的操作系统部件被当作服务器进程实现,它们可以借助通过微内核传递信息来实现相互之间的交互。
  微内核将许多OS服务放入分离的进程,如文件系统,设备驱动程序,而进程通过消息传递调用OS服务.微内核结构必然是多线程的,第一代微内核,在核心提供了较多的服务,因此被称为"胖微内核",它的典型代表是MACH,它既是GNU HURD也是APPLE SERVER OS 的核心,可以说,蒸蒸日上.第二代为内核只提供最基本的OS服务,典型的OS是QNX,QNX在理论界很有名,被认为是一种先进的OS。
  微内核结构的例子:
  * AIX
  * BeOS
  * L4微内核系列
  * Mach, 用于GNU Hurd和Mac OS X
  * Minix
  * MorphOS
  * QNX
  * RadiOS
  * VSTa
      在微内核结构中,操作系统的内核只需要提供最基本、最核心的一部分操作(比如创建和删除任务、内存管理、中断管理等)即可,而其他的管理程序(如文件系统、网络协议栈等)则尽可能的放在内核之外。这些外部程序可以独立运行,并对外部用户程序提供操作系统服务,服务之间使用进程间通信机制(IPC)进行交互,只在需要内核的协助时,才通过一套接口对内核发出调用请求。
  微内核系统的优点时操作系统具有良好的灵活性。它使得操作系统内部结构简单清晰。程序代码的维护非常之方便。但是也有不足之处:微内核系统由于核心态只实现了最基本的系统操作,这样内核以外的外部程序之间由于独立运行使得系统难以进行良好的整体优化。另外,进程间互相通信的开销也较单一内核系统要大许多。从整体上看,在当前的硬件条件下,微内核在效率上的损失小于其在结构上获得的收益,故而选取微内核成为操作系统的一大潮流。
三、Q+微内核多进程架构设计方案

  从产品需求的角度来看,Q+主要由Q+平台与第三方APP扩展两部分组成。Q+需要为应用提供统一的接入方式,提供统一的应用开发调试环境,以及使用平台开放的API的能力。同时,应用也可以作为API的提供者。Q+平台支持多种应用类型(dll/exe/web/flash/…)的接入。需要保证平台的稳定性,不受应用的任何影响。
1、设计概述和设计思想
  整个Q+产品技术定义如下:



     
  Q+ =  Q+内核 +  应用/服务扩展;
  Q+内核 = Q+微内核 + API管理器 + 任务管理器;
  应用/服务扩展 = 通信外壳 + SDK + 应用/服务实体;
  应用可以是在一个单独的进程内,也可以是几个应用在一个进程内,甚至应用可以直接在Core进程内。进程模型完全根据产品需求,在框架内动态管理,甚至Server可控。一种可能的产品形态是:


  Q+微内核多进程架构设计的目标是:
   扩展性:对API的扩展和不同应用类型的扩展比较容易
  安全性:对敏感数据的跨进程通信需要保证安全
  高效性:跨进程API调用性能
   稳定性:应用或者服务Crash,都不会对整个平台造成影响
  可调试:对整个框架流程需要有完善的Log输出
  涉及的名词定义解释如下:
  MiniCore:微内核,提供最基础,最核心的功能(安全通道/登录等),需要逐步趋于稳定;
  服务:对内核以及基本逻辑的包装,主要API的提供者;
  应用:内部开发的本地应用,或者第三方开发的应用;
  任务:服务或应用加载起来之后的运行时标识,一个实例即一个任务;
  API:平台提供给应用可以使用的功能接口;
  appid:应用的唯一标识;
  service_id:服务的唯一标识;
  taskid:任务的唯一标识,也是进程通信的寻址标识;
  IPC:进程通信通道;
  RPC:在IPC基础上封装的用于Q+API跨进程调用的机制;
  2、微内核多进程系统结构
  系统结构总体框架图如下:


  各模块实现功能如下:


  Apimgr:作为整个系统的最顶层模块,负责Core和taskmgr的生命期管理,api注册以及api信息管理,api权限管理,接收api请求并根据api注册信息正确的派发请求到具体的任务;
  MiniCore:Q+微内核,提供Q+最基础最核心的支持,比如安全通道,登录等,随着时间的推移,版本的迭代,这里应该要逐步趋于稳定;
  Taskmgr:负责任务的加载,任务列表管理,以及任务信息的查询。在这里根据应用的配置类型,决定应用按什么方式(进程内/进程外)加载;
  Task:分成dlltask和exetask,分别对应进程内和进程外任务,封装对任务的操作,屏蔽不同类型任务的差异;
  DllAgent/ExeAgent:物理模块的代理对象,比如,一个应用进程,在主进程内对应一个ExeAgent实例。
  ExeAgentMgr:负责ExeAgent的管理,以及分配逻辑。exetask创建的时候过来申请exeagent,在这里决定是选择一个已有的exeagent还是重新创建一个新的exeagnet。这里决定了整个Q+的进程模型。
  应用都以dll的方式接入Q+系统,对于其他类型的应用接入方式,以web为例:


  为每种不同的应用类型,提供一个dll的接入模块,不需要影响整个架构,且不影响其他类型的应用接入。
  3、微内核多进程逻辑设计
  整个Q+微内核多进程架构的重点,也是主要逻辑在于,
  跨进程通信层次设计
   跨进程API调用流程的实现
  事件通知的处理逻辑
  Callback的处理逻辑
  API调用的线程模型
  1)跨进程通信层次设计
  跨进程的通信模型,采用多层封装设计,目前大概分成3层:


  具体模块的对应关系如下:


  2)跨进程API调用流程的实现
  在API调用的整个流程中,主要参与者有3个角色:
  API调用者
  Core中的apimgr
  API实现者
  简单API调用的流程说明如下:


  1、应用A向Core发起API的调用(如上图①)
  2、Core接收到RPC包
  如果可以转发该请求包,则修改目的id并把请求包直接转发给指定的Task(上图②).
  3、应用B接收到RPC包
  4、Core接收到RPC包
  如果是响应包,则根据目的id,直接寻址到具体的task,直接转发该答复包(如上图④)。
  5、A接收到答复包
  完成一次API调用。
  6、API的调用方,处理Timeout逻辑和同步调用逻辑。
  3)事件通知的处理逻辑
  1、与CallAPI对应的,还有FireEvent
  2、Event和API采用同样标识方式,比如string
  3、FireEvent和CallAPI不同的地方是,FireEvent不需要答复包
  4、在任何地方调用FireEvent,都先把包发到Core,Core在广播给所有的Task
  5、Task根据注册情况,把事件转发给对应的app/service
  4)Callback的处理逻辑
  1、要求一个API最多有一个callback,并且参数在最后;
  2、远程API调用的被调用模块的代理部分(进程壳),检查请求包的need_callback字段,生成一个callback函数对象,作为API的callback参数传递给API。Callback函数对象,结合C++模版,可以支持任意类型,任意个数的参数的回调。同时该对象中,记录了请求包的相关的信息,以便给调用者回包的时候,调用者用于区分Callback的对应关系。
四、Q+ 第三方APP支撑体系

  Q+ 平台作为微内核多进程的架构体系以及开放体系,对于各种类型应用(web、flash、client等)的全面支撑体系至关重要,Q+ 开放平台允许支持多种类型的应用接入:
  1)首先在第三方应用统一安装注册方面:通过外部辅助工具,将不同的应用描述信息,转换成统一的Q+ 应用安装注册脚本,并由Q+ 开放平台内置安装脚本引擎解析执行;
  2)其次在第三方应用统一加载方面,Q+ 开放平台接入层针对不同类型的应用分别提供了不同的运行加载环境,确保不同类型的应用都能正确的被加载执行,同时可以灵活的控制每个进程在什么进程被加载;
  3)最后在第三方应用开发方面,Q+ 开放平台提供了各种语言版本的SDK,满足各类开发人员在Q+ 开放平台上进行应用开发,第三方开发商只需要一键安装Q+ 开放平台应用开发包,就可以完成整个开发环境的部署,整个开发环境包括应用工程新建向导,多语言SDK开发包,API使用帮助文档,应用演示Demo,调试环境,辅助开发工具,应用部署工具等等。
五、小结

  Q+不仅仅是一种产品形态,而是构建一种新的互联网生态,是作为互联网化的开放平台而诞生,通过以上针对Q+开放平台中最核心部分的微内核多进程架构的深入讲解,可以让读者能够非常清楚了解到腾讯Q+作为互联网业界第一款真正意义上的PC客户端架构开放平台,在保证Q+平台安全、稳定与可靠的前提下,为互联网生态所有第三方APP开发商提供了非常强大的诸如包括帐号、关系链、信息、通讯能力、支付体系等在内的核心API能力,在2011年腾讯开放大会上马化腾曾经说过一句话“开放不仅仅是一种姿态更是一种能力”,只有在强大的技术能力支撑下才能更有效稳定可靠安全的提供开放,为用户、为第三方APP开发商、为整个互联网贡献腾讯的技术实力与能力。