租房业务APP后端服务重构之路

背景

随着租房业务的快速发展，业务系统开发人员在忙于业务系统快速迭代的过程中往往会忽视了系统本身的优化，需求不断的累积，导致冗余逻辑越来越多，代码耦合度越来越高，开发迭代效率也变的大不如前。一个同样的功能，集成在不同页面，有时候需要写多套同样的逻辑代码。在APP端尤其明显，严重影响了用户体验和迭代效率，因此需要对业务系统做一次升级优化。

业务现状

租房业务系统在2017年经历过一次服务化改造和重构，解耦了核心的业务和服务，抽离出了几个公共应用服务层，对于性能和开发效率都有一定的提升，然而随着业务的快速迭代、变更，我们的业务系统也需要随之升级。我们之前的业务系统是为房产所有类目如租房、二手房、商业地产等而设计的，业务系统重点关注的是不同类目不同场景下，相同类型页面的通用性以及扩展性。而2019年集团战略调整，我们只专注于租房业务即可。这就需要我们在优化设计系统时重点对租房业务的快速发展以及未来的业务可能变化提前做好准备，避免以后系统反复重构，浪费资源。当然也要考虑到避免过度设计，否则会带来更高的维护成本和线上排查问题的难度。

问题&设计方案

1、开发效率方面  1.1、问题

• 业务代码长时间积累，可读性差。
  

• 单一接口，模块众多逻辑耦合，需求改动互相影响，不利于业务系统稳定性。
  

• 相同模块的扩展性，复用性差，影响迭代速度。
  

• 各个系统职责模糊，流程不规范，不利于新人介入。

目前影响开发效率最主要的原因是由于业务调整业务层系统架构设计的扩展性和复用性差，不同页面系统的相同模块有产品逻辑迭代需要更改多个页面系统。那么如何更改系统架构提升系统的开发效率呢？
1.2、方案
1）拆分通用模块系统
对现有的业务系统进行全局分析，分析出哪些通用模块可以拆出单独的系统，既需要考虑的业务的扩展性，又需要考虑的业务的差异性以及对于各个版本的兼容性。最后我们从原有的系统之上又拆分出了四个业务子系统，分别是推荐系统、列表系统、微聊电话系统、房东信息系统。

老系统结构图VS新系统结构图

2）子模块不同页面体验一致：
统一交互&视觉规范，接口协议字段对齐且增加区分场景标识，保证各个页面场景上的相同模块业务逻辑保持一致。
3）统一系统流程规范
统一开发规范，统一各个系统职责规范，保证系统的单一职责性。
4） 通用模块系统平滑迁移
由于新的公共模块协议系统返回协议格式适配了所有APP迭代的版本，业务迁移的话成本还是比较低的。

• 迁移方式采用内部系统互相调用的方式平移迁移，对上下游页面系统无感知。
  

• 采取灰度配置策略，保留老代码逻辑增加灰度配置开关，实时监控，保证有问题随时回滚。按照流量10%、20%、50%、100%逐步灰度放量直至全量。

1. 3.效果

• 需求层面：支持单个系统快速迭代，以及多个系统互相组合适配出新的页面，伸缩性强，支持业务场景最小成本的快速试错。
  

• 开发层面：各个系统模块独立开发，代码解耦，维护成本低，职责更清晰。
  

• 运维层面：各个系统独立部署，单独扩容，互不影响。
  

• 实际效果：例如以下页面都是根据拆分后的系统快速互相组合适配出的新页面，以前开发周期至少2人/日，而现在基本上只需要几个小时就能适配出来，大大提升了我们的开发效率，如下图线上复用配置模块：
  

2、用户体验方面  2.1、问题

• 接口加载速度慢？

• 用户感知卡顿？

• 接口拆分不合理？

• 请求合并没做到位？

主要场景

首屏渲染avg时间 服务接口avg耗时

优化前后对比

优化前后对比

APP大类页 下降60% 下降65% APP列表页 下降55% 下降60% APP详情页 下降72% 下降80%

团队介绍

58租房技术部，负责58和安居客双平台的租房业务研发，业务上致力于提高租客和房东在房屋出租上的用户体验和效率，技术上我们采用PHP和JAVA的双语言技术栈，业务流量、数据量、复杂度都比较高，在系统的性能、稳定性、研发的效率提升方面有丰富的技术积累，团队技术氛围浓厚。

作者简介

果海涛，房产租房技术部。16年加入58同城先后负责从0到1的PHP技术栈的服务化重构、租客端业务，专注于业务系统架构和性能提升等工作。