Spring Could 尝鲜记录

这是我 17 年刚进公司时的技术架构(我称它为 1.0 版本), 应用服务器在自建机房.

客户端有 PC端, iOS客户端(原生), 安卓客户端(原生), 以及 H5 应用端.

南北流量通过 nginx 反向代理接入

web层是 spring mvc, 每个业务线都单独放到 tomcat 服务器中, 通过 dubbo 协议, 调用后端的领域服务

领域服务层, 都有对应的数据库(schema 分离, 在同一个 mysql 物理机上), 领域服务之间可以相互调用.

在我们项目初始阶段, 该架构足够满足我们业务场景, 但是在日常维护迭代过程中, 也逐渐发现了一些痛点:

每次迭代更新, 我们都是在领域服务层实现对应的业务逻辑, 同时为了将对应的服务通过 http 暴露给客户端, 必须修改 web 层的 spring mvc 应用, 增加对应的 controller 方法, 这些 controller 转发器基本上都是比较无聊的体力活, 每次更新都会涉及到 web 接入层的部署更新;
我们的业务线近 1 年扩充的比较多(理财, 借贷, 聚合支付, 分销等等), 所有这些业务线都要重复实现一次身份认证, 请求日志记录等通用的功能, 这不仅会浪费开发资源, 而且一旦需要修改这部分的代码, 就需要修改很多代码, 这是版本管理和升级维护的噩梦;
技术总监要求我们增加接口测试, 我们的 dubbo 用的是 2.5.4 版本, 并不是当当维护的 dubbox, 不能方便的通过 rest 方式暴露给测试人员;
每次 APP 更新, 都需要对应的原生客户端开发人员进行迭代开发, 然后提交送审, 一般审核时间在 1 至 2 天, 有时候审核驳回又要延长时间;

所以, 在 17 年 11 月开始, 我们开始尝试业界的其他解决方案, 这时候后端微服务架构的 spring cloud 进入了我们的考虑场景(基本上也就这个比较流行), 通过整个团队的努力, 2018年4月, 我们的 2.0 架构版本上线了

技术架构的改动有以下方面:

手机客户端, 我们抛弃了原先的 native 开发模式, 引入了 hybird 架构(基于cordova + webview), android 和 ios 小伙伴主要负责开发 jsbridge 功能, 前端小伙伴负责 webview 相关的开发, 同时还要加入了 APP 静态资源动态热更新的设计;
废弃了之前的传统 web 接入层模式, 我们引入了 zuul 网关, 在 zuul 网关中我们统一实现了用户身份鉴权, 请求日志记录, APP 版本更新检测等通用功能(这里我们不同用户会话体系的 zuul 网关部署还是分离的, 比如我们的管理后台 zuul 网关, APP zuul 网关, 开放平台 zuul 网关);
后端领域服务, 我们将原先的 dubbo fat jar 模式, 调整成了基于 spring boot 的spring mvc 应用, 提供 http 服务与网关配合集成, 同时保留原先的 dubbo 服务能力(因为接口实在太多了, 全部移除 dubbo 的话, 工作量太大), 我们默认从 zuul 过来的 http 接口, 都已经通过了鉴权校验, header 中的用户身份识别信息, 可以直接相信;

这套架构, 带来了以下好处:

APP 迭代更新速度大幅提升, 只要不是增加 jsbridge 等功能的改动, 我们不需要提交任何审核, 可以直接发布 webview 热更新资源包;
领域服务迭代时, 顺便就开发完成了对应的 http 接口, 基本上 zuul 网关我们完全都不用做任何改动;
因为新暴露的接口, 都是 http 协议, 并且在开发测试时, 不需要做鉴权(postman 设置对应的用户header), 测试人员可以做自动化接口测试(用的是 python);
因为通过 zuul 和 eureka 做了服务自动发现, 在系统发布时, 不需要运维人员手动去切换 nginx 流量操作;