在哈啰的APP中，活动、大促、周年庆等都需要我们能够拥有更快捷的响应速度、更高效的人力来缩短试错周期，而且流量区域运营位为了能够做到千人千面，又迫切的需要有一种可以根据不同的人群达到展示不同效果的目的。UI 可定制化、快速迭代、高性能体验一直以来都是移动端开发领域的核心诉求，随着哈啰业务的不断拓展，越来越多的业务线对上述三点提出了更高的要求，但由于移动端 App 发版的天然限制，无法很好满足业务方的诉求。 基于以上一些业务痛点，我们结合 Native 黄金流量业务区域对于性能极高的要求，输出了一套 Native 局部动态化方案 Wukong（悟空），截止到目前，已在App内部多个业务模块中得到验证。
哈骑士是哈啰的一款终端安全应用，本文主要介绍我们在做新版哈骑士桌面端时的一些技术架构思考和实践，分享我们沉淀的一些桌面端应用的解决方案和经验。
为什么哈啰AI平台需要Faas 一是运维复杂问题，AI平台有多种不同语言的模型推理服务， 如python、C++（tf-serving）、Java等，各自管理上百个不同类型的模型；架构也很复杂，存在大型单体应用、多container应用、小型GPU应用等多种服务组织方式；同时，手动运维有余，自动化工具不足。 二是稳定性问题，成百上千模型集中式部署，存在明显热点问题，在应对一些突发流量的时候，自动伸缩速度也存在问题。同时，模型cpu、gpu资源竞争问题也困扰了我们。 三是IDC成本问题，存在资源利用率低的问题，有很大的提升空间。
Android应用采用Java或Kotlin编写，iOS应用采用Objective-C和Swift编写，但当我们要去开发支持多端的应用，每一端都需要独立研发、测试，直到上线。为了解决多端独立开发的问题，跨端技术的方案备受青睐。 两轮跨端技术的尝试要追溯到2019年，当时整个互联网行业都在提效的大背景推动下开始各种跨端方案的尝试，而前身还是两轮助力车团队的两轮大前端也开始了跨端技术方案的探索。 当时可供选择的跨端方案有React Native方案、Weex方案，H5离线化方案以及当时较火的Flutter技术方案，而我们的目标是希望能够找到稳定、适合我们业务特性，并且可以继续进行深耕的技术方案进行调研和尝试。
在定点还车的模式下，用户还车需要在一些指定的区域里。此时用户停好车后在APP或小程序内点击“我要还车”，手机会将位置信息传输给后端，系统会判断是否在站点内，如在站点内会提示用户点击“确认关锁”，用户手动关闭车锁完成还车。
应急预案，是指在系统出现故障时，为了保障核心业务能够持续可用，而提前准备的指导手册。这个手册可以用来告诉我们：在遇到什么样的问题后，做什么样的操作能最大化地降低对业务的影响，将被动响应变为主动防御。
故障也有积极意义 在复杂系统中，故障是必然的，无法彻底避免。从定性的角度来看，并非所有的故障都是坏事，有些故障是有正面意义的，比如说通过一个线上的小故障发现了一个大隐患，或者是某次故障中相关人员的意识和应急预案都很到位，但是由于故障的原因非常特殊最后仍然造成了较大的影响等等，类似这样的故障都要找出其中的亮点。 所以，我们要用辩证的眼光去看待，避免大家“闻故障色变“。为了往这方面引导，我们在规章制度方面也做了很多设定，因此在我们的故障管理制度上，我们也是鼓励快速恢复(对于快速恢复的故障定级比较低)、鼓励通过演练发现更多的线上问题(对于由于演练导致的故障有一定的豁免权)等等。但是，大家也应该充分意识到我们对故障的理念：即偶尔的系统失效是可以容忍的，人为的犯错是要严肃对待的，比如说不符合高可用规范的系统设计模式、强弱依赖设计不合理、由于人员意识不到位带来的故障处理时间较长、值班人员未及时接通oncall、由于对线上系统不够重视带来的变更隐患、不遵守变更三板斧规范等等。
负载均衡是分布式系统里最常用的能力，实现方式有很多，轮询、随机、加权轮询、一致性hash等文章很多，今天要讲的是遇到的一个真实的生产问题。 公司内部的ES访问架构一般是，Java应用--->SLB(域名)---->ES ingest node (no data) --> ES data node，其中ingest节点是对外暴露的，供Java应用访问，承担了一个纯client角色，不提供数据存储和倒排索引检索服务。这其中SLB是为了方便起到一个域名和负载均衡的功能，绑定后端的n个client节点，并且做到对业务透明，但是毕竟还是有开销的，多了一次网络rpc的转发(尽管很快)，同时也是多花了一份钱。所以在930的时候我们把SLB去掉了，并且进行了验证完全没有问题，这其中还要得益于es本身就支持ip配置列表，并且自身实现了负载均衡的功能。 更改之后的访问链路，Java应用--->ES ingest node -->ES data node。
