編者按：本文系 美團智慧支付技術負責人李星亮 講師，在由掘金技術社群主辦，以非同步社群與 python之禪（劉志軍公眾號） 協辦的《系統架構演進設計 | JTalk 第九期 – 北京場》 活動上的分享整理。JTalk 圍繞以系統架構演進開發主題的系列線下活動。每期 JTalk 會邀請優秀技術團隊和工程師線上下分享技術乾貨。旨在為開發者提供線下技術交流互動機會，幫助開發者成長。
我只是一名普通的程式猿。開篇我先給大家丟擲這次分享的核心要點： 沒有最好的架構，只有最合適的架構。（這個只是這次活動的一堂課分享O(∩_∩)O）
支付業務發展迅猛， 從一開始的單一POS機產品擴充到二維碼、秒付、小程式、小白盒、小黑盒、輕收銀、輕pos等8大類產品
產品的交付週期越來越短
團隊成員逐步增加、協同作戰越來越多
系統穩定性要求越來越高
支付業務還要滿足不用的業務來適應不用的需求
- M端 ： 產品 + 售賣 -> 產品和商家關係的處理
- C端 : 支付 + 資源整合 + 營銷獲客
- B端 ： 商戶後臺管理
支付方式越來越多,我們需要如何處理應對？
相關挑戰
- 快速相應
- 一天發版多次
- 管理越來越混亂
- 系統越來越臃腫
- 呼叫線路越來越長
- 對接的參與系統越來越多等等
我的思路
第一步：先搞定人，再弄明白事
- 統一認知
- 規範制度建設
- 團隊文化建設
- 業務技術改造
統一認知
新人團隊，統一認知非常重要
- 數不完的pm需求(適當過濾) ————>業務系統
穩定性的認知？
系統穩定性標準
- 平均失效前時間(MTTF)
- 平均恢復時間(MTTR)
- 系統可用性：(1 – MTTR/(MTTF + MTTR)) * 100%
- 業務傾向用N個9來量化可用性
智慧支付穩定性要求：
- 訂單可用性: >=5個9
- 訂單損失量: <1% (日訂單量) (故障時間<5min)
定規範
- 開發流程規範
- 發版規範
- 程式碼稽核規範
- 上線規範
打造團隊
- 正能量
- 主人翁
- 學習型團隊
- 激勵
業務改造
- 緊跟業務
- 分期迭代
- 專題梳理
今天的我們如何設計架構才能合適的、合理的？
架構是什麼？
其實就是應對不同發展階段，使用合理技術思想和手段來match和支撐業務的一種思想；
吐槽：這個需要大量時間和經驗來積累的，暫時我是不敢想O(∩_∩)O
架構原則
- MVP階段
- 技術選擇 ：熟練掌握的技術、和大團隊方向一致(有人給你兜底)
- 業務分層 ：資料層、服務層、接入層拆分清晰
- 方便運維 ：依賴、部署簡單，All-In-One
- 發展階段
- 快速實現，但要強調抽象性和結構性
- 明確系統定位 劃清系統邊界
- 核心目標是支援業務，有時候不合理的存在是合理的
- 穩定期
- 全面解耦
- 服務化/元件化
- 彈性伸縮 持續演進