Android App Store架构设计与分析.docVIP

Android App Store架构设计与分析 　　摘 要： App Store即application store，通常理解为应用商店。用户可以在该应用商店浏览和购买或免费下载一些应用程序。App Store模式的意义在于为第三方软件的提供者提供方便而又高效的一个软件销售平台，第三方软件的提供者参与该平台的积极性可谓是空前高涨，这正适应手机用户们对个性化软件的需求，从而使得手机软件业开始进入一个高速、良性发展的轨道。主要就Android App Store业务架构及架构验证做一个全面的设计及详细分析。 　　1 业务架构设计 　　1.1 通道管理 　　运营商通道指在运营商及三方提供商处开通的一条通道，是发送各种信息的接入点，它包括两种类型，一种为物理通道，即实际开通的通道；虚拟通道是并不存在的通道，用它来代表一组物理通道。 　　特服号码是进行通道资源分配的基本单位，一个通道包含多个特服号码，特服号本身存在继承关系，即特服号码可以实现分级管理；同时特服号码也是进行上行匹配的主要结构。 　　特服号码体系结构即资源的分配结构，也是上行匹配的关键，必须满足业务灵活性的同时，要考虑到上行的要求，现对此进行详细解释： 　　运营商通道包括了其注册的账户及密码，及一些针对于此通道的相关属性，总包含一个通道号码（即默认的特服号前缀）。每一个通道总是包含一个根特服号，即它的特服号码就是通道号码的特殊特服号，它不能对外进行分配；能够进行分配的是扩展特服号，即根特服号是所有特服号码的根结点（采用这种形式是用来统一白名单及上行匹配的处理），特服号之间的继承关系是通过特服号码之间的关系来体现，一个完整的特服号码是从根特服号开始，所有属性中的特服号码连接而成。 　　扩展特服号码具有两种分配类型，第一种是固定分配型，另一种是企业识别型。这两种的区别是，对于第一种类型，该特服号码是分配给一家指定的企业；而企业识别型，当生成一个短信的特服号时，它总会在特服号码后加上该企业的识别号（企业识别号是在系统内唯一识别一家企业的数字标识），这种类型主要是针对于多个企业共用一个特服号时，可以用来进行上行识别。 　　虚拟通道是系统内虚构出来的一种通道资源，从业务使用上两者保持一致，区别是一个虚拟通道可以被映射到多个物理通道的特服号下，在实际发送的过程中，虚拟特服号的根特服号将会被实际发送物理通道的特服号所代替，这样可以让每个通道根据自己的实际发送状况承接发送任务（比如通道发送条数限制）。 　　虚拟通道与物理通道的使用实际上是完全一致的，只是在最后发送环节上，将使用实际发送通道中映射的特服号代替虚拟特服号中的根特服号，保持了整个业务模型的简单性。 　　上行匹配体系结构主要是接收用户短信，并依据其所返回的特服号对应所绑定企业的过程。在其模型中，将在内存中构建出完整的特服号树，匹配出相应的企业，通过逐层对比，按最大匹配原则，找到与上行特服号码相对应的号码。 　　整个匹配分为两个步骤，一个是特服号匹配，一个是企业匹配；当没有发现直接绑定企业时，转入虚拟特服号的匹配，其后续流程和正常匹配一致。 　　1.2 账户管理财务模型 　　以上模型为账户及财务的核心领域模型。 　　2 架构验证 　　2.1 数据处理流程 　　整个短信发送及状态报告及上行消息的处理流程总共走16个步骤，在此做一个总体的数据处理流程展示： 　　1）由客户端发送过来的请求（包括群发消息、单条组发消息）级前端统一包装成MSG Pack，代表了一次客户的请求。 　　2）MSG Pack根据发送通道、优先级、计费等其它规则需要分解成MSG Frame，每一条MSG Frame代表了一组具备相同业务特征的短信组（包括多条手机号及要发送的内容），它构成一个基本的发送处理单元。 　　3）依据相关的业务计费规则，根据MSG Pack及分解后的MSG Frame进行计费处理。 　　4）计费处理后，形成业务完备的MSG Frame。 　　5）将计费数据、MSG Pack及MSG Frame写入数据库。 　　6）返回客户端信号，确认本次请求的有效性，确认本次请求接受并计费。 　　7）将MSG Frame下推至MSG Centrum Server进行发送处理。 　　8）缓存当前帧，并进行帧发送处理。 　　9）MTO Server对MSG Centrum Server进行请求，MSG Frame根据MTO Server的相关属性分配一个相应的帧给MTO Server，同时在缓存中将当前帧标记为处理中状态。 　　10）将待处理的帧保存至本地数据库，进行帧发送的处理，对于不同的运营商网关，有的可能支持群发、有的不支持，MTO Server针对性的进行群发或者分解为单条短信进行发送。