通过本文，您将了解什么是Web components，以及业务中台如何将其落地到业务场景的最佳实践。

本文基于行程平台的中台化进行了一些中台化建设的思路和感想，更多是对中台的定义以及一些框架的使用。

为了让乘客能够看到司机的实时位置，有了司乘同显出行方案，提供地图功能，给用户展示司机相对实时的位置，以及司机到乘客的行驶路线。

智能匹配引擎主要服务于哈啰四轮业务，为顺风车、打车业务的司乘匹配场景提供强有力的技术支持。本文主要讲解顺风车业务下司机与乘客相互匹配过程中的一些技术实现。

本文描述了典型产线团队管理进化的过程。从职能部门创建出来，引入基本的管理框架，在解决实际问题中逐步完善管理策略，形成稳定的管理框架，使得过程更加顺畅，过程持续改进、团队持续进化。

哈啰本地生活的业务主要是售卖电子卡券，但是要解决的业务问题基本上涵盖整个电商，本身具有一定的复杂性，本次主要选用本地生活的业务和大家讨论一下领域驱动。

得物App的图片、视频等资源有反馈加载较慢、有卡顿感。它们使用阿里云CDN进行下发，客户端与CDN服务器之间的请求耗时较长对用户体验产生了极大影响。

得物App核心的CDN域名共10个，其中流量最大的域名是cdn.poizon.com，占比92%，使用场景包括图片、视频、H5资源、小文件等，涉及得物App全域。

因此，本文主要以cdn.poizon.com为主讲解CDN网络性能优化过程。

为提升系统稳定性，和线上故障的触达、定位、恢复的速度，以及建立一套可执行、便于操作的特色的演练规范，并沉淀通用、可移植的演练规范，故发起了故障演练。

事事皆项目，生孩子养娃也不例外。

如果科技让出行更美好，可以推动出行的进化，那么AI算法模型的应用，就是其中一个最大的推动力。

算法测试团队在日常的测试工作中，探索与积累的算法测试经验。

我们的供应链场景有很多供应商，每个供应商都有物流、资产、仓储等多个域，而这些域我们的后端都基于 DDD 领域模型做了微服务化，此时前端在开发面向这些供应商使用的中后台应用时，遇到了以下问题：

页面显示需要请求多个域：比如一个商家的详情页，可能既需要请求仓储数据，还需要请求资产数据，才能将一个页面显示出来。

接口格式不满足前端需求：后端微服务化后，是面向多项目，通用性的，其接口格式不一定能满足前端需求，前端需要自己做转换，比如单位转换，字段裁减。

需求变化快：业务在快速迭代，需要接口的大量支持，而我们的后端域是面向多项目的，更改成本较大，需要投入更多的测试，此时如果在前端和后端中间存在一个中间层，来做这些事情，那么效率会有比较好的提高。

部门协作成本大：有些需求需要其它部门的后端同学支持，而其它部门的同学因为自己部门的需求紧张，排期较满，导致我们的需求迟迟无法排期，此时如果存在一个中间层，在中间层去请求其它部门提供的领域服务来组合数据提供给前端，此时就可以在其它部门同学不参与的情况下，前端自己完成需求开发，部门之间的协作成本会大大降低。

基于以上背景，前端这边引入了 BFF 架构，BFF 架构能做哪些事情：

业务编排：从后端域多接口获取数据合并输出给页面。比如一个商家详情页即需要仓储数据，也需要资产数据，此时我们在 BFF 层将仓储和资产数据请求回来组装吐给前端。

字段转换：字段过滤、数据格式化等工作。比如资产域的商户名字段叫 businessName，而仓储域的商户名字段叫 shopName，此时可以在BFF层统一掉，这样前端就不需要做判断了。

个性化数据：为前端提供个性化服务，如数据压缩，单位转换等。

因为业务需求，接触了ws协议以及在实时语音识别中的运用，总体的感觉还是挺有意思，并且了解到很多人其实是没有用过这个协议的，所以还是值得分享记录一下。

本文将分为以下几个模块去讲述WebSocket，1.以实际场景引入来分析传统方式实现实时数据传输存在的弊端，由此引出ws的作用和特点。2.介绍ws协议的工作流程，握手过程以及对于心跳机制的一些理解。3.结合实际的业务场景去看看ws协议是怎么使用的，并且实现了什么样的价值。

每次发布SOA拉入时就有少量报错，报错的集中在RPC设置超时时间比较短的上游服务，比如设置300ms，发布完就好了。且最近没有发布新版本，应该不是中间件变更引起的。

系统的复杂度体现在：前端对后端的依赖，后端服务之间的依赖。在没有明确强弱依赖的前提下，我们很难进行熔断、降级、限流的相关操作，也不能有效的对系统进行相关优化改造、持续推进系统稳定性提升。

本文是哈啰技术沙龙-哈啰中台业务跨端技术Flutter实践分享文字版本；讲解了移动端跨端的历史背景和哈啰出行平台移动端在落地Flutter时遇到的业务痛点，并且详述了哈啰平台移动端如何利用容器化解决这些业务痛点，其解决方案和实践的成果。