闲鱼单体应用Serverless化拆分实践

　　背景2018，我们在实践中提出了flutter+Dart Faas的云端集成研究解决方案，该方案借助Serverless轻（聚焦业务）、快（少数接口实际函数，开发、部署快）、NoOps（运维化） ）的能力，降低了服务端业务整体层的能力，服务端的学生也有能力参与到端业务开发中，减少了服务客户端服务端的集体效率问题，提升了新兴业务的迭代效率。但是在闲鱼传统应用架构中，也存在着类似业务现实层，这个应用的名字叫idleapi。

　　由于应用的实时业务概述和架构设计不清晰，近乎所有业务都在空闲api上发生。新的业务不断更新，新的业务不断更新，老业务又及时更新，导致应用不断更新。据统计，截止2020年双十一，Idleapi对外提供了1200条网关接口，其中有500条（没有业务流量的业务下线），但代码仍在运行，没有及时清理。导致idleapi最多有70w+行代码，2k+个业务开关，上百个业务模块。这么多业务、开发都在一个应用程序上，引发了多个列的独立性问题：上线了：上百个业务模块运行在一个应用程序中，相互干扰，容易引发代码隔离性问题。例如一个业务模块出现问题（将内存单元或者线程池占满），就会导致在同一台机器上的其他业务模块没有资源，拒绝服务，连累了同机部署的核心业务，引发故障。这样的例子每年都有。探索收获：几十个探索踪迹开发学生维护上百个业务模块，每次发布整体有几十个分支，每增加一个分支分支，探索代码的漏洞，分支的底层版本和其他分支低的相关版本搏，要解决的冲突也多，耗时的时间也久了。据统计，Idleapi 预发发布一次需要 30 分钟，其中有 20 分钟是在等开发同学解决冲突，开发效率低下。业务垂直化对比：为了更好的业务发展，关注业务指标，闲鱼结合业务领域结合了人员结构，但应用结构还来不及跟进。所属业务组内部自己能够自主内聚，有效沟通，但是当所有业务共同在一个中时，业务间还需要大量的能力跨组协同管理--拆分大型系统的结构在发展过程中往往会瓦解，质量上比小型系统更是如此。设计系统受限于生产设计的组织，这些设计是这些组织的通信结构的副本。可知康威技巧：大的系统总是在发展中趋向于整体、状态重整，以达到系统结构和人员结构的整体。为了解决空闲API存在的各种问题，我们决定对它进行拆分。在拆分过程中，有几个问题必须要提前考虑清楚：

　　1。分裂的产物是什么？是按业务还是域划分的传统应用，以业务接口为单位的FaaS函数？2。拆分过程中，业务代码是全部完整还是一群？如何处理命运的业务代码？3。业务的配置、监控、业务迁移？4。如何快速验证？5。损害赔偿？怎么回滚？业务迁移过程中，新的需求如何处理？6。应用上线后，是否有措施防止再次出现应用/Faas膨胀问题？几个问题是拆分流程的关键点，决定着拆分方案能否成功落地执行。接下来我们逐个分析下。应用VS FaaS传统功能拆分要解决的第一个方向性问题：拆分的目标产物是什么？思想男孩有两个：1。按照业务域拆分成一个常规的应用，独立研究部署运维；2。以照网关接口为单位，分解为一个对应的FaaS函数。可知这几年的探索和对比：我们认为 FaaS 非常适合解决 Idleapi 遇到的问题。

　　调试期首先在调试期，传统应用下，多个接口在一个应用上并行开发，不同的分支代码发布时存在代码合并冲突的风险，并且预发开发一次大概需要 30 秒。而在Faas下，一个网关接口，对应一个Faas函数，每个Faas函数有自己独立的git仓库和部署环境。Faas之间相互独立，物理隔离，开发同学可以放心修改自己的代码和远程版本，也可以随时发起调试，而不用担心其他开发同学调试。因为只需要发一个函数只专注于一个业务网关接口接口，FaaS函数的代码量和的二方服务远远依赖于传统应用，因此预发部署一次只需要3分钟，比传统应用快10倍。运行期在运行期，每个函数都运行在不同的函数上，细微的物理隔离性，伪装FaaS函数不会引发异常性故障。一个表面上的业务背景池、写爆磁盘，都不会影响其表面的功能（业务关联除外）。编码期虽然Faas函数在调试期，运行期，运维期都拥有土地所有权，但是传统的应用在时期土地优势，例如：代码城市性：许多业务的代码在一个工程仓库里面，全部的工具、管理器类，上层业务都可以直接调用，代码简单直接；不同的网关接口分别在不同的代码仓库中，代码代码：需要代码副本或者公共下沉到二方包或者领域服务中，又会引起关注维护问题。

软件版本升级：当Pandora或者二方包必须要升级时：需要应用只需要该应用依赖的软件版本，重发布就可以解决升级问题。而在 FaaS 模式下：如果需要业务开发学生逐个修改和发布，重复劳动的工作量会是应用的上百倍，非常影响开发效率。我们通过一些化的工具或措施的措施等方案来解决这个难题。拆分工具拆分确定后，闲置的API方案为一个单独的应用，被拆分成一个个以网关接口单位的FaaS函数。这么多的业务现实是不是真实的，所以最好的方式是全部应用中的业务代码。

　　对代码分析后，我们发现了空闲api中，各业务的代码相互引用，形成了一个错综复杂的网站状结构。一个业务接口关联了五个甚至十个其他业务接口的代码，牵涉的源文件数近1000，占idleapi代码源文件我们的1/4，完全没有达到具体业务代码的目的。除了业务网关入口外，还有其他各种隐式的函数入口，例如：json序列化会自动调用类的设置函数等，Bean的初始化函数等等。对人工拆分业务代码提出了很大的挑战。，我们设计和实现了一个代码拆分工具，能够帮助业务寻找如麻的代码中，出业务入口函数所依赖的类、方法和属性，排除没有调用到的类、方法和属性。该工具能够将单个业务入口所依赖的源文件数量进一步降低到 100 左右，（其中 70% 是接口数据类型）。结合我们设计实现的Faas业务框架，业务迁移同学时，能够一键拆分出业务代码、创建Faas函数，并部署到预发环境，整个过程持续了半小时以内。对于开关，我们也提供了业务迁移工具，能够一键将预发的实例迁移到新的函数，免去人工迁移需要逐个经验的重复劳动。自动化回归测试是分离出的业务代码质量的高级服装。为了降低应用分离给业务和测试同学带来平台的额外工作量，我们协同Faas和回归测试平台，将录制自动化演示等回归测试功能，适配到Faas平台的SideCar和Pod框架。开发同学只需要在FaaS函数发布后，在应用程序中记录函数上线流量，然后把流量导入待测FaaS函数进行自动化回归测试。通过对接自动化测试平台，开发同学可以辅导完成业务的回归测试。降低了业务迁移的风险和测试同学的测试压力，提升迁移的效率。运维在FaaS业务的运维方面，我们保留开发学生的运维习惯：分离出的FaaS功能保留了组织应用中日志的名称、日志的组织格式、编码等等，也保留了学生开发登录远程机器的能力。同时，我们将业务个性化日志适配到Faas平台的白屏化日志功能，开发学生可以通过管控平台查看搜索任意机器上的所有日志，模拟登陆机器逐个查看，提很多效。同时，基于日志的监控完成系统只需要更新下相关监控点的业务路径就可以了。

　　演进对于应用程序拆分为细粒度的方法后，业务代码问题，解决方案架构，有两种思路：一。的代码下沉（下到公共二方包或下到公共二方包或下到），然后该业务应用沉应用沉为多个Faas函数。这个方案存在2个问题：1。代码简单，会带来不必要的工作量，2。原有应用上产生新的，新的业务做新的业务和新的开发，做新的，复杂的高，复杂的高。二。先拆分后治理：先对未应用进行业务拆分，暂时忽略代码的问题，等函数拆分，有业务学生在开发过程中，具体需要进行过程中代码改造。将业务服务代码或独立为工作二方包，或下沉到领域服务中。拟第一种方案，在隔离清晰的函数代码库之间有问题，难度和风险会很多。因此，我们选择了另一种方案。

　　收益

　　目前已经有30+个网关从应用中分离出来，并交付业务开发维护，进一步验证了该在应用的拆分重点方案是什么。孩子们分开方案提供给同学们，由开发同学分开迁移业务。拆分后，业务保留了原有的开发运维习惯。同时，一个业务网关接口对应一个函数的规则，应用一个Faas函数只专注于一个业务网关接口，解决了一个业务网关接口，解决了新的场景推陈出新的场景下传统应用不断的难题了。关注性，也应用函数代码量只有传统应用的3%不到（且以数据类居多），业务发布一次仅需5分钟（Java）总结

　　宏观来看，借助自动化拆分工具，业务能够在半小时内一键拆分出一个业务接口，并预发部署，中间过程无需人工干预，且拆分出的功能保持了原有的开发运维习惯，迁移成本低，能够被业务同学接受。还有借助函数的业务聚焦性，一个函数，各函数在开发接口期没有其他业务的干扰，可测性高，开发速度快。在运行期，各函数运行在不同的物理机，这种天然的物理隔离，致命提升了运行期的稳定性，降低了业务的运维成本。目前的预测功能平台还在快速发展中，还存在一些小待改进的地方：机器成本 流量小功能机器成本高：在集团安全生产的高要求下，即使是流量函数，也需要每个机房台机器，机器严重，平台正在考虑通过降低规格和超卖等多种措施提升机器。弹性：在业务上单比较长的情况下，所有问题点的弹性并不能解决，这需要通盘考虑和解决。维护成本统一升级：这是在集团卡口发布时间，每个系统都需要修复问题重发布，一个巨大的工作量，相关解决方案我们正在探索实践中。

Tags： 闲鱼单 闲鱼 在闲鱼

转载：如非注明，本站文章均为 zyby 原创，转载请注明出处和附带闲鱼单体应用Serverless化拆分实践本文链接。