移动端发展至今，诞生了很多架构用于解决各领域的专有问题。比如针对移动端动态化的Hybrid方案；兼顾动态化和性能的RN、WEEX乃至界面搭建方案；针对热修复的各种Patch方案；还有一些配置、编排等特殊需求的方案。
对计算、数据、时机三个维度的补充，框架已经从埋点修复，泛化为一般的端计算框架。通过控制数据，去影响APP的功能。从端计算的角度看JSPatch等热修框架，它的计算、数据层面限制较少，但是修复时机是函数调用级别。相比代码行级别的修复，框架对修复方案有一定的限制。
从算力经济性角度看，端设备硬件的算力逐渐攀升。一般使用场景，算力其实是过剩的。同时频繁、大数据量的通讯，无论对用户还是运营组织，都是存在成本的。云计算与端计算未来会因经济性和体验，在适用场景上达到一个平衡。这是整体计算经济性最优导致的结果。
云原生是零售云的最重要的技术底座，云原生是什么，会走向哪里，在零售2B交付的场景上该如何应用，怎么能够结合帮助建设零售云系列产品体系，值得我们的思考和探索，也将有效指导我们接下来几年的零售云项目和产品建设。
12-Factor应用完全自我加载，而不依赖于任何网络服务器就可以创建一个面向网络的服务。互联网应用通过端口绑定来提供服务，并监听发送至该端口的请求。比如，在线上环境中，请求统一发送至公共域名，然后路由至绑定了端口的网络进程。
相 比 于 传 统 PaaS 封 闭、 不 能 同“ 以 Operator 为 基 础 的 云 原 生 生 态” 衔 接 的 现 状， 基 于 OAM 和 Kubernetes 构建的现代云原生应用管理平台的本质是一个“以应用为中心”的 Kubernetes，保证应用平台能够无缝接入整个云原生生态。
知识的传递 transfer of knowledge ：知识的传递是为了解决两个问题，一个是为了避免某个人成为单点，从而导致一个人的休假或离职，就导致工作不能完成。另一个是提高团队的集体能力，团队的集体能力要高于个人的能力。
控制复杂性。由于业务的复杂性，需要我们用更好的手段帮助研发组织克服认知障碍，更好的分工协作。分而治之，关注点分离等手段皆是如此。
更快、更轻、更敏捷的应用运行时技术是云原生计算的持续追求。
体积更小 - 对于微服务分布式架构而言，更小的体积意味着更少的下载带宽，更快的分发下载速度。
对于数据驱动，很多人做到一定程度之后，脑海中会形成一定的方法论和体系，进而形成驱动流程和组织机制。大家也听了很多方法论，包括增长黑客等，貌似自己已经很懂数据驱动了，但是实际操作起来可能连“什么是事件属性这种基础的概念都不了解”，这是很多业务线同学普遍的现状。
