一、設(shè)計(jì)開(kāi)發(fā)一個(gè)App究竟需要多少錢(qián)？

想要了解設(shè)計(jì)開(kāi)發(fā)一個(gè)App的費(fèi)用，就必須明白這其中的多種影響因素。App的類型、功能的復(fù)雜程度、設(shè)計(jì)的精致程度以及用戶需求等都是決定費(fèi)用的關(guān)鍵因素。費(fèi)用范圍從幾千元到幾十萬(wàn)元不等。

對(duì)于簡(jiǎn)單的生活類App，無(wú)需后臺(tái)支持，只需前端設(shè)計(jì)開(kāi)發(fā)，一個(gè)月內(nèi)即可完成，費(fèi)用在幾千至幾萬(wàn)元之間。而游戲類App，尤其是無(wú)后臺(tái)、無(wú)購(gòu)買的2D游戲，開(kāi)發(fā)時(shí)間約兩個(gè)月，價(jià)格普遍在5-10萬(wàn)之間。對(duì)于復(fù)雜的App，開(kāi)發(fā)難度較高，通常起步價(jià)就在8萬(wàn)以上，需要經(jīng)歷多次升級(jí)才能完善成熟系統(tǒng)。

App開(kāi)發(fā)還有固定款和定制款之分。固定款直接使用現(xiàn)有模板，功能固定，開(kāi)發(fā)時(shí)間短，大約2-3天完成，費(fèi)用在幾千到幾萬(wàn)之間。但客戶無(wú)法獲得源代碼，無(wú)法進(jìn)行企業(yè)定制。而定制款則根據(jù)企業(yè)需求全新開(kāi)發(fā)，功能設(shè)計(jì)均為定制，價(jià)格相對(duì)較高。開(kāi)發(fā)時(shí)間長(zhǎng)，可能需要兩三個(gè)月甚至更久，費(fèi)用可能在幾萬(wàn)至十幾萬(wàn)之間。

二、京東的組織架構(gòu)探究

京東的組織架構(gòu)核心板塊為京東商城，下設(shè)四個(gè)事業(yè)部：3C事業(yè)部、家電事業(yè)部、消費(fèi)品事業(yè)部以及家居事業(yè)部。還有京東金融、海外事業(yè)部、京東到家以及京東智能等板塊。

京東金融于2013年成立，近年來(lái)發(fā)展迅猛，估值已超460億人民幣，預(yù)計(jì)3年內(nèi)將獨(dú)立上市。海外事業(yè)部自2014年成立以來(lái)，不斷開(kāi)拓全球市場(chǎng)。京東到家負(fù)責(zé)圈占生活服務(wù)O2O市場(chǎng)，主打生鮮及超市產(chǎn)品的配送。而京東智能主要業(yè)務(wù)包括智能云平臺(tái)以及JD+京東智能產(chǎn)品等。

三、京東活動(dòng)系統(tǒng)的架構(gòu)應(yīng)對(duì)之策

京東活動(dòng)系統(tǒng)是一個(gè)實(shí)時(shí)編輯、發(fā)布新活動(dòng)的在線平臺(tái)，具備高時(shí)效性和靈活性。隨著業(yè)務(wù)的高速發(fā)展和流量的大幅增長(zhǎng)，京東活動(dòng)系統(tǒng)面臨著巨大的壓力。急需構(gòu)建更高效穩(wěn)定的系統(tǒng)架構(gòu)以支撐業(yè)務(wù)發(fā)展。本文將重點(diǎn)探討活動(dòng)頁(yè)面瀏覽性能的提升問(wèn)題。

四、活動(dòng)頁(yè)面瀏覽性能提升的難點(diǎn)

活動(dòng)頁(yè)面瀏覽性能的提升面臨兩大難點(diǎn)?；顒?dòng)與活動(dòng)之間的差異較大，不同于商品頁(yè)有固定的模式。每個(gè)頁(yè)面能抽取的公共部分有限，可復(fù)用性較差。

五、應(yīng)對(duì)策略與展望

針對(duì)以上難點(diǎn)，我們需要采取一系列應(yīng)對(duì)策略。包括但不限于優(yōu)化代碼、提升服務(wù)器性能、采用更高效的緩存策略等。還需要對(duì)未來(lái)系統(tǒng)進(jìn)行規(guī)劃，確保系統(tǒng)能夠隨著業(yè)務(wù)的發(fā)展而不斷進(jìn)化，更好地滿足用戶需求。

設(shè)計(jì)開(kāi)發(fā)一個(gè)App的費(fèi)用以及京東的組織架構(gòu)和活動(dòng)系統(tǒng)應(yīng)對(duì)之策都是復(fù)雜而深入的話題。需要我們從多個(gè)角度去理解和探討，才能更好地滿足實(shí)際需求并推動(dòng)業(yè)務(wù)發(fā)展。經(jīng)過(guò)深入研究和改造，我們的web系統(tǒng)架構(gòu)取得了顯著的進(jìn)步。以下是新架構(gòu)的詳細(xì)介紹，分為五個(gè)章節(jié)，每個(gè)章節(jié)都將以

標(biāo)簽包含。

一、系統(tǒng)現(xiàn)狀與挑戰(zhàn)

我們的活動(dòng)頁(yè)面內(nèi)容多樣，業(yè)務(wù)繁多。由于依賴大量外部業(yè)務(wù)接口，數(shù)據(jù)閉環(huán)難以實(shí)現(xiàn)。外部接口的性能及穩(wěn)定性問(wèn)題，嚴(yán)重制約了活動(dòng)頁(yè)面的渲染速度及穩(wěn)定性。這是我們面臨的挑戰(zhàn)。

二、現(xiàn)有web系統(tǒng)架構(gòu)簡(jiǎn)述

以京東活動(dòng)系統(tǒng)架構(gòu)的演變?yōu)槔?，我們的現(xiàn)有架構(gòu)存在一些瓶頸。為了提高性能，我們通常在消耗性能的地方加緩存，如對(duì)部分查庫(kù)操作使用了redis緩存。我們還對(duì)頁(yè)面進(jìn)行了整頁(yè)redis緩存，以降低渲染頁(yè)面的成本。

三、應(yīng)用服務(wù)層面架構(gòu)演進(jìn)

為了減少應(yīng)用服務(wù)器的壓力，我們采取了多項(xiàng)措施。例如，在應(yīng)用服務(wù)器前面添加了cdn和nginx的proxy_cache，以降低回源率。我們還實(shí)施了頁(yè)面渲染、瀏覽異步化的策略，對(duì)整個(gè)架構(gòu)進(jìn)行了升級(jí)改造。

四、老架構(gòu)解析

除了瀏覽服務(wù)，我們的老架構(gòu)還進(jìn)行了其他兩個(gè)大的優(yōu)化：接口服務(wù)和靜態(tài)服務(wù)。訪問(wèn)請(qǐng)求首先到達(dá)瀏覽服務(wù)，整個(gè)頁(yè)面框架通過(guò)各級(jí)緩存返回給瀏覽器。對(duì)于實(shí)時(shí)數(shù)據(jù)和個(gè)性化數(shù)據(jù)，我們采用前端實(shí)時(shí)接口調(diào)用前端接口服務(wù)的方式獲取。靜態(tài)資源則通過(guò)靜態(tài)服務(wù)進(jìn)行訪問(wèn)。在老架構(gòu)下，瀏覽服務(wù)和接口服務(wù)被分離，頁(yè)面固定不變的部分走瀏覽服務(wù)，實(shí)時(shí)變化和個(gè)性化的部分則通過(guò)前端接口服務(wù)實(shí)現(xiàn)。

五、新架構(gòu)的性能對(duì)比與挑戰(zhàn)

在新老架構(gòu)的對(duì)比中，我們發(fā)現(xiàn)新架構(gòu)在性能上有顯著提升。我們也面臨一些挑戰(zhàn)。例如，擊穿cdn緩存、nginx緩存后，回源到應(yīng)用服務(wù)器的流量大約在20%-40%之間，這部分的性能對(duì)比是我們需要重點(diǎn)關(guān)注和優(yōu)化的。在2015年的雙十一期間，我們的瀏覽方法tp99約為1000ms，且存在抖動(dòng)幅度大、內(nèi)存使用近70%、cpu占用約45%的問(wèn)題。我們需要繼續(xù)探索和優(yōu)化新架構(gòu)，以應(yīng)對(duì)高并發(fā)、大數(shù)據(jù)量的挑戰(zhàn)。

我們的web系統(tǒng)架構(gòu)在不斷地演進(jìn)和優(yōu)化中。通過(guò)實(shí)施“頁(yè)面渲染、瀏覽異步化”的策略，以及對(duì)架構(gòu)的升級(jí)改造，我們?nèi)〉昧孙@著的成果。仍面臨一些挑戰(zhàn)，需要我們繼續(xù)探索和努力。我們相信，通過(guò)不斷地優(yōu)化和創(chuàng)新，我們將能夠構(gòu)建更加高效、穩(wěn)定的web系統(tǒng)架構(gòu)。

新架構(gòu)瀏覽服務(wù)性能優(yōu)化

一、新架構(gòu)概述及瀏覽性能提升

在2016年618電商節(jié)期間，我們采用了全新的架構(gòu)支持，顯著提升了瀏覽服務(wù)的性能。無(wú)論是針對(duì)移動(dòng)端的app活動(dòng)還是PC端活動(dòng)，瀏覽的tp99（即99%的用戶請(qǐng)求響應(yīng)時(shí)間）都得到了極大的優(yōu)化。具體來(lái)說(shuō)，移動(dòng)活動(dòng)瀏覽的tp99穩(wěn)定在8ms，PC活動(dòng)瀏覽的tp99則穩(wěn)定在約15ms，全天性能幾乎呈現(xiàn)一條直線，無(wú)任何性能抖動(dòng)。這一飛躍式的進(jìn)步得益于我們對(duì)新架構(gòu)的全面優(yōu)化和改進(jìn)。

二、服務(wù)器性能及CPU消耗分析

在新架構(gòu)的支持下，服務(wù)器的性能表現(xiàn)同樣令人矚目。通過(guò)Docker容器化技術(shù)，我們的CPU性能得到了極大的釋放。具體來(lái)說(shuō)，CPU消耗一直平穩(wěn)在1%，幾乎沒(méi)有出現(xiàn)抖動(dòng)。相較于舊架構(gòu)，新架構(gòu)的CPU消耗從原本的45%降低到了1%，性能得到了質(zhì)的提升。

三、為何選擇新架構(gòu)

為何要進(jìn)行如此大規(guī)模的架構(gòu)升級(jí)呢？答案在于舊架構(gòu)存在的瓶頸。在之前的瀏覽服務(wù)架構(gòu)中，高達(dá)20%-40%的頁(yè)面請(qǐng)求需要重新渲染，這一過(guò)程中涉及重新計(jì)算、查詢、創(chuàng)建對(duì)象等操作，導(dǎo)致了CPU和內(nèi)存的消耗增加，進(jìn)而影響了tp99的性能。為了保證瀏覽的流暢性和響應(yīng)速度，我們必須對(duì)舊架構(gòu)進(jìn)行大刀闊斧的改革。

四、頁(yè)面瀏覽與頁(yè)面渲染的異步化

新架構(gòu)的核心思想在于實(shí)現(xiàn)頁(yè)面瀏覽與頁(yè)面渲染的異步化。我們希望通過(guò)保證每次請(qǐng)求都能獲取到Redis的整頁(yè)緩存，從而消除因頁(yè)面渲染導(dǎo)致的性能問(wèn)題。理想情況下，如果頁(yè)面數(shù)據(jù)發(fā)生變動(dòng)，我們可以通過(guò)手動(dòng)觸發(fā)渲染（如頁(yè)面發(fā)布新內(nèi)容）或者通過(guò)監(jiān)聽(tīng)MQ（消息隊(duì)列）自動(dòng)觸發(fā)渲染。

在實(shí)際操作中，有些外部接口并不支持MQ或者使用MQ存在困難。例如，活動(dòng)頁(yè)面置入的某個(gè)商品名稱發(fā)生變化的情況。為了解決這一問(wèn)題，我們的view工程會(huì)每隔指定時(shí)間向engine發(fā)起重新渲染請(qǐng)求，并將最新內(nèi)容放入Redis。這樣，下一次請(qǐng)求到來(lái)時(shí)，就可以快速獲取到新內(nèi)容。雖然活動(dòng)眾多，但我們通過(guò)加一個(gè)緩存key的方式，實(shí)現(xiàn)對(duì)有訪問(wèn)活動(dòng)的定時(shí)重新發(fā)起渲染，有效解決了這一問(wèn)題。

五、新架構(gòu)整理（不包含業(yè)務(wù)）

在新架構(gòu)中，view工程的職責(zé)被重新定義。它主要負(fù)責(zé)直接從緩存或硬盤(pán)中獲取靜態(tài)HTML返回。如果沒(méi)有緩存命中，則返回錯(cuò)誤頁(yè)面。這樣的設(shè)計(jì)使得瀏覽服務(wù)更加高效、響應(yīng)更快，為用戶帶來(lái)了更流暢的瀏覽體驗(yàn)。

系統(tǒng)架構(gòu)與存儲(chǔ)策略解析

在探討文件系統(tǒng)的存取性能之前，我們需要理解其背后的技術(shù)架構(gòu)和存儲(chǔ)策略。對(duì)于當(dāng)前的工程架構(gòu)，我們主要關(guān)注緩存和渲染流程，以及不同存儲(chǔ)方案的優(yōu)缺點(diǎn)。

一、緩存與渲染機(jī)制

在項(xiàng)目中，緩存key的過(guò)期狀態(tài)是重新發(fā)起渲染的重要觸發(fā)因素。當(dāng)緩存未過(guò)期時(shí)，系統(tǒng)將直接從緩存中獲取數(shù)據(jù)，避免了向渲染引擎重新請(qǐng)求數(shù)據(jù)的過(guò)程。而當(dāng)緩存key過(guò)期時(shí)，系統(tǒng)會(huì)根據(jù)需求向渲染引擎發(fā)起請(qǐng)求，進(jìn)行頁(yè)面的重新渲染。渲染引擎的主要職責(zé)是處理活動(dòng)頁(yè)面的渲染，并將結(jié)果存儲(chǔ)到硬盤(pán)或Redis中。publish工程和MQ（消息隊(duì)列）負(fù)責(zé)監(jiān)控頁(yè)面變化，一旦發(fā)生變化則觸發(fā)重新渲染。

二、Engine工程與存儲(chǔ)策略

Engine工程的核心任務(wù)是頁(yè)面內(nèi)容的渲染和更新。當(dāng)頁(yè)面內(nèi)容發(fā)生變化時(shí)，Engine會(huì)進(jìn)行頁(yè)面的重新渲染，并將整頁(yè)內(nèi)容存儲(chǔ)在Redis中或者推送至硬盤(pán)。與此View工程則負(fù)責(zé)從Redis中獲取頁(yè)面內(nèi)容并返回給用戶。這種架構(gòu)使得頁(yè)面內(nèi)容的更新和訪問(wèn)更加高效和靈活。

三、View工程架構(gòu)對(duì)比：硬盤(pán)版與Redis版

1. Redis版：

優(yōu)點(diǎn)：接入簡(jiǎn)單、性能好，尤其在大規(guī)模頁(yè)面訪問(wèn)場(chǎng)景下表現(xiàn)突出。單個(gè)Docker的TPS（每秒事務(wù)處理量）可達(dá)到700。

缺點(diǎn)：嚴(yán)重依賴京東Redis服務(wù)，一旦Redis服務(wù)出現(xiàn)問(wèn)題，將導(dǎo)致所有頁(yè)面無(wú)法訪問(wèn)。

2. 硬盤(pán)版：

優(yōu)點(diǎn)：不依賴外部服務(wù)，只要應(yīng)用服務(wù)正常運(yùn)行且網(wǎng)絡(luò)通暢，即可穩(wěn)定提供服務(wù)。在頁(yè)面數(shù)量不大的情況下，性能卓越，單個(gè)Docker的TPS可達(dá)到2000。

缺點(diǎn)：當(dāng)頁(yè)面數(shù)據(jù)量巨大時(shí)（如系統(tǒng)所有活動(dòng)頁(yè)），磁盤(pán)IO消耗會(huì)增加（使用Java IO時(shí)）。通過(guò)采用nginx+lua的組合，可以有效控制IO消耗在10%以內(nèi)。

四、解決方案與未來(lái)趨勢(shì)

針對(duì)上述存儲(chǔ)策略的優(yōu)缺點(diǎn)，我們提出以下解決方案：

1. 采用URL hash方式分配頁(yè)面訪問(wèn)和存儲(chǔ)，確保所有頁(yè)面均勻分布到各個(gè)應(yīng)用服務(wù)器上。

2. 利用nginx+lua的異步IO代替Java IO，提高IO效率。現(xiàn)在，nginx+lua的應(yīng)用服務(wù)因其高并發(fā)處理能力、高性能和高穩(wěn)定性而受到青睞。

View工程主要負(fù)責(zé)從存儲(chǔ)介質(zhì)（Redis或硬盤(pán)）中獲取頁(yè)面內(nèi)容。通過(guò)深入了解各種存儲(chǔ)方案的優(yōu)缺點(diǎn)，并結(jié)合實(shí)際需求選擇合適的方案，我們可以構(gòu)建更高效、穩(wěn)定的Web服務(wù)。對(duì)于Java工程化、高性能及分布式技術(shù)感興趣的朋友，歡迎加入我們的Java進(jìn)階交流群，與阿里大牛直播交流技術(shù)，共享Java大型互聯(lián)網(wǎng)技術(shù)的視頻資源。群號(hào)為：694549689。技術(shù)突破與架構(gòu)升級(jí)：為你打開(kāi)新世界的大門(mén)

一、技術(shù)瓶頸的突破

你是否擁有1-5年的工作經(jīng)驗(yàn)，面對(duì)當(dāng)前流行的技術(shù)感到迷茫，不知道從何下手？或者你在公司多年，過(guò)得安逸，但跳槽面試時(shí)卻屢屢碰壁？如果是這樣，那么你可能需要突破技術(shù)瓶頸，進(jìn)一步提升自己的技能水平。本文為你提供了一條可行的路徑。

二、進(jìn)階與跳槽策略

對(duì)于想要在短時(shí)間內(nèi)進(jìn)修并跳槽拿高薪的你，我們提供了一種解決方案。通過(guò)學(xué)習(xí)和掌握java工作機(jī)制、常用設(shè)計(jì)思想以及常用java開(kāi)發(fā)框架，你可以為自己的職業(yè)生涯打開(kāi)新的大門(mén)。對(duì)于那些沒(méi)有工作經(jīng)驗(yàn)但基礎(chǔ)扎實(shí)的開(kāi)發(fā)者，我們也歡迎你加入我們的行列。

三、架構(gòu)優(yōu)化與創(chuàng)新：硬盤(pán)與redis的結(jié)合

通過(guò)測(cè)試對(duì)比，我們發(fā)現(xiàn)view工程讀本地硬盤(pán)的速度比讀redis還要快。我們選擇了硬盤(pán)作為終極版架構(gòu)的主要存儲(chǔ)，而redis則作為備份。當(dāng)硬盤(pán)讀取失敗時(shí)，才會(huì)轉(zhuǎn)向讀取redis。這種架構(gòu)具備硬盤(pán)版的全部?jī)?yōu)點(diǎn)，同時(shí)去掉了tomcat，直接利用nginx的高并發(fā)能力和io處理能力，使各項(xiàng)性能和穩(wěn)定性達(dá)到最優(yōu)。

四、新架構(gòu)的優(yōu)勢(shì)與挑戰(zhàn)

新架構(gòu)的優(yōu)勢(shì)在于：所有業(yè)務(wù)邏輯都被剝離到engine工程，使得新view工程理論上永遠(yuǎn)無(wú)需上線；災(zāi)備多樣化且更加簡(jiǎn)單；與業(yè)務(wù)邏輯完全隔離，不依賴外部接口和服務(wù)，大促期間也能保持穩(wěn)定訪問(wèn)；性能大幅提升，從1000ms提升到10ms左右；穩(wěn)定性增強(qiáng)，只要view服務(wù)器的網(wǎng)絡(luò)正常，就可以實(shí)現(xiàn)理論上永不掛機(jī)；大幅度節(jié)省了服務(wù)器資源。

五、分享與心得

作為開(kāi)發(fā)者，我們一直在吸取網(wǎng)絡(luò)上的資源，不斷成長(zhǎng)。受“張開(kāi)濤”大神的啟發(fā)，我將活動(dòng)系統(tǒng)新架構(gòu)進(jìn)行整理并分享給大家，希望能給大家?guī)?lái)幫助。這是我第一次在網(wǎng)上分享，難免有考慮不周之處。未來(lái)我會(huì)繼續(xù)分享自己的心得，與大家共同成長(zhǎng)。我想說(shuō)的是，只要我們不斷努力，不斷突破自己，就一定能打開(kāi)新世界的大門(mén)。讓我們一起迎接挑戰(zhàn)，共創(chuàng)未來(lái)！

從事開(kāi)發(fā)已有近10載的我，深知技術(shù)的魅力和挑戰(zhàn)。我希望能通過(guò)我的分享，激發(fā)更多人的學(xué)習(xí)熱情和創(chuàng)新精神。我相信，只要我們保持學(xué)習(xí)的心態(tài)，不斷追求進(jìn)步，我們就能在這個(gè)快速變化的時(shí)代中立足。我想說(shuō)的是，無(wú)論遇到什么困難，都不要放棄。讓我們一起努力，創(chuàng)造更美好的未來(lái)！