当我们准备做前后端分离项目时，我们在考虑什么？

Posted 2021-04-30 服务端技术杂谈

几年前做前后端分离项目的原因，是node刚刚横空出世，业界开始考虑如何真正的用js去写后端服务，于是就借鉴阿里中途岛项目去尝试，主要还是用到了node的密集io场景下的转发。

我们的新项目是采用前后端分离的方式进行开发，这一点主要是基于产品特点考虑而来，产品本身会有很强的富客户端的特点。

我们后端服务面向的客户端包含：ios，android，iPad，H5，还有一些游戏场景。所以最好的方式就是后端提供通用的restapi进行数据传输，而前端展示逻辑则交由不同客户端自己实现。

前后端分离项目主要基于微服务架构开发，既然是微服务，所以分布式系统所应该面对的问题一个也漏不掉。

JAVA微服务开发场景下，SpringBoot可谓神器，我们基于SpringBoot开发了一个可以快速开发的脚手架，脚手架本身包含了常用及通用的基本功能，如auth验证，功能鉴权，mysql，Mq，Redis及通用配置的依赖，这样开发工程师在需要开发新功能时，直接从对应的代码库拉下来，编译之后便可跑起来一个hello world的restapi项目。剩下的工作就是围绕业务逻辑去写repository，service，controller代码了。

通信

服务之间的通信主要可以通过HTTP，RPC方式，众所周知RPC调用的效率要高HTTP好几个等级，所以推荐使用RPC，但是综合考虑系统性能及可用性，快速开发等因素，我们也大量使用HTTP进行服务调用，同时我们也通过Golang对一些核心api，比如支付，交易类接口进行了重写，所以需要在系统效率及开发效率之间做好平衡。

接口规范

虽然是前后端分离项目，大部分是通过restapi方式给客户端暴露数据，但是也不可避免在系统中会存在自己的view页面，所以在api及controller命名上会建立：AuthApi，AuthController，约定大于配置，可以帮助我们后端对不同的请求做隔离和控制。

任务类系统

项目中不可避免存在大量的任务程序，主要需要做好数据备份，考虑分布式场景下的任务调度，资源分配问题，主要根据场景不同进行开发。 
我们采用Zk+定时任务自研的调度系统，也可以采用开源的Elastic-Job方案。

依赖梳理

这个是一个项目开发过程中最重要的一点，梳理好系统上下游所依赖的服务，同时梳理好服务之间的等级关系。

依赖关系主要分为两部分：依赖别人，被别人依赖；

依赖别人的服务，包含其他系统API及底层的数据库，Redis，MQ等服务，需要做好对方服务不可用的准备，随时做好降级，限流及开关功能，最好做成可配置，自动化。 
被别人依赖的服务做成高可用，幂等性，响应数据的可读性好等特点。

同时对服务依赖性梳理，哪些系统属于强依赖，哪些属于若依赖。

不同依赖的标准做好开关，降级，重试等功能，强依赖比如DB挂了，可以写日志，写到MQ。弱依赖可以做成柔性降级，比如写日志到ES中，ES不可用，可以直接降级即可。

对于黄金等级服务，则一定保证服务高可用，可以做灾备，比如依赖集群，多个机房，也就是这个服务是不可降级的，必须准备多套方案保证服务可用。

关于依赖降级可以使用Hystrix做。

用户友好性

做好最坏的打算，如果后端服务全部不可用，前端转发问题等，一定不要给用户一个错误页面，一定建立多级缓存，有数据托底，无论如何保证页面上有内容的。

总结

综上所述，做好工具，梳理好服务依赖，对服务做等级划分，弱依赖可以通过降级，限流方式处理。强依赖则必须通过多种灾备手段保证高可用，不要给用户感到恐慌的页面，要有数据托底。