通用业务服务化之后,系统的典型后端结构如上:
web-server 通过 RPC 接口,从通用业务服务获取数据
biz-service 通过 RPC 接口,从多个基础数据 service 获取数据
基础数据 service 通过 DAO,从独立 db/cache 获取数据
db/cache 存储数据
随着时间的推移,系统架构并不会一成不变,业务越来越复杂,改版越来越多,此时 web-server 层虽然
使用了 MVC 架构,但以下诸多痛点是否似曾相识?
产品追求绚丽的效果,并对设备兼容性要求高,这些需求不断折磨着使用 MVC 的 Java 工程师们(本文以
Java 举例)
不管是 PC,还是手机 H5,还是 APP,应用前端展现的变化频率远远大于后端逻辑的变化频率(感谢那些
喜欢做改版的产品经理),改 velocity 模版并不是 Java 工程师喜欢和擅长的工作
此时,为了缓解这些问题,一般会成立单独的前端 FE 部门,来负责交互与展现的研发,其职责与后端
Java 工程师分离开,但痛点依然没有完全解决:
一点点展现的改动,需要 Java 工程师们重新编译,打包,上线,重启 tomcat,效率极低
原先 Java 工程师负责所有 MVC 的研发工作,现在分为 Java 和 FE 两块,需要等前端和后端都完成研发,
才能一起调试整体效果,不仅增加了沟通成本,任何一块出问题,都可能导致项目延期
更具体的,看一个这样的例子,最开始产品只有 PC 版本,此时其系统分层架构如下:
客户端,web-server,service,非常清晰。
随着业务的发展,产品需要新增 Mobile 版本,Mobile 版本和 PC 版本大部分业务逻辑都一样,唯一的
区别是屏幕比较小:
信息展现的条数会比较少,即调用 service 服务时,传入的参数会不一样
产品功能会比较少,大部分 service 的调用一样,少数 service 不需要调用
展现,交互会有所区别
由于工期较紧,Mobile 版本的 web-server 一般怎么来呢?