会调试模型，知道如何评估模型、定位模型问题、调优模型、压缩剪枝和知识蒸馏降低模型算法复杂度提升模型性能。
因众所周知的原因，苹果禁止类似JSPatch的热修复方案上线。对于考拉iOS客户端，大多数问题需要发版解决。通过发版解决数据问题，周期长且持续产生脏数据。对于依赖数据驱动产品迭代的开发方式会产生很大影响。同时，我也在思索是否有一种更敏捷的移动端取数方案，缩短数据试验周期。基于以上目的，埋点热修方案的研发就提上了日程。
世上没有免费的午餐，微服务技术让 IT 系统变得更敏捷、更健壮、更高性能的同时，也带来了架构复杂度的提升。对于开发者而言，要想更好的驾驭微服务架构，需要解决持续集成、服务发现、应用通信、配置管理、流量防护等一系列难题。幸运的是，针对这些普遍存在的难题，业界涌现了一系列优秀的开源技术组件和工具，让开发者可以更轻松的构建微服务应用。像 Spring Cloud 和 Dubbo 这样的技术框架，经过多年的发展，已经演化为微服务领域的通用标准，极大地降低了微服务的门槛，但这些技术框架依然没有办法解决其中两个最大的挑战，这两个挑战成为摆在开发者面前的两座大山。
资源利用率低的根本原因，在于以服务器为载体的应用架构中，开发者需要将构建好的程序包部署到服务器上，从而对多个用户事件进行响应。为了确保事件响应的及时性，需要让程序长驻于服务器上，而且尽可能保守的规划资源，以避免出现负载过重而导致服务崩溃的情况。在这个过程中，实际的负载在时间上分配并不均衡，从而导致整体的资源利用率偏低。
是否有一种介于 FaaS 和 Serverless 化容器之间的技术，可以实现上述重要诉求呢？当然有，这就是以阿里云 Serverless 应用引擎（SAE）为代表的应用层 Serverless 技术。
面对这种全球性跨地域的分布式系统，我们不得不谈到CAP理论，为了能够多中心全量数据提供服务，Partition tolerance（分区容错性）是必须要解决的，但是根据CAP的理论，Consistency（一致性）和Availability（可用性）就只能满足一个。对于线上应用，可用性自不用说了，那面对这样一个问题，最终一致性是最好的选择。
通过DRC的拆解，数据库操作有三种：insert、update、delete，这三种操作不管哪两种操作都是不能满足交换律的，会产生冲突，所以我们在并发级别（主键）加上额外信息，这里我们采用序号，也就是2中提到的染色的过程，这个过程是保留的。而主键之间是并发的，没有顺序而言。当接收消息的时候我们并不保证强顺序，采用LWW（Last Write Wins）的方式，也就是说我们执行当前的SQL而放弃前面的SQL，这样我们就不用考虑交换的问题。同时我们会根据消息的唯一性（实例+单元+数据库+MD5(SQL)）对每个消息做幂等，保证每个SQL都不会重复执行。而对于结合律，我们需要对每个操作单独分析。
Re-platform 新平台 - 利用托管的云服务替换线下自建应用基础设施，比如通过 RDS 数据库服务替换自建 MySQL；通过容器服务，比如阿里云 ACK 来取代自建 K8s 集群。托管的云服务通常提供更好的弹性、稳定性和自治运维能力，可以让用户关注于应用而非基础设施管理。
作为一个复杂的业务应用，如何实现技术支撑对蚂蚁非常关键。蚂蚁目前正在尝试许多FAAS相关的技术选型，但从更大的范围来看，微服务仍然是主流的选择。蚂蚁所使用的微服务架构本身也在不断演进，比如把和业务无关的功能下沉到Sidecar，将数据库的一些中间件mesh化等。
状态型数据的容灾设计
这两种数据在进行应用层容灾设计时需要不同的处理方式，状态型数据的容灾设计通常比较困难。比如，会员信息在出现错误时通常不能再写该数据，也不能让该用户重新注册一次支付宝。状态型数据的容灾设计需要以数据库不可靠为前提。数据库通常存在主备库，这两个库通常使用异步复制的方式来保证两个库之间的同步。然而，这种同步通常具有时延特征。
