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

i042416發表於2018-04-22

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

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

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

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

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

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

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

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

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

天微星九紋龍史進。

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

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

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

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

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

而李貝南，在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還提供了自己的一些中介軟體: