架构实战(7)——界面代理
报价宝综合消息架构实战(7)——界面代理
按照分层的设计理念，互联网应用一般分为多个层
接入层：一般是负载均衡器或者Nginx，是流量的入口，按照特定的规则，转发流量到内部服务器。 web层：使用者登入的验证、鉴权等，和具体的业务解耦，业务实现则由服务层完成。一般的原则是：web层不依赖于数据库。Tips：在前后端分离的开发模式下，web层的专案，可以用nodejs开发，由前端工程师维护；也可以采用的后端技术栈开发，由后端工程师维护。我们团队采用的是后者，web层的专案由SpringBoot技术开发。 服务层：根据业务实际，划分成多个独立的服务，每个服务独立承担一项业务职责。 当然还有资料层、快取层等，因为和此文章无关，不做详细描述。
图1 - 互联网应用分层架构
从这个部署架构图上可知，浏览器的所有界面访问请求，都需要通过web层的转发，才能呼叫到内部的具体业务实现。
web层呼叫内部的业务界面，主要有两种实现的方案
方案一：单独实现。对浏览器提供的每一个界面，在web层中定义controller，组装引数后呼叫服务层的界面，然后把结果返回给浏览器。优点：对每一个界面做具体详细的控制，个性化能力更强。 缺点：微服务化的专案实践中，一般是按模组/微服务来分配工作的，例如A负责使用者微服务，B负责流程微服务等等。按照这种模式，工程师不仅关注自己的微服务专案，还需要关注web专案的实现，不利于工作职责的专注，增加了工作量。从架构的角度看，web层实现的工作流程是一样的：验证使用者状态-->呼叫内部服务。每个人都去写几乎同样的逻辑，既不经济，又容易导致不可控。方案二：界面代理。在web专案中，增加界面代理模组，约定浏览器界面和内部服务界面的对映规则，例如/webapi/1/usr/info/get对映到使用者服务的/webapi/1/info/get界面。在界面代理模组，根据界面的路径，转发呼叫到特定的服务例项上。这样做的优点很明显，工程师不需要再关注web专案了，只要做好的自己负责的微服务就好；对架构师也很友好，把界面呼叫的入口统一了，做调整或优化的时候，更容易入手。
图2 - 界面代理实现
引入界面代理的概念，有两个细节需要探讨。
1、界面访问越权问题。界面代理的实现，是根据url的规则进行转发的，恶意的攻击者，可以构造一些符合规则的url，试图访问内部服务的非公开界面。解决此问题，引入了界面代理白名单的机制，只有在白名单中宣告的界面，才能被转发到内部服务。2、非法引数透传。界面代理进行界面转发的时候，需要附带上浏览器提交的引数。使用者相关的敏感字段，例如当前使用者Id，需要从session中读取，而不能由透传浏览器传递的引数。解决此问题，引入引数黑名单机制，转发请求时，忽略在黑名单中的请求字段。
