各位肯定都聽過這樣一句話 : "好的架構不是設計出來的，而是演進出來的，沒有完美的架構，只有不斷演變、不斷完善的架構。" 今天我們來看一下1 號店 App 服務端架構改造的例子，來具體說明架構的演變過程，讓你能更深入地理解架構演變背后的原因。

隨著智能設備的普及和移動互聯網的發展，移動端逐漸成為用戶的新入口，各個電商平臺都開始聚焦移動端 App。這個時候，1 號店也開始試水移動端購物，從那時起，1 號店 App 的服務端架構一共經歷了三個版本的變化。接下來，我就為你具體介紹 App 服務端架構變化的過程以及原因。

一、V1.0 架構

我先說說最開始的 1.0 版本。當時的情況是，App 前端的 iOS 和 Android 開發團隊是外包出去的，而 App 的服務端是由 1 號店內部一個小型的移動團隊負責的，這個團隊主要負責提供 App 前端需要的各個接口，接口使用的通信協議是 HTTP+JSON。具體的架構如下圖所示：

這個架構比較簡單，App 的服務端整體上就一個應用，由移動團隊來維護所有對外接口，服務端內部有很多 Jar 包，比如商品搜索、商品詳情、購物車等等，這些 Jar 包包含了各個業務線的業務邏輯及數據庫訪問，它們由各個業務線的開發者負責提供。

你可以看到，這個 1.0 版本的服務端，實際上就是一個單體應用，只是對外的接口和內部 Jar 包分別由不同的團隊來提供，這個架構的優點和缺點同樣都非常明顯。

它的優點是簡單方便。 App 前端的外包團隊只需要對接后端的一個移動團隊就可以了，然后移動團隊通過現成的 Jar 包，封裝各個業務線的功能。至于這些 Jar 包，業務線團隊也無需額外去開發。

為什么呢？我們知道，早期的電商平臺都是先有 PC 端應用，再推 App，App 最開始的功能，大多是從已有的 PC 端平移過來的。因此，這些 Jar 包直接從 PC 端應用里拿過來就可以了，如果 Jar 包版本有更新，由業務線團隊直接同步給移動團隊即可。

那這個架構設計是不是很完美啊？當然不是，不知道你發現了沒有，其實這里也存在了很多問題。

第一個問題：移動服務端對 Jar 包的緊密依賴

移動團隊負責對外接口，但他們非常依賴業務團隊提供的 Jar 包來實現業務邏輯，這是一種物理上的緊耦合依賴關系。如果業務團隊根據 PC 端的需求，修改了應用代碼后，Jar 包也會隨之修改。那么在實踐中，經常會出現這樣的情況：業務團隊很多時候，要么忘了同步新的 Jar 包給移動團隊，要么是新的 Jar 包調整了類的接口，導致了 App 服務端的功能有問題，或者直接不可用。

第二個問題：移動團隊的職責過分復雜

服務端為 App 提供的是粗粒度接口，而業務團隊的 Jar 包提供的是細粒度的接口。

因此，移動團隊在 Jar 包的基礎上，還需要做很多的業務邏輯聚合，很多時候，這些邏輯還跨多個業務線，導致移動團隊對所有業務邏輯都要深入了解。相信你也知道，這是很難做到的。

第三個問題：團隊并行開發困難

由于移動團隊和業務團隊是通過物理 Jar 包進行集成的，移動團隊直接受業務團隊的代碼影響，就導致了團隊之間并行開發困難，一次大的 App 升級經常需要 2~3 個月的時間。

而當時的 1 號店，需要能盡快地推出 App 端，我們所有的做法都是圍繞這個目的來的，包括把前端團隊外包出去，后端采用單體架構，移動端功能從 PC 端直接移植過來。所以，從當時的情況來說，這種簡單的服務端架構和團隊合作模式是非常合適的。

而過了一段時間，當移動端的功能已經初步具備，我們就需要針對移動自身的特點去組織功能，并能夠快速上線這些新功能。那么，這種單體架構加物理 Jar 包耦合的方式，就成為 App 進一步發展的瓶頸。接下來，我們就看下系統是如何通過架構升級，來解決這個問題的。

二、V2.0 架構

到了 2013 年，1 號店 App 服務端架構升級到了 V2.0。在這個時候，1 號店自己接手了 App 前端的開發工作，同時，服務端接口也由各個業務線團隊直接負責，這樣，App 前端直接對接多個后端應用提供的 HTTP 接口。

整體架構如下圖所示：

對于各個業務團隊來說，他們現在走向了前臺，每個團隊負責各個業務線的 App 接口。他們一般采取這樣的做法，一方面，他們以 Web 應用的方式，為 PC 端瀏覽器提供訪問；另一方面，針對移動端的訪問需求，他們在 Web 應用里面，增加了一些 REST 接口，直接供 App 訪問。在這里，移動接口和 Web 應用在同一個工程里開發，作為同一個應用進行部署和運行。

這里你可以看到，這實際上就是一種分布式的系統架構，每塊業務由不同的團隊負責，可以很好地支持團隊之間的并行開發；同時，移動接口和 PC 端共享底層業務邏輯，有助于快速把 PC 端的功能完整地復制到 App 端。

這樣，通過 V2.0 架構的升級，業務線團隊的生產力就被完全釋放了，App 的功能也就快速豐富起來了。

但這種方式也帶來了一系列的問題，我們具體說下。

1.首先是移動端和 PC 端互相干擾的問題。

你可以看到，在同一個業務線內部，移動接口和 Web 應用，物理上是綁定在一起的。很多時候，PC 端的代碼修改會影響到移動接口，而 Web 應用的發布，也會導致移動接口被動地被發布，如果 PC 端出現功能問題，也會影響到移動接口的可用性。反過來也是一樣的，移動接口的需求變化，會影響到 PC 端的功能。

我們知道，當移動端發展到了一定程度，它需要和 PC 端有不同的功能和用戶體驗，但這種緊耦合的方式，導致了相互之間產生很多不必要的干擾，對系統的功能和穩定性都帶來了負面影響。

2.其次是重復開發的問題。

移動接口除了要給 App 端提供業務數據，還需要考慮一系列系統級的功能，比如說，安全驗證、日志記錄、性能監控等等，每個移動接口都需要這些通用功能。

那現在，由于 App 前端是和后端直連的，這就意味著，每個后端系統都需要獨自去支持這些系統級的功能，導致了各個后端系統重復開發。一旦這些通用需求發生了變化，比如說，我們要對傳輸數據進行壓縮，那么，所有的后端系統都需要同步調整，這樣不但工作量很大，而且也給項目管理也帶來了很大的挑戰。

3.最后是穩定性的問題。

在這里，基于這種直連方式，只要一個后端系統出問題，就會直接影響到 App 的可用性，使得 App 整體上非常的脆弱。

之所以會出現以上這些問題，它的根本原因在于，我們在 App 端，直接照搬了 PC 端的做法，沒有針對移動端自身的特點，去做架構設計。

我們知道，當 App 發展到一個成熟階段時，無論是業務功能，還是非業務性功能，和 PC 端都是不同的。所以，在架構設計上，我們必須能夠支持它們各自不同的特點，根據這個思路，我們的 App 服務端架構也演變到了 V3.0 版本。

三、V3.0 架構

在 V3.0 版本中，服務端架構包含了兩個大的升級。

首先，我們對每個業務線的服務端進行拆分，讓 App 接口和 PC 端接口各自在物理上獨立，但它們共享核心的業務邏輯。

拆分后的架構如下圖所示：

這樣拆分的結果是，原來大的服務端變成了 3 個應用，包括一個 App 端接口應用，一個 PC 端 Web 應用，還有一個核心業務邏輯服務，3 個部分都是獨立維護和部署的。

除此之外，架構改造還考慮了移動端自身的特點。

一方面，每個移動端接口需要調用對應的后臺服務，進行業務邏輯處理，這個是個性化的，每個接口的處理邏輯都不一樣；另一方面，每個移動端接口都需要進行系統級的功能處理，比如前面所說的安全驗證、接口監控等，這個是共性的，每個接口的處理方式都是一樣的。

那么，在架構上，我們就需要把共性的系統級功能進行集中處理，把個性化的業務功能進行分散處理。

最后，我們結合服務端的應用拆分，以及對移動接口本身的改造，落地了服務端 V3.0 架構。

如下圖所示：

在這里，App 前端會通過移動網關來訪問服務端接口。這里的網關主要就是負責處理通用的系統級功能，包括通信協議適配、安全、監控、日志等等；網關處理完之后，會通過接口路由模塊，轉發請求到內部的各個業務服務，比如搜索服務、詳情頁服務、購物車服務等等。

對于 PC 端瀏覽器來說，它直接訪問對應的 Web 應用，如搜索應用、詳情頁應用等，然后這些應用也是訪問同樣的內部服務。

這里說明下，當時還沒有流行前后端分離，所以 PC 端有對應的 Web 應用，同時負責業務邏輯和 UI 展現。現在，你已經了解了 V3.0 版本的整體架構設計，接下來，我們就深入移動網關，去具體了解下它的內部實現機制。

四、移動網關的內部實現

在圖中，你可以看到，整個移動網關分為三層，自上而下分別是通用層、接口路由層、適配層，接下來我們逐一分析。

1.通用層

首先是通用層，它負責所有系統級功能的處理，比如通訊協議適配、安全、監控、日志等等，這些功能統一由網關的通用層進行預處理，避免了各個業務線的重復開發。

在具體實現時，每個通用功能的處理邏輯都會封裝成一個攔截器，這些攔截器遵循統一的接口定義，并且攔截器都是可配置的。當有外部請求過來，網關會依次調用這些攔截器，完成各個系統級功能的處理。

這個攔截器接口的定義如下：

Object filter(Object input)throws Exception

2.接口路由層

接下來是接口路由層。移動端請求經過通用層的預處理之后，將會進一步分發給后端的業務適配器進行處理。

我們在配置文件里，對接口請求的 URL 和業務適配器進行映射，接口路由層的分發邏輯就是根據請求中的 URL，在配置文件里找到對應的適配器，然后把請求交給適配器進行后續的處理。

配置文件的具體內容如下所示：

www.website.com/search SearchAdapter
www.website.com/detail DetailAdapter

3.服務適配層

最后是服務適配層。我們知道，外部接口的請求格式，往往和內部服務接口的格式是不一樣的。具體到 1 號店當時的情況，外部接口是 HTTP+JSON 格式，內部服務是 Hessian+ 二進制格式。

適配器首先用來解決內外部接口的適配，除此之外，適配器還可以根據需要，對多個內部服務做業務聚合，這樣可以對 App 前端提供粗粒度的接口服務，減少遠程網絡的調用次數。

這些適配器遵循統一的接口定義：

Object adapter(Object input)throws Exception

這些適配器物理上是 Jar 包的形式，由各個業務線研發團隊提供，所有的適配器會集中部署在網關，而網關本身可以支持多實例的部署，通過水平擴展的方式提升服務端的處理能力。

現在，你已經很清楚了 V3.0 架構的實現細節，接下來，我們就深入看下，這次架構升級達到了什么樣的實際效果。

五、架構的實際效果

首先，App 端和 PC 端徹底獨立了。在上面的圖中，我們可以看到，App 前端和 PC 端瀏覽器是完全對等的，PC 端瀏覽器有自己的服務端，App 前端也有自己的服務端，在這里，移動網關就充當 App 服務端的角色。

在這個架構下，兩個服務端都可以針對自身的特點，獨立開發，獨立部署，無論在邏輯層面還是物理層面都實現了徹底解耦。我們知道，一開始，App 是依附于 PC 端，而現在，它終于可以獨立地發展了。

其次，通過架構改造，實現了核心業務的復用。 這里，我們把核心的業務邏輯從 Web 應用中剝離出來，變成了共享的服務。在服務設計時，我們不再區分 PC 端還是移動端，而是從業務本身出發，提供一套通用的接口，同時供 PC 端和移動端調用，從而實現了底層業務邏輯的復用。

還有，這個架構強化了系統級功能。 原來通用的系統級功能，由各個團隊各自去提供，很多團隊要么不提供，要么實現的方式不一樣；現在的系統級功能，是由集中式的移動網關統一來提供，我們就可以很方便地強化這些系統級功能。

舉個例子，我們可以把通信協議由 HTTP 升級為更安全的 HTTPS，當后端服務有問題時，也可以通過網關進行事先的數據緩存，直接返回給 App 前端。比如說商品的詳情數據，就很適合這樣的處理。

所以，有了移動網關，整個 App 的可用性、穩定性和安全性都得到了大幅度的提升。

最后，團隊分工也更明確了。 在這里，移動團隊主要負責移動網關，包括網關本身和各種過濾器的維護，他們可以針對移動端的特點，做各種系統級功能的優化；而業務團隊，主要負責各自的業務邏輯，包括適配器和底層服務。移動團隊和業務團隊通過明確的適配接口進行協作，相互不影響。

我們可以看到，V3.0 在 V2.0 分布式架構的基礎上，通過服務化改造，實現了基礎業務的復用；同時，通過移動網關落地系統級功能，實現了系統的平臺化改造。

總的改造結果就是，解放了業務線，提升了系統的穩定性，使得移動端可以做大做強。

六、總結

今天，我與你分享了 1 號店 App 服務端架構改造的實際例子。在這個例子中，架構經歷了單體架構到分布式架構，再到 SOA 架構的變化過程，并且通過移動網關的方式，一定程度上實現了平臺化。在這里，你可以清晰地看到，公司每個階段的業務，都有它不同的特點，我們選擇的架構必須能夠適配它，過度設計和設計不足，同樣都是有害的。

通過今天的分享，相信你對各種架構的優缺點，以及業務上的適用性有了更進一步的了解。他山之石，可以攻玉。架構的策略和原則是通用的，希望你能夠通過實戰不斷去領會和運用。