共计 2972 个字符，预计需要花费 8 分钟才能阅读完成。
这期内容当中丸趣 TV 小编将会给大家带来有关如何理解 SCP Application Router，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
Routes
source: 可以是一个 URL，也可以是一个正则表达式，定义了当前的 route 是匹配什么样的请求路径
target: 当前请求如何被重写到目标地址
destination: 当前请求路由到 manifest 中的哪个目标地址
authenticationType: 有三种选择，xsuaa, none 和 basic，xsuaa 和 none 分别代表了是否对当前请求在 App Router 上做用户安全认证，下一节会具体介绍。Basic 是和 SAP HANA 集成的时候提供默认的安全验证支持。
Destination
Name: 用来跟 xs-app.json 中的 destination 配置相匹配
URL: 目标应用程序真实的 Clould Foundry 地址
ForwardAuthToken: 如果请求中带有 oauth token，是否将 oauth token 转发给目标应用程序. App Router 也支持 oauth token 的部分校验功能，所以用户也可以根据具体情况选择不转发 oauth token，就在 App Router 端校验
除了基本的路由功能，App Router 还提供了丰富的 Web 应用程序相关的功能支持，比如连接管理，session 管理，扩展 http 头，跨域，Web Socket 等等。
App Router 和 SCP UAA 的安全集成
如上一节提到的，App Router 在路由的时候提供了用户的安全认证支持。将路由的 Authentication Type 配置为 xsuaa，App Router 则会检查前端发过来的请求是否带有合法的 session。如果没有，App Router 会将用户导向 SCP UAA 的用户认证界面，当用户重新认证成功之后，会生成新的合法 session，并将此 session 返回给前端应用程序。
整个认证的流程是是 SCP App Router 和 SCP UAA 协同完成的，SCP UAA 是 SAP 对 Cloud Foundry 上提供的安全组件 UAA (User Account and Authentication Service) 的一个封装，Cloud Foundry UAA 是一个实现了标准 Oauth 2.0 协议的 authorization server，SAP 在此基础上做了一些自定义的增强，但是在接口上和原生的 UAA 保持了一致，这样可以尽可能的对 OAuth Client 端程序提供兼容性。
Cloud Foundry UAA 官方文档:
https://docs.cloudfoundry.org/api/uaa/version/4.10.0/index.html#overview
SCP 标准的 OAuth3.0 流程:
关于 OAuth3.0，请参见: https://oauth.net/2/
看到这里您也许会问，为什么不是前端浏览器作为 OAuth Client？除了安全性的考虑，App Router 将 OAuth 流程对前端隐藏的另一个好处是，各种前端应用程序不需要知道 UAA 上诸如 Client ID, Client Secret 的细节，提供了更好的安全性。
其次还有 SAP 在产品层面的考量，为了其标准的产品在 UI 技术上的一致性，包括 SCP 上的产品在内大多数都是基于 SAP UI5 来构建前端 UI，而 UI5 又是基于 HTML5 技术而来，即这些产品都是基于浏览器的富客户端应用。如此一来，在标准的 App Router 里面实现 OAuth3.0 流程可以使 SAP 的各种前端应用并不需要关注认证流程的细节。如上图所示，App Router 在完成了认证流程并最终拿到 token 之后，并没有将 token 返回给浏览器端，而是在 App Router 上生成一个 session，并且将 session 和 token 关联起来，App Router 在这里起到一个中介者的角色，对于前端统一用 session 进行交互，对于后端统一用 token 进行交互。
SCP 除了将标准的实现默认支持浏览器端应用程序外，作为一个开放的平台，当然也支持移动端原生应用程序的集成，这里不作赘述，具体细节可以参考 SCP 的开发文档。
App Router 上的 session 管理
App Router 上的 session 管理利用了 Node.js 的 session-express 框架，默认将 session 缓存在 instance memory 中 (下图第 79 行):
Session Stickiness:
https://stackoverflow.com/questions/10494431/sticky-and-non-sticky-sessions
这样做的好处是既利用了 instance memory 的高性能，也可以在一定程度上保证高可靠性。不过代价是牺牲了动态伸缩的能力，一旦某个 App Router 实例上还有正在使用中的 session，这个实例就不能被关闭。
好在 App Router 使用的是开源的 express-session 框架，该框架并非只能将 session 存储在 instance memory 中，在 Node.js 开源社区已经提供了多种 express-session 的外部存储方案。至少在技术上，可以将 App Router 提供的 instance memory 存储替换为外部存储，而不需要做太多的定制化开发，这样一来多个 App Router 实例就可以共享同一套 session 存储。
App Router 的可扩展性
只要说到 SAP 的产品，extensibility 是一个不可避免的话题，这是由 SAP 的业务是面向企业级客户这一特质决定的。SAP 也一直致力于从平台到框架，再到上层的产品，尽可能多的给 SAP 客户提供良好的可扩展性。App Router 同样也不例外，因为直接使用了 Node.js 的 connect 框架，这是一款本身就提供了丰富扩展的中间件框架，可以通过可插拔的方式对 Node.js 的请求和响应提供过滤和拦截，具体大家可以参考 connect 的主页。
App Router 基于 connect, 当然 App Router 的用户就可以直接获得 connect 提供的各种中间件，除此之外 App Router 还提供了自己的一些中间件:
是不是非常简单和直接？使用这些中间件而不需要修改原生 App Router 里面的代码。
这里不再对 App Router 上的各种中间件一一赘述。总结说来，App Router 是一款设计简单，使用方便，提供了良好可扩展性的反向代理组件，为广大 SAP 用户在 SCP 上开发应用程序提供了更多的选择和方便。
上述就是丸趣 TV 小编为大家分享的如何理解 SCP Application Router 了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注丸趣 TV 行业资讯频道。
