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

今天的文章來自李貝寧(Ben)，SAP成都研究院的資深程序猿和架構師。

做爲成都研究院裏同時精通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的原創技術文章，請關注公衆號"汪子熙"或者掃描下面二維碼: