安居客 Android App 走向平臺(tái)化

image

首發(fā)于微信公眾號(hào)：BaronTalk

安居客 Android App 距離上次的模塊化/組件化重構(gòu)已經(jīng)兩年多了，重構(gòu)之后很好的支撐了兩年多以來(lái)的業(yè)務(wù)發(fā)展。但這個(gè)世界總是在向前走的，沒(méi)有任何一種架構(gòu)能夠一勞永逸的解決所有問(wèn)題，外部環(huán)境的不斷變化相應(yīng)的也要求項(xiàng)目架構(gòu)做出改變，以此來(lái)應(yīng)對(duì)環(huán)境變化所帶來(lái)的挑戰(zhàn)。

本文分享的就是我們安居客 App 團(tuán)隊(duì)這次向平臺(tái)化轉(zhuǎn)型的背景、轉(zhuǎn)型過(guò)程中所面臨的問(wèn)題、挑戰(zhàn)、我們的解決方案以及我個(gè)人在這個(gè)過(guò)程中的收獲和感悟。

一. 背景

自 18 年以來(lái)的市場(chǎng)環(huán)境大家都知道，各大公司都在縮減開(kāi)支、提升組織效率，希望用更少的投入帶來(lái)更多的產(chǎn)出，以此來(lái)應(yīng)對(duì)經(jīng)濟(jì)下行帶的不確定性。在這個(gè)大背景下，集團(tuán)在 18 年底做出了一系列人效提升、業(yè)務(wù)整合的動(dòng)作。

拿房產(chǎn)業(yè)務(wù)舉例：58 App 里的房產(chǎn)業(yè)務(wù)之前是由北京的房產(chǎn)團(tuán)隊(duì)開(kāi)發(fā)的，而整個(gè)安居客 App 是由我所在的上海安居客團(tuán)隊(duì)開(kāi)發(fā)的。在這次調(diào)整之后，北京的房產(chǎn)團(tuán)隊(duì)作為一條垂直業(yè)務(wù)線來(lái)負(fù)責(zé) 58 App 和安居客 App 中的租房業(yè)務(wù)的開(kāi)發(fā)，安居客團(tuán)隊(duì)則繼續(xù)負(fù)責(zé)整個(gè)安居客 App（包含新房、二手房、內(nèi)容、IM 等業(yè)務(wù)）的開(kāi)發(fā)，同時(shí)還要開(kāi)發(fā) 58 App 中二手房、新房、房產(chǎn)大內(nèi)容等業(yè)務(wù)。

image

這樣一次調(diào)整給我們帶來(lái)了三大挑戰(zhàn)：

  1. 在人力不變，工作量翻倍的情況下，我們要如何保證業(yè)務(wù)的迭代速度不受影響？
  2. 由以往的「單兵作戰(zhàn)」變成了跨團(tuán)隊(duì)跨地域協(xié)作開(kāi)發(fā)，我們要如何作為一個(gè)平臺(tái)方來(lái)和業(yè)務(wù)方協(xié)作開(kāi)發(fā)？
  3. 對(duì)于 58 App 而言我們是業(yè)務(wù)方，對(duì)于北京房產(chǎn)團(tuán)隊(duì)而言我們是平臺(tái)方，我們要如何同時(shí)處理好雙重角色？

面對(duì)這些挑戰(zhàn)我們需要轉(zhuǎn)變開(kāi)發(fā)思維、改進(jìn)項(xiàng)目架構(gòu)。

一次項(xiàng)目重構(gòu)和架構(gòu)升級(jí)，不只是要解決當(dāng)下的問(wèn)題，更要為未來(lái)一到兩年的業(yè)務(wù)發(fā)展提供支持。為了解決這一系列的問(wèn)題，我們聯(lián)合 58 無(wú)線團(tuán)隊(duì)、58 房產(chǎn)團(tuán)隊(duì)、前端、后端多個(gè)團(tuán)隊(duì)的同學(xué)一起發(fā)起了「木星計(jì)劃」，也開(kāi)啟了我們的平臺(tái)化轉(zhuǎn)型之路。

二. 問(wèn)題、挑戰(zhàn)及解決方案

當(dāng)公司的業(yè)務(wù)調(diào)整政策下來(lái)以后，團(tuán)隊(duì)面臨的最急迫的一個(gè)選擇是繼續(xù)在 58 App 上維護(hù)老的房產(chǎn)代碼，迭代新功能；還是將安居客現(xiàn)有業(yè)務(wù)搬遷到 58 App 實(shí)現(xiàn)一套代碼在兩個(gè) App 里運(yùn)行呢？

  • 前者我們需要分一半的人力去開(kāi)發(fā) 58 App，這必然導(dǎo)致團(tuán)隊(duì)的需求消化量減半，業(yè)務(wù)迭代速度受影響。好處是暫時(shí)不用做任何技術(shù)上的改造。

  • 后者需要我們協(xié)調(diào) 58 無(wú)線、58 房產(chǎn)、前后端等多個(gè)團(tuán)隊(duì)一起對(duì) App 做一次「大手術(shù)」，同時(shí)還需要說(shuō)服產(chǎn)品團(tuán)隊(duì)容忍改造期間業(yè)務(wù)迭代速度的放緩。好處是能夠一次性將安居客上的房產(chǎn)業(yè)務(wù)搬遷到 58 App 上，后續(xù)我們只需針對(duì)房產(chǎn)業(yè)務(wù)做一次開(kāi)發(fā)就能跑在兩個(gè) App 上，用一份人力做了兩份的活，開(kāi)發(fā)效率翻倍。

為長(zhǎng)遠(yuǎn)計(jì)，我們最終選擇了后者?？墒且龅揭惶状a雙端運(yùn)行并不容易，58 App 和安居客 App 隸屬于北京、上海兩個(gè)不同的團(tuán)隊(duì)開(kāi)發(fā)，大家底層庫(kù)不一樣，技術(shù)方案不一樣，開(kāi)發(fā)模式也不一樣，要達(dá)到我們的目的必然要費(fèi)一番功夫。接下來(lái)我從整體到局部逐步介紹我們?cè)谄脚_(tái)化演進(jìn)過(guò)程中的設(shè)計(jì)思路、遇到的問(wèn)題和解決方案

2.1 整體設(shè)計(jì)

所謂平臺(tái)化，就是安居客 App 要作為一個(gè)平臺(tái)來(lái)對(duì)平臺(tái)上承載的各種垂直業(yè)務(wù)提供服務(wù)，每個(gè)服務(wù)都需要對(duì)上層提供標(biāo)準(zhǔn)化的接口來(lái)支撐平臺(tái)上各類垂直業(yè)務(wù)的功能。

image

這一次的項(xiàng)目重構(gòu)除了要轉(zhuǎn)型平臺(tái)型 App 支持其他業(yè)務(wù)的接入和未來(lái)業(yè)務(wù)的發(fā)展，還有更重要一點(diǎn)是要做到一套代碼在 58 和安居客雙平臺(tái)運(yùn)行。

要做到這一點(diǎn)，在現(xiàn)有的業(yè)務(wù)體系和代碼體量下雖然工作量巨大，但大的思路確是很清晰簡(jiǎn)單的：

  • 底層庫(kù)能統(tǒng)一的盡量統(tǒng)一；
  • 短時(shí)間內(nèi)無(wú)法統(tǒng)一的庫(kù)以及平臺(tái)特性通過(guò)中間層屏蔽平臺(tái)差異。

安居客 App 架構(gòu)調(diào)整

針對(duì)安居客 App ，我們需要調(diào)整架構(gòu)，引入一個(gè)平臺(tái)中間層并針對(duì)平臺(tái)中間層接口做安居客 App 側(cè)的實(shí)現(xiàn)，并將垂直業(yè)務(wù)中原本調(diào)用平臺(tái)接口的地方改為調(diào)用中間層接口。同時(shí)將之前的業(yè)務(wù)組件層細(xì)分為「平臺(tái)級(jí)組件」和「業(yè)務(wù)級(jí)組件」，所有垂直業(yè)務(wù)不再依賴平臺(tái)級(jí)組件，只依賴平臺(tái)中間層和業(yè)務(wù)級(jí)組件，并明確業(yè)務(wù)代碼遷移的邊界。

image

58 App 架構(gòu)調(diào)整

同時(shí) 58 無(wú)線團(tuán)隊(duì)的同學(xué)也改進(jìn)了他們的架構(gòu)，和我們一樣引入了平臺(tái)中間層及中間層在 58 App 上的實(shí)現(xiàn)，保證安居客業(yè)務(wù)遷移進(jìn)來(lái)后能正常編譯運(yùn)行。

image

上面這兩張架構(gòu)圖呈現(xiàn)了兩個(gè) App 架構(gòu)調(diào)整的大方向，具體做了哪些、遇到了哪些問(wèn)題我在下面的小節(jié)里一一介紹。

2.2 平臺(tái)中間層屏蔽底層差異

計(jì)算機(jī)領(lǐng)域的任何問(wèn)題都可以添加一個(gè)中間層來(lái)解決。58 App 和安居客 App 作為兩個(gè)不同的平臺(tái)，對(duì)業(yè)務(wù)層提供的能力是不一樣的，接口、方法名都是不一樣的。同一塊業(yè)務(wù)代碼要跑在兩個(gè)不同的平臺(tái)，必然要引入一個(gè)中間層來(lái)抹平差異、屏蔽底層細(xì)節(jié)，同時(shí)對(duì)外提供統(tǒng)一的接口供業(yè)務(wù)層調(diào)用。

因此 58 無(wú)線團(tuán)隊(duì)、58 房產(chǎn)團(tuán)隊(duì)和我們安居客團(tuán)隊(duì)三方協(xié)商，共同制定了一套平臺(tái)中間層 API，然后兩個(gè)平臺(tái)再針對(duì)平臺(tái)中間層 API 做具體實(shí)現(xiàn)。

image

為了便于后期管理、劃清代碼邊界，我們將平臺(tái)中間層服務(wù)進(jìn)一步細(xì)化，根據(jù)平臺(tái)差異性將中間層劃分為平臺(tái)公共服務(wù)、安居客平臺(tái)特有服務(wù)、58 平臺(tái)特有服務(wù)等。以 Java Package 作為區(qū)分,劃分到不同的包結(jié)構(gòu)下。一旦后期某一特有服務(wù)變成了公共服務(wù)，則將其往平臺(tái)公共服務(wù)遷移。

image

在實(shí)現(xiàn)上，平臺(tái)中間層會(huì)提供一系列 Service 接口供垂直業(yè)務(wù)調(diào)用，同時(shí)提供一個(gè) PlatFormServiceRegistry 類用來(lái)注冊(cè)和獲取服務(wù)。

public class PlatFormServiceRegistry {

    ...

    /**
     * 注冊(cè)服務(wù)
     */
    private void registService(Class serviceInterface, Class<? extends IService> serviceImpl) {
        if (serviceInterface != null && serviceImpl != null ) {
            classMap.put(serviceInterface.getName(), serviceImpl);
        }
    }


    /**
     * 獲取服務(wù)
     */
    private <T> T getService(Class<? extends T> service) {
        
                ···
          
        IService instance = serviceImplMap.get(service.getName());
        if (null == instance) {
            try {
                Class<? extends IService> serviceClass = classMap.get(service.getName());
                if (serviceClass != null) {
                    instance = serviceClass.getConstructor().newInstance();
                    serviceImplMap.put(service.getName(), instance);
                }
            } catch (Exception e) {
                Log.d(TAG, e.toString());
            }
        }
        return (T) instance;
    }
}

在使用方式上，平臺(tái)方首先要注冊(cè)服務(wù)

//注冊(cè)平臺(tái)服務(wù)
PlatFormServiceRegistry.registeAppInfoService(AjkAppInfoServiceImpl.class);

業(yè)務(wù)方在使用服務(wù)的時(shí)候獲取到對(duì)應(yīng)的 Service 就可以調(diào)用相關(guān)方法了。

//使用平臺(tái)服務(wù)
IAppInfoService appInfoService = PlatFormServiceRegistry.getAppInfoService();
appInfoService.getAppName(context);

2.3 統(tǒng)一 HybridSDK 解決雙平臺(tái) H5 交互問(wèn)題

安居客 App 由于歷史原因，Android 和 iOS 在與 H5 的交互協(xié)議上有很多不一樣（雖然后期統(tǒng)一過(guò) JSBridge 協(xié)議，但很多歷史遺留協(xié)議仍舊是不一致的），58 App 上的 Native 和 JS 交互協(xié)議更是和安居客不一致。為了解決這些問(wèn)題我們需要 Android 和 iOS、58 和 安居客有一個(gè)統(tǒng)一的 Native 與 JS 的交互協(xié)議；同時(shí)為了兼容歷史協(xié)議，讓業(yè)務(wù)平穩(wěn)過(guò)渡，我們還需要設(shè)計(jì)一套過(guò)渡方案。

在未實(shí)現(xiàn)協(xié)議統(tǒng)一的情況下，一個(gè) H5 頁(yè)面要上 58 App 和安居客 App 兩個(gè)平臺(tái)，需要支持兩套協(xié)議，再加上安居客之前 Android、iOS 協(xié)議的不一致，一個(gè) H5 頁(yè)面最多可能需要支持 4~5 套協(xié)議。

為了實(shí)現(xiàn)協(xié)議的最終統(tǒng)一，并且讓業(yè)務(wù)平穩(wěn)過(guò)渡，我們引入了一套過(guò)渡方案。在保留兩個(gè)平臺(tái)現(xiàn)有協(xié)議和 JSBridge SDK 的情況下，58 無(wú)線團(tuán)隊(duì)的同學(xué)設(shè)計(jì)并開(kāi)發(fā)了一個(gè)全新的 HybridSDK，過(guò)渡階段三套協(xié)議并存，來(lái)不及調(diào)整的舊業(yè)務(wù)使用舊協(xié)議，新開(kāi)發(fā)及本次要調(diào)整的業(yè)務(wù)使用新協(xié)議。

然后隨著業(yè)務(wù)的迭代，不斷廢棄兩個(gè)平臺(tái)的自有協(xié)議，最終走向統(tǒng)一。

image

2.4 統(tǒng)一路由協(xié)議、API 動(dòng)態(tài)下發(fā)路由解決頁(yè)面交互問(wèn)題

現(xiàn)有 App 內(nèi)的頁(yè)面跳轉(zhuǎn)要么是 intent 跳轉(zhuǎn)，要么是寫死的路由跳轉(zhuǎn)。在這次的平臺(tái)化改造過(guò)程中，我們從 58 App 上也學(xué)到了很多東西，其中動(dòng)態(tài)路由下發(fā)就是我們學(xué)習(xí)并引入到安居客 App 中的。

簡(jiǎn)單的說(shuō)就是 App 給各個(gè)頁(yè)面定義好路由協(xié)議，App 在調(diào)用 API 的時(shí)候返回結(jié)果中會(huì)包含當(dāng)前頁(yè)面跳轉(zhuǎn)到下一頁(yè)面的路由協(xié)議，這就是所謂的動(dòng)態(tài)路由下發(fā)。這樣做會(huì)帶來(lái)三個(gè)好處：

  1. 可以做到完善的降級(jí)策略，比如當(dāng)線上的房源詳情頁(yè)出現(xiàn)了大面積的 Crash，API 可以返回一個(gè) H5 頁(yè)面的路由協(xié)議，臨時(shí)用 H5 的房源詳情頁(yè)替代；同時(shí) App 上線 HotFix，等 HotFix 覆蓋率達(dá)到一定程度后 API 再改回下發(fā)Native 路由，跳回 Native 頁(yè)面；
  2. 可以支持新功能的效果驗(yàn)證，利用 H5 和 Native 自由切換這一特性，可以在不發(fā)版的情況下驗(yàn)證新功能的數(shù)據(jù)效果。比如要上線驗(yàn)證某個(gè)改動(dòng)或者某個(gè)新功能的效果，之前需要 App 發(fā)版，現(xiàn)在只需要做一版 H5 頁(yè)面，API 直接路由到這個(gè) H5，如果驗(yàn)證下來(lái)效果好則可以開(kāi)發(fā)對(duì)應(yīng)的 Native 頁(yè)面，不好則可以再嘗試其他方案；
  3. 可以支持平臺(tái)化改造過(guò)程中的灰度上線，這一點(diǎn)放到下一小節(jié)詳細(xì)說(shuō)明。

2.5 灰度策略保證上線后的穩(wěn)定性

我們這次的平臺(tái)化改造，無(wú)論對(duì)安居客 App 還是 58 App 來(lái)說(shuō)都是一次「大手術(shù)」，術(shù)后能否保證線上的穩(wěn)定性、業(yè)務(wù)數(shù)據(jù)不受影響是非常重要的。就拿把安居客業(yè)務(wù)遷移到 58 App 這件事來(lái)說(shuō)，如果一股腦的用安居客遷移過(guò)去的房產(chǎn)業(yè)務(wù)代碼替代 58 App 內(nèi)的房產(chǎn)業(yè)務(wù)代碼，就算我們?cè)诩夹g(shù)上做到了絕對(duì)的穩(wěn)定，也難保業(yè)務(wù)數(shù)據(jù)不會(huì)受影響。

好在得益于上面提到的動(dòng)態(tài)路由下發(fā)方案，我們可以做到在少量城市、少量用戶上做灰度，讓這部分人先試用安居客遷移過(guò)去的業(yè)務(wù)，其它用戶繼續(xù)使用老的房產(chǎn)業(yè)務(wù)，數(shù)據(jù)效果好再逐步加量，直到完全替代。這樣就能最大限度的降低影響，保證上線后的穩(wěn)定性。

2.6 業(yè)務(wù)平移帶來(lái)的包大小問(wèn)題

雖然在上一次的模塊化/組件化改造過(guò)程中我們對(duì)各項(xiàng)垂直業(yè)務(wù)做了拆分、解耦，但是各業(yè)務(wù)還是有很多重疊的業(yè)務(wù)，于是我們將這些業(yè)務(wù)下沉到 CommonBusiness 組件中，同時(shí)這個(gè) CommonBusiness 組件里還包含了一些 App 平臺(tái)級(jí)別的基礎(chǔ)功能，因此這個(gè) CommonBusiness 組件成了個(gè)大而全的東西。

在這次的架構(gòu)調(diào)整中，我們?yōu)榱藢?shí)現(xiàn)業(yè)務(wù)的快速平移，將 CommonBusiness 和新房、二手房等幾條垂直業(yè)務(wù)線的代碼一股腦的遷移進(jìn)了 58 App，這就直接導(dǎo)致了 58 App 體積的快速膨脹。于是在后期，我們將 CommonBusiness 按能力拆分成了多個(gè)獨(dú)立的組件，并且分為了「平臺(tái)級(jí)組件」和「業(yè)務(wù)級(jí)組件」。平臺(tái)級(jí)組件屬于安居客平臺(tái)特有，不隨業(yè)務(wù)遷移；業(yè)務(wù)級(jí)組件屬于多個(gè)垂直業(yè)務(wù)公用的組件，隨業(yè)務(wù)代碼一起遷移到 58 App。這一點(diǎn)在前面的架構(gòu)圖中有體現(xiàn)。

2.7 持續(xù)演進(jìn)

前面介紹中間層的時(shí)候提到，還有一部分底層庫(kù)暫時(shí)無(wú)法統(tǒng)一，現(xiàn)階段是通過(guò)引入中間層來(lái)解決的。但從長(zhǎng)遠(yuǎn)來(lái)看，整個(gè)集團(tuán)無(wú)線體系下，依賴的底層庫(kù)還是要走向統(tǒng)一。就拿分享組件來(lái)說(shuō)，現(xiàn)階段安居客和 58 都是使用自己的 ShareSDK，然后中間層定義了一套分享接口，兩個(gè) App 分別調(diào)用自己的 ShareSDK 來(lái)實(shí)現(xiàn)接口滿足業(yè)務(wù)的分享需求。為了進(jìn)一步降低開(kāi)發(fā)成本，避免重復(fù)造輪子，后期雙方還需要統(tǒng)一使用同一個(gè) ShareSDK，拋棄中間層。最終整個(gè)集團(tuán)體系下所有的 App 的架構(gòu)應(yīng)該如下面這張圖所示：

image

統(tǒng)一的平臺(tái)層，不同的宿主搭配上不同的垂直業(yè)務(wù)，就是不同的 App。這一點(diǎn)還需要我們持續(xù)迭代才能做到。

三. 收獲和感悟

整個(gè)木星計(jì)劃下來(lái)，個(gè)人有很多的收獲和感悟。說(shuō)實(shí)話，這次的技術(shù)改造在技術(shù)上并沒(méi)有太大的難度，更談不上有什么「黑科技」。改造能順利落地，更多的對(duì)于全局的把控、資源的協(xié)調(diào)溝通以及各個(gè)兄弟團(tuán)隊(duì)的積極配合。所以這里拋開(kāi)技術(shù)不談，談?wù)勎业膸c(diǎn)收獲：規(guī)范化、流程化和全局視角。

3.1 規(guī)范化、流程化

安居客 Android App 團(tuán)隊(duì)在技術(shù)上過(guò)往基本都屬于小團(tuán)隊(duì)作戰(zhàn)，很少有跨團(tuán)隊(duì)、跨地域協(xié)同開(kāi)發(fā)的經(jīng)驗(yàn)，也缺少和集團(tuán)其它團(tuán)隊(duì)的交流，因此規(guī)范和流程一直是我們團(tuán)隊(duì)所欠缺的。

在之前的小團(tuán)隊(duì)開(kāi)發(fā)模式下，就這么一畝三分地，想怎么玩都行，怎么方便怎么來(lái)。但是這種方式一旦涉及到跨地域跨團(tuán)隊(duì)的協(xié)作時(shí)就會(huì)遇到瓶頸。

比如北京租房團(tuán)隊(duì)的需求開(kāi)發(fā)完要集成進(jìn)安居客，按照我們單純的想法，定個(gè)時(shí)間點(diǎn)提交代碼給我們就 OK 了，但實(shí)際情況是這種方式根本行不通。業(yè)務(wù)方什么時(shí)候開(kāi)發(fā)完、測(cè)試完、什么時(shí)候交付給我們？業(yè)務(wù)集成的交付標(biāo)準(zhǔn)是什么？平臺(tái)方測(cè)試和業(yè)務(wù)方測(cè)試如何配合、如何交接？業(yè)務(wù)代碼是以源碼方式集成還是 aar 方式集成等等這些都是問(wèn)題，需要有一套標(biāo)準(zhǔn)化、流程化的規(guī)范來(lái)約束各方的行為，這樣才能保證項(xiàng)目順利上線。

像上面這樣的例子還有很多，我這里就不一一列舉了。

3.2 全局視角

正所謂「不謀全局者，不足謀一域」，本次平臺(tái)化改造過(guò)程中我的另外一個(gè)重大收獲是讓我意識(shí)到要以全局視角去看到問(wèn)題。

前面提到我們?cè)谝?guī)范和流程上有很多欠缺，很多問(wèn)題單從自身無(wú)法解決，這促使我跳出自己的圈子來(lái)思考問(wèn)題。我們做 App 開(kāi)發(fā)的同學(xué)往往容易把視角局限于自己負(fù)責(zé)的一個(gè)頁(yè)面、一個(gè)功能模塊、一個(gè)業(yè)務(wù)，能站在整個(gè) App 的角度看待問(wèn)題的已經(jīng)寥寥無(wú)幾了，更別提跳出 App 的視角來(lái)看待問(wèn)題。

但缺少全局視角，很多事情就不能很好的完成。舉個(gè)例子，假設(shè)你接到了一個(gè)優(yōu)化頁(yè)面響應(yīng)速度的任務(wù)，如果你單從 App 的角度入手你會(huì)發(fā)現(xiàn)能做的很有限，當(dāng)你一通操作把 App 的優(yōu)化點(diǎn)做完了卻發(fā)現(xiàn)中臺(tái)部門提供的 SDK 方法耗時(shí)兩秒，API 返回?cái)?shù)據(jù)耗時(shí)三秒，真的是一頓操作猛如虎，一看結(jié)果二百五。

上面提到的這個(gè)例子還只是最常見(jiàn)、最基礎(chǔ)的一點(diǎn)。真正的全局視角是要求我們跳出 App 的限制，去思考整個(gè)研發(fā)流程的痛點(diǎn)、跨團(tuán)隊(duì)協(xié)作上還有哪些優(yōu)化空間等等，這樣才能真正提升我們的開(kāi)發(fā)效率、產(chǎn)品性能和用戶體驗(yàn)。就拿我業(yè)余時(shí)間里一直在做的 APM 項(xiàng)目來(lái)說(shuō)，如果只從 App 的角度來(lái)看，要實(shí)現(xiàn)對(duì)線上性能數(shù)據(jù)的采集會(huì)涉及到 Gradle Plugin、字節(jié)碼、ASM、數(shù)據(jù)的采集、存儲(chǔ)、上報(bào)、跨進(jìn)程通訊等等，每一項(xiàng)都不簡(jiǎn)單，每一項(xiàng)需要有一定的技術(shù)深度才能做好一個(gè) APM 組件。那么是不是每一項(xiàng)都做好了，實(shí)現(xiàn)了一個(gè)優(yōu)秀的 APM 組件就能解決線上性能問(wèn)題、提升用戶體驗(yàn)?zāi)?？顯然不是！

如果你站在更高的角度來(lái)看，一個(gè)單純的 APM 組件并沒(méi)有辦法解決任何性能問(wèn)題。我們需要從前期開(kāi)發(fā)階段的開(kāi)發(fā)規(guī)范和實(shí)現(xiàn)方案、QA 驗(yàn)收標(biāo)準(zhǔn)、上線后的性能數(shù)據(jù)采集、數(shù)據(jù)上報(bào)后的聚合、分析和報(bào)警、性能問(wèn)題的處理流程和規(guī)范等各個(gè)維度來(lái)協(xié)同處理，全方位的系統(tǒng)的思考每一個(gè)點(diǎn)，從更高的角度入手才能真正解決線上性能問(wèn)題。

登高望遠(yuǎn)

現(xiàn)在我們把視角再往上拔高一個(gè)層次，站在整個(gè)技術(shù)團(tuán)隊(duì)的角度來(lái)看移動(dòng)開(kāi)發(fā)。

安居客 App 是市面上一類比較典型的互聯(lián)網(wǎng)應(yīng)用，它包含了基本的業(yè)務(wù)呈現(xiàn)、即時(shí)通訊、視頻播放、直播等面向用戶的功能模塊，也包含了數(shù)據(jù)采集、日志記錄、網(wǎng)絡(luò)通訊等用戶看不見(jiàn)的功能模塊，同時(shí)還需持續(xù)交付平臺(tái)、測(cè)試平臺(tái)等等平臺(tái)的支持。

早期，即使在同一家公司這些內(nèi)容各個(gè) App 都是獨(dú)立的，各自自己做一套；

后來(lái)慢慢發(fā)現(xiàn)這種各自為戰(zhàn)的模式效率太低，重復(fù)造輪子的現(xiàn)象太嚴(yán)重，于是有了平臺(tái)化的概念。即時(shí)通訊是一個(gè)平臺(tái)、視頻直播是一個(gè)平臺(tái)、日志系統(tǒng)又是一個(gè)平臺(tái)，持續(xù)交付、測(cè)試均是單獨(dú)的平臺(tái)。各個(gè)平臺(tái)為各種 App 提供不一樣的服務(wù)，各個(gè) App 單獨(dú)對(duì)接各個(gè)平臺(tái)就可以了，避免了重復(fù)造輪子。

這種平臺(tái)化方案也有它自己的問(wèn)題，通過(guò)前面的描述你會(huì)發(fā)現(xiàn)，基本上來(lái)一個(gè)新業(yè)務(wù)就要開(kāi)發(fā)一個(gè)新系統(tǒng)，形成一個(gè)新平臺(tái)，這樣也會(huì)給 App 的接入帶來(lái)困擾，同時(shí)不同的平臺(tái)自然會(huì)有不同的團(tuán)隊(duì)，這之間的溝通協(xié)作成本是巨大的。于是更進(jìn)一步把各種分散的平臺(tái)統(tǒng)一成一個(gè)更大的平臺(tái)，統(tǒng)一對(duì)各種 App 提供服務(wù)。

這就是整個(gè) App 研發(fā)體系從蠻荒時(shí)代到平臺(tái)化，再?gòu)钠脚_(tái)到中臺(tái)的完整進(jìn)化史。

這里說(shuō)的平臺(tái)化和文章標(biāo)題里的平臺(tái)化不是同一個(gè)概念，這里的平臺(tái)化是指一套系統(tǒng)作為一個(gè)平臺(tái)為各種 App、Web、小程序等前臺(tái)應(yīng)用提供服務(wù)；而文章標(biāo)題里的平臺(tái)化是指安居客 App 作為一個(gè)平臺(tái)來(lái)支持各類房產(chǎn)業(yè)務(wù)。

那么現(xiàn)在我們?cè)賮?lái)看研發(fā)團(tuán)隊(duì)的組織結(jié)構(gòu)，就完全不一樣了。請(qǐng)看下圖：

image

當(dāng)我們能站在這樣一個(gè)角度看團(tuán)隊(duì)的組織結(jié)構(gòu)、研發(fā)流程的時(shí)候，很多事就更容易理解了。比如中臺(tái)部門推出了一套日志系統(tǒng)，各個(gè)前端團(tuán)隊(duì)要不要替換掉自研的埋點(diǎn)庫(kù)，使用中臺(tái)部門的服務(wù)，我的看法是當(dāng)然要。讓專業(yè)的團(tuán)隊(duì)做專業(yè)的事，中臺(tái)為各個(gè)前端業(yè)務(wù)團(tuán)隊(duì)賦能，無(wú)論是質(zhì)量上還是效率上都會(huì)有極大的提升。同時(shí)這樣也便于對(duì)各業(yè)務(wù)線的用戶數(shù)據(jù)、行為做統(tǒng)一的聚合、分析、報(bào)警等等，然后進(jìn)一步反哺業(yè)務(wù)。

這也是為什么之前集團(tuán) TEG 團(tuán)隊(duì)推出 WMDA（58集團(tuán)埋點(diǎn)系統(tǒng)）后，我們要頂住巨大壓力在安居客內(nèi)部推廣的原因。

寫在最后

平臺(tái)化改造能順利完成并非我們一個(gè)團(tuán)隊(duì)的功勞，這得益于前后端、產(chǎn)品、測(cè)試、58 無(wú)線、58 房產(chǎn)等多個(gè)團(tuán)隊(duì)積極的配合，就比如前面介紹的很多技術(shù)方案都是 58 無(wú)線團(tuán)隊(duì)的同學(xué)提出并開(kāi)發(fā)的，因此要在這里說(shuō)一聲感謝，我們從兄弟部門學(xué)到了很多。

這次平臺(tái)化改造的過(guò)程中涉及了太多的內(nèi)容，其中每一個(gè)點(diǎn)都能拿出來(lái)單獨(dú)寫一篇文章，由于篇幅限制并不能在文中一一詳述。我們團(tuán)隊(duì)在平臺(tái)化方面的實(shí)踐上還缺乏足夠的經(jīng)驗(yàn)，個(gè)人能力也有限，未能將細(xì)節(jié)很好的一一呈現(xiàn)。如果大家發(fā)現(xiàn)文章中的錯(cuò)誤或者實(shí)現(xiàn)方案上的不完美，歡迎在評(píng)論區(qū)留言交流指正。

如果你喜歡我的文章，就關(guān)注下我的公眾號(hào) BaronTalk 、 知乎專欄 或者在 GitHub 上添個(gè) Star 吧！

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書(shū)系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 前言 最近聽(tīng)了一個(gè)數(shù)據(jù)倉(cāng)庫(kù)的培訓(xùn)，那位數(shù)據(jù)專家開(kāi)口的第一句話是：我把這些信息給大家同步一下。然后就活學(xué)活用了——身...
    蕎麥和小喬閱讀 49,470評(píng)論 4贊 38
  • 原寫于2014年8月6日。 今天來(lái)奶奶家時(shí)，在門板上看到這樣一則通知：九蓮新村要砍倒兩顆危樹(shù)，因此會(huì)在7曰29日上...
    漆雕秘閣閱讀 395評(píng)論 0贊 2
  • 昨日，和閨蜜聊天，偶然說(shuō)到年少時(shí)光，那些青澀和瘋狂，一番感慨，感覺(jué)的事情就發(fā)生在昨天，實(shí)則轉(zhuǎn)眼已數(shù)年。 聊著扯著，...
    V鹿慕溪閱讀 695評(píng)論 0贊 0
  • 如果從現(xiàn)實(shí)主義出發(fā)，那必然是后悔沒(méi)有投資到對(duì)的行業(yè)或領(lǐng)域，沒(méi)有遵守自己定的計(jì)劃，沒(méi)有很好的將現(xiàn)在和將來(lái)聯(lián)系起來(lái)。 ...
    scarle閱讀 378評(píng)論 0贊 0

友情鏈接更多精彩內(nèi)容