云原生浪潮下自如的技术演进之路

董浩——自如技术专家，主导了自如无线网关和Devops体系从0到1的演进工作，现在负责自如私有云体系的搭建。

▼

自如是一家提供高品质居住产品和生活服务的科技公司，经过十多年的发展，涵盖了租住，服务，智能，社区生活等多条业务线，其中基础平台部门为所有业务线提供了底层的技术支撑，助力各部门快速响应业务需求。随着业务需求的不断发展，基础平台的职责范围也不断扩大，目前主要划分了中间件，devops，业务平台支撑三大块体系。作为参与了自如技术栈从单体走向云原生的工程师，也随着这波技术演变的浪潮不断探索学习。这篇文章就以API网关和devops平台建设为例，穿插着分享下这些年的变迁。

上图展示了自如整体的技术架构。在18年前， 基础平台的核心职责是：

1.  建设无线网关， 完成对外统一出口流量的治理。

2.  对常用的核心组件(redis/kafka/rabbitmq/es等)做封装，包括sdk和管理平台的建设。协助运维完成常用中间件从申请到使用以及监控告警的流程。

— API网关的建设 —

在基础平台成立前，移动端和业务线对接没有任何规范，全部依赖后端开发给出格式定义，移动端完成对接。权限验证也依赖各业务独立对接，整个链路缺乏监控。所以无线网关应运而生。当时spring cloud netflix初步进入大众视野，基于OpenResty的kong也是刚刚展露头角。经过调研，确认基于spring cloud zuul的方案更适合内部体系，所以第一版基于spring cloud zuul改造的网关就推向各业务线，接入网关之后架构变成了下图所示，所有的服务都通过API网关去访问后端服务。

 

 

当时解决的几个核心问题有：

undefined 统一了入口的加密方式, 对移动端和web端请求做了统一的加密处理，提高爬虫成本

undefined 规范了前后端的格式定义，方便前端解析

undefined 接入了链路追踪方案，链路一开始基于cat实现，后来切换到了pinpoint，metrics也基于dropwizard的metrics库做了埋点

undefined 开发了通用的mock能力提高联调效率

undefined 支持配置单机QPS限流规则

undefined 支持服务路由动态刷新

 

 

 

zuul的过滤类型和生命周期

随着业务的发展，基于zuul的网关有一定的瓶颈。一方面Java实现的占用资源消耗比较大，zuul基于阻塞IO实现的模型导致线上部署的机器数量较多，另一方面由于内部网关/开放平台等其他平台和无线网关有着类似的需求，所以希望用一套代码来解决相似的问题，降低维护成本。所以20年初启动了网关2.0的研发。考虑到成本以及内部技术栈，我们选择了Go作为网关2.0的实现语言，基于fasthttp server和fasthttp client作为底层组件，支持从mysql/nacos/consul中读取获取服务列表，参考zuul的filter机制实现了一套类似的扩展。从底层实现了区分了不同端（移动/内部/开放平台），极大程度降低了维护成本。压测下来可以降低到之前1/5的机器数量。开发完成后上线面临着非常大的挑战，一方面是稳定性，具体实践中通过白名单方式来灰度服务，同时做好监控和回滚方案。先保持Java/Go网关共存一段时间，密切观察监控指标。然后在逐渐替换下掉Java网关。平台的更替不是一蹴而就的， 在平台迭代过程中，业务对鉴权的需求也不断升级， 针对不同来源的用户实现不同的鉴权方案，有需要和内部平台打通的方案，也有基于oauth2,jwt 实现的方案。以及平台自身涉及到的技术点也会不断地更迭，随着社区对一些标准规范的提出，我们也在逐渐靠拢。比如 监控从Cat的方案切换到了pinpoint+graylog, 后来又基于Opentelemetry的方案来完成监控的闭环。

目前已接入300个核心服务，涵盖了自如的9个app，所有移动端出口都实现了网关接入

— Devops平台的建设 —

接下来讲一下关于自如Devops体系的建设。在18年以前，自如的整体技术栈以Java/php为主。Java中有大量的tomcat，dubbo，spring-boot类型的应用。

当时的发布平台基于shell脚本编译 ，svn上传到服务器的思路，使用难度大，排查问题难， 上线繁琐，吐嘈声一片。为了适应业务快速发展的同时，平台也启动了基于kubernetes的发布平台建设。 

在平台确定之初，就明确了核心的功能点:

1.  支持用户从原有平台快速迁移，批量迁移，减少改造成本

2.  屏蔽开发对Dockerfile 和k8s yaml语法的理解成本，无需关心ingress,deployment,service等概念

3.  打通日志监控平台，从资源申请到上线运维实现一站式能力集成

有了明确的方向，平台的建设就有了思路。首先提供给用户跨机房多环境申请资源的功能，工单快速流转到owner和运维。完成后自动生成k8s中的Service和Ingress资，其中Ingress支持泛解析。只要deployment资源生成，就可以通过域名访问。 

为了降低用户对编译打包的关注，会根据应用类型生成不同的描述文件，无需编写Dockerfile, 同时留出扩展位置支持用户修改挂载到镜像中的文件，做到了简单又不失灵活。 

 在部署阶段，利用环境配置，配置文件以及环境变量来生成ConfigMap以及Deployment，同时根据annotation的方式实现了金丝雀/蓝绿发布。

平台发布后受到了用户的广泛好评，在效率和性能上都取得了巨大改善。但平台建设之路非常漫长，对业务来说和VM时代的变动都不可接受。比如之前的文件上传和下载，还有IP漂移导致的按IP划分黑白名单不可用，以及跳板机改成webshell带来的不适，都需要去解决。以及不同平台间的集成，从日志监控到服务治理，是一整套方案的变更。 

所以为了解决这些问题也花费了大量的心思。比如文件下载，通过deployment yaml中对固定目录做软链接，在物理机的node上挂nginx做目录服务，实现了文件的下载能力。以及IP漂移对众多老旧业务的影响，也加了一层代理去支持旧业务对外提供固定IP的能力。但是服务治理的能力无法一蹴而就。分两部分来看待：

1.  可以依靠agent去集成的，比如监控，日志，在线诊断等，使用频率不高

2.  高频常用的平台，例如配置中心，各种中间件管理平台，熔断限流配置等能力

第一类能力在平台上只做了开关，开启后在Pod中自动注入agent，支持动态的开启关闭

例如基于去哪儿bistoury的jvm诊断平台集成，点击开启后即可在诊断平台上看到应用，进行动态调试。

第二类需要在平台上做深度集成，方便使用。

例如基于istio的熔断限流能力，在平台配置后审批即可生效，不需要跳转其他平台。

目前自如的应用数已达上千个，每月发布次数超过2w次。随着各个平台的功能已经趋于稳定，我们的重心也逐渐转移到平台间的集成融合上，以应用为中心，在服务元信息治理上构建应用画像，在应用开发和应用交付阶段不断提升用户体验，参考类似OpenSergo的协议提升服务治理的能力。随着云原生浪潮的推动，我们也会选择最适合的技术栈去引入，道阻且长，行则将至，行而不辍，未来可期。

                                                                   END

想要了解更多自如的技术演进之路，请关注2023年即将于北京举办的K+全球软件研发行业创新峰会，届时董浩老师将带来《自如收出房业务驱动的技术架构演进之路》主题演讲，感兴趣的小伙伴赶快扫码了解详情吧！