途牛的服務(wù)器部署及架構(gòu)有哪些演進(jìn)-創(chuàng)新互聯(lián)

本篇內(nèi)容主要講解“途牛的服務(wù)器部署及架構(gòu)有哪些演進(jìn)”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“途牛的服務(wù)器部署及架構(gòu)有哪些演進(jìn)”吧!　

在邊壩等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè) 網(wǎng)站設(shè)計(jì)制作按需搭建網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站設(shè)計(jì),全網(wǎng)營(yíng)銷推廣,成都外貿(mào)網(wǎng)站建設(shè),邊壩網(wǎng)站建設(shè)費(fèi)用合理。

服務(wù)化推進(jìn)
途牛的服務(wù)化始于2011年，當(dāng)時(shí)途牛主要進(jìn)行了會(huì)員的服務(wù)化，2012年進(jìn)行了搜索2.0的服務(wù)化，2013年是服務(wù)化大舉前進(jìn)的時(shí)刻，主要進(jìn)行了搜索3.0、價(jià)格中心、訂單中心、產(chǎn)品基礎(chǔ)數(shù)據(jù)等系統(tǒng)的服務(wù)化，2014年將TSP（途牛服務(wù)治理平臺(tái)）、業(yè)務(wù)公共系統(tǒng)、資源搜索系統(tǒng)等進(jìn)行服務(wù)化，2015年對(duì)產(chǎn)類目、開(kāi)放API進(jìn)行服務(wù)化。
從上面的過(guò)程可以看出，途牛的服務(wù)化不是一蹴而就的，而是經(jīng)歷了一個(gè)漫長(zhǎng)的過(guò)程，每一次拆分都相當(dāng)于為高速行駛的汽車更換輪胎的過(guò)程。可以注意到，在2012年途牛拆分了一個(gè)搜索2.0，之后很快又在2013年推出了搜索3.0。
這兩個(gè)版本的區(qū)別是：做搜索2.0一開(kāi)始沒(méi)有什么經(jīng)驗(yàn)，雖然采用了Solr這樣非常成熟的開(kāi)源搜索引擎來(lái)搭建搜索平臺(tái)，但是沒(méi)有明確界定搜索平臺(tái)和業(yè)務(wù)系統(tǒng)之間的關(guān)系，導(dǎo)致搜索平臺(tái)的邏輯非常重，被當(dāng)成一個(gè)數(shù)據(jù)聚合的平臺(tái)來(lái)使用，網(wǎng)站列表頁(yè)數(shù)據(jù)和詳情頁(yè)數(shù)據(jù)都從搜索中出來(lái)，導(dǎo)致搜索獲取數(shù)據(jù)源部分的邏輯非常復(fù)雜，搜索開(kāi)發(fā)人員將70%的時(shí)間都放在和業(yè)務(wù)系統(tǒng)對(duì)接邏輯的處理上，索引效率也比較低，從而導(dǎo)致性能不穩(wěn)定，逐漸退役。吸取教訓(xùn)后，途牛搭建了搜索3.0的平臺(tái)，僅僅提供列表搜索，統(tǒng)一列表字段，將數(shù)據(jù)推送邏輯移到搜索外部，由各個(gè)產(chǎn)品系統(tǒng)來(lái)進(jìn)行數(shù)據(jù)推送，搜索本身專注于性能的提升與穩(wěn)定性，并逐步加入智能排序、人工干預(yù)搜索結(jié)果功能。迄今為止，搜索3.0是途牛公司最為穩(wěn)定的系統(tǒng)。
接下來(lái)是服務(wù)化過(guò)程中，技術(shù)層面做得比較好的兩個(gè)服務(wù)：價(jià)格計(jì)算服務(wù)和服務(wù)治理平臺(tái)。

價(jià)格計(jì)算服務(wù)
從技術(shù)上，價(jià)格計(jì)算服務(wù)有兩個(gè)難點(diǎn)：一個(gè)是團(tuán)期價(jià)格依賴的因素較多，并且依賴路徑較深；另一個(gè)是這些因素價(jià)格變動(dòng)的頻率較高，尤其在旺季。因此從設(shè)計(jì)上，價(jià)格計(jì)算服務(wù)必須要有較大的容量要求，同時(shí)具有實(shí)時(shí)性。
價(jià)格計(jì)算服務(wù)從13年開(kāi)始構(gòu)建，架構(gòu)上也經(jīng)歷了四個(gè)階段：同步架構(gòu)、異步架構(gòu)、并發(fā)架構(gòu)和分布式架構(gòu)，如下圖所示。

同步架構(gòu)：系統(tǒng)間主要通過(guò)接口進(jìn)行交互，其他系統(tǒng)通過(guò)調(diào)用接口通知價(jià)格中心發(fā)起運(yùn)算，價(jià)格中心通過(guò)接口獲取其他系統(tǒng)價(jià)格依賴的所有資源。整個(gè)計(jì)算流程采用串行模型行，效率低僅能滿足小規(guī)模的計(jì)算需求。
異步架構(gòu)：系統(tǒng)間通過(guò)MQ進(jìn)行交互，價(jià)格中心通過(guò)依賴數(shù)據(jù)庫(kù)獲取其他系統(tǒng)的數(shù)據(jù)，加快了數(shù)據(jù)讀取的效率，并將計(jì)算價(jià)格變成兩段：先針對(duì)一個(gè)資源多個(gè)供應(yīng)商的情況，將資源的最低成本價(jià)計(jì)算好，然后再算產(chǎn)品最低價(jià)。這種架構(gòu)比同步架構(gòu)數(shù)據(jù)讀取的效率更高，并能通過(guò)預(yù)先生成數(shù)據(jù)，加快計(jì)算的速度，提升3倍整體性能。
并發(fā)架構(gòu)：首先將價(jià)庫(kù)自身的數(shù)據(jù)（資源的成本價(jià)，產(chǎn)品團(tuán)期起價(jià)）進(jìn)行了分庫(kù)分表，提升了系統(tǒng)的數(shù)據(jù)容量，然后再根據(jù)產(chǎn)品的訪問(wèn)頻度區(qū)分冷熱數(shù)據(jù)的計(jì)算頻率，冷數(shù)據(jù)降低計(jì)算頻率，熱數(shù)據(jù)增加計(jì)算頻率——并通過(guò)在內(nèi)存中建立團(tuán)期、行程、資源這三個(gè)維度的數(shù)據(jù)結(jié)構(gòu)，提升計(jì)算過(guò)程中數(shù)據(jù)的讀寫效率。整體上性能比異步架構(gòu)提升了3.5倍，每次每個(gè)團(tuán)期的價(jià)格計(jì)算時(shí)間控制在200ms以下。
分布式架構(gòu)：通過(guò)解析依賴數(shù)據(jù)庫(kù)的Binlog，將依賴數(shù)據(jù)庫(kù)的數(shù)據(jù)轉(zhuǎn)換成適合使用的內(nèi)存數(shù)據(jù)庫(kù)結(jié)構(gòu)，進(jìn)一步提升數(shù)據(jù)讀取效率，從而解決計(jì)算過(guò)度依賴數(shù)據(jù)庫(kù)的問(wèn)題，通過(guò)使用Sharding MQ，實(shí)現(xiàn)本地訪問(wèn)、本地計(jì)算；通過(guò)使用Unix域通信的機(jī)制，實(shí)現(xiàn)本地通信，將每個(gè)計(jì)算實(shí)例所依賴的資源和通信盡量限制在本地服務(wù)器上，較大化提升I/O能力，降低I/O損耗。整體性能比并發(fā)架構(gòu)提升2倍，每次每個(gè)團(tuán)期的價(jià)格計(jì)算時(shí)間控制在100ms以下。
通過(guò)上面幾個(gè)階段的優(yōu)化，價(jià)格計(jì)算服務(wù)的整體架構(gòu)如下圖所示。

其中分發(fā)節(jié)點(diǎn)中的計(jì)算成本節(jié)點(diǎn)就是一些預(yù)處理節(jié)點(diǎn)，主要計(jì)算資源成本價(jià)，物理機(jī)中的計(jì)算節(jié)點(diǎn)是實(shí)際執(zhí)行價(jià)格計(jì)算的單元節(jié)點(diǎn)。調(diào)度節(jié)點(diǎn)通過(guò)一定路由規(guī)則，將價(jià)格計(jì)算分片到不同機(jī)器上，Binlog同步的時(shí)候也會(huì)按照類似規(guī)則，將數(shù)據(jù)同步到不同存儲(chǔ)節(jié)點(diǎn)物理機(jī)，從而整體上實(shí)現(xiàn)本地存儲(chǔ)、本地計(jì)算。
截止到2015年5月，價(jià)格計(jì)算服務(wù)每天的計(jì)算量在9億次左右，每個(gè)團(tuán)期平均每天被計(jì)算2次以上。價(jià)格計(jì)算服務(wù)始終在I/O能力和計(jì)算效率上不斷迭代改進(jìn)，期待未來(lái)能夠有更好的架構(gòu)出現(xiàn)。

服務(wù)治理平臺(tái)
隨著服務(wù)化推進(jìn)越來(lái)越深入，每個(gè)系統(tǒng)提供的接口也越來(lái)越多，整個(gè)系統(tǒng)逐漸產(chǎn)生了這樣一些問(wèn)題：網(wǎng)狀接口調(diào)用；接口中存在循環(huán)依賴，可能引起雪崩效應(yīng)；服務(wù)調(diào)用缺乏監(jiān)控；使用硬件實(shí)現(xiàn)負(fù)載均衡，可維護(hù)性較差。針對(duì)這些問(wèn)題，途牛急需一套服務(wù)治理平臺(tái)來(lái)將所有的服務(wù)管理起來(lái)。
基于開(kāi)源的服務(wù)治理平臺(tái)，途牛進(jìn)行了部分定制，很快將適合于途牛的服務(wù)治理平臺(tái)搭建起來(lái)，架構(gòu)如下圖所示。

其中注冊(cè)中心采用主從模式進(jìn)行集群部署，“主”進(jìn)行服務(wù)地址的變更及心跳的保持，“從”提供查詢服務(wù)。主從之間建立長(zhǎng)連接，保持心跳?！爸鳌卞礄C(jī)后，“從”接替，變更自己的身份標(biāo)識(shí)。注冊(cè)中心各個(gè)部署的實(shí)例只有獲得“主”身份才能接受客戶端長(zhǎng)連接請(qǐng)求。各個(gè)服務(wù)提供者、服務(wù)消費(fèi)者感知“主”宕機(jī)后，嘗試連接“從”，并與之建立長(zhǎng)連接，使用SQLLite數(shù)據(jù)庫(kù)持久化服務(wù)列表，使用高可用的內(nèi)存緩存保存可用服務(wù)地址列表，與服務(wù)提供者、服務(wù)消費(fèi)者之間建立長(zhǎng)連接，維持心跳。
服務(wù)提供者啟動(dòng)之后，通過(guò)通用組件將提供的服務(wù)告之注冊(cè)中心，注冊(cè)中心更新可用服務(wù)地址列表。如果該服務(wù)沒(méi)有審核記錄，則作為新服務(wù)待審核。新服務(wù)提交到注冊(cè)中心后，注冊(cè)中心不會(huì)更新到可用服務(wù)列表，需要人工在管理頁(yè)面進(jìn)行審核通過(guò)后才能進(jìn)入使用，被服務(wù)消費(fèi)者感知。
服務(wù)提供者發(fā)生宕機(jī)，心跳中斷的情況，注冊(cè)中心將更新可用服務(wù)地址列表，刪除提供者的所有服務(wù)，并發(fā)出變更通知。心跳具有重連保持機(jī)制。一定時(shí)間內(nèi)無(wú)心跳才斷開(kāi)連接。服務(wù)提供者使用連接池，控制長(zhǎng)連接的數(shù)目，設(shè)置高連接數(shù)。如果連接數(shù)得到高限制，則拒絕新的連接接入，保證當(dāng)前系統(tǒng)的可用性。
管理頁(yè)面上可以查詢服務(wù)、查看服務(wù)詳細(xì)情況及可用服務(wù)地址列表，查看服務(wù)消費(fèi)者列表，新上線服務(wù)的審核，待下線服務(wù)的禁止，實(shí)時(shí)調(diào)整某個(gè)服務(wù)的負(fù)載均衡策略，對(duì)某個(gè)服務(wù)提供者進(jìn)行降權(quán)、倍權(quán)、禁用、允許操作。

南北京機(jī)房之痛
本節(jié)主要介紹途牛的機(jī)房部署策略。在2014年以前，途?；旧隙季S持了南北京機(jī)房的結(jié)構(gòu)，在當(dāng)時(shí)的情況下，這種策略基本上還是比較合理的，但是隨著應(yīng)用體量越來(lái)越大，逐步出現(xiàn)了問(wèn)題，途牛在2015年變成了南京單機(jī)房的策略，未來(lái)途牛將向兩地三中心這種更加穩(wěn)定、高可用的架構(gòu)演變。
南北京單機(jī)房的策略，在設(shè)計(jì)之初，很好的滿足了業(yè)務(wù)需求。在2010年以前，途牛70%以上的訂單均為電話訂單，加上旅游訂單的預(yù)訂流程又比較復(fù)雜，需要客服人工參與的環(huán)節(jié)較多，途牛需要將訂單系統(tǒng)部署在南京機(jī)房，以便為途牛的客服提供好的用戶體驗(yàn)。同時(shí)為了給互聯(lián)網(wǎng)用戶提供更好的機(jī)房條件，途牛需要將網(wǎng)站部署在北京。在這種機(jī)房架構(gòu)下，途牛進(jìn)行了大量系統(tǒng)優(yōu)化工作，主要是為了解決異地機(jī)房之間的數(shù)據(jù)同步問(wèn)題。
首先針對(duì)網(wǎng)站數(shù)據(jù)“讀多寫少”的特征，途牛對(duì)每一個(gè)子系統(tǒng)，均采用如下的典型系統(tǒng)設(shè)計(jì)，如圖4所示。

南北京之間通過(guò)數(shù)據(jù)庫(kù)的主從同步機(jī)制進(jìn)行數(shù)據(jù)同步，北京機(jī)房的應(yīng)用讀取北京的數(shù)據(jù)庫(kù)，通過(guò)專線寫入南京的數(shù)據(jù)庫(kù)，從而確保兩邊數(shù)據(jù)的一致性。
該設(shè)計(jì)方案在系統(tǒng)容量小的時(shí)候，可以很好地運(yùn)行，但是在專線不穩(wěn)定的情況下，會(huì)產(chǎn)生較多問(wèn)題，最常見(jiàn)的是數(shù)據(jù)同步延遲，比如用戶在網(wǎng)站注冊(cè)后，無(wú)法立刻登錄。針對(duì)這個(gè)問(wèn)題，途牛采用了熔斷的設(shè)計(jì)方案，使用特定進(jìn)程監(jiān)控?cái)?shù)據(jù)庫(kù)同步延遲，如果延遲達(dá)到上限，將嘗試使用公網(wǎng)VPN進(jìn)行同步，當(dāng)專線情況好轉(zhuǎn)時(shí)，再切換回去。
另外為了控制數(shù)據(jù)同步的數(shù)據(jù)量，所有數(shù)據(jù)同步均采用了壓縮機(jī)制，較大限度減少同步的數(shù)據(jù)量。同時(shí)途牛也不斷擴(kuò)大專線的容量。
隨著業(yè)務(wù)不斷增長(zhǎng)，同步的數(shù)據(jù)量越來(lái)越多，這種部署架構(gòu)遇到的挑戰(zhàn)越來(lái)越大，最終在2015年初，途牛將兩地機(jī)房進(jìn)行合并。中途較大挑戰(zhàn)是南京機(jī)房的網(wǎng)絡(luò)條件問(wèn)題，當(dāng)時(shí)南京地區(qū)尚無(wú)接入條件較好的多線BPG機(jī)房，為了給全國(guó)用戶提供較好的網(wǎng)絡(luò)服務(wù)，途牛最終采用了動(dòng)態(tài)CDN方案，南京機(jī)房出口僅提供電信出口的IP。對(duì)聯(lián)通、移動(dòng)的用戶通過(guò)動(dòng)態(tài)域名解析，解析到本地較近中轉(zhuǎn)服務(wù)器，再由中轉(zhuǎn)服務(wù)器優(yōu)化路由訪問(wèn)南京的電信線路。該方案能為全國(guó)用戶提供良好的網(wǎng)絡(luò)服務(wù)。
在整個(gè)服務(wù)器部署成本上，途牛至少降低了30%，一是避免了同一套系統(tǒng)在南北京部署兩份，二是節(jié)省了大量的專線費(fèi)用。
目前的單機(jī)房策略，是一個(gè)過(guò)渡方案，為了保證系統(tǒng)進(jìn)一步的高可用和數(shù)據(jù)的安全性，途牛后期將向標(biāo)準(zhǔn)的兩地三中心機(jī)房部署策略邁進(jìn)。

性能優(yōu)化
性能優(yōu)化主要介紹途牛在優(yōu)化過(guò)程中總結(jié)出來(lái)幾個(gè)工具，途牛的思路是：首先，不斷推進(jìn)架構(gòu)演變，系統(tǒng)劃分整理，提前對(duì)資源進(jìn)行擴(kuò)展，保證總體的承載能力。然后，不斷推進(jìn)監(jiān)控完善，性能指標(biāo)具體化，發(fā)現(xiàn)問(wèn)題、解決問(wèn)題，保證總體的穩(wěn)定能力。主要由這樣三個(gè)工具實(shí)現(xiàn)：CODIS、BWT、OSS。
Codis是豌豆莢使用Go和C語(yǔ)言開(kāi)發(fā)，以代理方式實(shí)現(xiàn)的一個(gè)Redis分布式集群解決方案，且完全兼容Twemproxy。Codis底層會(huì)處理請(qǐng)求的轉(zhuǎn)發(fā)、不停機(jī)的數(shù)據(jù)遷移等工作。所有底層的處理, 對(duì)于客戶端來(lái)說(shuō)都是透明的?？傊梢院?jiǎn)單地認(rèn)為后臺(tái)連接的是一個(gè)內(nèi)存無(wú)限大的Redis服務(wù)。途牛從無(wú)緩存，到文件緩存，到Memcache緩存，到今天的Codis緩存，緩存是大型架構(gòu)的必然。
使用Codis后，應(yīng)用端不需要再關(guān)心緩存具體存放在哪里，不需要關(guān)心緩存擴(kuò)容和數(shù)據(jù)遷移的工作，不需要關(guān)心緩存數(shù)據(jù)一致性的問(wèn)題，極大提升了應(yīng)用開(kāi)發(fā)和維護(hù)的效率。
BWT是途牛自主開(kāi)發(fā)的一個(gè)主動(dòng)緩存更新服務(wù)，為了進(jìn)一步提升頁(yè)面的生成效率，應(yīng)用系統(tǒng)發(fā)生數(shù)據(jù)變更時(shí)，將要更新的數(shù)據(jù)請(qǐng)求發(fā)到BWT中，BWT根據(jù)設(shè)置好的更新策略，對(duì)緩存進(jìn)行更新。應(yīng)用系統(tǒng)推送過(guò)來(lái)的數(shù)據(jù)，一般會(huì)延時(shí)3分鐘，進(jìn)行更新。同時(shí)BWT也會(huì)通過(guò)日志分析出來(lái)的熱點(diǎn)數(shù)據(jù)，會(huì)根據(jù)設(shè)置的時(shí)間自動(dòng)更新。更新的過(guò)程中，若目標(biāo)機(jī)器負(fù)載高，會(huì)自動(dòng)停止更新。
OSS也是途牛自主研發(fā)的一個(gè)網(wǎng)站運(yùn)營(yíng)監(jiān)控系統(tǒng)，該系統(tǒng)初期目標(biāo)是對(duì)網(wǎng)站的性能、可用性和安全的進(jìn)行監(jiān)控和管理。后期將獨(dú)立成一個(gè)單獨(dú)的運(yùn)營(yíng)監(jiān)控系統(tǒng)，為所有系統(tǒng)提供監(jiān)控服務(wù)。圖5是OSS的系統(tǒng)結(jié)構(gòu)。

主要特點(diǎn)是使用UPD的方式將日志從應(yīng)用系統(tǒng)發(fā)送出來(lái)，盡可能降低發(fā)送日志對(duì)應(yīng)用系統(tǒng)的性能消耗。通過(guò)NSQ隊(duì)列接收日志，使用Go語(yǔ)言編寫的消費(fèi)進(jìn)程將日志匯總處理后，存入DB，并最終通過(guò)頁(yè)面將各種統(tǒng)計(jì)報(bào)表呈現(xiàn)出來(lái)。
網(wǎng)站的各種故障，可以通過(guò)錯(cuò)誤與性能圖表，很快找到問(wèn)題。主要有依賴接口監(jiān)控，慢查SQL監(jiān)控，Memcache監(jiān)控，Redis監(jiān)控以及單頁(yè)面性能監(jiān)控。

App客戶端技術(shù)演進(jìn)
這里主要介紹途牛App在開(kāi)發(fā)過(guò)程中的實(shí)踐心得，側(cè)重于線熱補(bǔ)丁和前端資源靜態(tài)化兩個(gè)方面。

1.在線熱補(bǔ)丁
由于App采用客戶端發(fā)布的方案，一旦發(fā)布出去的包有Bug，修復(fù)是一個(gè)非常頭疼的問(wèn)題，傳統(tǒng)的修復(fù)方法主要有：服務(wù)器端屏蔽技術(shù)，也就是將有問(wèn)題的功能暫時(shí)屏蔽掉；跳轉(zhuǎn)H5頁(yè)面，將產(chǎn)生問(wèn)題的頁(yè)面直接跳轉(zhuǎn)到對(duì)應(yīng)的H5頁(yè)面；緊急發(fā)布新版本。這幾種辦法均有一定的局限性，對(duì)于服務(wù)端屏蔽技術(shù)，會(huì)增加服務(wù)端代碼復(fù)雜度并隱藏局部功能；對(duì)于跳轉(zhuǎn)到H5，會(huì)降低用戶體驗(yàn)；對(duì)于緊急發(fā)布新版本，會(huì)增加運(yùn)營(yíng)成本并降低用戶體驗(yàn)。
為此途牛引入了阿里的在線熱補(bǔ)丁技術(shù)，以便在問(wèn)題發(fā)生時(shí)，能夠快速發(fā)布補(bǔ)丁包將問(wèn)題解決。

2.前端資源靜態(tài)化
由于H5開(kāi)發(fā)周期短，容易部署的特性，在途牛App中存在大量的H5頁(yè)面，但對(duì)于H5頁(yè)面，用戶體驗(yàn)的損失也是顯而易見(jiàn)。為了讓頁(yè)面中的元素更快渲染，呈現(xiàn)給用戶，途牛采用了前端資源靜態(tài)化的方案，主要思路是將H5頁(yè)面中的靜態(tài)資源提前加載，實(shí)現(xiàn)要點(diǎn)如下：
靜態(tài)資源異步加載，用戶打開(kāi)App的時(shí)候異步下載或者更新靜態(tài)文件。優(yōu)化渲染，減少不必要的開(kāi)銷。通過(guò)優(yōu)化DOM布局，將加載的靜態(tài)資源分組，可以打包的，優(yōu)先渲染，需要從服務(wù)器取的，后渲染，從而加快第一次進(jìn)入速度；減少第一屏DOM渲染數(shù)，使用懶加載，分步加載；優(yōu)化渲染結(jié)構(gòu)，由于App中的Webview性能低于手機(jī)瀏覽器，所以減少不必要的渲染開(kāi)銷，比如減少消耗非常高的一些滾動(dòng)圖；優(yōu)化交互，有交互操作，造成DOM重排重繪的，盡量使用最小的DOM重排，將需要新加入的一些層，與原來(lái)的DOM結(jié)構(gòu)分開(kāi)；使用一些3D CSS，使用GPU幫助頁(yè)面重繪。
以上就是途牛在架構(gòu)變遷過(guò)程中的一些實(shí)踐要點(diǎn)，雖然看起來(lái)有些散，但還是主要從架構(gòu)的以下三個(gè)方面進(jìn)行介紹。
邏輯架構(gòu)：服務(wù)化，如何將業(yè)務(wù)中通用的功能抽象出來(lái)，以服務(wù)的方式提供給其他各個(gè)系統(tǒng)。
物理架構(gòu)：南北京機(jī)房的設(shè)計(jì)初衷，遇到的問(wèn)題，解決方案等。
系統(tǒng)架構(gòu)：非功能性的架構(gòu)，比如性能優(yōu)化，App客戶端性能改進(jìn)實(shí)踐。

到此，相信大家對(duì)“途牛的服務(wù)器部署及架構(gòu)有哪些演進(jìn)”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)建站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

本文題目：途牛的服務(wù)器部署及架構(gòu)有哪些演進(jìn)-創(chuàng)新互聯(lián)
瀏覽路徑：http://muchs.cn/article46/dphjhg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、品牌網(wǎng)站制作、網(wǎng)站建設(shè)、做網(wǎng)站、企業(yè)網(wǎng)站制作、網(wǎng)站改版

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)