网站首页怎样排版,网站设置高度,什么叫网站被k,杭州高端响应式网站建设关于为什么要选择跨平台的实现方式
Write Once#xff0c; Run AnyWhere.
越来越多的业务需求都有统一的业务诉求#xff0c;按照传统的方式#xff0c;在开发、测试、维护上的成本都是乘以N的#xff0c;体验也很难做到一致性#xff0c;特别是复杂的业务#xff0c;实…关于为什么要选择跨平台的实现方式
Write Once Run AnyWhere.
越来越多的业务需求都有统一的业务诉求按照传统的方式在开发、测试、维护上的成本都是乘以N的体验也很难做到一致性特别是复杂的业务实现成本高导致功能不能很快的上线各端侧对齐存在成本综合来看这样或者类似的业务基于研发效率等考虑选择用跨平台的实现方式是非常有必要的。 多角色的运营多场景的触发多重能力的支持导致我们的消息系统十分的复杂历史发展下的多通道消息系统底层由于历史发展衍生出3个子系统分别是
BC消息 - 最早的阿里旺旺就是基于此AMP消息 - 淘宝天猫的各类运营基于此衍生出来的主要业务包括商家群、淘友、达人业务等IMBA消息 - 主要是号方面相关的消息包括BC通知类的消息、达人运营品牌号运营等
分别在不同的BU维护而这些在多平台运营下都是需要的比如多角色的融合多载体运行的诉求每个载体又有多种平台。 基于以上背景研发一个高可用、高复用、可定制的跨终端消息模块是非常有必要的。
关于语言的选择
选择编译型语言还是解释型语言我觉得是没有绝对而言的具体选择哪个要根据面对业务形态适配的终端类型等多方面抉择而言这里说下我们选择C作为跨平台开发的首选语言一些背景。
我们团队本身是客户端的业务型团队当前需要跨平台的业务主要是消息以及消息衍生业务的开发、维护和创新。主要的终端包括移动IOS、移动安卓、MAC、WINDOWS。主要载体包括淘宝app、天猫app、千牛app、淘特app、1688app、ICBU app等等。
C作为天然的跨平台语言可以高效无缝的调用系统能力有丰富的技术生态综合组内的技术栈是比较契合我们的。
其实也跟集团里其他几个有类似需求的团队聊过目前选择比较多的也是C技术栈本文也将以C作为跨平台选型语言为主要来讲述。
即使是对于客户端而言可选择跨平台语言也是众多的通常跟随着跨平台技术方案一起来看会比较好一些没有绝对的对和错只有是否适合你。
关于基础库的选择
既然选择了C作为我们跨平台开发的基础语言那么面临的第一个问题是需要有一个功能较为完备且符合当前诉求的基础库。我们调研了市面上几个主流的基础库 再结合集团内当时的现状特别考虑移动端的现状
包大小问题集团中多种中间件mtop、db、accs等要不然已然跨终端要不然在各端上都有较为优秀的独立sdk提供基于第一点考虑这一部分不需要在基础库里二次建设。
综合以上因素集团内没有合适的足够小的且满足需求的c基础库因此我们当时决定自研一个基于C STD的符合移动端现状的轻量级跨终端基础库。 这里是跨终端轻量级基础库(LITE)的一个功能集合图在对这部分进行设计的时候主要考虑的几个设计原则
基础能力要圈覆盖综合考虑包大小性能 以及耗电量等除了提供默认实现外当系统层面有比较好的能力、或更优解时时复用端上的能力通过统一的方式嫁接。举个例子集团中间件mtopaccs等亦或者诸如Crypt模块我们期望用比较简单的方式去实现调用了Openssl的加解密接口熟悉Openssl的同学都知道他的库大小在1M左右同时IOS系统直接就提供Openssl能力所以在做这一部分的时候我们提供了默认实现同时开放统一接口接入系统能力从而实现包大小最优。
总结一下设计原则9个字最小够用可扩展原则。
平台包大小(kb, 基础功能)说明ANDROID43kb动态库v8aIOS116静态库实际占app大小Windows47kbx86
包大小情况如图未包含淘宝天猫基础客户端能力包含后略增加60k左右。
目前Lite库已经作为淘系C基础库集成在集团的近100个App里除了包大小优势外稳定性也极佳百万分之1左右的崩溃率淘宝双端统计同时与淘宝天猫架构组合作无缝提供淘宝天猫客户端基础能力log、埋点、键值存储等。
关于跨平台的架构选择
通常技术还是为业务服务还是贴近业务来讲述能更有体感一些这样也更直观的把我们遇到的问题和背后思考透漏给大家作为参考还是以消息为例
我们面临的问题和诉求
屏蔽通道以统一的数据模型方式对外提供底层需要对接3个服务端多通道同时每个server端提供的能力、功能又高度相似需要抽象后统一屏蔽提供给上层此外相关数据需要跨通道或者屏蔽通道存储。调用方线程不统一业务部分需要处理来自不同线程的高并发于客户端而言请求。多语言接入层需要适配不同平台ANDROID-JAVAIOS、MACOS-Object CWIN-C。多维度支持定制 业务定制业务上需要面对不同的APP可以有不同的功能定制这里还包括支持通道的可配置业务能力的可定制等举个例子在淘特里无群聊服务但是在淘宝里这一部分又是需要的在千牛里需要有商家群但不需要有淘友关系群等等基于业务、以及包大小考虑的定制。线程调度定制基于耗电量、系统资源、平台特性等考虑需要线程调度方案的可定制。在移动端对耗电量比较敏感且系统资源有限但是PC端上对性能要求会更高一些如何在统一的方案里支持线程调度的平台级、甚至是业务级别定制。网络流量管理定制对网络能力一方面要有统一的监控方便判断MTOP的各种API调用情况分析另一方面需要有统一的切面能力在MTOP的调用上做二次业务级别的网络流量接口优化定制。DB管理定制基于FD、平台特定等考虑需要DB管理可以根据不同的平台有不同的定制策略在移动端采用单用户一库多表的形式在pc端性能最大化采用多库多表甚至需要支持不同app的不同db管理方案可定制。基础能力复用对于集团通用的基础组件需要有统一的能力从外部获取从而方便c层使用。稳定性保障是否方便做单元测试设计上如何避免单元测试对内部代码的入侵。
基于以上我们设计了MessageSDK的架构大致如下 来整体看下上面的设计是如何解决这些问题的。
总体分5部分Service层业务层数据层数据通道层以及基础服务层。从上到下看整个架构设计
Service层也就是我们通常说的Wrapper层其目的是为了翻译业务层C的接口提供三种方式的直接接入JavaOcC需要说明的是这一层不要做除语言转换外的任何代码一来方便问题排查wrapper不做额外的处理和问题排查二来业界也有不少自动化实现语言翻译的工具有关这部分我们后面部分详细聊。业务层业务逻辑的一个组合以消息为例按模块分为三个子模块第一个消息模块第二个profile模块第三个群模块模块与模块之间相对独立做强制隔离代码无耦合功能可定制化数据层分为两部分本地存储以及网络存储其目的是屏蔽数据来源以统一的方式提供给业务层让业务不感知通道来源同时在这一层还吃掉所有的耗时操作IO以及网络请求其中Adpter主要是屏蔽通道之间的差异这一部分支持整体可替换目的提高扩展性可定制接入三方通道数据通道层这一部分就是数据来源的通道主要有SYNCWXNetDB等基础服务层是一个跨平台的c基础库。
其实客户端按层分割的设计理念无论是在PC时代还是现在的移动互联都不是什么显而易见的事儿主要关注下这里面的差异点也可以说是这种框架设计的优点。
便捷service我们只做语言层面的胶水缩短后期排查问题的整个链路方便后期排查和定位问题。同时自动化的实现也再次降低了维护成本。开放上图右侧是Openpoint能力主要是通过一些标准化的开放点去开放一些能力让接入方做更多的业务属性简单来说【每个业务有特定的开放点用统一的形式开放出去】定制 业务定制模块与模块之间相互完全独立代码无耦合强制隔离实现功能的可定制化让业务方可以自由的进行业务形态组合的同时做到包大小最优线程调度定制统一线程调度处理方案抽象线程配置策略多app可自由配置上层可选择平台级线程调度最优方案。网络流量管理定制网络调用处统一切面处理一方面对瞬时相同请求做拦截合并大幅度降低服务端压力另一方面针对业务级别做原子调用的合并定制减少服务端查询量此外切面处进行统一打点处理方便客户端做调用流量监控。DB管理定制同线程调度定制统一DB管理分配方案抽象库分配策略多app可自由配置上层可选择平台级线程调度的最优方案。扩展对外提供整体能力又可以动态替换目的是提供一种能力让接入方可以放入自己的数据通道从而实现一个业务的扩展此方法也极大的方便了后期做统一的单元测试。
于CPP程序员而言线程模型是非常重要的好的设计可以从架构上就避免掉后期一系列隐秘的bug这里包括一系列问题比如
在移动端上通常调用者不关心调用线程但是在数据层又需要做统一的数据修改和聚合能力业务层频繁调用过多的锁除了可能会出现死锁外也不利于性能最大化。部分接口如果IO、NET时间过长可能导致整个流程中断或异常。
来看下跨终端SDK架构设计的线程模型 接入层不限制调用线程降低接入成本业务层 : 按模块做隔离单独运行在自己的业务线程里在biz层做业务无锁话的同时做到单业务无锁化多业务并行化Model层 : 主要是做IO、网络操作目的是为了业务线程IO、网络无阻塞
整个线程模型的特点纯异步可定制单业务无锁化多业务并行化IO网络无阻塞。
C工程脚手架及C工程标准化
C作为天然的跨平台语言可以高效无缝的调用系统能力有丰富的技术生态。但是实际面向Android、iOS、Windows、Mac等多平台的开发过程并不顺滑主要存在以下问题
平台特性差异、开发语言、开发工具链、编译打包等多平台下项目配置维护成本高胶水(语言转换层)代码人工接入成本高、重复性工作大、门槛高(主要是对于C开发者)业务及技术框架选型困难构建发布方案规范化较差、集团研发平台对跨平台构建发布的设计不足我们在想SDK开发流程是否可以是一个可被SOP的过程如果有统一的跨平台SDK开发SOP流程特别是对于新入此行的同学当然是非常友好的。想想coder如果可以上来就可以写业务代码不用关心框架工程模型打包方案等等是不是美滋滋。
为了解决上述共性问题结合之前我们在消息SDK上的相关经验我们启动了Eyas(雏鹰)项目。
Eyas旨在进一步结合集团技术能力降低跨终端开发成本为其提供标准化的作业流程包括跨平台基础库组件化、业务框架通用化、配置一体化、语言转换层代码工具化以及发布能力统一化等一整套解决方案让开发者们可以在轻量级认识跨终端的同时更专注于业务本身。
Eyas的中文是雏鹰我们希望通过Eyas可以一起在跨终端的蓝海中探索无限可能同时可以孵化出更多跨平台的模块让开发者低成本开发跨平台SDK保证多平台业务一致性提升业务开发效率的同时降低测试成本。
为了让开发者可以更快的上手跨平台的开发我们拟定了一套跨平台SDK开发的作业流程同时在每一步都提供了对应的解决方案所有的解决方案均提供工具化的方式来高效、低成本的辅助开发者们进行跨平台SDK的开发。下图是MTL4上C跨平台研发工作流 其中 IDL(接口描述)的编写 以及 功能代码编写需要开发者根据实际业务进行开发。我们从项目创建、代码生成、编译选项和构建四个维度分析。
创建项目
跨终端团队在以往的桌面端开发中积累了很多SDK开发经验也有一套成熟的SDK框架代码但是我们在孵化新SDK时候还是要花一定时间在SDK的通用代码的拷贝上无法快速的复制出一个新的SDK项目。
开发者都是懒惰的为了尽可能的复用代码提升开发效率开发者发明了宏也发明了模板编程。为了支持复用SDK框架通用代码和项目配置我们提供了基于项目模板创建项目的工具快速实现项目工程从0到1的过程。
其实对于刚涉足到跨终端开发的开发者创建了可以编译不同平台产物的项目就已经开启了跨平台的大门。 代码生成
代码生成即语言胶水层代码工具化由于平台开发的语言差异需要有一层胶水代码来进行语言的翻译胶水代码本身是没有业务逻辑的并且耗费开发成本人工编写代码也会带来出错的风险。我们使用胶水代码自动化来解决该问题。
胶水代码自动化的原理:
根据接口的idl描述生成接口文件和胶水代码
JNI: C - Java交互的胶水代码 ObjCPP: C - ObjC交互的胶水代码 我们基于djinni地址https://github.com/dropbox/djinni进行了二次开发提升安全性的同时增加了多项feature更容易对复杂项目做模块定制化能力。 编译配置依赖管理 支持以下能力
使用GN管理工程和源码文件确保多端的C项目配置一致。统一多平台业务模块定制化能力。支持多平台下不同IDE编码和调试。结合集团技术能力统一依赖管理解决方案支持通过一份配置文件管理多平台下的依赖。
原文链接
本文为阿里云原创内容未经允许不得转载。
