N年前曾有一個(gè)架構(gòu)設(shè)計(jì)的案例。

一、需求

【背景】

當(dāng)時(shí)集團(tuán)有10萬(wàn)名一線員工，每名一線員工工作都手持一個(gè)基于Android系統(tǒng)定制的移動(dòng)設(shè)備（下文簡(jiǎn)稱A設(shè)備）。類似于手機(jī)，通過(guò)SIM卡可進(jìn)行網(wǎng)絡(luò)通信。其上安裝多個(gè)應(yīng)用，支持多種業(yè)務(wù)。A設(shè)備其中一個(gè)附件設(shè)備可支持刷卡支付業(yè)務(wù)，簡(jiǎn)稱此應(yīng)用為pos應(yīng)用。另有一個(gè)用于無(wú)卡支付的應(yīng)用，簡(jiǎn)稱為pay應(yīng)用。由于發(fā)展歷程的原因，兩個(gè)應(yīng)用都是符合ISO8583協(xié)議要求，但對(duì)8583部分可自定義的字段由于業(yè)務(wù)場(chǎng)景的不同，有不同的自定義實(shí)現(xiàn)。而且這兩個(gè)應(yīng)用由不同的開(kāi)發(fā)團(tuán)隊(duì)實(shí)現(xiàn)，無(wú)法兼容。A設(shè)備除了pos應(yīng)用、pay應(yīng)用還部署了很多集團(tuán)旗下其它子公司的應(yīng)用。pay應(yīng)用、pos應(yīng)用作為前端，其對(duì)應(yīng)的后端應(yīng)用系統(tǒng)也是不同的。而根據(jù)業(yè)務(wù)發(fā)展趨勢(shì)，后續(xù)的業(yè)務(wù)類型會(huì)更多，而自定義的8583報(bào)文協(xié)議已經(jīng)顯示出力不從心。特別是從3G網(wǎng)絡(luò)升級(jí)到4G網(wǎng)絡(luò)，A設(shè)備承載的業(yè)務(wù)將增加圖像等多媒體信息。

【需求】

由于集團(tuán)發(fā)展戰(zhàn)略的需要，要進(jìn)一步加強(qiáng)終端設(shè)備的管控，將只允許A設(shè)備通過(guò)https直接接入集團(tuán)私有云，再由集團(tuán)的私有云接到原有機(jī)房服務(wù)器。如何設(shè)計(jì)一個(gè)改造方案，能以盡可能低的成本完成集團(tuán)要求并支持未來(lái)發(fā)展需要？

原有的部署：pos app / pay app ----( 8583協(xié)議基于tcp短連接 )----> bff ----（hessian rpc ) ----> ms 。
要求的部署：A設(shè)備（pos app / pay app） ---- ( https ) ----> 集團(tuán)的私有云 ---->公司 SF網(wǎng)絡(luò)區(qū)。

【補(bǔ)充】

1. 8583協(xié)議是基于ISO8583報(bào)文國(guó)際標(biāo)準(zhǔn)的包格式的通訊協(xié)議，8583包最多由128個(gè)字段域組成，每個(gè)域都有統(tǒng)一的規(guī)定，并有定長(zhǎng)與變長(zhǎng)之分。8583包前面一段為位圖，它是打包解包確定字段域的關(guān)鍵。8583協(xié)議都是請(qǐng)求響應(yīng)式，沒(méi)有會(huì)話狀態(tài)關(guān)聯(lián)多個(gè)請(qǐng)求?？蛻舳税l(fā)起一個(gè)請(qǐng)求，服務(wù)器端對(duì)應(yīng)的接收請(qǐng)求，驗(yàn)證請(qǐng)求，處理請(qǐng)求，響應(yīng)結(jié)果。8583報(bào)文是二進(jìn)制數(shù)據(jù)的格式。

2. bff是一個(gè)Backend for Frontend前置網(wǎng)關(guān)性質(zhì)的應(yīng)用系統(tǒng)，負(fù)責(zé)解釋8583報(bào)文，編排串聯(lián)并調(diào)用rpc微服務(wù)，再將rpc微服務(wù)響應(yīng)的結(jié)果，編碼成8583報(bào)文響應(yīng)給前端。前端app 通過(guò)8583協(xié)議訪問(wèn)bff前置系統(tǒng)。而其中的8583協(xié)議是BFF基于mima框架TCP短鏈接實(shí)現(xiàn)的，TCP有SSL安全層。一次請(qǐng)求與響應(yīng)，就對(duì)應(yīng)于一次TCP連接的打開(kāi)與關(guān)閉。bff前面有F5負(fù)載均衡器。

3. ms在這里是指后端的多個(gè)微服務(wù)架構(gòu)風(fēng)格的應(yīng)用系統(tǒng)，支持hessian 協(xié)議，micro-service-a, micro-service-b, micro-service-c... 。bff與ms都部署在公司Server Farms 網(wǎng)絡(luò)區(qū)，此網(wǎng)絡(luò)區(qū)與私有云有專線連接。

二、分析

1. pay app + pos app 需要支持?jǐn)?shù)千的TPS。
   并發(fā)請(qǐng)求不是太高。但A設(shè)備有10萬(wàn)，維持10萬(wàn)的長(zhǎng)連接成本較高，是沒(méi)有太多必要的。
2. 8583報(bào)文最大不超過(guò)10KB。
   對(duì)私有云至SF網(wǎng)絡(luò)區(qū)的專線帶寬有些要求。
3. 基本屬于重構(gòu)的范圍，不涉及業(yè)務(wù)功能的變化。但需要支持發(fā)展趨勢(shì)。一是一線員工需要假設(shè)一定的增長(zhǎng)速度。二是隨著A設(shè)備全部升級(jí)為4G網(wǎng)絡(luò)，能承載的業(yè)務(wù)也更多種多樣，8583報(bào)文的靈活性不及restful。
4. 已自定義的8583報(bào)文，按MESSAGE_TYPE+PROCESSING_CODE計(jì)算，包括請(qǐng)求與答復(fù)，按1000類報(bào)文評(píng)估。
   如果全部都直接改造系統(tǒng)代碼，改為restful風(fēng)格的URL形式，顯然是開(kāi)發(fā)與測(cè)試成本極大的。想要更低成本的解決方案，就必須保留8583報(bào)文原本的編碼解碼邏輯，將其報(bào)文內(nèi)容通過(guò)https傳輸。

三、架構(gòu)方案

【設(shè)計(jì)思路】

基于以上需求分析，架構(gòu)方案的主要思路是：8583 over http。
將8583二進(jìn)制報(bào)文內(nèi)容基于https協(xié)議傳輸。即在HTTP服務(wù)器的配置文件中增加一種自定義的MIME( Multipurpose Internet Mail Extensions)多用途互聯(lián)網(wǎng)郵件擴(kuò)展類型。例如content-type可命名為"application/pay8583", ”application/pos8583“。只要自已的http服務(wù)器能識(shí)別即可。如果http服務(wù)器不方便修改，采用application/octet-stream的content-type也是可行的。但需要另外定義一個(gè)http頭部字段標(biāo)識(shí)具體是哪一種8583自定義報(bào)文格式。

在集團(tuán)私有云部署3臺(tái)Nginx服務(wù)器，使其成下面的訪問(wèn)鏈路：

A設(shè)備（pos app / pay app） ---- ( 8583 over https ) ----> 私有云Nginx ----(8583 over http)----> bff ----（hessian rpc ) ----> ms 。

【pos app / pay app 改造】

1. 將原本的TCP(SSL)連接改為 https連接。按下文Nginx要求，增加請(qǐng)求及響應(yīng)時(shí)的http首部字段。
2. 8583報(bào)文不需要改動(dòng)，以二進(jìn)制格式通過(guò)https傳輸。

【私有云部署Nignx】

Nginx前可利用私有云已有的負(fù)載均衡器（例如可能的LVS-DR + Keepalive)。

1. 修改Nginx配置文件 mime.types。使其支持content-type "application/pay8583"，對(duì)于自定義的content-type，只支持post請(qǐng)求方法，不支持GET/PUT/DELETE/HEAD等請(qǐng)求方法。

2. 修改nginx.conf 的http配置塊，修改keepalive_timeout保持與前端一定時(shí)長(zhǎng)的連接。

3. 修改nginx.conf 的server配置塊，配置https ssl_certificate。Nginx可以卸載SSL層，轉(zhuǎn)換為普通的http長(zhǎng)連接給到BFF。

4. 修改nginx.conf 的location配置塊,proxy_pass。
   根據(jù)context反向代理至對(duì)應(yīng)的bff。例如 https://domain-name/pos 轉(zhuǎn)發(fā)至pos-bff，https://domain-name/pay轉(zhuǎn)發(fā)至pay-bff，https://domain-name/biz-new轉(zhuǎn)發(fā)至新的業(yè)務(wù)。不同的context可以對(duì)應(yīng)到不同的前端app/ 不同的業(yè)務(wù)類型 / 不同的子公司。biz-new可以采用新的restful風(fēng)格。domain-name/pay的業(yè)務(wù)可以在未來(lái)長(zhǎng)期的系統(tǒng)功能迭代過(guò)程中，慢慢的逐步的將8583報(bào)文轉(zhuǎn)換為restful風(fēng)格。如果原有業(yè)務(wù)長(zhǎng)期沒(méi)有變化，則保持為8583格式。

5. 保持與BFF的長(zhǎng)連接。

proxy_http_version 1.1;
proxy_set_header Connection "";
keepalive 16;

6. 轉(zhuǎn)發(fā)客戶端真實(shí)IP

proxy_set_header X-Real-IP $remote_addr;

7. 請(qǐng)求時(shí)，Nginx應(yīng)該轉(zhuǎn)發(fā)這些首部字段： Host， Accept， User-Agent， Connection， Keep-Alive， Content-Type， Content-Length。

8. 響應(yīng)時(shí)，Nginx應(yīng)該轉(zhuǎn)發(fā)這些首部字段：Connection， Keep-Alive， Cache-Control，Content-Type， Content-Length。

【BFF改造】

1. 需要增加一個(gè)DispatcherServlet，用于從http post的request body獲得8583報(bào)文，轉(zhuǎn)交給BFF原有的解碼器。

2. 增加一個(gè)Header8583Filter，用于檢查下面 8583 over https 設(shè)計(jì)中所要求的 HTTP 首部字段， 不合法時(shí)返回 400 狀態(tài)碼， 合法時(shí)設(shè)置響應(yīng)首部。
   Accept應(yīng)該為”application/pay8583“，User-Agent應(yīng)該為”<device_name>-<app_name>-version“，Content-Type應(yīng)該為”application/pay8583“，Cache-Control應(yīng)該為” no-cache“。
   當(dāng)BFF編排微服務(wù)， 發(fā)生了 Hessian 超時(shí)或其它意外異常時(shí)， 應(yīng)當(dāng)響應(yīng)500狀態(tài)碼。 嚴(yán)禁將服務(wù)器異常堆棧信息返回終端設(shè)備。

3. 待上線驗(yàn)證沒(méi)問(wèn)題后，逐步移除mina 框架。 改造后的方案不再使用 mina 框架， 而是利用了 Servlet 容器對(duì)于 Http 協(xié)議的支持。并且原本的大量的 TCP 短連接，已有私有云服務(wù)器 nginx 承接，轉(zhuǎn)變?yōu)樯倭康?http 長(zhǎng)連接。

4. 禁用Cookie，BFF不需要HttpSession。

5. 8583報(bào)文不需要改動(dòng)，后續(xù)ms都不需要有任何改動(dòng)。最大限度的減少開(kāi)發(fā)的工程量。