「中大型公司」支付服務架構演進之路，解決實際問題！
今天就說說支付服務的那些事吧。以此來對過去幾年的創業經歷做個小結。
系統演進
新的業務系統初建時，業務邏輯相對簡單，業務量也比較小，為了能夠快速實現功能，發布上線，大多數團隊都會把所有的邏輯都耦合在一個系統。這對於初期業務的快速迭代是有一定好處的。毫不例外，前公司的支付交易系統也採用了這樣的方式。
單體架構簡便快速，然而這種架構的缺點也很明顯，姑且不說高併發訪問，邏輯分散，隨著需求的迭代，後期難以維護。初接項目，問題很多，每天就是排查問題，和第三方確認交易等。好在深陷泥濘不久，就開始著手新支付服務設計實現。那麼，支付要解決的問題有哪些呢？
解決的問題
做支付服務也有兩年多了，總結下支付服務要解決的有哪些問題。
Advertisements
最原始和核心的需求，資金流動。
高可用。全天候提供服務。需要解決如下問題：
多機。熱發布。
通信異常或超時。異常的交易如何保證交易最終一致性。
防雪崩。渠道偶也會有抽風時，他們抽風了，我們可不能跟著抽風。快速熔斷，防止大量資源（連接）被暫用。
通知下游服務失敗或異常時，重試通知。
易用性。滿足各種業務需求，各業務系統調用只需提供少量必要信息即可，介面簡單、調用方便。
簡單風控。對交易做校驗，識別並阻止誤交易或惡意交易。
防止重複交易。不用的業務場景，對重複扣款要求不一。對於同一用戶下同一業務的扣款，交易發起方可能會有多個，如：用戶自動發起、工作人員介入發起、系統定時扣款發起，即會下多個支付訂單，然由於業務要求多個支付訂單隻能有一筆支付成功。如何保證不會多扣用戶的錢，即需要防止對同一業務下的支付訂單重複扣款。而有些業務（如充值）又沒有此限制。
Advertisements
支付路由。為保證服務的穩定可靠，一般會接入多個支付渠道互備。多個支付渠道，如何個性化選擇？一般考慮路由的的因素有如下：
不同業務對支付渠道有特殊要求。
同一業務不同時期對支付渠道有特殊要求。
支付渠道有個人問題（卡掛失、卡過期、交易金額超個人設置限額、未知異常等）和渠道問題（渠道下某個銀行未開通或交易金額超渠道設置限額、渠道跪了、渠道對個人餘額不足做次數限制等）導致不可用。
不同渠道費率可能不盡相同，省錢省錢省錢。
一般會將費率高的渠道作為備用，然而作為合作備胎也是有尊嚴的，你也是要時不時撩一下，給下希望，所以每天也得保證一定的交易量。
需求迭代。由於業務的特殊性，需求一直在迭代，經常需要接入新渠道。如何滿足快速的需求迭代？如何讓新人快速高效投產？系統架構要合理，高內聚低耦合。自動化測試釋放重複性的一些測試工作。
監控與預警。要保證系統的高可靠和高可用，監控必不可少。業務上，監控異常的交易。監控銀行和渠道的可用性。手續費預警，避免坐扣發生。系統運行情況監控等。
資源分配。按交易來源的不同，交易可以分為兩類：一類是用戶發起，一類是系統定時批量交易。用戶發起的交易一定得先得到保證，然後又要兼顧系統定時批量交易。
異常交易快速發現及處理。系統難免有異常交易的情況發生。如交易超時、回盤超時、渠道或銀行系統抽風、掉單等。如何快速發現異常交易並快速修復異常。
動態配置。渠道或銀行系統難免會有維護的時候，尤其銀行節假日經常會有升級維護。維護期間或者他們的服務是不可用的，或者限制交易限額等等。智能路由也有如權重優先順序等一些配置，等等此類的配置都是需要動態維護的。
全局異常處理。各業務調用方式不一，有RESTFUL介面DUBBO介面等。如何保證異常處理的一致性。
支付結果個性化通知。由於支持了不同的業務，而不同業務的後續處理方式是不同的，需要個性化通知下游系統。
Fail fast。分散式系統，要對每個模塊系統的可用性持懷疑態度，當出現某個系統不可用時（如發包），要能快速優雅地結束整個流程。這點設計出問題時可能會幫你避免影響的進一步擴大。舉個例子，服務出現過僅有的兩次事故，一次是路由服務機子磁碟滿了，一次是網路問題，導致異常交易發生，「Fail fast」避免了雪崩效應，同時保證了交易的一致性，避免人工修數據情況的發生，為服務的快速恢復提供了可能（從問題發現到服務恢復，均在十分鐘左右）。
埋點。涉及錢的，應該是一件很嚴肅的事。任何系統都會存在BUG，所以交易需要進行必要的埋點用於追蹤問題交易。
限制資源的使用。對於資源使用的限制設計是高可用系統最重要的一點，也是容易被忽略的一點，資源相對有限，用的過多了，自然會導致應用宕機。一般有如下限制：
限制連接數
限制線程創建
限制併發
限制內存的使用
如果想學習Java工程化、高性能及分散式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java進階群：694549689，群里有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。
具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加群。
在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加群。
如果沒有工作經驗，但基礎非常紮實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的可以加群。
狀態碼的學習。第三方支付渠道返回的狀態碼偶爾會變更（推測是第三方會切換渠道或者接入新的渠道），而新增的新狀態碼第三方往往通知不及時甚至不通知，新狀態碼在未能判定成功或失敗的情況下，是個未知狀態（寧可未知也不能誤判。這一點很重要，很多第三方在處理和銀行或其他第三方時，出現通訊超時或者未知狀態碼后就返回失敗，這導致了很多掉單情況的發生，踩了很多這樣的坑…），如何快速發現並學習新狀態碼的含義？總之，需求很明確，就是適應互聯網應用的場景，也沒啥特別之處。後面有時間再理一下系統的演進實現吧