2、在項(xiàng)目的架構(gòu)設(shè)計中，對于未來可能發(fā)生的需求變更，你是如何考慮的？如何應(yīng)對？
需求變更可以分成業(yè)務(wù)性和非業(yè)務(wù)性兩類。
非業(yè)務(wù)性主要是指由于系統(tǒng)自身應(yīng)用場景發(fā)生變化（處理的數(shù)據(jù)量，業(yè)務(wù)規(guī)則復(fù)雜度），使得需要對現(xiàn)有系統(tǒng)做結(jié)構(gòu)性調(diào)整。
舉個例子：
開放平臺的日志分析系統(tǒng)，在數(shù)據(jù)量不斷增大和計算即時性要求增強(qiáng)的情況下，由單機(jī)多線程計算演變?yōu)槎鄼C(jī)分布式協(xié)作計算，從全量文件分析轉(zhuǎn)變?yōu)樵隽炕跀?shù)據(jù)流分析。但整體結(jié)構(gòu)卻沒有發(fā)生太大變化，如下圖：
最初，每日訪問量6千萬，數(shù)據(jù)分析報表每日一出，分析器僅僅用于業(yè)務(wù)行為分析統(tǒng)計，單機(jī)每日拖取全量日志文件，多線程切割分析后合并。系統(tǒng)設(shè)計中有統(tǒng)計模型抽象層和簡單的任務(wù)管理層，統(tǒng)計模型抽象層就是將傳統(tǒng)的統(tǒng)計分析抽象成為對無結(jié)構(gòu)化的數(shù)據(jù)做MapReduce的計算，模型規(guī)則引擎可以根據(jù)配置直接分析無結(jié)構(gòu)化定義的日志數(shù)據(jù)，任務(wù)管理層在第一階段只是負(fù)責(zé)任務(wù)多線程內(nèi)分配和管理。
當(dāng)日志量每日達(dá)到2億，分析器每日分析數(shù)據(jù)涵蓋了系統(tǒng)，ISV，服務(wù)提供方，業(yè)務(wù)多角度分析和數(shù)據(jù)挖掘，單機(jī)IO及CPU成為瓶頸。因此，首先修改第二層，將原來多線程的任務(wù)管理和分配，擴(kuò)展支持多機(jī)任務(wù)管理和分配（基于TCP層的數(shù)據(jù)交互協(xié)議）。第三層里所當(dāng)然的出現(xiàn)成為承載多機(jī)協(xié)作的基礎(chǔ)層，因?yàn)楸旧頉]有太多的復(fù)雜流程在里面，就直接實(shí)現(xiàn)NIO的通信層。這次需求變更的代價就是擴(kuò)展了任務(wù)分配協(xié)議，支持多機(jī)協(xié)作工作，本地的數(shù)據(jù)合并，轉(zhuǎn)變?yōu)橥ㄐ艂鬏敽蟮谋镜財?shù)據(jù)合并，但對上層業(yè)務(wù)分析引擎沒有任何影響。
當(dāng)日志量每日達(dá)到8億，分析器已經(jīng)應(yīng)用于整個系統(tǒng)的監(jiān)控和告警及業(yè)務(wù)趨勢分析等各個方面，全量每日分析不滿足業(yè)務(wù)需求，則由每日全量分析，改變?yōu)闀r時增量分析。這次修改了第二層，首先擴(kuò)展了slave的數(shù)據(jù)源獲取的方式，除了支持文件獲取，還支持http數(shù)據(jù)流的獲取，其次，擴(kuò)展了master對于任務(wù)周期的管理，任務(wù)列表可以周期被重置，同時可以周期性導(dǎo)出增量數(shù)據(jù)，因此即時分析可以通過使用較短周期（分鐘級別）的任務(wù)列表管理，任務(wù)分配，結(jié)果合并和增量導(dǎo)出，實(shí)現(xiàn)即時的大數(shù)據(jù)量分析。這次需求變更，可以發(fā)現(xiàn)僅僅是對任務(wù)管理的周期做了更靈活的擴(kuò)展，同時在Slave上做了多數(shù)據(jù)源數(shù)據(jù)的獲取，對于本身任務(wù)管理，合并，計算都沒有任何影響。
總結(jié)來說，對于非業(yè)務(wù)性的需求改變，需要能夠?qū)I(yè)務(wù)性設(shè)計和系統(tǒng)設(shè)計隔離開來，同時明晰系統(tǒng)設(shè)計邊界，支持外部接口的可擴(kuò)展，這樣就能夠支撐由于系統(tǒng)應(yīng)用場景的變化帶來的系統(tǒng)架構(gòu)的變化。
對于業(yè)務(wù)性需求變更，思維方式應(yīng)當(dāng)如下（有順序）：
1. 是否已經(jīng)有類似功能，需要做些改進(jìn)就可以滿足需求。
2. 沒有類似功能，是否可以抽取部分已有功能，再做部分封裝即可實(shí)現(xiàn)。
3. 完全沒有可以復(fù)用的內(nèi)容，考慮一下后續(xù)可能的業(yè)務(wù)需求。
也許大家看了比較虛，但是業(yè)務(wù)一定是根據(jù)場景來做出自己的實(shí)際判斷，而上面說的三點(diǎn)其實(shí)就是一個理念，不斷優(yōu)化業(yè)務(wù)代碼，復(fù)用的思考會促進(jìn)不斷的合理化結(jié)構(gòu)（因?yàn)閺?fù)用性越小的代碼大部分情況下結(jié)構(gòu)本身存在耦合性過強(qiáng)的問題）。
3、在開放平臺中，如何防范對于API應(yīng)用接口的安全入侵、拒絕服務(wù)攻擊？如何應(yīng)對突發(fā)的訪問請求激增情況？
API的安全問題主要涉及兩個方面：用戶隱私安全和服務(wù)自身安全。
用戶隱私安全主要通過對應(yīng)用的身份認(rèn)證及用戶主動授權(quán)的兩方面來保證。當(dāng)然現(xiàn)在很多開放平臺對于授權(quán)的時效性放的還比較松，這樣會導(dǎo)致用戶一次授權(quán)，而被應(yīng)用無限制使用的風(fēng)險（用戶往往找不到平臺解除授權(quán)的地方）。淘寶開放平臺，對應(yīng)用做了級別劃分和類型劃分，首先在服務(wù)訪問范圍上，不同級別和類型的應(yīng)用可訪問的服務(wù)范圍就被區(qū)別開來，因此高風(fēng)險性的數(shù)據(jù)類服務(wù)只對Hosting的應(yīng)用合作伙伴開放，不同類型的應(yīng)用訪問的服務(wù)也有所差別。其次，用戶授權(quán)也根據(jù)應(yīng)用類型的不同及服務(wù)本身的安全級別會有不同的授權(quán)時效性及授權(quán)提示，使得不同應(yīng)用操作用戶數(shù)據(jù)會限制在不同時長內(nèi)。最后，還提供了用戶主動查詢應(yīng)用訪問數(shù)據(jù)的情況及解綁授權(quán)的入口，給用戶提供主動解除風(fēng)險的機(jī)會。
服務(wù)自身安全，主要是應(yīng)用自身主動和被動攻擊（例如網(wǎng)站沒有作數(shù)據(jù)緩存和防爬蟲的功能，在爬蟲爬取網(wǎng)頁的同時，導(dǎo)致大量的無用服務(wù)請求）。當(dāng)前開放平臺主要通過兩種模式多種維度來防止服務(wù)激增的問題。兩種模式：一種是主動在業(yè)務(wù)流程處理中按照簡單規(guī)則計算并做訪問流量控制，例如通過利用集中式和本地Cache作為計數(shù)器根據(jù)簡單規(guī)則來屏蔽過量訪問。另一種是通過記錄日志，交由外部分析系統(tǒng)增量分析，外部分析器根據(jù)各種復(fù)雜關(guān)聯(lián)性業(yè)務(wù)規(guī)則最后將分析后的決策推送給業(yè)務(wù)系統(tǒng)去做過量訪問控制。多種維度：IP，應(yīng)用身份，用戶身份，User Agent，訪問的服務(wù)。這些維度可以簡單的單個控制，也可以是組合控制，例如，IP維度可以用在業(yè)務(wù)數(shù)據(jù)可能都是非法的情況下去屏蔽，由于規(guī)則很簡單，可以直接放在主動模式下，而應(yīng)用身份+用戶身份比較復(fù)雜的控制，放在被動模式下，同時規(guī)則可以根據(jù)業(yè)務(wù)基線（不同日同時段，不同周同日的統(tǒng)計結(jié)果）的變化調(diào)整。從技術(shù)角度上來說，通過將業(yè)務(wù)線程池和容器線程池分開（類似于Servlet3容器線程生命周期不再固化與單一的方法），可以自己定義業(yè)務(wù)線程權(quán)重和處理流速來保證后端業(yè)務(wù)系統(tǒng)能力不會由于前端請求量激增時產(chǎn)生惡性循環(huán)。
4、在開放平臺中，面對不同背景、習(xí)慣的用戶和開發(fā)者，如何能夠讓他們使用起來更便捷、易用？
開放平臺在這方面主要做了和將要做這些事情：
1． 多語言SDK自動生成。淘寶當(dāng)前有300多個API，而且服務(wù)還在不斷地增加，每次SDK的升級和發(fā)布都采用模板化方式自動生成，同時多語言的支持可以給開發(fā)者減小開發(fā)成本。這里就要談到SDK的業(yè)務(wù)部分和非業(yè)務(wù)部分的抽象和隔離，更加有利于服務(wù)的增加和減少。
2． 服務(wù)數(shù)據(jù)化到服務(wù)流程化的轉(zhuǎn)變。對于不同領(lǐng)域的開發(fā)者來說，淘寶的服務(wù)其實(shí)并不是都需要或者無差別的，例如淘江湖軟件和商家管理軟件就有很大差異，因此對于淘寶這樣行業(yè)性認(rèn)知要求比較高的服務(wù)使用成本降低需要通過將服務(wù)由專家來做一定的流程化定制，避免使用的高門檻。
3． 提供demo和doc直接附加在SDK中，讓開發(fā)者比較直接的能夠看到使用方式，并且簡單的運(yùn)行一些具體的實(shí)例，增加感性認(rèn)識。
4． 提供wiki和社區(qū)，為服務(wù)升級和變更提供足夠的信息傳播渠道。
5． 提供線上運(yùn)行環(huán)境和控制臺，用直觀體驗(yàn)降低門檻。
5、在優(yōu)化程序，降低系統(tǒng)資源消耗上，有哪些經(jīng)驗(yàn)可以分享？
1．優(yōu)化程序很多程度上是從全局去看，而不是從局部去看，局部的優(yōu)化可能導(dǎo)致全局的性能下降。例如，A系統(tǒng)和B系統(tǒng)是強(qiáng)依賴的，A的處理能力被提升后，到B的單位時間請求量會增加，而此時B服務(wù)能力達(dá)到瓶頸，單位事務(wù)處理時間就會增加，而A的處理能力增強(qiáng)并不一定會提高在A階段的單位處理時間，因此整體事務(wù)處理時間增加，同時系統(tǒng)穩(wěn)定性降低。因此優(yōu)化需要關(guān)注更多的依賴，特別需要事先審視自己系統(tǒng)是依賴流入還是依賴流出系統(tǒng)。
2．優(yōu)化流程首先要切分流程的步驟，然后找到瓶頸的步驟，而優(yōu)化瓶頸點(diǎn)有兩種方式，一種直接優(yōu)化減少瓶頸點(diǎn)資源消耗和處理時間，另一種是利用并行化方式，縮短資源生命周期，增加資源利用率從而減少對于資源消耗，為瓶頸點(diǎn)的資源使用增加能力。
3．合理利用外部計算資源，在可維護(hù)性和性能上找到平衡點(diǎn)。例如開放平臺的結(jié)果返回處理通常情況下需要將對象根據(jù)規(guī)則定義轉(zhuǎn)變?yōu)橥ㄓ玫母袷健＿@部分工作可以交由開放平臺集群來統(tǒng)一處理，也可以將規(guī)則處理后移到業(yè)務(wù)系統(tǒng)，前者的優(yōu)勢在于映射規(guī)則變動升級容易，后者可以把計算工作分?jǐn)偟礁鱾€業(yè)務(wù)集群上，基于映射規(guī)則的成熟和無業(yè)務(wù)性，因此計算外移是提高本系統(tǒng)性能的一種方式。
4．可以將不同資源消耗型的應(yīng)用部署在一起，合理利用資源（CPU消耗型，內(nèi)存消耗型）。
5．在做海量數(shù)據(jù)處理時，不要認(rèn)為Java原生的東西都是無消耗的，那么是去拿一個時間戳，切分一個字符串，匹配一個字符等等，盡量以最直接和簡單的方式實(shí)現(xiàn)邏輯，用原生數(shù)據(jù)類型做為系統(tǒng)中間過程處理內(nèi)容（例如系統(tǒng)中就用long型做日期類處理）。
上面提到的也許看起來很抽象，但過于具體的細(xì)節(jié)優(yōu)化其實(shí)遍及每個角落，優(yōu)化最重要的就是找到全局的問題所在，同時在優(yōu)化后是否會產(chǎn)生新的問題，導(dǎo)致了性能反而不如優(yōu)化前，同時系統(tǒng)穩(wěn)定性也是優(yōu)化所需要考慮的問題。
6、在高并發(fā)應(yīng)用中，Cache的作用不可忽視，在Cache的使用上，有哪些問題需要去注意？
1．集中式緩存不是無代價的。從存儲的數(shù)據(jù)量到交互次數(shù)上都需要去考慮如何降低成本，在海量并發(fā)請求的系統(tǒng)中，存儲標(biāo)識還是內(nèi)容，多次交互還是一次交互，都會對系統(tǒng)產(chǎn)生很大影響。適當(dāng)?shù)目梢允褂枚嗉壘彺妫?/span>remote + local），然后根據(jù)數(shù)據(jù)敏感度設(shè)置有效時間，簡單的處理數(shù)據(jù)失效問題。
2．Cache不可用如何降級。對業(yè)務(wù)系統(tǒng)來說，需要考慮Cache如何降級，也就是業(yè)務(wù)流程是否可以繼續(xù)下去。另一方面如果Cache失效會從其他數(shù)據(jù)源獲取數(shù)據(jù)，那么就需要考慮Cache的瞬間失效產(chǎn)生的峰值是否會直接擊垮后端數(shù)據(jù)源。
3．Cache如果采用數(shù)據(jù)源作為不命中的主動獲取途徑，那么需要防止無效的數(shù)據(jù)請求攻擊透過Cache直接進(jìn)入后端數(shù)據(jù)源。一般可以考慮用布隆算法來做增量白名單。
4．注意使用好Cache提供的原子操作來避免并發(fā)帶來的問題，例如add , replace, inc ,dec等等。
5．需要去了解Cache的命中率和使用容量情況，不要為了技術(shù)而技術(shù)，需要更多的分析業(yè)務(wù)場景，最大限度利用Cache的優(yōu)勢，同時減小存儲消耗的代價。
7、開源產(chǎn)品，很多時候可以用來借鑒設(shè)計思路、進(jìn)行二次開發(fā)、引用部分類庫，應(yīng)用到業(yè)務(wù)產(chǎn)品中。你是如何看待開源產(chǎn)品和業(yè)務(wù)產(chǎn)品之間的關(guān)系？
業(yè)務(wù)產(chǎn)品對于開源技術(shù)的選型需要慎重，同時切記跟風(fēng)，今天FB用了什么，明天TW用了什么，最重要的是自己的業(yè)務(wù)場景，如果可以用簡單的技術(shù)實(shí)現(xiàn)，則優(yōu)先考慮簡單的技術(shù)借鑒部分開源設(shè)計的思想去做，同時量體裁衣簡化系統(tǒng)設(shè)計，往往開源項(xiàng)目發(fā)展到一定規(guī)模會朝通用化方式發(fā)展，使用成本，附加功能，系統(tǒng)的松耦合，都會給中小型系統(tǒng)高速系統(tǒng)帶來一定的負(fù)擔(dān)。
使用開源項(xiàng)目最重要的是了解它解決的問題是什么？應(yīng)用于什么場景，不同場景下的優(yōu)勢和劣勢在什么地方，自身場景中使用的部分成熟度如何，最后做好足夠的測試和驗(yàn)證，聽來的總是虛的，因?yàn)闃I(yè)務(wù)場景不同，就算技術(shù)框架相同，結(jié)果也不同。