在進(jìn)入一個(gè)未知的范疇前，一定要先梳理這個(gè)范疇的架構(gòu)，待有了對(duì)比全部認(rèn)知后再深挖。學(xué)習(xí)UI規(guī)劃也是相同，假如有條件，能夠嘗試了解一個(gè)新的互聯(lián)網(wǎng)商品出爐的作業(yè)流程。

怎么做競(jìng)品分析

1. 找到商業(yè)需求
2. 用戶操作流程
3. 產(chǎn)品功能分析
4. 交互邏輯思考
5. 用戶使用評(píng)價(jià)
6. 得到設(shè)計(jì)需求

01. 找到商業(yè)需求

02. 用戶操作流程

03. 產(chǎn)品功能分析

04. 交互邏輯思考

• 搜索之后頁(yè)面的跳轉(zhuǎn)的層級(jí)
• 搜索結(jié)果展示
• 頁(yè)面布局的合理性
• 圖片比例規(guī)則
• 按鈕熱區(qū)
• 表單展示形式
• 等等

05. 用戶使用評(píng)價(jià)

06. 總結(jié)輸出

• 關(guān)鍵詞搜索
• 搜索建議
• 條件過(guò)濾
• 搜索歷史
• 查找相似商品
• 讓用戶快速識(shí)別搜索入口
• 字段排序

小結(jié)

話說(shuō)回來(lái)，所謂「認(rèn)真分析」，也是有法可依、有據(jù)可循的。今天就給大家復(fù)盤(pán)下，身為產(chǎn)品經(jīng)理，最需要掌握的四大分析法，都如何來(lái)做。 

一、市場(chǎng)分析

• 從行業(yè)角度，要看行業(yè)有沒(méi)有發(fā)展，市場(chǎng)規(guī)模大不大，政策好不好；
• 從用戶角度，要看市場(chǎng)中的用戶習(xí)慣、用戶構(gòu)成、用戶期望；
• 從自身角度，要認(rèn)清在市場(chǎng)中自己的優(yōu)勢(shì)劣勢(shì)，遇到的挑戰(zhàn)等。

• 搜集相關(guān)資料，包括宏觀經(jīng)濟(jì)、行業(yè)競(jìng)爭(zhēng)、技術(shù)趨勢(shì)、市場(chǎng)階段、市場(chǎng)規(guī)模等；
• 分析市場(chǎng)用戶基本情況；
• 分析自身基本情況。

二、競(jìng)品分析

三、用戶分析

• 避免出現(xiàn)誘導(dǎo)用戶選擇的選項(xiàng)，比如：如果給你提供一個(gè)XX功能，你會(huì)不會(huì)用。
• 避免出現(xiàn)無(wú)法理解的專業(yè)術(shù)語(yǔ)，比如：你是否希望我們的產(chǎn)品采用個(gè)性化推薦算法分發(fā)內(nèi)容。
• 避免出現(xiàn)容易引起歧義的模糊詞語(yǔ)，比如：你使用社交電商產(chǎn)品頻率是多少。
• 避免出現(xiàn)需要讓用戶思考的問(wèn)題，比如：你每周共花多少錢買我們的產(chǎn)品。
• 避免直接出現(xiàn)產(chǎn)品名稱，比如：你覺(jué)得像喜馬拉雅、得到這樣的知識(shí)付費(fèi)產(chǎn)品能解決你的問(wèn)題么。

四、需求分析

什么人，在什么場(chǎng)景下，為了達(dá)到什么目的，在遇到什么問(wèn)題的情況下，希望采用什么方法來(lái)解決。

如果您想訂閱本博客內(nèi)容，每天自動(dòng)發(fā)到您的郵箱中， 請(qǐng)點(diǎn)這里

原因

出于安全考慮，瀏覽器有一個(gè)同源策略。瀏覽器中，異步請(qǐng)求的地址與目標(biāo)地址的協(xié)議、域名和端口號(hào)三者與當(dāng)前有不同，就屬于跨域請(qǐng)求。

限制跨域訪問(wèn)是瀏覽器的一個(gè)安全策略，因?yàn)槿绻麤](méi)有這個(gè)策略，那么就有被跨站攻擊的危險(xiǎn)。比如，攻擊者在自己的網(wǎng)站A放置一個(gè)表單，這個(gè)表單發(fā)起DELETE請(qǐng)求，刪除某個(gè)用戶在B網(wǎng)站上的個(gè)人資料。如果沒(méi)有同源策略保護(hù)，那么在同一個(gè)瀏覽器內(nèi)，如果用戶已經(jīng)登錄了B網(wǎng)站，這個(gè)刪除的請(qǐng)求就會(huì)被接受，導(dǎo)致在用戶不知情的情況下自己在B網(wǎng)站中的資料被刪除。

解決方式

瀏覽器的同源策略提升了安全性，但是給需要在不同域名下開(kāi)發(fā)的開(kāi)發(fā)者帶來(lái)了跨域問(wèn)題。

解決跨域的問(wèn)題主要有： 
jsonp和cors。jsonp是利用 script 標(biāo)簽可以跨域加載的特性而創(chuàng)造出來(lái)的一種非正式的跨域解決方案。在實(shí)際開(kāi)發(fā)中，推薦使用cors，即在服務(wù)端返回時(shí)加入允許跨域的請(qǐng)求頭，允許指定域名的跨域訪問(wèn)。

千萬(wàn)要小心！這種直接加 * 號(hào)的做法是相當(dāng)危險(xiǎn)的，千萬(wàn)別這么做！

response.addHeader("Access-Control-Allow-Origin", "*"); 


    

        1
    

/**
 * 使用Filter的方式解決跨域問(wèn)題
 */ public class CorsFilter implements Filter { private static final List<String> ALLOW_ORIGINS = Config.getListString("allowOrigins", ","); private static final String REQUEST_OPTIONS = "OPTIONS"; @Override public void init(FilterConfig filterConfig) throws ServletException {
    } @Override public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        HttpServletRequest request = (HttpServletRequest) servletRequest;
        HttpServletResponse response = (HttpServletResponse) servletResponse;
        String orgHeader = request.getHeader(HttpHeaders.ORIGIN); if (orgHeader != null && ALLOW_ORIGINS.contains(orgHeader)) { // 允許的跨域的域名 response.addHeader("Access-Control-Allow-Origin", orgHeader); // 允許攜帶 cookies 等認(rèn)證信息 response.addHeader("Access-Control-Allow-Credentials", "true"); // 允許跨域的方法 response.addHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE, PATCH, PUT, HEAD"); // 允許跨域請(qǐng)求攜帶的請(qǐng)求頭 response.addHeader("Access-Control-Allow-Headers", "Content-Type, Content-Length, Authorization, Accept, X-Requested-With"); // 返回結(jié)果可以用于緩存的最長(zhǎng)時(shí)間，單位是秒。-1表示禁用 response.addHeader("Access-Control-Max-Age", "3600"); // 跨域預(yù)檢請(qǐng)求，直接返回 if (REQUEST_OPTIONS.equalsIgnoreCase(request.getMethod())) { return;
            }
        }
        filterChain.doFilter(request, response);
    } @Override public void destroy() {

    }
} 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

    

        16
    

    

        17
    

    

        18
    

    

        19
    

    

        20
    

    

        21
    

    

        22
    

    

        23
    

    

        24
    

    

        25
    

    

        26
    

    

        27
    

    

        28
    

    

        29
    

    

        30
    

    

        31
    

    

        32
    

    

        33
    

    

        34
    

    

        35
    

    

        36
    

    

        37
    

    

        38
    

    

        39
    

<filter> <filter-name>corsfilter</filter-name> <filter-class>com.bj58.crm.plus.filter.CorsFilter</filter-class> </filter> <filter-mapping> <filter-name>corsfilter</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> </filter-mapping> 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

let axios = require("axios"); let qs = require("qs");
axios.defaults.withCredentials = true;
axios.defaults.headers.post["Content-Type"] = "application/x-www-form-urlencoded"; function post(url, param) { return axios.post(url, qs.stringify(param))
} function get(url, param) { axios.get(url, {params: param})
}

export default {
  get,
  post
};

藍(lán)藍(lán)設(shè)計(jì)( www.yvirxh.cn )是一家專注而深入的界面設(shè)計(jì)公司，為期望卓越的國(guó)內(nèi)外企業(yè)提供卓越的UI界面設(shè)計(jì)、BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計(jì)、 網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)

背景

下圖所示線上故障，你的產(chǎn)品線是否曾經(jīng)中招或者正在中招？同樣的問(wèn)題總是在不同產(chǎn)品線甚至相同產(chǎn)品線不同系統(tǒng)重復(fù)上演，這些故障有個(gè)共同特點(diǎn)，就是線下常規(guī)測(cè)試很難發(fā)現(xiàn)，即便線上驗(yàn)證也不易暴露。但是總是在“無(wú)變更安全日”悄然爆發(fā)，嚴(yán)重影響系統(tǒng)穩(wěn)定性指標(biāo)。

面對(duì)這些看似并無(wú)規(guī)律的故障，Case by case的分析無(wú)疑是低效而且不系統(tǒng)的，無(wú)法全面掃除穩(wěn)定性測(cè)試盲區(qū)，也無(wú)法阻止悲劇在其他產(chǎn)品線再一次發(fā)生。為此筆者把問(wèn)題聚類，根據(jù)問(wèn)題特點(diǎn)尋求通用測(cè)試手段，并在產(chǎn)品線各個(gè)系統(tǒng)落地驗(yàn)證，效果顯著，現(xiàn)把個(gè)人經(jīng)驗(yàn)融合前輩經(jīng)驗(yàn)產(chǎn)出，供大家參考，有則改之，無(wú)則加勉。

首先，為了讓大家更好了解這些故障對(duì)業(yè)務(wù)系統(tǒng)穩(wěn)定性的影響程度，需了解下何為穩(wěn)定性，衡量指標(biāo)就是系統(tǒng)可用性= MTBF / (MTBF + MTTR) ， 其中MTBF， Mean Time Between Failure， 是平均無(wú)故障時(shí)間， 而MTTR， Mean Time To Repair，是平均修復(fù)時(shí)間，參考下表更加直觀。

從如上數(shù)字看，5個(gè)9的故障時(shí)間月故障時(shí)間只有25s，3個(gè)9的可用性月故障時(shí)間也只有40多分鐘，回想我們平時(shí)處理過(guò)的線上問(wèn)題，開(kāi)發(fā)和測(cè)試質(zhì)量把控不過(guò)關(guān)，然后再把期望寄托在半人肉處理故障的運(yùn)維團(tuán)隊(duì)，顯然無(wú)法達(dá)到線上產(chǎn)品穩(wěn)定性要求。

為了保障系統(tǒng)穩(wěn)定性，提前消除風(fēng)險(xiǎn)勢(shì)在必行。產(chǎn)品質(zhì)量風(fēng)險(xiǎn)類型很多，產(chǎn)品研發(fā)流程的各個(gè)階段都可能引入和存在風(fēng)險(xiǎn)，每個(gè)階段的風(fēng)險(xiǎn)的類型和發(fā)現(xiàn)手段都不盡相同，為此產(chǎn)出如下風(fēng)險(xiǎn)模型。按照風(fēng)險(xiǎn)發(fā)生的階段及原因，風(fēng)險(xiǎn)類型可分為：架構(gòu)設(shè)計(jì)風(fēng)險(xiǎn)、編碼風(fēng)險(xiǎn)、安全風(fēng)險(xiǎn)、流程規(guī)范風(fēng)險(xiǎn)、運(yùn)維風(fēng)險(xiǎn)和監(jiān)控風(fēng)險(xiǎn)。

本文主要講解架構(gòu)設(shè)計(jì)風(fēng)險(xiǎn)，接下來(lái)介紹的每個(gè)風(fēng)險(xiǎn)都會(huì)說(shuō)明風(fēng)險(xiǎn)定義，影響，以及通過(guò)什么技術(shù)手段來(lái)進(jìn)行風(fēng)險(xiǎn)識(shí)別，最后總結(jié)風(fēng)險(xiǎn)消除方案。另外每個(gè)風(fēng)險(xiǎn)都會(huì)有具體的例子來(lái)講解，這些例子都是發(fā)生在百度內(nèi)部的真實(shí)故事。

架構(gòu)設(shè)計(jì)風(fēng)險(xiǎn)

架構(gòu)設(shè)計(jì)風(fēng)險(xiǎn)是QA最容易忽略的，該類風(fēng)險(xiǎn)出現(xiàn)在研發(fā)階段的早期，我們都知道缺陷越早的暴露后期研發(fā)的維護(hù)成本越低，而且一旦架構(gòu)設(shè)計(jì)上出現(xiàn)了問(wèn)題，影響面是涉及整個(gè)模塊甚至系統(tǒng)的，修復(fù)代價(jià)必然非常高，因此對(duì)于架構(gòu)設(shè)計(jì)的風(fēng)險(xiǎn)更要提前了解和避免。

根據(jù)既往經(jīng)驗(yàn)，架構(gòu)設(shè)計(jì)風(fēng)險(xiǎn)大概可以分為以下幾個(gè)維度：交互、依賴、耦合。

交互類常見(jiàn)風(fēng)險(xiǎn)：重復(fù)交互、高頻交互、冗余/無(wú)用交互、接口不可重用、超時(shí)重試設(shè)置不合理、IP直連、跨機(jī)房等。

依賴類常見(jiàn)風(fēng)險(xiǎn)：不合理強(qiáng)弱依賴、無(wú)效依賴、忽略第三方依賴、緩存依賴失效等。

耦合類常見(jiàn)風(fēng)險(xiǎn)：架構(gòu)耦合不合理、緩存耦合不合理等。

一、重復(fù)交互

1、風(fēng)險(xiǎn)定義

在一次業(yè)務(wù)請(qǐng)求中，系統(tǒng)內(nèi)部發(fā)起了多次完全相同的網(wǎng)絡(luò)交互，即存在重復(fù)交互風(fēng)險(xiǎn)。從交互層級(jí)和上下游來(lái)說(shuō)，重復(fù)交互有兩類，整個(gè)業(yè)務(wù)請(qǐng)求范圍內(nèi)的重復(fù)和同層重復(fù)，其中同層重復(fù)交互的上下游也是相同的，本文更多關(guān)注的是整個(gè)業(yè)務(wù)請(qǐng)求范圍內(nèi)的重復(fù)交互。通常在一次業(yè)務(wù)請(qǐng)求中，為了提升性能和負(fù)載，盡量避免或者降低重復(fù)交互次數(shù)。

2、風(fēng)險(xiǎn)影響

重復(fù)交互增加接口耗時(shí)，降低接口性能，當(dāng)重復(fù)的是跨機(jī)房交互會(huì)使得性能急劇下降影響系統(tǒng)穩(wěn)定性，增加對(duì)下游服務(wù)的壓力（模塊壓力增加一倍，下游服務(wù)壓力增加幾倍）。

3、風(fēng)險(xiǎn)識(shí)別

如果兩個(gè)交互具有完全相同的請(qǐng)求服務(wù)對(duì)象（尤其是mysql、redis、memcache這類數(shù)據(jù)存儲(chǔ)服務(wù)）、請(qǐng)求數(shù)據(jù)、返回?cái)?shù)據(jù)，那么這兩個(gè)交互就判定為重復(fù)交互；對(duì)于獲取不到交互數(shù)據(jù)時(shí)也可以通過(guò)數(shù)據(jù)包size進(jìn)行初判。這里可以借助開(kāi)源trace系統(tǒng)，采集業(yè)務(wù)測(cè)試時(shí)的調(diào)用鏈信息，根據(jù)上面的判斷規(guī)則進(jìn)行風(fēng)險(xiǎn)自動(dòng)識(shí)別。

4、風(fēng)險(xiǎn)消除

在對(duì)實(shí)時(shí)性要求可控的前提下，將第一次查詢信息緩存下來(lái)。

• 真實(shí)案例一：系統(tǒng)間重復(fù)交互。11次重復(fù)請(qǐng)求session，對(duì)于前端一次請(qǐng)求就要對(duì)session模塊產(chǎn)生幾十倍的流量沖擊，所有這些交互都是完全重復(fù)的，極大的降低的了接口性能和session的負(fù)載能力。

• 真實(shí)案例二：mysql/redis重復(fù)交互。mysql/redis作為系統(tǒng)中性能瓶頸，這樣的重復(fù)請(qǐng)求無(wú)疑加速了其性能瓶頸的到達(dá)。

二、高頻交互

1、風(fēng)險(xiǎn)定義

一次用戶發(fā)起的請(qǐng)求，如果在模塊之間的交互次數(shù)完全依賴于后端返回的數(shù)據(jù)條數(shù)，會(huì)給下游造成極大壓力的同時(shí)，也降低了系統(tǒng)的穩(wěn)定性。相同業(yè)務(wù)請(qǐng)求的模塊交互次數(shù)多少不一，原因通常是代碼中循環(huán)操作內(nèi)部存在網(wǎng)絡(luò)交互，總交互次數(shù)受到循環(huán)迭代的次數(shù)影響。這樣的情況在模塊上線初期，可能因?yàn)閿?shù)據(jù)量比較小、pv比較小很容易被人忽視，當(dāng)某天上線一些大數(shù)據(jù)、大客戶，將會(huì)給予致命一擊。

2、風(fēng)險(xiǎn)影響

循環(huán)請(qǐng)求次數(shù)過(guò)多會(huì)導(dǎo)致下游壓力倍增（前端pv增加一倍，后端pv增加幾十倍），接口性能不穩(wěn)定，降低系統(tǒng)處理能力。系統(tǒng)穩(wěn)定性完全依賴于數(shù)據(jù)的代碼邏輯非常脆弱，當(dāng)遇到某一個(gè)大數(shù)據(jù)時(shí)將會(huì)出現(xiàn)模塊假死、系統(tǒng)雪崩、功能失敗。

3、風(fēng)險(xiǎn)識(shí)別

基于上游傳來(lái)的數(shù)據(jù)或某個(gè)子請(qǐng)求返回的數(shù)據(jù)量（通常是一個(gè)數(shù)組），針對(duì)每個(gè)數(shù)組元素進(jìn)行網(wǎng)絡(luò)請(qǐng)求，遍歷并沒(méi)有錯(cuò)，但是要對(duì)這個(gè)遍歷的數(shù)組元素個(gè)數(shù)有限制，否則循環(huán)遍歷的次數(shù)就完全依賴于數(shù)據(jù)。這里也可以借助開(kāi)源trace系統(tǒng)，采集業(yè)務(wù)測(cè)試時(shí)的調(diào)用鏈信息，根據(jù)上面的判斷規(guī)則進(jìn)行風(fēng)險(xiǎn)自動(dòng)識(shí)別。

4、風(fēng)險(xiǎn)消除

數(shù)據(jù)量要可控，結(jié)合產(chǎn)品業(yè)務(wù)需求，比如請(qǐng)求返回結(jié)果要有上限；批量請(qǐng)求替代逐個(gè)請(qǐng)求。

• 真實(shí)案例：查詢某商戶物料詳情，當(dāng)該商戶擁有大量物料，就出現(xiàn)了如下場(chǎng)景，用戶的一次查詢就造成服務(wù)與db之間156次交互，那該接口的性能就可想而知了，平均耗時(shí)都在3s+，用戶體驗(yàn)極差。

三、冗余/無(wú)用交互

1、風(fēng)險(xiǎn)定義

交互依賴的數(shù)據(jù)已出現(xiàn)異常，還繼續(xù)執(zhí)行后續(xù)交互，使得后續(xù)的交互是沒(méi)有任何意義的冗余交互。這些依賴的數(shù)據(jù)，可能是上游傳遞而來(lái)，也可能是與下游模塊請(qǐng)求得來(lái)。

2、風(fēng)險(xiǎn)影響

冗余交互會(huì)占用系統(tǒng)資源，降低接口性能，從而影響系統(tǒng)穩(wěn)定性和性能。

3、風(fēng)險(xiǎn)識(shí)別

如果交互A依賴數(shù)據(jù)B（比如交互A的請(qǐng)求數(shù)據(jù)中需要傳入B），在B異常（比如數(shù)據(jù)為空、null、false等）情況下，還是發(fā)生了交互A，那么就認(rèn)為A是冗余交互；如果操作A依賴于操作B的成功執(zhí)行，當(dāng)B異常時(shí)，還是發(fā)生了操作A，那么A也認(rèn)為是冗余交互?？梢越柚_(kāi)源trace系統(tǒng)，采集業(yè)務(wù)測(cè)試時(shí)的調(diào)用鏈信息，根據(jù)上面的判斷規(guī)則進(jìn)行風(fēng)險(xiǎn)自動(dòng)識(shí)別。

4、風(fēng)險(xiǎn)消除

代碼中增加異常邏輯判斷：當(dāng)交互依賴的數(shù)據(jù)異常時(shí)不進(jìn)行該交互。

• 真實(shí)案例：如下調(diào)用鏈正常場(chǎng)景是先查詢團(tuán)單list，然后用團(tuán)單list去查詢每個(gè)團(tuán)單的優(yōu)惠。但是當(dāng)查詢團(tuán)單列表為空時(shí)，就沒(méi)有必要再調(diào)用marketing查詢團(tuán)單的優(yōu)惠信息了，應(yīng)該立即返回錯(cuò)誤碼。這里增加無(wú)效交互無(wú)疑降低了接口性能。

四、接口不可重入

1、風(fēng)險(xiǎn)定義

相同請(qǐng)求發(fā)給模塊再次處理，不能保證結(jié)果一致，符合預(yù)期。

2、風(fēng)險(xiǎn)識(shí)別

相同請(qǐng)求，模塊返回結(jié)果不一致亦或重復(fù)寫(xiě)操作產(chǎn)生臟數(shù)據(jù)。這里可以利用錄制工具，重放請(qǐng)求，驗(yàn)證結(jié)果正確性。

3、風(fēng)險(xiǎn)消除

對(duì)于防重入可總結(jié)三點(diǎn)，前端加入防重復(fù)點(diǎn)擊設(shè)置，接口層加入鎖機(jī)制，db層需要加入唯一鍵設(shè)置。

• 真實(shí)案例

在商家會(huì)員卡充值購(gòu)買的流程中，nmq故障情況下，購(gòu)買結(jié)果頁(yè)顯示充值失敗，但是卡中余額卻一直在直線增加，原因是充值接口沒(méi)有做到可重入，這個(gè)case幸好在線下及時(shí)發(fā)現(xiàn)，否則后果不堪設(shè)想。

商家會(huì)員卡涉及到的購(gòu)買流程如右下圖所示：

用戶提交訂單并且錢包處理完成后，錢包回調(diào)交易模塊的payresult接口，交易模塊驗(yàn)證通過(guò)之后，會(huì)調(diào)用商家會(huì)員卡的rechargemoney接口給商家會(huì)員卡充值。為了提高充值接口的可用性，與交易模塊有個(gè)約定了一個(gè)機(jī)制：若調(diào)用rechargemoney返回的errno不為0 ，則投入nmq重試三分鐘，三分鐘之內(nèi)的重試均沒(méi)有成功，才觸發(fā)自動(dòng)退款。商家會(huì)員卡模塊的充值接口rechargemoney的流程圖如下圖所示：

在rechargemoney接口處理過(guò)程中，有一個(gè)防頻繁重入的判定redis鎖過(guò)程，expireTime設(shè)置時(shí)間為10s，10s內(nèi)會(huì)攔截過(guò)來(lái)的重復(fù)請(qǐng)求，直接返回。

上述過(guò)程可以看到，前端是有無(wú)限重試策略的，因此可以認(rèn)為前端無(wú)防重入，那么看接口層鎖機(jī)制，重試時(shí)間3min明顯大于鎖有效時(shí)間10s，因此相同請(qǐng)求10s后鎖機(jī)制也失效，再看db層，插入order_id和其他營(yíng)銷信息，數(shù)據(jù)庫(kù)中并沒(méi)有設(shè)置order_id為唯一鍵，因此該接口徹底失守，沒(méi)有做到可重入，相同訂單可以重復(fù)插入成功，從而導(dǎo)致業(yè)務(wù)表現(xiàn)為同一訂單多次重復(fù)充值。

對(duì)于該案例，改進(jìn)方案是首先將鎖有效時(shí)間設(shè)置大于一切來(lái)源的重試時(shí)間，其次在db充值記錄表中將orderid設(shè)置為主鍵，雙重保護(hù)該接口做到可重入。

五、超時(shí)設(shè)置不合理

1、風(fēng)險(xiǎn)定義

顧名思義，就是超時(shí)并沒(méi)有根據(jù)系統(tǒng)真實(shí)表現(xiàn)科學(xué)的設(shè)置。

2、風(fēng)險(xiǎn)影響

就像下圖化學(xué)反應(yīng)一樣，不合理的超時(shí)實(shí)際設(shè)置并不會(huì)產(chǎn)生真正影響，但是遇到網(wǎng)絡(luò)故障，依賴超時(shí)時(shí)，后果不堪設(shè)想。

模塊交互必設(shè)超時(shí)，這是基本要求，但是超時(shí)設(shè)置過(guò)長(zhǎng)、過(guò)短可能會(huì)適得其反。不合理超時(shí)設(shè)置主要表現(xiàn)為①交互超時(shí)時(shí)間設(shè)置過(guò)長(zhǎng)，比如5s甚至10s的超時(shí)②下游超時(shí)時(shí)間大于上游超時(shí)時(shí)間。

交互超時(shí)重試時(shí)間過(guò)長(zhǎng)，在下游偶爾出現(xiàn)網(wǎng)絡(luò)抖動(dòng)時(shí)連接被hang住，接口耗時(shí)增加，并且降級(jí)模塊處理能力。下游超時(shí)>上游超時(shí)，上游超時(shí)后斷開(kāi)連接引發(fā)重試，下游還在繼續(xù)上次運(yùn)算（此時(shí)已經(jīng)沒(méi)有意義），下游負(fù)載增加N倍（取決于重試次數(shù)設(shè)置和發(fā)生重試的層數(shù)），使得系統(tǒng)性能急劇下降甚至雪崩。

3、風(fēng)險(xiǎn)識(shí)別

①超時(shí)時(shí)間設(shè)置過(guò)長(zhǎng)（比如數(shù)據(jù)庫(kù)connect超時(shí)1s，模塊讀寫(xiě)超時(shí)5s）

②下游超時(shí)時(shí)間大于上游超時(shí)時(shí)間。

4、風(fēng)險(xiǎn)消除

從系統(tǒng)整體考慮，并且結(jié)合重試和本模塊計(jì)算時(shí)間的影響。下游超時(shí)<上游超時(shí)；超時(shí)時(shí)間不宜過(guò)長(zhǎng)，根據(jù)下游接口性能設(shè)置；對(duì)于弱依賴的服務(wù)交互，超時(shí)時(shí)間更不能過(guò)長(zhǎng)，以免弱依賴阻塞主流程。

• 真實(shí)案例：如下圖，該接口調(diào)用redis超時(shí)時(shí)間超過(guò)2s，然而Redis性能極好，單線程阻塞性server，這種長(zhǎng)耗時(shí)會(huì)阻塞其他請(qǐng)求，很容易引起系統(tǒng)雪崩，應(yīng)該把redis連接超時(shí)時(shí)間修改適當(dāng)小。

六、重試設(shè)置不合理

1、風(fēng)險(xiǎn)定義

顧名思義，就是重試并沒(méi)有根據(jù)系統(tǒng)真實(shí)表現(xiàn)科學(xué)的設(shè)置。

2、風(fēng)險(xiǎn)影響

任何網(wǎng)絡(luò)交互都可能失敗，為了保證最終交互成功，通常交互失敗/超時(shí)、數(shù)據(jù)錯(cuò)誤后再次與該模塊交互，即發(fā)生了重試。重試的次數(shù)設(shè)置不當(dāng)，輕者交互成功率不達(dá)標(biāo)，業(yè)務(wù)失敗率增高，嚴(yán)重者引發(fā)系統(tǒng)雪崩。

3、風(fēng)險(xiǎn)識(shí)別

查看框架配置文件中重試次數(shù)配置，是否簡(jiǎn)單粗暴的經(jīng)驗(yàn)值設(shè)定重試次數(shù)，比如一律重試3次，查看代碼中邏輯控制的重試限制（這種很隱蔽）。

4、風(fēng)險(xiǎn)消除

相對(duì)于固定的重試序列，隨機(jī)重試序列也可能給系統(tǒng)帶來(lái)風(fēng)險(xiǎn)，例如可能會(huì)降低下游模塊的cache命中率，降低系統(tǒng)性能，甚至引起雪崩。

評(píng)估重試機(jī)制：

1) 真的需要在每一層都努力重試嗎？

2) 真的需要這么多次重試嗎？

3) 真的需要在連接，寫(xiě)，讀這三者失敗后都重試嗎？

• 按照業(yè)務(wù)需求和模塊性能設(shè)置重試次數(shù)

• 弱依賴不用重試也可以

• 下游模塊性能好，基本不會(huì)超時(shí)，也可以不重試

• 大部分情況下，重試次數(shù)為1已經(jīng)足夠

• 真實(shí)案例

如圖為某產(chǎn)品線的架構(gòu)，整個(gè)系統(tǒng)中，上游模塊對(duì)下游模塊所有的交互，重試次數(shù)都是設(shè)成3次，交互失敗包括連接失敗，寫(xiě)失敗，讀失敗這三種情形。如果是寫(xiě)和讀失敗，那么要關(guān)閉當(dāng)前連接，再重新發(fā)起連接。

如果一臺(tái)bs假死，到該bs的請(qǐng)求會(huì)超時(shí)。（注意區(qū)分模塊假死和真死，假死情況下，模塊端口打開(kāi)，能夠接收上游連接，但是由于各種原因（如連接隊(duì)列滿，工作線程耗盡，陷入死循環(huán)等），不會(huì)返回任何應(yīng)答，上游模塊必須等待超時(shí)才知道失敗，連接超時(shí)，寫(xiě)超時(shí)和讀超時(shí)都有可能。而在真死情況下，模塊端口關(guān)閉，或者干脆程序退出，上游模塊連接它會(huì)很快得到失敗返回碼，這個(gè)返回碼由下游模塊的操作系統(tǒng)協(xié)議棧返回的，如ECONNREFUSED錯(cuò)誤碼代表端口不存在，連接被拒絕。） 

那么as有1/3的概率需要重試，as重試的過(guò)程中，ui可能早就認(rèn)為as已經(jīng)超時(shí)了，所以u(píng)i也開(kāi)始重試，ui重試的過(guò)程中，webserver可能認(rèn)為ui已經(jīng)超時(shí)了，所以webserver也開(kāi)始重試……就這樣，整個(gè)系統(tǒng)的負(fù)載急劇增加，到達(dá)bs的qps會(huì)是平時(shí)的27倍，直到系統(tǒng)崩潰為止。

七、IP直連服務(wù)方式

1、風(fēng)險(xiǎn)定義

A,B兩個(gè)系統(tǒng)交互，B系統(tǒng)分布式部署，A-B連接是通過(guò)配置B系統(tǒng)所有IP方式。

2、風(fēng)險(xiǎn)影響

當(dāng)B系統(tǒng)分布式服務(wù)中某一臺(tái)掛掉時(shí)，不能做到failover，導(dǎo)致故障影響擴(kuò)大。

3、風(fēng)險(xiǎn)消除

通過(guò)bns或者組的方式進(jìn)行連接。

• 真實(shí)案例

某產(chǎn)品線依賴服務(wù)redis調(diào)用均采用ip列表的方式，如果redis proxy出現(xiàn)單機(jī)故障，需要人工介入進(jìn)行切流量止損。單機(jī)發(fā)單重啟修復(fù)周期有時(shí)會(huì)達(dá)小時(shí)級(jí)別，因此線上服務(wù)在故障期間會(huì)長(zhǎng)時(shí)間處于切流量狀態(tài)，高峰期單機(jī)房容量會(huì)存在風(fēng)險(xiǎn)。如同時(shí)有其他機(jī)房服務(wù)異常，則無(wú)法執(zhí)行既定預(yù)案止損。并且如想下掉故障proxy，只能采用發(fā)上線單修改線上配置的方式。止損操作復(fù)雜，周期長(zhǎng)，效率低下，具體case如下:

(1)用戶中心redisproxy單機(jī)故障，人工切流量止損，恢復(fù)服務(wù)花費(fèi)2小時(shí)，期間線上處于切流量狀態(tài)。

(2)商品中心redis proxy單機(jī)故障，會(huì)存在扣除庫(kù)存失敗的風(fēng)險(xiǎn)。恢復(fù)服務(wù)花費(fèi)半小時(shí)，后續(xù)又再次發(fā)生宕機(jī)，發(fā)單下掉故障proxy。

如上對(duì)應(yīng)前面講的故障時(shí)間，該服務(wù)sla月可用性已不足3個(gè)9。

八、跨機(jī)房請(qǐng)求

1、風(fēng)險(xiǎn)定義

交互的兩個(gè)模塊分別部署在不同機(jī)房。

2、風(fēng)險(xiǎn)影響

跨機(jī)房交互由于存在網(wǎng)絡(luò)延時(shí)，嚴(yán)重影響接口性能、請(qǐng)求成功率，極大的降低了系統(tǒng)穩(wěn)定性。

3、風(fēng)險(xiǎn)識(shí)別

①配置錯(cuò)誤（ODP框架）ral-service中配置的服務(wù)后端IP的Tag不能為空（在ral中，會(huì)將Tag為空的也認(rèn)為是本機(jī)房）②上游傳入idc錯(cuò)誤，Idc是完全匹配，nj和nj02就不相同，因此如果上游傳入nj02，當(dāng)前模塊的idc是nj，就會(huì)找不到對(duì)應(yīng)的Tag而只能使用default。

4、風(fēng)險(xiǎn)消除

主要關(guān)注配置是否合理，由于線上配置很難在線下驗(yàn)證正確性，肉眼排查難免遺漏，因此可通過(guò)線上機(jī)房流量切換演練驗(yàn)證。

九、不合理強(qiáng)/弱依賴

1、風(fēng)險(xiǎn)定義

所謂強(qiáng)依賴就是，請(qǐng)求鏈路中某個(gè)服務(wù)失敗/結(jié)果異常/無(wú)結(jié)果后，核心邏輯必失敗，否則就認(rèn)為是弱依賴。不合理的強(qiáng)弱依賴有兩類，本應(yīng)該是弱依賴的設(shè)置為強(qiáng)依賴，本應(yīng)該是強(qiáng)依賴的設(shè)置為弱依賴。

2、風(fēng)險(xiǎn)影響

系統(tǒng)穩(wěn)定性取決于調(diào)用鏈中所有依賴穩(wěn)定性最差的依賴，如果將穩(wěn)定性較差的服務(wù)作為強(qiáng)依賴將嚴(yán)重影響穩(wěn)定性

3、風(fēng)險(xiǎn)識(shí)別

強(qiáng)弱依賴的合理性是需要結(jié)合業(yè)務(wù)判斷的，如果業(yè)務(wù)返回結(jié)果不可或缺該依賴，那么就該設(shè)置強(qiáng)依賴；如何判斷該依賴是否為強(qiáng)依賴可以通過(guò)故障模擬驗(yàn)證，如果模擬該依賴異常時(shí)導(dǎo)致調(diào)用異常，則判斷其為強(qiáng)依賴。

4、風(fēng)險(xiǎn)消除

①調(diào)整不合理的強(qiáng)弱依賴關(guān)系，將業(yè)務(wù)非強(qiáng)依賴服務(wù)降級(jí)；②通過(guò)系統(tǒng)優(yōu)化及運(yùn)維優(yōu)化等手段提高強(qiáng)依賴的穩(wěn)定性。③對(duì)強(qiáng)依賴結(jié)果進(jìn)行全面校驗(yàn)，保證強(qiáng)依賴故障能夠及時(shí)被發(fā)現(xiàn)。

• 真實(shí)案例

用戶下單請(qǐng)求到trade模塊，是通過(guò)消息隊(duì)列nmq保證下單后的商戶通知功能，通知商戶是借助公共服務(wù)云推送，這里云推送被實(shí)現(xiàn)成了強(qiáng)依賴，也就是當(dāng)云推送如果失敗，返回給本次請(qǐng)求失敗。

某次下單高峰期時(shí)，云推送出現(xiàn)故障，無(wú)法給ios用戶推送消息，nmq收到請(qǐng)求失敗后，會(huì)持續(xù)不斷的重發(fā)，nmq的通道堵塞之后也影響了trade模塊向nmq的請(qǐng)求故障不斷往上層蔓延，最后用戶無(wú)法下單。

對(duì)于如上案例，工程師最后去掉對(duì)云推送強(qiáng)依賴代碼，服務(wù)才慢慢恢復(fù)，但已造成非常大的損失。

十、無(wú)效依賴干擾

1、風(fēng)險(xiǎn)定義

服務(wù)啟動(dòng)流程中與該依賴建立了連接，但是整個(gè)邏輯處理過(guò)程中無(wú)需依賴該服務(wù)，無(wú)任何業(yè)務(wù)關(guān)聯(lián)性。

2、風(fēng)險(xiǎn)影響

其實(shí)該風(fēng)險(xiǎn)是不合理依賴的一個(gè)特例，無(wú)業(yè)務(wù)關(guān)聯(lián)性的依賴應(yīng)該及時(shí)去除，否則會(huì)影響整體服務(wù)穩(wěn)定性。

3、風(fēng)險(xiǎn)識(shí)別

與依賴服務(wù)只有一次鏈接交互，無(wú)其他交互，就可以初步判斷該依賴為無(wú)效依賴，為了準(zhǔn)確評(píng)估可再結(jié)合代碼排查。

• 真實(shí)案例

某產(chǎn)品線由于配置管理較亂，有個(gè)服務(wù)每次啟動(dòng)都會(huì)判斷多個(gè)與業(yè)務(wù)完全不依賴的服務(wù)啟動(dòng)情況，這幾個(gè)依賴服務(wù)處于無(wú)人維護(hù)狀態(tài)，非常不穩(wěn)定，從而導(dǎo)致該服務(wù)啟動(dòng)失敗率非常高。

十一、第三方依賴

1、風(fēng)險(xiǎn)定義

請(qǐng)求的完成，需要依賴產(chǎn)品外的其他服務(wù)，都稱之為第三方（tp）依賴，按照公司又分為公司外第三方，比如糯米酒店依賴攜程服務(wù)；公司內(nèi)第三方，比如passport相對(duì)于手百。

2、風(fēng)險(xiǎn)影響

第三方服務(wù)的性能，正確性，穩(wěn)定性直接影響自身服務(wù)，尤其是第三方強(qiáng)依賴，當(dāng)?shù)谌揭蕾嚦霈F(xiàn)異常，很可能導(dǎo)致自身產(chǎn)品受到損失；公司外第三方依賴有些是小型公司，技術(shù)和運(yùn)維能力有限，其服務(wù)的性能，正確性、穩(wěn)定性不是很高。

3、風(fēng)險(xiǎn)識(shí)別

第三方依賴的可靠性是不可控的也是我們系統(tǒng)建設(shè)中不可避免的，那么只能盡量降低第三方依賴不穩(wěn)定對(duì)自身的影響。

4、風(fēng)險(xiǎn)消除：

• 盡量避免第三方強(qiáng)依賴；

• 超時(shí)設(shè)置，重試設(shè)置結(jié)合第三方容量，平均響應(yīng)時(shí)間，部署情況；

• 增加第三方依賴掛掉，假死，接口變更的校驗(yàn)及容錯(cuò)降級(jí)處理，從架構(gòu)和云微商做到各個(gè)TP方與自身業(yè)務(wù)的解耦；

• 運(yùn)維上，提高第三方依賴可靠性，使用內(nèi)網(wǎng)bns，vip請(qǐng)求，且避免跨機(jī)房交互。

• 真實(shí)案例

某產(chǎn)品線依賴A,B,C三個(gè)tp方數(shù)據(jù)進(jìn)行匯總展示，每次都需要調(diào)用三方都有結(jié)果時(shí)再進(jìn)行聚合，否則認(rèn)為整個(gè)流程失敗，而三個(gè)tp方穩(wěn)定性不盡相同，其中B是個(gè)小公司，經(jīng)常出現(xiàn)故障，導(dǎo)致自身服務(wù)經(jīng)常故障。

對(duì)此工程師對(duì)各個(gè)TP方加上了全面校驗(yàn)，當(dāng)驗(yàn)證故障后自動(dòng)調(diào)用降級(jí)操作，去掉該tp依賴。從此服務(wù)穩(wěn)定性大大提升。

十二、緩存穿透

1、風(fēng)險(xiǎn)定義

前端請(qǐng)求一個(gè)肯定不存在的key，導(dǎo)致每次請(qǐng)求都會(huì)請(qǐng)求后端原始數(shù)據(jù)，使得緩存被“穿透”，當(dāng)該類請(qǐng)求高并發(fā)時(shí)，那么后端壓力凸顯。

2、風(fēng)險(xiǎn)影響

緩存穿透后，每個(gè)請(qǐng)求都會(huì)到達(dá)后端服務(wù)，對(duì)后端服務(wù)壓力突增；當(dāng)緩存穿透的并發(fā)較高（尤其是惡意攻擊），后端服務(wù)很可能被壓垮，導(dǎo)致整個(gè)系統(tǒng)癱瘓。

3、風(fēng)險(xiǎn)原因

一種可能是對(duì)于主從分離系統(tǒng)，緩存失效時(shí)間小于主從延遲時(shí)間，尤其是跨機(jī)房的主從分離，主從延遲在某些時(shí)候會(huì)達(dá)到數(shù)秒甚至數(shù)十秒，這是如果緩存時(shí)間設(shè)置過(guò)小，就會(huì)導(dǎo)致所有緩存讀寫(xiě)記過(guò)均為失效結(jié)果，進(jìn)而請(qǐng)求后端服務(wù)獲取新的數(shù)據(jù)。另一種可能是查詢結(jié)果為空的情況。

4、風(fēng)險(xiǎn)消除

• 對(duì)于查詢結(jié)果為空的情況也進(jìn)行緩存，緩存時(shí)間設(shè)置短一點(diǎn)，或者該key對(duì)應(yīng)的數(shù)據(jù)insert了之后清理緩存；

• 對(duì)于一定不存在的key進(jìn)行過(guò)濾，把這些key放到一個(gè)大的bitmap上；

• 設(shè)計(jì)的時(shí)候考慮，當(dāng)緩存失效時(shí)，系統(tǒng)服務(wù)的情況及應(yīng)對(duì)措施。

十三、緩存失效/緩存雪崩

1、風(fēng)險(xiǎn)定義

大量緩存同時(shí)過(guò)期失效，前端請(qǐng)求同時(shí)到達(dá)后端服務(wù)。

2、風(fēng)險(xiǎn)影響

當(dāng)并發(fā)量足夠大（比如秒殺，搶購(gòu)），后端服務(wù)很可能被壓垮，導(dǎo)致整個(gè)系統(tǒng)雪崩。

3、風(fēng)險(xiǎn)識(shí)別

緩存設(shè)置時(shí)間相同，失效周期也相同，導(dǎo)致多個(gè)緩存同時(shí)失效。

4、風(fēng)險(xiǎn)消除

• 不同的key，設(shè)置不同的過(guò)期時(shí)間，讓緩存失效的時(shí)間點(diǎn)盡量散列均勻；

• 在緩存試下后，通過(guò)加鎖或者隊(duì)列來(lái)控制讀數(shù)據(jù)庫(kù)讀寫(xiě)緩存的線程數(shù)量（比如對(duì)某個(gè)key只允許一個(gè)線程查詢和寫(xiě)緩存，其他線程等待）；

• 做二級(jí)緩存，A為原始緩存，A2位拷貝緩存，A1失效時(shí)，可以訪問(wèn)A2，A1緩存失效設(shè)置為較短，A2設(shè)置為長(zhǎng)期。

• 真實(shí)案例

某產(chǎn)品線監(jiān)控發(fā)現(xiàn)機(jī)器A機(jī)器的8688端口掛掉了，經(jīng)追查發(fā)現(xiàn)一個(gè)廣告配置下發(fā)的接口（/api/v1/ipid）掛掉了，據(jù)統(tǒng)計(jì)，前一天23點(diǎn)到當(dāng)日9點(diǎn)之間，該接口被訪問(wèn)了400萬(wàn)+次，正常來(lái)講，這種廣告配置下發(fā)的接口一天最多幾百個(gè)請(qǐng)求量。

經(jīng)查，客戶端有一個(gè)零點(diǎn)定時(shí)觸發(fā)策略，零點(diǎn)會(huì)同時(shí)啟動(dòng)很多服務(wù)，平時(shí)并發(fā)請(qǐng)求會(huì)命中緩存，不會(huì)造成太大壓力，可是當(dāng)時(shí)正趕上緩存時(shí)間到期，大量請(qǐng)求將服務(wù)接口壓死，端口掛掉。

對(duì)此臨時(shí)方案是在接入層nginx配置文件中加入了流量控制機(jī)制，用lua腳本來(lái)將零點(diǎn)的請(qǐng)求屏蔽掉，長(zhǎng)期方案是避免這種緩存集體失效的情況。

十四、 架構(gòu)耦合不合理

1、風(fēng)險(xiǎn)定義

系統(tǒng)架構(gòu)和設(shè)計(jì)上存在著耦合，包括模塊耦合、接口耦合、消息隊(duì)列耦合。具體體現(xiàn)在，主次不分的功能在一個(gè)模塊或者接口中實(shí)現(xiàn)，nmq中不同重要性的命令耦合在同一個(gè)module中。

2、風(fēng)險(xiǎn)影響

整個(gè)系統(tǒng)穩(wěn)定性<最不穩(wěn)定的功能穩(wěn)定性，不重要的功能可能拖垮重要功能

3、風(fēng)險(xiǎn)消除

整體思路就是，重要與不重要拆分，實(shí)時(shí)與非實(shí)時(shí)拆分，在線與離線拆分，根本上解決就是架構(gòu)解耦，但是系統(tǒng)發(fā)展到一定階段再拆分代碼成本很高，這里可以通過(guò)運(yùn)維方法控制解耦，具體見(jiàn)如下案例。

• 真實(shí)案例

某產(chǎn)品線的一級(jí)服務(wù)和二級(jí)服務(wù)共同依賴一個(gè)基礎(chǔ)服務(wù)，由于二級(jí)服務(wù)的一個(gè)bug拖垮基礎(chǔ)服務(wù)，從而導(dǎo)致一級(jí)服務(wù)不可用，對(duì)此解決方案是通過(guò)運(yùn)維將不同上游流量分開(kāi)。

十五、緩存耦合不合理

思想同2.1.14這里不再贅述。

總結(jié)

本文給出了常見(jiàn)的15種架構(gòu)設(shè)計(jì)風(fēng)險(xiǎn)，希望大家能夠在實(shí)際工作中參考審視自己系統(tǒng)是否也存在同樣的風(fēng)險(xiǎn)，盡早消除，提高穩(wěn)定性！

      web前端開(kāi)發(fā)工程是是一個(gè)很新的職業(yè)，在國(guó)內(nèi)乃至國(guó)際上真正開(kāi)始受到重視的時(shí)間不超過(guò)五年。web前端開(kāi)發(fā)，是從網(wǎng)頁(yè)制作演變而來(lái)的，名稱上有很明顯的時(shí)代特征。隨著人們對(duì)用戶體驗(yàn)的要求越來(lái)越高，前端開(kāi)發(fā)的技術(shù)難度越來(lái)越大，web前端開(kāi)發(fā)工程師這一職業(yè)終于從設(shè)計(jì)和制作不分的局面中獨(dú)立出來(lái)。

       早期的前端其實(shí)就是table布局，后來(lái)發(fā)展到所謂的div+css網(wǎng)站重構(gòu)，再到現(xiàn)在的讓人眼花繚亂的各種各樣的新技術(shù)，web前端技術(shù)發(fā)展是非?？焖俚模虼诉x擇了前端這個(gè)行業(yè)就意味著不停的學(xué)習(xí)吧。讓我們先看看張克軍繪制的前端知識(shí)體系結(jié)構(gòu)：

      前端開(kāi)發(fā)的核心是HTML+CSS+JavaScript。本質(zhì)上他們構(gòu)成了一個(gè)MVC框架，即HTML作為信息模型（Model），css控制樣式（View），JavaScript負(fù)責(zé)調(diào)度數(shù)據(jù)和實(shí)現(xiàn)某種展現(xiàn)邏輯（Controller）。

      HTML

      1.標(biāo)簽的分類，

      2.標(biāo)簽表示一個(gè)元素

      3.按性質(zhì)分類：block-level 和 inline-level

      4.按語(yǔ)義分類：

            Headings:h1,h2,h3,h4,h5,h6

            paragraphs:p

            Text formatting:em,strong,sub,del,ins,small

            Lists:ul,li,ol,dl,dt,dd

            Tables:table,thead,tbody,tr,th,td

            Forms and input: form,input,select,textarea

            Others:div,span,a,img,<!---->

            HTML5:header,footer,article,section

       XHTML

       XHTML于2000年的1月26日成為W3C標(biāo)準(zhǔn)。W3C將XHTML定義為的HTML版本，XHTML將逐漸取代HTML。XHTML是通過(guò)把HTML和XML各自的長(zhǎng)處加以結(jié)合形成的。XHTML語(yǔ)法規(guī)則如下：

      屬性名和標(biāo)簽名稱必須小寫(xiě)

      屬性值必須加引號(hào)

      屬性不能簡(jiǎn)寫(xiě)

      用ID屬性代替name屬性

      XHTML元素必須被正確地嵌套

      XHTML元素必須被關(guān)閉

     標(biāo)簽語(yǔ)義化

     為表達(dá)語(yǔ)義而標(biāo)記文檔，而不是為了樣式，結(jié)構(gòu)良好的文檔可以向?yàn)g覽器傳達(dá)盡可能多的語(yǔ)義，不論是瀏覽器位于掌上電腦還是時(shí)髦的桌面圖形瀏覽器。結(jié)構(gòu)良好的文檔都能向用戶傳達(dá)可視化的語(yǔ)義即使是在老的瀏覽器，或是在被用戶關(guān)閉了CSS的現(xiàn)代瀏覽器中。同時(shí)結(jié)構(gòu)良好的HTML代碼也有助于搜索引擎索引你的網(wǎng)站。

      不要使用table布局，table是用來(lái)表格顯示的。

      不要到處濫用div標(biāo)簽，div是用來(lái)分塊用的。

      不要使用樣式標(biāo)簽，如font，center，big，small，b，i，樣式可以用CSS來(lái)控制，b和i可以用strong和em來(lái)代替。

      不要使用換行標(biāo)簽<br />和空格來(lái)控制樣式，請(qǐng)用CSS。

      盡量不要使用內(nèi)聯(lián)CSS

      CSS

      1.css基礎(chǔ)知識(shí)

        層疊和繼承

        優(yōu)先級(jí)

        盒模型

        定位

        浮動(dòng)

     2.css進(jìn)階

        css sprite

        瀏覽器兼容性

        IE haslayout和block format content

        css frameworks 

        css3

        css性能優(yōu)化

        less and sass

        css sprite主要用于前端性能優(yōu)化的一種技術(shù)，原理是通過(guò)多張背景圖合成在一張圖片上從而減少http請(qǐng)求，加快載入速度。

        瀏覽器兼容性

        絕大部分情況下，我們需要考慮瀏覽器的兼容性，目前正在使用的瀏覽器版本非常多，IE6，IE7，IE8，IE9，IE10，Chrome，F(xiàn)irefox，Safari。

        IE haslayout和block format content

        IE haslayout是一個(gè)Internet explore for Windows的私有概念，他決定了一個(gè)元素如何顯示以及約束其包含的內(nèi)容、如何與其他元素交互和建立聯(lián)系、如何響應(yīng)和傳遞應(yīng)用程序事件、用戶事件等。而有些HTML元素則默認(rèn)就有l(wèi)ayout。目前只有IE6和IE7有這個(gè)概念。BFC是W3C css2.1規(guī)范中的一個(gè)概念，他決定了元素如何應(yīng)對(duì)其內(nèi)容進(jìn)行定位。以及與其他元素的關(guān)系和相互作用。這個(gè)其實(shí)和瀏覽器的兼容性有關(guān)，因?yàn)闆Q大部分的兼容性問(wèn)題都是他們引起的。參考：css BFC和IE haslayout介紹。

        css framework

        css框架是一系列css文件的集合體，包含了基本的元素重置，頁(yè)面排版、網(wǎng)格布局、表單樣式，通用規(guī)則等代碼塊，用于簡(jiǎn)化web前端開(kāi)發(fā)的工作，提高工作效率。目前常見(jiàn)框架有：

       960 grid system

       blueprint css

       bluetrip

       minimum page

       還是一個(gè)比較出名的和特殊的框架是Twitter的bootstrap，bootstrap是快速開(kāi)發(fā)web應(yīng)用程序前端的工具包。它是一個(gè)css和HTML的集合，它使用了的瀏覽器技術(shù)，給你的web開(kāi)發(fā)提供了時(shí)尚的版式，表單，buttons，表格，網(wǎng)格系統(tǒng)等等。它是基于less開(kāi)發(fā)的，不支持IE6，在IE7和IE8里效果也不咋地。

       css3

       雖然css3還沒(méi)有正式成為標(biāo)準(zhǔn)，但是IE9+，Chrome，F(xiàn)irefox等現(xiàn)代瀏覽器都支持css3。css3提供了好多以前需要用JavaScript和切圖才能搞定的功能，目前主要功能更有：圓角、多背景、@font-face、動(dòng)畫(huà)與漸變、漸變色、box陰影、RGBa-加入透明色、文字陰影。

       css性能優(yōu)化

       css代碼是控制頁(yè)面顯示樣式與效果的最直接“工具”  ，但是在性能調(diào)優(yōu)時(shí)他們通常會(huì)被web開(kāi)發(fā)工程師所忽略，而事實(shí)上不規(guī)范的css會(huì)對(duì)頁(yè)面渲染的效率有嚴(yán)重影響，尤其是對(duì)于結(jié)構(gòu)復(fù)雜的web2.0頁(yè)面，這種影響更是不可磨滅的。所以，寫(xiě)出規(guī)范的、高性能的css代碼會(huì)極大地提高應(yīng)用程序的效率。

       less and sass

       less和sass都是css預(yù)處理器，用來(lái)為css增加一些編輯的特性，無(wú)需考慮瀏覽器的兼容問(wèn)題，例如你可以在css中使用變量、簡(jiǎn)單的程序邏輯、函數(shù)等等在編程語(yǔ)言中的一些基本技巧，可以讓你的css更加簡(jiǎn)潔。適應(yīng)性更強(qiáng)，代碼更直觀等諸多好處。

        sass基于ruby開(kāi)發(fā)，less既可以在客戶端運(yùn)行，也可以借助node.js或者rhino在服務(wù)器端運(yùn)行。

UI設(shè)計(jì)師提升自己沒(méi)有捷徑，就是多練。聯(lián)系當(dāng)然也要分階段和方法。且在練習(xí)前的審美也很重要。下面先說(shuō)說(shuō)練習(xí)的幾個(gè)階段。