業務架構是一個存在二十多年的概念，很多工程師認為業務架構與技術架構相比，缺乏技術含量，對於工程師的能力增長沒有多少幫助。但對於大型科技公司而言，業務架構卻非常重要。它是連接企業戰略和技術實現的橋樑，是連接業務人員與技術人員的橋樑。基礎架構有很多可以複用的通用能力，但業務架構卻是千變萬化需要針對企業自身業務去設計、生長的。

業務架構的定義是什麼？有哪些特點和難點？都有哪些發展階段和挑戰？業務架構師該怎麼設計架構、做技術選型？它與中臺、微服務的關係是什麼？我採訪了 58 同城高級總監江軍平，向他請教了業務架構背後的那些事兒。

什麼是業務架構？

業務架構是實現業務目標的一整套技術方案，也可以是針對某個具體業務點的架構方案。在互聯網行業，好的業務架構具有業務效果好、能快速落地、可持續迭代、不容易出錯等特點。

舉例而言，對於創業型小團隊來說，初期技術團隊解決的幾乎所有問題都是業務架構的範疇。隨著業務的發展和團隊規模不斷擴大，才會有一部分人專注地去做服務於其他開發人員的通用技術工作，最早被抽象出來的就是運維和基礎架構（微服務框架、監控、雲平臺、前端組件等），上層業務只需關注業務本身的複雜性，而不用去重複製造基礎設施的輪子。

基礎架構相對而言更加通用，因此也是開源社區比較活躍的領域，有很多開源的成熟產品可以直接用，或者結合自身業務特點二次開發深度定製。業務架構和具體的業務領域相關，一般不能在不同業務中直接複用，但是解決問題的思路方法是通用的，因此業務架構非常適合分門別類介紹方法論。

從單體到微服務

業務架構的演進和業務的發展變化是息息相關的。

早期業務規模較小的時候，一臺服務器就可以搞定所有業務，研發人數也較少，這個時候基本都會採用單體架構，比如流行的 LNMP 架構。隨著業務發展壯大，一臺機器搞不定，就要做分佈式，多臺機器同時提供服務。伴隨組織規模的不斷擴大，單體架構無法適應業務的發展，人越多越亂，迭代速度變慢、上線困難等問題接踵而至。這個時候微服務架構就派上用場了，將一個超大規模的單體應用拆分為多個微服務，每個微服務完成一個相對完備獨立的功能，可以獨立研發、上線、演進。組織也可以相應地劃分為小團隊，每個小團隊都可以小步快跑，敏捷高效。

以 58 集團的業務架構發展為例。

1. 58 集團最早是基於 Windows .NET 的單體架構，很好地滿足了業務早期發展的需求；
2. 隨著業務發展壯大，2010 年整體升級到 Linux 平臺，編程語言也改成 Java ，這個時期研發了 58 自己的 RPC 框架和 WEB 框架等中間件，業務架構由一個 Web 服務和後端多個 RPC 服務組成，底層存儲使用的是 MySQL ；
3. 發展到 2015 年，併購安居客、合併趕集網之後，公司組織上推進 BG 化，業務分品類做深做透，技術上業務架構也跟著組織做相應調整，業務服務垂直拆分到各 BG，每條業務線可以獨立迭代、上線。同時橫向也進行架構拆分，成立公司級技術中臺，負責通用技術能力的建設，例如運維、存儲、中間件、搜索、數據平臺、AI 平臺、移動組件、安全、商業等。

業務架構最常遇到的一個痛點是，企業級的業務場景是多變的，如何讓業務架構適應不同階段的業務特性，是業務架構師們最頭疼的問題。58 同城在 2015 年併購安居客、合併趕集網以後，亟待解決的問題是如何整合多平臺的業務架構。

以房產業務為例，細分的品類有新房、二手房、租房、商業地產等，這些業務在 58 同城和安居客上都有，但是兩個 App 的客戶端和後端業務架構完全不同，需要兩支團隊分別開發，整個團隊的資源和效率被嚴重稀釋和消耗，急需提升研發效率。

為了解決這個問題，在保證現有線上業務正常運轉的前提下，業務架構團隊將 58 同城和安居客 App 的業務架構進行打通，首先將 App 底層的公共組件統一，此後基於統一的公共組件對業務代碼進行重構，實現兩個 App 的房產業務使用同一份代碼，通過配置的方式實現差異化；同時整合了後端服務，將所有的底層系統打通，包括邏輯層和數據層服務，實現一個服務能夠同時承載 58 和安居客的業務，並且做到新老服務線上平滑切換。架構整合完成以後，團隊可以同時做 58 和安居客的業務開發工作，一次開發，兩網同步上線，大幅提升了業務的迭代效率。

業務架構，沒有想象中那麼容易

基礎架構和業務架構是一對雙生子，後者通常會受到更多的誤解。

一般來說，基礎架構是通用的技術基礎設施，比如各家雲服務廠商在雲上提供的產品基本都是基礎架構相關：彈性計算、數據庫、存儲、中間件、監控等。業務架構則建立在基礎架構之上，基礎架構提供輪子，業務架構師將這些輪子又快又好地組裝成用戶想要的產品。

外界對業務架構的誤解通常是其相對基礎架構而言，缺乏“技術含量”，實則不然。業務架構師不僅要懂業務，更要能很好地理解基礎架構中每個輪子的特性和原理，只有理解夠深刻，才能用的更好，技術選型才能做對。

對於業務架構師來說，除了要有紮實的技術功底，還得有優秀的溝通和業務理解能力，能夠把複雜的業務場景抽象、分層、簡化，拆分給多個人協同開發，對其中的關鍵技術難點要有很好的識別和把控能力，比如數據規模、訪問量、策略效果等，做到快速開發快速上線，且對上線後的業務效果也要有預判能力。因此要成為一個好的業務架構師，很不容易。

對於業務架構師來說，設計業務架構，首先要做業務建模抽象，把架構拆解為表現層、邏輯層、數據層，對於每一層的關鍵技術重點識別和把控，搞清楚上下游系統的特性，對整體架構方案要做到心中有數，一切盡在掌控。

1. 規劃業務中臺，把業務中共性的部分抽象出來，避免重複造輪子。比如房產業務的房源庫、樓盤字典、開放平臺，都是房產各品類可以複用的，因此應該放在業務中臺，而不是每條線都自己搞一個。
2. 關注數據規模、訪問量，這兩個業務參數是每次做架構的設計的時候都應該重點考量的指標，對方案設計影響重大。
3. 考慮業務發展，預判業務未來可能的變化，在架構設計上提前做好規劃，避免業務需求一變整個方案推倒重來。

技術選型上，可以考慮如下因素：

1. 如果是在大公司，基礎架構一般都比較成熟，優先選擇公司內部有支持的技術，且能夠更加方便的和公司內部其他系統聯動。
2. 如果沒有現成的技術可用，優先考慮成熟的開源方案，選擇自己熟悉的，能 hold 住的技術，做好未來二次開發的準備。
3. 調研各大雲廠商，如果有成熟的方案選擇，綜合成本能接受的話，可以選擇直接用。
4. 如果需要自建，也先調研下業界的成熟方案，借鑑其中的優秀經驗和思路，避免走彎路。

業務架構、微服務與中臺

如前文所言，業務架構存在的時間已經超過 20 多年，背後是一個不斷髮展、與時俱進的過程。在當前的雲時代下，業務架構變得更加純粹專注、聚焦在業務上。雲時代以前，業務架構要大包大攬，什麼都自己做，但在雲時代下很多基礎的事情可以交給雲來做。這裡的雲，包括私有云和公有云。

除了雲時代給業務架構帶來的改變，中臺概念的出現也對業務架構的設計產生了很大影響。一般來說多個業務能夠複用的技術能力，應該放在中臺來建設，業務架構直接複用就行，不用重複造輪子。

58 同城內部有公司層面的技術中臺，負責通用技術能力的建設，例如運維、存儲、中間件、雲平臺、搜索、數據平臺、AI 平臺、移動組件、即時通訊、安全、商業等。在房產業務線，也會建設業務中臺，比如房源庫、樓盤字典、房產開放平臺、經紀人服務等，都是統一建設，新房、二手房、租房、商業地產等業務線可直接複用。

微服務是連接中臺和業務架構的一個橋樑，很多人認為中颱不過是微服務的集散地，這種觀點其實有失偏頗。首先，從純技術的角度來看，中臺能力除了通過微服務的形式提供，還有很多是前後端結合的，比如即時通訊平臺，大多數時候需要對接 JS 或 App 的 SDK。其次，中臺也不是一個純技術的概念，中臺需要組織的保障，中臺能力是可以隨著前臺業務發展不斷迭代演進，只有組織才能保障中臺的迭代能夠和業務的發展節奏同步。

隨著雲架構、中臺、 Serverless 等架構新趨勢的湧現，業務架構也需要持續迭代、進化生長。互聯網企業的業務規模增長迅猛，業務場景特性一天一變，對於業務架構的設計、實現乃至重構都提出了更多的要求，業務架構工程師同樣需要持續學習、迭代自己的知識結構，以滿足變化多端的業務架構。

業務架構不是銀彈，沒有放之四海皆準的選型方案，適合的，才是最好的。