作為成都研究院裏同時精通Java, JavaScript和ABAP這三門編程語言的數位同事之一，Ben曾經先後擔任了成都CRM Fiori開發團隊，S4CRM開發團隊和尚未發布的某款雲產品開發團隊的架構師。

Ben在這三個團隊的職責都是產品架構設計和部分功能代碼的編寫，以及組內其他同事的代碼審查。

除了自身架構設計和編程相關的技能過硬之外，Ben在傳業授道解惑方面也很有心得。Ben是SAP研究院內部的Agile Software Enginnering教練，也是SAP成都研究院若幹內部培訓課程的講師。他的課程幫助了很多剛剛走出大學校園的年輕同事們從在學校書寫玩具代碼到走向真正的企業軟件開發的專業之路。

每位同時精通數門風格截然不同的編程語言的開發人員，總有自己的一套心得和辦法，把這些語言融為一體，為自己所用。那麽Ben又是如何做到的呢？或許可以從Ben的業余愛好看出點端倪。Ben喜歡足球和圍棋，並且水平在業余愛好者裏不算太差。能同時駕馭這一動一靜，一剛一柔，一陽一陰的兩個愛好，除了Ben以外，我能想到的也就只有這幾位高手了：

1. 人到中年，把降龍十八掌練到超過洪七公造詣的大俠郭靖。

豈知郭靖近二十年來勤練九陰真經，初時真力還不顯露，數十招後，降龍十八掌的勁力忽強忽弱，忽吞忽吐，從至剛之中竟生出至柔的妙用，那已是洪七公當年所領悟不到的神功?

2. 左手短刀，右手長鞭的峨眉美女掌門周芷若。

周芷若取出軟鞭，右手一抖，鞭子登時卷成十多個大大小小的圈子，好看已極，左手翻處，青光閃動，露出了一柄短刀。群雄昨日已見識了她軟鞭的威力，不意她左手尚能同時用刀，一長一短，一柔一剛，那是兩般截然相異的兵刃。群雄驚佩之下，精神都為之一振。

3.?天微星九紋龍史進。

水滸傳裏雖然有幾位武力值爆表的好漢，比如盧俊義，史文恭，林沖這些，但是書中他們從始至終都只使用一種武器。而史大郎在戰場上和別人拼命時，曾先後使用了三種不同的武器，其中還包含中國古代武將很少有敢嘗試的高難度武器——流星錘。

史進大怒道：“賊回子敢如此猖獗！”便輪著三尖兩刃四竅八環刀，直取蘭生。蘭生急舉獨足銅人，敵住史進。兩下各顯武藝，奮勇大鬥。

史進換了一支點鋼丈八蛇矛，驟馬出來。哈蕓生見了，便挺著手中五股托天叉，一馬沖來，直取史進。二人也不打話，兩馬相交，叉矛並舉，一來一去。只見史進那枝矛，忽高忽低，忽前忽後，忽左沖，忽右掠，揮身上下，盡是一片矛影。

說時遲，那時快，史進早已手提流星錘，換了一匹高頭大馬，趕到陣前。蘭生飛起銅人打去，沙冕二人一齊攢上。史進耍圓那顆流星錘，擋住三人。

書中提到的史大郎在八十萬禁軍教頭王進的指導下，十八般武藝樣樣精通，果然名不虛傳。

而李貝寧，在SAP成都研究院三支分別使用Java, JavaScript和ABAP的開發團隊裏都被任命為架構師，技術的全面性不輸於史大郎。

據我所知李貝寧喜歡的球星是被球迷冠以“拼命三郎”，“鐵人”稱號的內德維德，喜歡他在球場上不惜體力奔跑那種鐵血作風。李貝寧希望自己在球場上也能做一個像內德維德那樣的拼命三郎。

Jerry不是球迷，只知道咱歷史上也有一位拼命三郎：

作為一個八零後，Jerry幼年在這些卡片上沒少花錢。如果您有同樣的收藏愛好，歡迎後臺交流。

下面是李貝寧的正文。

大家好，我叫李貝寧，也可以叫我Ben, 目前在SAP成都研究院某雲產品項目組擔任高級開發工程師和架構師。

我是09年加入SAP的, 之前在上海花旗集團軟件中心做了4年銀行系統開發， 進到SAP之後先在SAP上海研究院工作了兩年，於11年底轉到了SAP成都研究院直至現在，算起來在成都呆了快七年了。

除了編程之外，我還有兩個鐵打不動的愛好，足球和圍棋，水平嘛分別算得上小區球星級和街道業余高手級... 我認為這兩件事一個可以保持身體上的活力，一個可以保持頭腦上的活力，所以至今一直堅持每周踢一場球和下幾盤棋的節奏，當然同時也作為工作之余的放松。

這篇文章就SAP Hybris某款正在開發的雲產品在SAP雲平臺上用到的一個組件Application Router(以下簡稱App Router)做一個介紹。

SCP App Router是SAP雲平臺(以下簡稱SCP)上的核心模塊之一，作為獨立運行在SCP Cloud Foundry環境中的一個應用程序，它主要支持以下兩大核心功能：

• 反向代理：將外部請求分發給SCP Cloud Foundry環境內不同的應用程序。

• 安全集成：和SCP Cloud Foundry上的核心安全組件UAA無縫集成，提供了用戶認證，會話管理等安全相關的功能。

說到這裏您也許馬上會想到Nginx，一款優秀的開源Web服務器，用來做類似反向代理的功能。如果我的應用程序想要用Nginx，可不可以呢？其實SCP並沒有限制只能用App Router——它是一個完全開放的平臺，您可以部署任意你想要的組件為應用程序服務，只是SAP在上面已經提供了一系列的基礎設施組件，這套SAP原生組件之間提供了更佳的集成和協同，App Router就是其中之一。

理解App Router的技術選型

App Router是一個用Node.js構建的標準的Web應用。

眾所周知Node.js作為一門開放的技術環境，在構建基於HTTP的Web應用上有先天的優勢:?簡單，高效。並且Node.js經過近幾年的快速叠代和發展，已經非常成熟和穩定，再加上開源社區提供了豐富的庫，Node.js已經成為了服務器端強大的應用開發環境。SAP選擇Node.js作為其雲戰略平臺上的核心組件的技術棧，從這個選擇我們也能看出SAP在雲戰略上的思路是逐步走向開放。

您或許會問，Node.js是單線程模型，根據上面的示例圖，所有對於部署在SCP Cloud Foundry上的後端訪問都通過App Router，這會帶來性能問題嗎？其實這是對於Node.js運行時模型的一個誤解，參考一張Node.js的運行時架構圖:

Node.js對於應用程序端只提供了單線程的編程模型，但是其底層的運行架構並非是單線程模型。在Node.js中各種HTTP訪問，數據庫的讀寫，文件IO的訪問都是以異步的方式代理給了底層的V8引擎，主線程不會被阻塞，而底層V8引擎具備非常強大的並發處理能力，會迅速將各個事件並發的處理結果通過事件輪詢的方式返回給主線程。只要在Node.js的主線程中不做大量的CPU運算（比如大規模業務邏輯運算，科學計算等），這樣的Node.js應用程序是可以具備良好的性能的。

而App Router恰好具有上述所說的那些一典型特征：在用戶認證中將識別用戶身份和權限的工作代理給Cloud Foundry UAA來做，業務請求轉發給各個獨立的部署Cloud Foundry應用，自己僅僅做一些簡單的HTTP參數的轉換和校驗，請求的轉發，以及請求響應的返回。

App Router上的routing(路由)

在App Router上路由的實現是通過定義一系列destination來實現的，具體來說就是在App Router的xs-app.json中配置route和destination，以及在manifest.yml中配置對應destination的url：

manifest.yml:

簡單解釋一下主要的參數：

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標準的OAuth2.0流程:

如果熟悉OAuth2.0協議，從這張流程圖上很快就能看出App Router和UAA之間是通過Authorization Code Grant Flow來交互的，在交互過程中它們分別充當了OAuth Client和OAuth Server的角色。

關於OAuth2.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裏面實現OAuth2.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策略來保證在多實例部署的情況下，相同會話的請求會被發送到同一個實例上以保證會話能繼續進行。

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的Github文檔。

總結說來，App Router是一款設計簡單，使用方便，提供了良好可擴展性的反向代理組件，為廣大SAP用戶在SCP上開發應用程序提供了更多的選擇和方便。

感謝大家閱讀。

要獲取更多Jerry的原創技術文章，請關註公眾號"汪子熙"或者掃描下面二維碼:

SAP成都研究院李三郎：SCP Application Router簡介