前言
京麥服務市場是一個面向京東POP、物流配送、倉儲、供應鏈、金融等商家，由第三方提供軟件、培訓、模板裝修、代運營、質檢等服務的發布、共享、交易、結算、共贏的圍繞電商生態的平臺。那么京麥服務市場從無到有，從0到1的過程中都經歷了了什么呢，下面跟隨筆者來看看京麥服務市場在這段時間的歷經磨難和系統演進。
一 小荷才露尖尖角
在初始我們搭建了京麥服務市場，為服務商、商家提供了互通的橋梁，實現了PC版和移動版的插件市場，同時打造了服務商入駐、服務提審、審核發布、訂購履約及支付結算的服務生態閉環。下圖為當時整個京麥服務市場的系統架構圖：
當時開發人員較少、業務復雜度較低、系統交互少、開發時間緊張，所以采用了單體式應用，將業務糅雜在一起進行開發，這樣做在初期開發效率較快，可以滿足當時的業務需求，但是其中的問題也是顯而易見的。
隨著業務的發展，從業務上給我們增加了新的訂購規則，增加了升級、續費等訂購類型，添加了模塊等新商品模型，系統交互由原來系統內部模塊調用變為使用異步消息隊列通知和服務服務化調用，下圖為服務訂購流程：
在確定這個流程的過程時也是很坎坷的，在在確定流程初期，我們的方案是在訂購完成時將數據直接寫入當數據庫中，接入方通過服務化調用獲取存放在緩存中按需加載的數據，但是在執行該方案時，由于溝通的服務調用量與世紀服務調用量不符，導致提供服務異常并影響到其他業務功能，后修改方案，在訂購完成時將數據直接寫入當數據庫和緩存中并持久化緩存中數據，并通過worker將數據庫和緩存中數據進行比對來保證數據一致性。
二 路漫漫其修遠兮，吾將上下而求索
雖然上述方案滿足了業務上的需求但是其中存在的問題也是不能忽視的，單一業務功能存在問題時所用業務都會收到影響，而且在開發過程中簡單應用變得越來越大，模塊間依賴越來越復雜，在新增和修改業務功能時，要梳理原有流程才能開發，若梳理存在漏洞將會影響其他業務，業務擴展越來越困難，針對這些問題，我們對系統進行了架構升級，下圖升級后系統架構圖：
將現有業務進行了拆分搭建了開發者中心承載服務提審、插件市場承載訂購履約、運營中心承載審核發布、交易平臺承載支付結算等業務，從邏輯上和物理上將業務進行隔離使它們之間互補影響，隨著業務的拆離系統的增加，訂購支付流程也發生了很大的變化，下圖為升級后的訂購支付流程：
在整個訂購履約流程中采用服務泛化調用和異步消息隊列來進行系統交互，由于系統增多，業務流程加長，意味這在訂購支付流程失敗率會增高，對于訂購支付來說，成功率就代表著系統的穩定性，一筆訂單能否及時完成并進行后續履約對用戶來說是至關重要的。系統之間不可避免的會出現網絡抖動、接口不穩定等情況，會導致訂購履約流程無法流轉，這對用戶來說是不可接受的，對于這種異常情況，設計了相應的補償機制，通過系統字處理及時修復異常數據，并使訂購履約流程流轉下去；除此之外對于每一個重要的流程流轉步驟都會記錄日志，方便對問題的追蹤和恢復。
同時通過交易平臺根據不同接入方的業務需求將基礎支付能力進行組合，構建新業務能力提供給接入方，為其賦能，并通過插件市場將訂單履約信息以服務化的形式提供給開發者，幫助其提升用戶體驗。
三 欲窮千里目,更上一層樓
為了能讓系統更具有擴展性、更好的適應業務的變化，將業務相互影響減至小，我們對業務進行了更細粒度的拆分，同時對系統架構進行了一次升級，下面是升級后系統架構圖：
在其中我們為了提升用戶體驗將打造了服務前臺和服務中臺將前后端進行分離，新建訂單中心、支付中心、應用中心、結算中心、履約中心、商品中心等原子中心提供相應的基礎能力，
并對數據庫按照原子中心的力度進行拆分，使數據解耦。
總結
京麥服務市場經過一年多的時間中，在穩定、內容豐富、有了長足的發展。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
