端计算架构形成
|
计算上云目前是趋势。极端的角度看，期望客户端越做越轻，将主要的计算能力放到云上解决。我之前做过类似云游戏的方案，3D游戏这种极端依赖客户端硬件能力的应用也可以上云。随着通讯技术的进一步发展，游戏上云、APP上云将来会有商业化产品出现。虽然趋势如此，但是端上依然有两大优势，是云计算无法替代的：一是算力经济性，二是数据完备性。 从算力经济性角度看，端设备硬件的算力逐渐攀升。一般使用场景，算力其实是过剩的。同时频繁、大数据量的通讯，无论对用户还是运营组织，都是存在成本的。云计算与端计算未来会因经济性和体验，在适用场景上达到一个平衡。这是整体计算经济性最优导致的结果。 从数据完备性角度看，端上采集永远是第一手数据，无论维度还是数据量都较大。这些数据传输，以及在云上还原用户上下文场景都需要巨大的算力。云端获得数据前，需要端上处理、清洗数据。云端数据始终存在人为的信息丢失、修改情况。可计算性依赖数据完备性，另外出于对响应、算力的考虑，有些计算场景下放到端上计算更合适。特别是一些需要大量、复杂用户上下文数据参与的场景。此外，未来隐私合规升级，数据传输到云上会更为谨慎。为了保证一些服务的可持续运行，需要提供端计算的适配方案。可以解决上面的问题，但也有一些设计上的问题。比如纯动态化发版解决有些麻烦，逻辑分散，客户端会有额外的内存、IO操作。回到问题本身，其实我们是期望在DX引擎渲染计算时能够利用服务端侧和客户端侧数据。我通过对DX框架的学习，发现一种更优雅解决该问题的方案。 虽然DX渲染接口上只能使用单一数据源，但是DX提供了DataParser自定义计算表达式机制。我们可以定制一个DataParser，在模板渲染中使用客户端侧数据。这样DX模板其实可以支持多种数据源进行计算。同时DX提供了一个用户上下文，用于参与DataParser和EventHandler的计算。我们可以设计一个DataParser，获取用户上下文中的键值对数据;此外可以设计一个EventHandler用于将键值对数据设置到用户上下文中。用户上下文提供多种生命周期的存储方法，实现页面内DX组件间数据互通，但是FAAS只能利用服务端侧数据进行计算，从端计算角度看，无法天然使用客户端侧数据进行计算。这样并不适应需要服务端侧和客户端侧数据共同计算的需求。比如有些展示坑位有红点提示，需要点击后让红点消失，或者消失后隔一段时间再次展示。这个需求客户端侧相对好实现一些，坑位点击后本地打标，也不需要消耗服务端资源。服务端也有一些方案，比如点击后发起请求由服务端打标，然后FAAS层根据标记计算数据源展示。或者客户端打标，在请求时回传标记给服务端，然后由FAAS层计算数据源展示。两种服务端方案，本质上类似，都是想办法让服务端侧获取这个标记数据。随着提供的API、数据以及时机能力增强，该框架可以解决一些线上功能性问题修复。比如：
此外，还进行过一些数据实验。比如分析5秒内用户退出APP的原因，UT通道数据丢失指标建立等。 上图所示，埋点修复其实就是将一个错误的字典计算为一个正确字典的过程。如果满足下面两个条件，则可以修正任何错误的埋点数据：
要满足第一个条件，可以根据字典本身的数据特征、交互特征、当前页面等上下文数据来识别。埋点数据源自服务端返回数据、前端位置及交互和页面上下文。要满足第二个条件，只需要补充上述数据即可。因此接入的数据源是否完备，是决定框架修复能力上限的一个重要的因素。案;兼顾动态化和性能的RN、WEEX乃至界面搭建方案;针对热修复的各种Patch方案;还有一些配置、编排等特殊需求的方案。这些方案的核心都是用某种语言描述业务的逻辑方法，描述能力越强大，能够解决的问题越多。脚本语言似乎有着无限的可能性，但是当我们尝试解决某个未知领域的计算问题，对于问题计算的可行性又缺少自信。此外，正确评估各种架构的计算性极限对于我们选型、解决具体问题也是十分重要的。因此需要总结如何设计、评估端计算架构的一般性方法。 一 从解决埋点热修问题理解何为端计算 因众所周知的原因，苹果禁止类似JSPatch的热修复方案上线。对于考拉iOS客户端，大多数问题需要发版解决。通过发版解决数据问题，周期长且持续产生脏数据。对于依赖数据驱动产品迭代的开发方式会产生很大影响。同时，我也在思索是否有一种更敏捷的移动端取数方案，缩短数据试验周期。基于以上目的，埋点热修方案的研发就提上了日程。
虽然我们可以使用JS脚本作为计算载体，但是需要证明埋点热修是否可通过计算修复。 （编辑：南昌站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
