V1.0我先說說最開始的1.0版本。當時的情況是，App前端的iOS和Android開發(fā)團隊是外包出去的，而App的服務端是由1號店內(nèi)部一個小型的移動團隊負責的，這個團隊主要負責提供App前端需要的各個接口，接口使用的通信協(xié)議是HTTP+JSON。這個架構(gòu)比較簡單，App的服務整體上就一個應用，由移動團隊來所有對外接口，服務端內(nèi)部有很多Jar包，比如商品搜索、商品詳情、購物車等等，這些Jar業(yè)務線的業(yè)務邏輯及數(shù)據(jù)庫，它們由各個業(yè)務線的開發(fā)者負責提供。它的優(yōu)點是簡單方便。App后移動團隊通過現(xiàn)成的Jar包，封裝各個業(yè)務線的功能。至于這些Jar為什么呢？我們知道，早期的平臺都是先有PC端應用，再推App，App最開始的功能，大多是從已有的PC端平移過來的。因此，這些Jar包直接從PC端應用里拿過來就可以了，如果Jar包版本有更新，由業(yè)務線團隊直接同步給移動團隊即可。JarJar如果業(yè)務團隊根據(jù)PC端的需求，修改了應用代碼后，Jar包也會隨之修改。那么在實踐Jar么是新的Jar包調(diào)整了類的接口，導致了App服務端的功能有問題，或者直接不可用。服務端為AppJar因此，移動團隊在Jar跨多個業(yè)務線，導致移動團隊對所有業(yè)務邏輯都要深入了解。相信你也知道，這是很難做到Jar響，就導致了團隊之間并行開發(fā)，一次大的App升級經(jīng)常需要2~3個月的時間。而當時的1號店，需要能盡快地推出App端，我們所有的做法都是圍繞這個目的來的，包括把前端團隊外包出去，后端采用單體架構(gòu)，移動端功能從PC端直接移植過來。所以，從能，并能夠快速上線這些新功能。那么，這種單體架構(gòu)加物理Jar包耦合的方式，就成為App進一步發(fā)展的瓶頸。V2.0到了2013年，1號店App服務端架構(gòu)升級到了V2.0。在這個時候，1號店自己接手了AppApp直接對接多個后端應用提供的HTTP接口。對于各個業(yè)務團隊來說，他們現(xiàn)在了前臺，每個團隊負責各個業(yè)務線的App接口。他們一般采取這樣的做法，一方面，他們以Web應用的方式，為PC端瀏覽器提供；一方面，針對移動端的需求，他們在Web應用里面，增加了一些REST接口，直接App。在這里，移動接口和Web應用在同一個工程里開發(fā)，作為同一個應用進行部這里你可以看到，這實際上就是一種分布式的系統(tǒng)架構(gòu)PC把PC的功能完整地到App這樣，V2.0App首先是移動端和PC你可以看到，在同一個業(yè)務線內(nèi)部，移動接口和Web應用，物理上是綁定在一起的。很多時候，PC端的代碼修改會影響到移動接口，而Web應用的發(fā)布，也會導致移動接口地被發(fā)布，如果PC端出現(xiàn)功能問題，也會影響到移動接口的可用性。反過來也是一樣的，移動接口的需求變化，會影響到PC端的功能。我們知道，當移動端發(fā)展到了一定程度，它需要和PC緊耦合的方式，導致了相互之間產(chǎn)生很多不必要的干擾，對系統(tǒng)的功能和穩(wěn)定性都帶來了負移動接口除了要給App端提供業(yè)務數(shù)據(jù)，還需要考慮一系列系統(tǒng)級的功能，比如說，安全那現(xiàn)在，由于App前端是和后端直連的，這就意味著，每個后端系統(tǒng)都需要獨自去支持這的。App使得App整體上非常的脆弱。AppPC我們知道，當App發(fā)展到一個成熟階段時，無論是業(yè)務功能，還是非業(yè)務性功能，和PC路，我們的App服務端架構(gòu)也演變到了V3.0版本。V3.0在AppPCPC端Web應用，還有一個業(yè)務邏輯服務，3個部分都是獨立和部署的一方面，每個移動端接口需要調(diào)用對應的服務，進行業(yè)務邏輯處理，這個是個性化的，每個接口的處理邏輯都不一樣；另一方面，每個移動端接口都需要進行系統(tǒng)級的功能處理，前面的安證、口這個性的個接處理都是的。V3.0，App移動網(wǎng)關來服務端接口。這里的網(wǎng)關主要就是負責處理通用統(tǒng)級，包信協(xié)配、、日志；網(wǎng)理完，會接口對于PC端瀏覽器來說，它直接對應的Web應用，如搜索應用、詳情頁應用等，然后PCWeb務邏輯和UI展現(xiàn)。V3.0在具體實現(xiàn)時，每個通用功能的處理邏輯都會封裝成一個器，這些器遵循統(tǒng)一的接口定義，并且器都是可配置的。當有外部請求過來，網(wǎng)關會依次調(diào)用這些器，完成各個系統(tǒng)級功能的處理。代代1Objectfilter(Objectinput)throws我們在配置文件里，對接口請求的URL和業(yè)務適配器進行映射，接口路由層的分發(fā)邏輯就是根據(jù)請求中的URL，在配置文件里找到對應的適配器，然后把請求交給適配器進行后續(xù)的代代12最后是服務適配層。我們知道，外部接口的請求格式，往往和內(nèi)部服務接口的格式是不一樣的。具體到1N格式，內(nèi)部服務是+二進制格式。適配器首先用來解決內(nèi)外部接口的適配，除此之外，適配器還可以根據(jù)需要，對多個內(nèi)部服務做業(yè)務聚合，這樣可以對App前端提粗粒度的接口服務，減少網(wǎng)絡的調(diào)用次數(shù)。代代1Objectadapter(Objectinput)throws這些適配器物理上是Jar包的形式，由各個業(yè)務線研發(fā)團隊提供，所有的適配器會集中部署現(xiàn)在，你已經(jīng)很清楚了V3.0架構(gòu)的實現(xiàn)細節(jié)，接下來，我們就深入看下，這次架構(gòu)升級達首先，App端和PC端徹底獨立了。在上面的圖中，我們可以看到，App前端和PC端瀏覽器是完全對等的，PC端瀏覽器有自己的服務端，App前端也有自己的服務端，在這里，移動網(wǎng)關就充當App服務端的角色。還是物理層面都實現(xiàn)了徹底解耦。我們知道，一開始，App是依附于PC端，而現(xiàn)在，它其次，通過架構(gòu)改造，實現(xiàn)了業(yè)務的復用。這里，我們把的業(yè)務邏輯從Web應用中剝離出來，變成了共享的服務。在服務設計時，我們不再區(qū)分PC端還是移動端，而是從業(yè)務本身出發(fā)，提供一套通用的接口，同時供PC端和移動端調(diào)用，從而實現(xiàn)了底層業(yè)務邏還有，這個架構(gòu)強化了系統(tǒng)級功能團隊要么不提供，要么實現(xiàn)的方式不一樣；現(xiàn)在的系統(tǒng)級功能，是由集中式的移動網(wǎng)關統(tǒng)一來提供，我們就可以很方便地強化這些系統(tǒng)級功能。舉個例子，我們可以把通信協(xié)議由HTTP升級為更安全的HTTPS，當后端服務有問題時，也可以通過網(wǎng)關進行事先的數(shù)據(jù)緩存，直接返回給App前端。比如說商品的詳情數(shù)據(jù)，就所以，有了移動網(wǎng)關，整個App最后，團隊分工也更明確了濾器的，他們可以針對移動端的特點，做各種系統(tǒng)級功能的優(yōu)化；而業(yè)務團隊，主要負責各自的業(yè)務邏輯，包括適配器和底層服務。移動團隊和業(yè)務團隊通過明確的適配接口進行協(xié)作，相互不影響。我們可以看到，V3.0V2.0今天，我與你了1號店App服務端架構(gòu)改造的實際例子。在這個例子中，架構(gòu)經(jīng)歷了單體架構(gòu)到分布式架構(gòu)，再到SOA架構(gòu)的變化過程，并且通過移動網(wǎng)關的方式，一定程度今天的，你對架構(gòu)缺點及業(yè)的適有了一步解。他山之石，