探究平臺化設計的核心思想和Lattice的設計原則

小霖2012發表於2023-03-28

一. 平臺對業務敏捷支撐的挑戰

早期阿里的交易中臺遇到了一些挑戰，這個在毗盧的部落格中有提到，主要遇到了這些問題：新小業務都有一個成長規律，在早期業務模式驗證階段，需要的玩法比較簡單，希望能頻繁的釋出快速試錯。我們以電商領域為例，在成熟的電商體系下，有眾多複雜、龐大的平臺，如交易平臺、商品平臺、營銷平臺等。雖然這些平臺對於天貓、淘寶各種業務模式、玩法都支撐得很好，但對於新小業務而言，這些模式、玩法在早期並不適用，他們希望平臺能按照自己的要求做一些裁剪。

  • 早期的交易平臺的下單流程是硬編碼方式寫死的。整個流程，無論什麼業務，都必須要與優惠系統、物流系統、卡券平臺等系統對接。新業務開發時，必須要確保整個下單過程與這些服務的整合不會出現呼叫異常，一旦有異常出現，就需要與相關係統協調看如何遮蔽錯誤。
  • 商品單價計算邏輯也沒有很好在平臺中得到解耦，也沒有提供可擴充套件機制。汽車金融業務的商品單價是來源於支付寶的微貸系統。最終，該業務也只能以硬編碼方式，在平臺計算商品單價的地方，與其他業務的程式碼混在一起去編寫相關計算邏輯。這部分程式碼因為可能會影響到其他業務，所以程式碼在釋出上線前，必須經過嚴格的全網迴歸驗證，以確保不會對其他業務產生影響以及資損。
  • 汽車金融業務的釋出節奏因此也必須跟隨平臺版本的節奏，只能耐心的等待每週一次的全網迴歸驗證後，才能進行釋出，無法按自己的意願隨時釋出。
    以上內容來自： https://www.ryu.xin

有贊交易遇到的瓶頸
早期的有贊交易也遇到類似的問題，17年以後公司迅速發展壯大，團隊規模擴張了數倍，業務線也從單一的微商城電商交易擴充套件到多個垂直行業。然而，交易團隊卻面臨了許多尷尬的情況：

首先是垂直行業的接入問題，由於交易團隊的響應速度無法跟上業務團隊的迭代速度，垂直行業被迫自行開發了一套針對自身業務的交易系統，導致公司技術資源浪費。這包括商業化服務訂購、收銀、批發等業務。

其次，交易團隊新加入的成員發現交易核心開發非常困難，必須先完全理解整個系統，才敢嘗試開發，這增加了學習成本。

另外，許多交易玩法無法組合，如果想要組合，就必須重新編碼，將組合方案作為一個新方案進行開發，例如虛擬商品的拼團業務、酒店的分銷業務等。這限制了產品運營同學創意想法的快速實現。

最後，一個小需求的上線可能會導致核心交易系統大面積故障，影響無法隔離。

二. 基於可複用模式的平臺支援：加速業務發展

在現代企業架構中，企業級業務架構規劃已經關注面向能力的規劃，超越了面向功能與服務的規劃。如何透過能力的識別和規劃來最大化沉澱企業級可複用能力，以及如何將這些能力應用到更多的場景中，透過擴充套件、編排和組合等形式，是平臺型企業架構需要解決的核心問題。為了應對業務的快速迭代、多場景和不確定性，企業需要在平臺上構建可複用的“能力”，併為這些能力提供必要的擴充套件和可變機制，以便為不同前臺提供靈活多變的業務服務，滿足不同前臺的差異化個性化需求。這些“能力”可根據粒度的不同，細分為“基礎能力”、“能力元件”和“解決方案”三個層級。不同業務的差異性可以透過“能力的擴充套件點”設計和不同“業務身份”在擴充套件點上的“擴充套件實現”進行區分。

說明：基礎能力、能力元件和解決方案概念來自ThoughtWork現代企業架構白皮書

下單的基礎能力
在現代企業架構中，基礎能力被認為是支撐業務運營的關鍵要素。例如，交易下單的一些基礎能力包括快遞可達性和同城可達性校驗、下單扣減庫存、支付扣減庫存、子訂單計價能力、收單能力等。這些基礎能力的識別和規劃對於企業級業務架構的規劃至關重要。透過將這些基礎能力沉澱成為企業級可複用的能力，企業可以在多個場景中應用這些能力，從而最大化效益。

為了更好地應對業務的快速迭代、多場景和不確定性，企業需要在平臺上構建可複用的能力，並提供必要的擴充套件和可變機制，以此為不同的前臺提供靈活多變的業務服務，滿足不同前臺差異化個性化的需求。這些能力可以分為三個層級：基礎能力、能力元件和解決方案。基礎能力是企業架構中最基本的能力，而能力元件則是由多個基礎能力組成的較高層級的能力。最高層級的能力則是解決方案，它是一組能力元件的集合，可以滿足特定的業務需求。

在不同業務之間的差異性，則可以透過能力的“擴充套件點”設計和不同“業務身份”在擴充套件點上的“擴充套件實現”進行區分。透過這種方式，企業可以針對不同業務的需求，快速擴充套件和定製能力，從而滿足不同的前臺業務需求。

三. Lattice能力的定義

能力模型(Ability)
針對買家下單過程中需要計算運費和建立物流訂單的場景，在電商交易中，我們可以為不同的業務場景設計各種物流方案。例如，在國內不同城市之間的物流配送中，可以針對不同地區的快遞可達性和同城可達性進行校驗，以便為買家提供最佳的配送服務。在下單後，我們可以利用基礎能力，如下單扣減庫存和支付扣減庫存，來保證訂單的準確性和庫存的實時管理。

除此之外，我們還可以考慮如何在不同的業務場景下，透過擴充套件和組合不同的能力來提供更靈活和個性化的服務。例如，為了應對高峰期的訂單量激增，我們可以透過組合子訂單計價能力和收單能力，來提高交易系統的處理能力。同時，我們也可以透過基礎能力的不斷擴充套件，如增加新的快遞配送服務、更加靈活的計費方式等，來滿足不同業務的差異性和個性化需求。

在實現可複用的能力方面，我們需要考慮基礎能力、能力元件和解決方案這三個層級的劃分，併為不同業務場景設定擴充套件點和擴充套件實現，以實現更加靈活和個性化的服務。透過這樣的方式，我們可以最大化地沉澱企業級可複用的能力，併為業務的快速迭代、多場景和不確定性提供支援。

  • 傳統透過快遞進行配送的物流方式（例子中，我們定義 NormalLogisticsAbility）
  • 基於線下門店自提方式進行履約的物流方式。 這種方式，貨品發到門店，但交易訂單產生後不會有實際物流，使用者需要人肉到線下門店去提貨。比如，買輪胎，輪胎不是寄到家裡，而是自己開車去4S店去安裝已購買好的輪胎。 （例子中，我們定義 OfflineLogisticsAbility）
  • 虛擬物品發貨方式：比如卡密等商品。。
    無論這些物流方式外在的差異有多大，但他們總有一些共性的功能是可以抽象成統一的介面。比如，無論何種運輸方式，他都需要計算運費價格、需要在物流訂單上儲存物流資訊等。平臺> 則以面向介面的方式，去呼叫這些抽象好的介面，最終可實現平臺核心穩定，同時也能支援未來新的運輸方式的擴充套件。
@Ability(name = "OrderLine's Price Ability")  
public class OrderLinePriceAbility extends BaseLatticeAbility<OrderLinePriceExt> {  
  
    public OrderLinePriceAbility(OrderLine bizObject) {  
        super(bizObject);  
    }  
    public Long getCustomUnitPrice(OrderLine orderLine) {  
        return Optional.ofNullable(reduceExecute(p -> p.getCustomUnitPrice(orderLine),  
                        Reducers.firstOf(Objects::nonNull)))  
                .orElse(orderLine.getUnitPrice());  
    }  
    @Override  
    public BlankOrderLinePriceExt getDefaultRealization() {  
        return new BlankOrderLinePriceExt();  
    }}

能力SPI擴充套件(Extension)

能力是指某種實體或個體在特定環境下展示出的可行動的潛能，而這些行動是可以被擴充套件的。就像人的手，它天生具備抓握、捏取等能力，但是透過加裝手套或者增加外掛，比如手指尖的抓握延伸器等，就能夠進一步擴充套件手的功能，讓人具備更多的操作能力。類似地，在電子商務的場景中，為了滿足不同的需求，我們需要根據不同的物流方案來計算運費和建立物流訂單，這些行為的實現也是可以透過擴充套件不同的能力來完成的。

總的來說，能力不僅僅是一個固定的概念，而是可以透過不同形式的擴充套件和組合來實現更多的行為，從而適應不同場景和需求的。
定義一個“自定義子訂單商品單價”的擴充套件點，允許業務能夠去實現該擴充套件點，返回商品的自定義單價

public interface OrderLinePriceExt extends IBusinessExt {

    String EXT_ORDER_LINE_CUSTOM_UNIT_PRICE = "OrderLinePriceExt.EXT_ORDER_LINE_CUSTOM_UNIT_PRICE";

    @Extension(
            code = EXT_ORDER_LINE_CUSTOM_UNIT_PRICE,
            name = "Custom the Item's unit price of OrderLine",
            reduceType = ReduceType.FIRST
    )
    Long getCustomUnitPrice(OrderLine orderLine);
}

業務(Business)
"關於垂直業務"可以用"行業"來替代。這是因為每個行業都有自己的一套規則和標準，而不同的行業之間存在明顯的差異。雖然有時候會有跨界合作，但是對於某些行業的規則和術語，只有在這個行業內部的人才能真正理解。這就好比在不同的山間穿梭，每個山谷的景色都不盡相同，需要有足夠的經驗才能明白其中的奧秘。

在程式設計中，我們使用 @Business 註解來定義業務，例如業務A，編碼為 "business.a"。這有助於我們更好地區分不同的業務，併為每個業務定義其獨特的規則和邏輯。

@Business(code = "business.a", name = "Business A")
public class BusinessA extends BusinessTemplate {
}

然後，針對業務A，定義它的商品自定義單價為 2000 (單位分)。

@Realization(codes = "business.a")
public class BusinessAExt extends BlankOrderLinePriceExt {
    @Override
    public Long getCustomUnitPrice(OrderLine orderLine) {
        return 2000L;
    }
}

產品(Product)
產品是一個服務，有完整功能、能對外輸出並能形成業務場景，快速支撐業務場景的功能集合體。定義團購場景 “GroupBuyProduct” 產品

@Product(code = GroupBuyProduct.GROUP_BUY_PRODUCT_CODE, name = "Group Buy Trade Product")
public class GroupBuyProduct extends ProductTemplate {

    public static final String GROUP_BUY_PRODUCT_CODE = "lattice.productGroupBuyProduct";

    @Override
    public boolean isEffect(ScenarioRequest request) {
        if (request instanceof BuyScenarioRequest) {
            boolean effect = StringUtils.equals("groupBuy", ((BuyScenarioRequest) request).getSource());
            System.out.println("GroupBuyProduct effect status:" + effect);
            return effect;
        }
        return false;
    }
}

一旦我們識別和構建了平臺的基礎能力和能力元件，就可以讓不同的業務根據其特定需求來複用這些能力並快速進行定製。這可以透過配置和開發基礎能力下的擴充套件點來實現，以下是示例：

(圖片來自ThoughtWork)

相關文章