前天和朋友在一起聊天，聊到在做什麼，聽着他滔滔不絕地，真佩服他的記憶力，後面他說他都有記筆記的習慣，一篇篇的，什麼CSDN、javaeye、博客園，還自建博客。確實東西做久了，自然慢慢地也就淡忘了，回想一下以前做過的事，能記起來的還真屈指可數。
看看上次寫博文的時間是在2013年8月27日，距今已經4年了，這4年我在幹什麼？？
今天就說說支付服務的那些事吧。以此來對過去幾年做個小結。
系統演進
新的業務系統初建時，業務邏輯相對簡單，業務量也比較小，爲了能夠快速實現功能，發佈上線，大多數團隊都會把所有的邏輯都耦合在一個系統。這對於初期業務的快速迭代是有一定好處的。毫不例外，前公司的支付交易系統也採用了這樣的方式。
單體架構簡便快速，然而這種架構的缺點也很明顯，姑且不說高併發訪問，邏輯分散，隨着需求的迭代，後期難以維護。初接項目，問題很多，每天就是排查問題，和第三方確認交易等。好在深陷泥濘不久，就開始着手新支付服務設計實現。那麼，支付要解決的問題有哪些呢？
解決的問題
做系統時，我們往往需要先明確需求，所以我們先來看看支付服務需要解決的問題有哪些。
- 最原始和核心的需求，資金流動。
- 高可用。全天候提供服務。需要解決如下問題：
- 多機。熱發佈。
- 通信異常或超時。異常的交易如何保證交易最終一致性。
- 防雪崩。渠道偶也會有抽風時，他們抽風了，我們可不能跟着抽風。快速熔斷，防止大量資源（連接）被暫用。
- 通知下游服務失敗或異常時，重試通知。
- 易用性。滿足各種業務需求，各業務系統調用只需提供少量必要信息即可，接口簡單、調用方便。
- 簡單風控。對交易做校驗，識別並阻止誤交易或惡意交易。
- 防止重複交易。不用的業務場景，對重複扣款要求不一。對於同一用戶下同一業務的扣款，交易發起方可能會有多個，如：用戶自動發起、工作人員介入發起、系統定時扣款發起，即會下多個支付訂單，然由於業務要求多個支付訂單隻能有一筆支付成功。如何保證不會多扣用戶的錢，即需要防止對同一業務下的支付訂單重複扣款。而有些業務（如充值）又沒有此限制。
- 支付路由。爲保證服務的穩定可靠，一般會接入多個支付渠道互備。多個支付渠道，如何個性化選擇？一般考慮路由的的因素有如下：
- 不同業務對支付渠道有特殊要求。
- 同一業務不同時期對支付渠道有特殊要求。
- 支付渠道有個人問題（卡掛失、卡過期、交易金額超個人設置限額、未知異常等）和渠道問題（渠道下某個銀行未開通或交易金額超渠道設置限額、渠道跪了、渠道對個人餘額不足做次數限制等）導致不可用。
- 不同渠道費率可能不盡相同，省錢省錢省錢。
- 一般會將費率高的渠道作爲備用，然而作爲合作備胎也是有尊嚴的，你也是要時不時撩一下，給下希望，所以每天也得保證一定的交易量。
- 需求迭代。由於業務的特殊性，需求一直在迭代，經常需要接入新渠道。如何滿足快速的需求迭代？如何讓新人快速高效投產？系統架構要合理，高內聚低耦合。自動化測試釋放重複性的一些測試工作。
監控與預警。要保證系統的高可靠和高可用，監控必不可少。業務上，監控異常的交易。監控銀行和渠道的可用性。手續費預警，避免坐扣發生。系統運行情況監控等。
資源分配。按交易來源的不同，交易可以分爲兩類：一類是用戶發起，一類是系統定時批量交易。用戶發起的交易一定得先得到保證，然後又要兼顧系統定時批量交易。
- 異常交易快速發現及處理。系統難免有異常交易的情況發生。如交易超時、回盤超時、渠道或銀行系統抽風、掉單等。如何快速發現異常交易並快速修復異常。
- 動態配置。渠道或銀行系統難免會有維護的時候，尤其銀行節假日經常會有升級維護。維護期間或者他們的服務是不可用的，或者限制交易限額等等。智能路由也有如權重優先級等一些配置，等等此類的配置都是需要動態維護的。
- 全局異常處理。各業務調用方式不一，有RESTFUL接口DUBBO接口等。如何保證異常處理的一致性。
- 支付結果個性化通知。由於支持了不同的業務，而不同業務的後續處理方式是不同的，需要個性化通知下游系統。
- Fail fast。分佈式系統，要對每個模塊系統的可用性持懷疑態度，當出現某個系統不可用時（如發包），要能快速優雅地結束整個流程。這點設計出問題時可能會幫你避免影響的進一步擴大。舉個例子，服務出現過僅有的兩次事故，一次是路由服務機子磁盤滿了，一次是網絡問題，導致異常交易發生，“Fail fast”避免了雪崩效應，同時保證了交易的一致性，避免人工修數據情況的發生，爲服務的快速恢復提供了可能（從問題發現到服務恢復，均在十分鐘左右）。
- 埋點。涉及錢的，應該是一件很嚴肅的事。任何系統都會存在BUG，所以交易需要進行必要的埋點用於追蹤問題交易。
- 限制資源的使用。對於資源使用的限制設計是高可用系統最重要的一點，也是容易被忽略的一點，資源相對有限，用的過多了，自然會導致應用宕機。一般有如下限制：
- 限制連接數
- 限制線程創建
- 限制併發
- 限制內存的使用
- 狀態碼的學習。第三方支付渠道返回的狀態碼偶爾會變更（推測是第三方會切換渠道或者接入新的渠道），而新增的新狀態碼第三方往往通知不及時甚至不通知，新狀態碼在未能判定成功或失敗的情況下，是個未知狀態（寧可未知也不能誤判。這一點很重要，很多第三方在處理和銀行或其他第三方時，出現通訊超時或者未知狀態碼後就返回失敗，這導致了很多掉單情況的發生，踩了很多這樣的坑…），如何快速發現並學習新狀態碼的含義？
總之，需求很明確，就是適應互聯網應用的場景，也沒啥特別之處。後面有時間再理一下系統的演進實現吧。
轉載請註明出處！！！
http://blog.csdn.net/stuqbx