1. 如何使用API 網關做服務編排
服務編排/數據聚合 指的是可以通過一個請求來依次調用多個微服務，並對每個服務的返回結果做數據處理，最終整合成一個大的結果返回給前端。
例如一個服務是「查詢用戶預定的酒店」，前端僅需要傳一個訂單ID，後端會返回整個訂單的信息，包括用戶信息、酒店信息和房間信息等。
這個服務背後可能對應著以下幾個操作：
微服務架構上對功能做了解耦，使用服務編排可以快速從各類服務上獲取需要的數據，對業務實現快速響扒畢應。總的來說，編排有以下幾點優勢：
Goku API Gateway （中文名：悟空 API 網關）是一個基於 Golang 開發的微服務網關，能夠實現高性能 HTTP API 轉發、服務編排、多租戶管理、API 訪問許可權控制等目的，擁有強大的自定義插件系統可以自行擴展，並且提供友好的圖形化配置界面，能夠叢念快速幫助企業進行 API 服務治理、提高 API 服務的穩定性和安全性。
Goku API Gateway支持一個編排API對應多個後端服務，每個後端服務的請求參數可以使用前端傳入的參數，也可以在編排里自定義（寫靜態參數或從返回數據里獲得）。每個後端服務的返回數據支持過濾、刪除、移動、重命名、拆包和封包等操作；編排API能夠設定編排失敗時的異常返回。
Goku API Gateway 的社區版本（CE）同時擁有完善的使用指南和二次開發指南，內置的插件系統也能夠讓企業針對自身業務進行定製開發。
項目地址： https://github.com/eolinker/goku-api-gateway
官網地址： https://www.eolinker.com
我們將編排的整個操作滲此困放到網關進行，由網關對數據做處理與轉換，這樣無需對後端服務做改動。一個請求到達網關，網關調用多個後端服務，並且在網關上對各個服務的返回數據做處理（操作有過濾、移動、重命名、封包、拆包，後面會對各操作做詳細解釋），最後由網關將數據整合好返回給前端。
網關將編排過程中對 API的轉發處理過程 （轉發->獲取返回數據->數據處理）稱為一個 Step 。
添加一個轉發服務，該服務為 查詢訂單詳情API，配置相應的轉發地址、傳入的參數、對返回數據做何種處理等。
由於篇幅原因，後續的Step（查詢用戶詳情、查詢酒店詳情、查詢房間詳情）就不一一展示了。
網關將編排過程中對 API的轉發處理過程 （轉發->獲取返回數據->數據處理）稱為一個 Step。
我們將處理查詢訂單詳情API稱為 Step1 ，其中Step1的返回數據有：用戶ID、酒店ID、房間ID。同理，將查詢用戶信息這步稱為 Step2 ，將查詢酒店信息稱為 Step3 ，將查詢房間信息稱為 Step4 。
傳參規則：
以下為轉發路徑的傳參寫法：
Step2中需要接收Step1里返回的userID作為參數，同時需要接收前端傳入的Authorization參數
在網關里Step2的請求參數配置如下所示，請求參數存在多個的話用換行表示：
1.查詢訂單詳情的API，返回數據稱為json1，內容如下：
2.查詢用戶詳情的API，返回數據稱為json2，內容如下：
3.查詢酒店詳情的返回數據，稱為json3，內容如下：
4.查詢房間詳情的返回數據，稱為json4，內容如下：
5.可以在每一個Step里對返回Json做處理，網關會將處理過的數據最後整合起來，再返回前端，例如這是通過網關返回的最終數據：
這里以查詢酒店詳情API的返回數據json3為例，講解網關如何在編排過程中對返回數據做處理。
查詢酒店詳情API返回的原始數據如下：
從網關返回給前端的數據中截取酒店信息的數據如下：
從原始數據到處理後的數據需要經過以下操作：
欄位黑名單的作用是排除某些欄位，支持數組形式。
在網關的Step3里配置如下：
經過網關處理後，實際的返回數據如下，可以看到data對象里的id欄位已經被過濾掉：
拆包是指將指定對象的內容提取出來作為該步驟（step）的返回結果。其中匹配目標只能為object，匹配目標為空時，結果為 {}，可用於清除數據。
在網關的Step里配置如下：
經過網關處理後，實際的返回數據如下，可以看到data對象被拆開，最終數據僅保留了data對象裡面的欄位：
欄位封包會將當前的數據整體打包為最終返回數據中的一個對象，不支持*，不支持數組。
在網關的Step里配置如下：
經過網關處理後，實際的返回數據如下，數據被整體打包為hotelinfo對象：
經過三個步驟，就可以將原始數據變成最終的數據。
本文僅列舉了編排過程中部分數據處理的操作，如需了解更多編排細則，可通過文末給出的教程鏈接。
相關鏈接
2. 業務梳理-電商-訂單管理模塊
Java工程師知識樹
訂單中心是一個電商後台系統的樞紐，在這訂單這一環節上需要讀取多個模塊的數據和信息進行加工處理，並流向下一環節；因此訂單模塊對一電商系統來說，重要性不言而喻。
同時，訂單是一個公司生存甚至盈利的核心，而電商系統中的訂單系統則是支撐訂單處理的載體，因此訂單系統的設計則十分重要。
要了解訂單系統，首先我們要從訂單系統的信息架構上去認識訂單系統，從而對訂單系統建立整體認知；
定義：為適應組織分工的需求和提升效率，系統將整個交易業團如務流程拆分成若干個可控的環節。
1.在訂單過程中進行安全校驗，主要是為了檢測用戶是否在黑名單上，用戶購買行為是否正常等，當檢測到不正常時終止下單；
2.從商品中心獲取塌轎啟商品信息（SKU，規格，價格等）
3.從營銷中心獲取商品，訂單促銷信息（優惠券,促銷活動）,判斷是否滿足優惠條件，計算出優惠金額。
4.在會員中心獲取會員權益，例如平台抵扣積分，優惠券折扣條件等。
5.在調度中心檢驗銷售層庫存，按照調度規則鎖定區域庫存。
6.根據拆單規則（商家，倉庫，訂單類型等）將訂單拆分成若干個子訂單，根據運費模板計算運費，根據商品金額，運費，優惠金額計算應付金額（實付款）。
定義：是指在實際銷售中將訂單的優惠去分攤到每一件SKU中去結算。
訂單實付金額=商品金額（SKU金額總計）+運費-總優惠金額
總優惠金額=促銷活動優惠金額+優惠券優惠金額+虛擬幣抵扣金額
按照商品比例分攤。
案例：
訂單中有甲乙兩店的商品A、B、C、D、E 包郵。商品A，D參加跨店滿200減40的活動（活動1），商品B，C參加滿100減10的活動（活動2）另外用戶還使用了100元現金券。
訂單優惠金額=40+10+100=150元.
依據優惠分攤原則：則各項的優惠金額為：
定義：為了方便訂單的發貨與結算，系統依據一定的規則（物流、倉庫等因素）將用戶訂單拆分成若干個發貨單。
不同店鋪：在電商平台類架構下，由於商品歸屬權不同，涉及財務結算和物流發貨的問題，需要根據店鋪歸屬問題對訂單進行拆單。例如淘寶，天貓的商品在下單時會將訂單根據不同店鋪進行拆分成若干個子訂單。
不同倉庫：若同一訂單分散在不同倉庫，則應按照倉庫歸屬進行拆分訂單。當一件商品在多個倉庫有貨時，應根據物流的區域的時效選擇倉庫進行拆單。
不同品類：由於商品的屬性不同一樣會產生拆單需求，例如易碎品需要特殊包裝，超大物品（鋼琴，座椅）需要單獨包裝。有些商品不能放在一起，同樣需要拆單。
物流因素：不同物流公司對單個包裹的重量或體積都有特殊要求，需要根據帆洞SKU的毛重和體積來計算包裹的總重量和體積，超出物流公司限制的也需要拆單。
商品價值：根據商品價值需要拆單的主要涉及海淘和跨境的商品；國家對每筆跨境訂單有單次限額，對年度跨境商品訂單總金額也有限制，當單次購買金額超過限制金額時，也需要對訂單進行拆單。
訂單正向流程相對常規，業務雖然從商品中心，物流，會員，倉庫，內容等各大模塊進行數據交互，但涉及的業務邏輯易於理解，所以難度並不大。
但在訂單逆向流程中，業務流程和邏輯則相對復雜。因為在訂單正向流程中，每一個環節都有可能觸發逆向訂單任務流；而在訂單正向任務流中，每一個子環節上的商品在後台出庫發貨流程中所處的具體節點不一致，所以不同節點觸發的訂單逆向流程的處理規則則有差異。
定義：訂單逆向流程是為了解決在訂單流程中出現的退貨退款的業務流程。在前端訂單狀態下，各個環節都有觸發的可能，而訂單的不同節點觸發訂單逆向流程的處理方式不同。訂單觸發訂單逆向流程，可以按照主體與客體劃分，可分為用戶端觸發和商家端觸發兩種。
1. 待付款取消訂單
說明：待付款訂單取消訂單分為兩種情況：
在待付款訂單狀態下，取消訂單無需客服審核。流程圖如下：
2. 待發貨取消訂單
說明：在待發貨訂單狀態下取消訂單時，此時應根據訂單此時所在的節點作出處理。
由於訂單在支付完成後，發貨單可能已經推送至WMS，甚至已經交接發貨，狀態未及時回傳更新。為避免貨款兩失，要先暫停訂單出庫，在調度中心查詢訂單是否推送至倉庫。
若尚未推送至倉庫，則停止推送至倉庫；若已經推送至倉庫，則去wms中心去攔截，攔截成功則暫停出庫。
3. 待收貨/交易成功退貨
說明：在用戶提交退貨申請後，需經過客服審核。審核通過則回到原有狀態，審核通過後則進入退貨流程並告知用戶退回地址及收件信息，此時進入退貨流程。系統生成退貨入庫單，當倉庫收貨後，進行退款。
在待收貨狀態下平台設計者仍需考慮退貨是否全退的問題。當SKU全退時，原訂單則中止進入交易關閉狀態。當訂單中發生部分退貨時，原訂單的狀態不變，維持待收貨或交易成功狀態，同時退貨的部分生成交易售後訂單。剩餘未退貨部分仍然允許申請售後。
注意：在訂單流程逆向流程中，涉及到財務數據的處理時 ，為了保證財務數據的真實性及可追溯性（這與會計數據的處理原則有關，具體問下會計或者財務同學），都不能直接在原訂單狀態下修改，因此在設計訂單逆向流程時應注意這一點。
3. 在APP開發中電商APP的前端和後台主要功能分別都有哪一些
一般來說相比於其他的行業類型的APP，電商類、商城類APP算是比較復雜的，而且還會涉及到購買支付與商家收款這種很重要的功能，那麼 濟南文匯傳媒 的我可以和大家一起來看看關於 電商類APP 在開發中App的前端和後台分別有哪些主要功能？讓您對電商類 APP開發 有一個大致了解。
首先我們來看一看在App端的主要功能有什麼？
一、商品展示
商品展示的功能應該算是整個APP里最為重要的功能之一了，畢竟電商類APP為的就是把商品推廣出去讓用戶去買，商品展示大多是使用圖片展示，會將商品進行分類，點擊進去就是關於商品的詳細信息，用戶可以直接購買或者收藏商品加入購物車內，能直觀的看到商品的優惠信息等。
二、商品搜索
如果用戶有了明確的商品目標那麼他就會直接使用搜索功能，這樣也是流量的入口，只有保證用戶流量，APP才能更長久的存在。
三、個人中心與客服中心
這個功能內主要是面向用戶提供的比較基礎的服務，比如登錄注冊、幫助中心、更新升級、關於我們等，也可以看到自己的購買搜索或購買歷史。在這里用戶也可以直接與平台客服進行售前、售後的溝通，及時維護用戶利益。也是必備功能。
四、購買支付
因為涉及到了移交支付，所以這個功能是要注重安全的，能夠在這里管理購物車內的商品，查看用什麼方式去支付。
其次，再來看一下APP的後台功能有什麼？APP的後台一般就是商家對於APP的管理了。
一、積分管理
會有一個商品的列表與商品信息，能夠查看用戶積分使用兌換情況，商家也可以制定積分如何使用。
二、財務管理
對用戶支付、結算、提現、扣費的統一管理。
三、用戶管理
可以查看用戶信息和對用戶許可權的管理。
四、訂單管理
查看訂單的狀態，能夠對已經有的訂單進行管理搜索。
五、商城管理
對於入駐的電商類APP平台的商家進行系統管理，刪除或者添加。
以上，就是濟南文匯傳媒的我為大家總結的有關電商類APP的前端和後台的主要功能了，當然在實際開發製作中還有很多比較常見的細節使用功能與服務，比如UI組件、擴展功能等，等下次我會為您一一介紹！