背景
典型的APP设计。客户端和服务端之间的交互是一个重要的环境。几乎没有APP能够保证不和后端通信。同时受限于客户端版本发布的掣肘。很多时候后端接口的升级无法实时反映到客户端。但是很多时候后端相关接口的升级又势在必行。
例子1： 读取客户端用户信息的接口上面。最近增加了用户等级相关的信息。客户端发版要在一周之后，但是客户端在渲染用户界面的时候没有对用户等级信息字段做相关解释。或者在协议中没有针对用户等级的解释。如果贸然增加字段，会导致客户端不可预期的结果。这个时候需要针对不同版本做相关的逻辑。老版本不动，新版本增加新的字段。
例子2： 如果服务端想要做模块划分。或者独立出来某些功能。那么需要在客户端针对一组URL做相关的改动。这个时候就会出现客户端需要在新版本中针对url做批量改动。同时在服务端又需要针对老版本的客户端做兼容工作。如果发布的版本较多。那么就会出现多个版本的接口并行的情况。流量一直要持续到版本的迭代周期，短则几个月，长则一两年。
针对以上情况，如果是小规模的app，管理起来还可以维护，但是如果规模较大。往往多个模块和多个功能分别部署与多个集群。那么就是同一组功能的多个接口部署在不同的集群上面。要同时维护的内容就变成了一个乘积。
只有逻辑接入层的部署结构如下图：
接入层的解决方案
如果是大厂一类的公司。一般会有比较完善的统一流量调度层。如百度的BFE 。通过这一层，根据不同的请求path将流量转发到不同集群。但是设计此层面的更大作用是流量调度。流量保护等相关事情。对于深入到业务的事情，接入层也无能为力。并且一般接入层的设计是不侵入业务的，也就是说接入层只用来管理流量。不关注具体的业务实现。
接入层的功能往往不能满足业务的相关需求。例如上面例子2中提到的整体URL切换。这个时候要在接入层完成流量转发。就需要大量的rewrite规则来实现。不易维护。
一般接入层负责的事情是将整体的流量进行转发。不会关注接口的语义内容和上下游关系。这个时候例子1里面的问题也不能够解决。
接入层能够解决的问题
- 流量的调度和转发，不同模块之间的。从A模块到B模块。
- 流量保护，过载保护。
- 针对不同的url或者uri进行流量转发和调度。
- 针对不同版本，不同地域做流量调度和分发。
接入层解决不了的问题
- 接口的字段注入。如用户信息等。例如给所有接口注入统一的用户信息字段。
- 接口接收和返回内容的协议转换如PB-JSON。
- 统一的加解密，验签逻辑。
- 针对多个下游服务的统一缓存。例如组合了多个下游微服务接口的缓存逻辑。
- 组合多个业务模块的数据。对多个模块之间的串行数据获取进行组合，减少请求的整体处理时间。
- 用户层面的session保持。cookie以及header的管理等操作。
在这样的情况下，我们就有必要把接入层划分成两部分，一部分用来专门执行相关的流量调度，另外一部分执行业务相关的逻辑。这样通过业务的接入层就能够实现流量接入层无法完成的一些操作，当然这样的部署结构也会带来一定的弊端，比如我们增加了一层业务相关的部署逻辑，相应的响应时间就会变长。但是带来的好处也显而易见。我们通过业务接入层，能够实现流量接入层无法实现的很多功能。而且通过这样的部署结构。我们能够将客户端和服务端对接的接口固定下来。相关的功能改动只需要在业务接入层完成即可。
整体的部署结构如下：
业务接入层的整体设计思想就是：
要完成上面通过流量接入层无法完成的事情。并且要保证高效率。不能出现复杂的业务逻辑。
这样RD的角色可以专心关注业务接入层的相关逻辑。通过业务接入层的功能能够实现相关的业务功能。同时还可以通过一些管理手段来给业务接入层增加一个管理平台，用来管理业务相关的逻辑。
而OP角色就能够专心关注流量接入层。保证流量的稳定。