【51CTO.com原創稿件】自2009年11月11日起，“雙十一”成為了一個盛大的狂歡購物節，一旦提到購物和電商，人們最關注的是GMV（商品交易總額），或者峰值時的壓力，反而忽略了此平臺擁有多么成熟的技術。

隨著雙十一的發展，越來越多的“賣家”參與進雙十一的活動中，這反而給阿里的技術帶來了很大的挑戰，雙十一的需求數量多，留給開發的時間短，質量要求又高。阿里巴巴業務平臺事業部的資深專家余剛老師坦言，如何降低開發的門檻，使每個業務都能自助研發交易平臺，來與峰值時的壓力抗衡，成為了阿里亟待解決的問題。

《企業門診》第二期和大家聊聊，交易平臺如何能更好的滿足業務方，從而提高研發效率。

病癥一：開發門檻高

從2009年至2016年，雙十一活動已經持續了7年，而阿里的技術也在不斷豐富和創新。面對眾多的支付業務，阿里選擇了各個業務都在同一交易平臺上完成的方式。此平臺是一個大流程，所有的業務都通過這個流程完成交易，流程上各個業務的定制點寫在一起，互相之間通過優先級、組合等關系完成一些業務場景。

一個好的平臺，是可以讓平臺上的用戶自助式的完成研發，而不需要依托平臺人員的支持才能完成。一旦滿足這個要求，平臺的門檻就要盡可能的降低。可是與之相反，能夠支撐應對各種情況的大型交易平臺，流程相對也會龐大、復雜，長此以往就會致使開發門檻變高，業務方無法自助完成研發。面對這相悖的問題，平臺應該如何降低開發門檻，成為了***問題。

病癥二：開發成本高

為了降低自助平臺的開發門檻，就不得不改變原有的離散定制點，其成本之高也成為了一大難題。離散式的定制點，使得每個業務方都要從零開始開發，難以復用，這樣下來就引發了兩個高成本問題：人工成本和時間成本。

阿里所用的交易平臺是流程很復雜的一種模式，要由專門的團隊來維護，每個業務方再配置各自的研發團隊。因為平臺開發門檻高，所以業務方的研發團隊需要平臺的維護人員支持，才能順利進行開發。如此反復，過程中就會耗費許多的人工成本。

加之，業務方的定制均混雜在一起，一旦某小業務出錯很可能會把非常重要的業務連累。簡而言之，流程上的每個業務都寫在一起，互相影響牽連，一錯均錯的模式會耽誤眾多業務的后續流程，浪費了太多的時間。

當意識到現有交易平臺并不能很好的滿足業務后，阿里對此進行了一次透徹的剖析。平臺一定要降低開發門檻，業務方不用了解全局后再進行開發，只要關注自己應關注的定制點即可。各個業務方的代碼也應該是相互隔離的狀態，并且平臺可以提供面對某一個業務場景的功能包，用來保證如果出現錯誤，問題方只影響自身業務，避免每個業務都從零開始開發所帶來的開發成本問題。

藥方：開放性與隔離性

業務能夠使用交易平臺進行自助開發，這就要求平臺具有開放性。以“雙十一”為例，參與活動的有數百萬商家，每個商家的活動都大同小異，標準化的平臺如何做到滿足數量如此之多的個性化交易要求呢？如果，向買賣雙方提供開放性的在線交易平臺，業務方就不需要考慮平臺全局，只要關注自己所需的定制點即可完成開發。這樣便相當于降低了開發門檻，高效滿足了業務的需求。

對于開發成本高的問題，余剛老師則認為，平臺一定要具備隔離性。平臺可以提供針對不同業務場景的業務包功能，業務包中包含業務的使用場景、業務產品和擴展點的定制，場景由實例構成。系統通過多種信息確定業務的唯一身份，再反饋到相應的業務包完成交易流程。通過這種“私人訂制”業務包功能，可以很好的避免業務與業務之間相互牽連的問題，從而提高研發效率，節約開發成本。

總結

對于需要多團隊協作的復雜平臺，要從平臺上所支持的業務方角度出發，如何降低其學習門檻，從而提升研發效率，這就是自助的理念。平臺要做好開放性，讓業務能開發；做好隔離性，讓業務敢開發，同時還要做好沉淀機制，讓業務與業務之間能復用更多能力，提升整體的研發效率。

延伸閱讀

阿里所使用的解決方案

• 基礎能力：通過域來組織交易的基礎能力，通過擴展點機制來提供業務方定制的可能
• 業務產品：跨域的定制，最終能完成一個具體業務場景，產品和業務可以直接使用
• 場景：一種具體交易模式的流程定義，場景中可以包括使用的業務產品的聲明
• 業務包：由業務方自己開發，業務包中指定了該業務所使用的場景，需要使用的業務產品，以及基礎能力中擴展點的定制。每個業務包都有自己的場景實例，系統在請求時通過商品和用戶等信息確定唯一的業務身份，路由到相應的業務包進行實現后，根據業務包中指定的場景、產品和擴展點完成業務的交易流程，這樣就做到了業務和業務之間的隔離
• 業務運營平臺：提供業務聲明周期的管理，比如業務創建、配置、下線等

每個層次通過代碼中的注解可以自動透出到運營平臺，通過運營平臺業務方就能看到自己業務選擇的場景、使用了哪些產品以及做了哪些定制。這些信息和代碼的實現完全一致，如此相當于有了一個動態的文檔，從而避免了原來文檔更新不及時，人員流動帶來的業務邏輯不清晰等問題，與此同時也降低了學習的成本。

***進行測試。人為的準備用例庫，難以保障覆蓋面，并且各個業務組合時，測試邊界并不清晰，線下環境測試的數據也不穩定，對于自動化測試的方法是很困難的。然而線上環境驗證又困難，所以對于測試來講，也有著不小的挑戰。

面對測試，阿里認為因為線上數據的場景是最完整的，所以用線上的數據來測試有保障，在利用自動測試，這樣也不會對線上產生影響。

最終測試方案，通過線上錄制請求，以及系統對外部服務的調用出入參，保存結果后，再線下讀取錄制結果，系統回放到驅動請求時，在執行過程中對外部服務的調用全部使用mock，且直接返回線上錄制再到對應的返回結果，整個過程自動執行，錄制的數據可以按照業務、場景等多個維度組織。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】