來(lái)源： 《從0開(kāi)始學(xué)架構(gòu)》（極客時(shí)間） ---李運(yùn)華

技術(shù)演進(jìn)的方向

動(dòng)力

一個(gè)行業(yè)的發(fā)展，歸根到底就是業(yè)務(wù)的發(fā)展。而影響一個(gè)企業(yè)業(yè)務(wù)的發(fā)展主要有 3 個(gè)因素：市場(chǎng)、技術(shù)、管理，這三者構(gòu)成支撐業(yè)務(wù)發(fā)展的鐵三角，任何一個(gè)因素的不足，都可能導(dǎo)致企業(yè)的業(yè)務(wù)停滯不前。

在這個(gè)鐵三角中，業(yè)務(wù)處于三角形的中心，毫不夸張地說(shuō)，市場(chǎng)、技術(shù)、管理都是為了支撐企業(yè)業(yè)務(wù)的發(fā)展。

我們可以簡(jiǎn)單地將企業(yè)的業(yè)務(wù)分為兩類(lèi)：一類(lèi)是產(chǎn)品類(lèi)，一類(lèi)是服務(wù)類(lèi)。

• 對(duì)于產(chǎn)品類(lèi)業(yè)務(wù)，技術(shù)創(chuàng)新推動(dòng)業(yè)務(wù)發(fā)展！

原因在于用戶選擇一個(gè)產(chǎn)品的根本驅(qū)動(dòng)力在于產(chǎn)品的功能是否能夠更好地幫助自己完成任務(wù)。用戶會(huì)自然而然地選擇那些功能更加強(qiáng)大、性能更加先進(jìn)、體驗(yàn)更加順暢、外觀更加漂亮的產(chǎn)品，而功能、性能、體驗(yàn)、外觀等都需要強(qiáng)大的技術(shù)支撐。

• 對(duì)于服務(wù)類(lèi)業(yè)務(wù)，業(yè)務(wù)發(fā)展推動(dòng)技術(shù)的發(fā)展！

用戶選擇服務(wù)的根本驅(qū)動(dòng)力與選擇產(chǎn)品不同。用戶選擇一個(gè)產(chǎn)品的根本驅(qū)動(dòng)力是其“功能”，而用戶選擇一個(gè)服務(wù)的根本驅(qū)動(dòng)力不是功能，而是“規(guī)模”。

模式

論什么模式的業(yè)務(wù)，如果業(yè)務(wù)的發(fā)展需要技術(shù)同步發(fā)展進(jìn)行支撐，無(wú)一例外是因?yàn)闃I(yè)務(wù)“復(fù)雜度”的上升，導(dǎo)致原有的技術(shù)無(wú)法支撐。

復(fù)雜度要么來(lái)源于功能不斷疊加，要么來(lái)源于規(guī)模擴(kuò)大，從而對(duì)性能和可用性有了更高的要求。既然如此，判斷到底是什么復(fù)雜度發(fā)生了變化就顯得至關(guān)重要了。

那架構(gòu)師具體應(yīng)該按照什么標(biāo)準(zhǔn)來(lái)判斷呢？答案就是基于業(yè)務(wù)發(fā)展階段進(jìn)行判斷，這也是為什么架構(gòu)師必須具備業(yè)務(wù)理解能力的原因。不同的行業(yè)業(yè)務(wù)發(fā)展路徑、軌跡、模式不一樣，架構(gòu)師必須能夠基于行業(yè)發(fā)展和企業(yè)自身情況做出準(zhǔn)確判斷。

互聯(lián)網(wǎng)技術(shù)演進(jìn)模式

聯(lián)網(wǎng)業(yè)務(wù)發(fā)展一般分為幾個(gè)時(shí)期：初創(chuàng)期、發(fā)展期、競(jìng)爭(zhēng)期、成熟期。同時(shí)期的差別主要體現(xiàn)在兩個(gè)方面：復(fù)雜性、用戶規(guī)模。

業(yè)務(wù)復(fù)雜性

1. 初創(chuàng)期

互聯(lián)網(wǎng)業(yè)務(wù)剛開(kāi)始一般都是一個(gè)創(chuàng)新的業(yè)務(wù)點(diǎn)，這個(gè)業(yè)務(wù)點(diǎn)的重點(diǎn)不在于“完善”，而在于“創(chuàng)新”，只有創(chuàng)新才能吸引用戶；而且因?yàn)槠洹靶隆钡奶攸c(diǎn)，其實(shí)一開(kāi)始是不可能很完善的。只有隨著越來(lái)越多的用戶的使用，通過(guò)快速迭代試錯(cuò)、用戶的反饋等手段，不斷地在實(shí)踐中去完善，才能繼續(xù)創(chuàng)新。

初創(chuàng)期的業(yè)務(wù)對(duì)技術(shù)就一個(gè)要求：“快”，但這個(gè)時(shí)候卻又是創(chuàng)業(yè)團(tuán)隊(duì)最弱小的時(shí)期，可能就幾個(gè)技術(shù)人員，所以這個(gè)時(shí)候十八般武藝都需要用上：能買(mǎi)就買(mǎi)，有開(kāi)源的就用開(kāi)源的。

2. 發(fā)展期

業(yè)務(wù)快速發(fā)展時(shí)期的主要目的是將原來(lái)不完善的業(yè)務(wù)逐漸完善，因此會(huì)有越來(lái)越多的新功能不斷地加入到系統(tǒng)中。對(duì)于絕大部分技術(shù)團(tuán)隊(duì)來(lái)說(shuō)，這個(gè)階段技術(shù)的核心工作是快速地實(shí)現(xiàn)各種需求，只有這樣才能滿足業(yè)務(wù)發(fā)展的需要。

一般會(huì)經(jīng)歷下面幾個(gè)階段：

1. 堆功能期

業(yè)務(wù)進(jìn)入快速發(fā)展期的初期，此時(shí)團(tuán)隊(duì)規(guī)模也不大，業(yè)務(wù)需求又很緊，最快實(shí)現(xiàn)業(yè)務(wù)需求的方式是繼續(xù)在原有的系統(tǒng)里面不斷地增加新的功能，重構(gòu)、優(yōu)化、架構(gòu)等方面的工作即使想做，也會(huì)受制于人力和業(yè)務(wù)發(fā)展的壓力而放在一邊。

2. 優(yōu)化期

核心思想是將現(xiàn)有的系統(tǒng)優(yōu)化。例如，采用重構(gòu)、分層、優(yōu)化某個(gè) MySQL 查詢語(yǔ)句，將機(jī)械硬盤(pán)換成 SSD，將數(shù)據(jù)庫(kù)從 MySQL 換成 Oracle，增加 Memcache 緩存等。優(yōu)勢(shì)是對(duì)系統(tǒng)改動(dòng)較小，優(yōu)化可以比較快速地實(shí)施；缺點(diǎn)就是可能過(guò)不了多久，系統(tǒng)又撐不住了。

3. 架構(gòu)期

經(jīng)過(guò)優(yōu)化期后，如果業(yè)務(wù)能夠繼續(xù)發(fā)展，慢慢就會(huì)發(fā)現(xiàn)優(yōu)化也頂不住了，畢竟再怎么優(yōu)化，系統(tǒng)的能力總是有極限的,只能進(jìn)行架構(gòu)調(diào)整。
架構(gòu)期可以用的手段很多，但歸根結(jié)底可以總結(jié)為一個(gè)字“拆”，什么地方都可以拆。

3. 競(jìng)爭(zhēng)期

當(dāng)業(yè)務(wù)繼續(xù)發(fā)展，已經(jīng)形成一定規(guī)模后，一定會(huì)有競(jìng)爭(zhēng)對(duì)手開(kāi)始加入行業(yè)來(lái)競(jìng)爭(zhēng)，當(dāng)競(jìng)爭(zhēng)對(duì)手加入后，大家互相學(xué)習(xí)和模仿，業(yè)務(wù)更加完善，也不斷有新的業(yè)務(wù)創(chuàng)新出來(lái)，而且由于競(jìng)爭(zhēng)的壓力，對(duì)技術(shù)的要求是更上一層樓了。

當(dāng)系統(tǒng)的數(shù)量越來(lái)越多就會(huì)產(chǎn)生質(zhì)變，主要體現(xiàn)在下面幾個(gè)方面：

• 重復(fù)造輪子

系統(tǒng)越來(lái)越多，各系統(tǒng)相似的工作越來(lái)越多。

• 系統(tǒng)交互一團(tuán)亂麻

系統(tǒng)越來(lái)越多，各系統(tǒng)的交互關(guān)系變成了網(wǎng)狀。系統(tǒng)間的交互數(shù)量和系統(tǒng)的數(shù)量成平方比的關(guān)系。

針對(duì)這個(gè)時(shí)期業(yè)務(wù)變化帶來(lái)的問(wèn)題，技術(shù)工作主要的解決手段有：

• 平臺(tái)化

目的在于解決“重復(fù)造輪子”的問(wèn)題。

• 服務(wù)化

目的在于解決“系統(tǒng)交互”的問(wèn)題，常見(jiàn)的做法是通過(guò)消息隊(duì)列來(lái)完成系統(tǒng)間的異步通知，通過(guò)服務(wù)框架來(lái)完成系統(tǒng)間的同步調(diào)用。

4. 成熟期

此時(shí)技術(shù)上該拆的也拆了，該平臺(tái)化的也平臺(tái)化了，技術(shù)上能做的大動(dòng)作其實(shí)也不多了，更多的是進(jìn)行優(yōu)化。但有時(shí)候也會(huì)為了滿足某個(gè)優(yōu)化，系統(tǒng)做很大的改變。

這個(gè)時(shí)候的技術(shù)優(yōu)化沒(méi)有固定的套路，只能按照競(jìng)爭(zhēng)的要求，找出自己的弱項(xiàng)，然后逐項(xiàng)優(yōu)化。在逐項(xiàng)優(yōu)化時(shí)，可以采取之前各個(gè)時(shí)期采用的手段。

用戶規(guī)模

用戶量增大對(duì)技術(shù)的影響主要體現(xiàn)在兩個(gè)方面：性能要求越來(lái)越高、可用性要求越來(lái)越高。

架構(gòu)模板

存儲(chǔ)層技術(shù)

SQL

隨著互聯(lián)網(wǎng)業(yè)務(wù)的發(fā)展，性能要求越來(lái)越高，必然要面對(duì)一個(gè)問(wèn)題：將數(shù)據(jù)拆分到多個(gè)數(shù)據(jù)庫(kù)實(shí)例才能滿足業(yè)務(wù)的性能需求。

數(shù)據(jù)庫(kù)拆分滿足了性能的要求，但帶來(lái)了復(fù)雜度的問(wèn)題：數(shù)據(jù)如何拆分、數(shù)據(jù)如何組合？這個(gè)復(fù)雜度的問(wèn)題解決起來(lái)并不容易，如果每個(gè)業(yè)務(wù)都去實(shí)現(xiàn)一遍，重復(fù)造輪子將導(dǎo)致投入浪費(fèi)、效率降低，業(yè)務(wù)開(kāi)發(fā)想快都快不起來(lái)。

所以互聯(lián)網(wǎng)公司流行的做法是業(yè)務(wù)發(fā)展到一定階段后，就會(huì)將這部分功能獨(dú)立成中間件。

當(dāng)規(guī)模繼續(xù)擴(kuò)大后，力雄厚的大公司此時(shí)一般都會(huì)在 SQL 集群上構(gòu)建 SQL 存儲(chǔ)平臺(tái)，以對(duì)業(yè)務(wù)透明的形式提供資源分配、數(shù)據(jù)備份、遷移、容災(zāi)、讀寫(xiě)分離、分庫(kù)分表等一系列服務(wù)。

NoSQL

由于 NoSQL 方案一般自己本身就提供集群的功能，因此 NoSQL 在剛開(kāi)始應(yīng)用時(shí)很方便，不像 SQL 分庫(kù)分表那么復(fù)雜。

NoSQL 發(fā)展到一定規(guī)模后，通常都會(huì)在 NoSQL 集群的基礎(chǔ)之上再實(shí)現(xiàn)統(tǒng)一存儲(chǔ)平臺(tái)，統(tǒng)一存儲(chǔ)平臺(tái)主要實(shí)現(xiàn)這幾個(gè)功能：

• 資源動(dòng)態(tài)按需動(dòng)態(tài)分配
• 資源自動(dòng)化管理
• 故障自動(dòng)化處理

小文件存儲(chǔ)

除了關(guān)系型的業(yè)務(wù)數(shù)據(jù)，互聯(lián)網(wǎng)行業(yè)還有很多用于展示的數(shù)據(jù)，這些數(shù)據(jù)具有數(shù)據(jù)小，數(shù)據(jù)量大，訪問(wèn)量巨大的特點(diǎn)?；旧厦總€(gè)業(yè)務(wù)都會(huì)有這樣的數(shù)據(jù)，為了防止重復(fù)造輪子，所以一般會(huì)將小文件存儲(chǔ)做成統(tǒng)一的和業(yè)務(wù)無(wú)關(guān)的平臺(tái)。

得益于開(kāi)源運(yùn)動(dòng)的發(fā)展和最近幾年大數(shù)據(jù)的火爆，在開(kāi)源方案的基礎(chǔ)上封裝一個(gè)小文件存儲(chǔ)平臺(tái)并不是太難的事情。例如，HBase、Hadoop、Hypertable、FastDFS 等都可以作為小文件存儲(chǔ)的底層平臺(tái)，只需要將這些開(kāi)源方案再包裝一下基本上就可以用了。

大文件存儲(chǔ)

說(shuō)到大文件，特別要提到 Google 和 Yahoo，Google 的 3 篇大數(shù)據(jù)論文（Bigtable/Map- Reduce/GFS）開(kāi)啟了一個(gè)大數(shù)據(jù)的時(shí)代，而 Yahoo 開(kāi)源的 Hadoop 系列（HDFS、HBase 等），基本上壟斷了開(kāi)源界的大數(shù)據(jù)處理。

對(duì)照 Google 的論文構(gòu)建一套完整的大數(shù)據(jù)處理方案的難度和成本實(shí)在太高，而且開(kāi)源方案現(xiàn)在也很成熟了，所以大數(shù)據(jù)存儲(chǔ)和處理這塊反而是最簡(jiǎn)單的，因?yàn)槟銢](méi)有太多選擇，只能用這幾個(gè)流行的開(kāi)源方案，例如，Hadoop、HBase、Storm、Hive 等。實(shí)力雄厚一些的大公司會(huì)基于這些開(kāi)源方案，結(jié)合自己的業(yè)務(wù)特點(diǎn)，封裝成大數(shù)據(jù)平臺(tái)。

開(kāi)發(fā)層技術(shù)

開(kāi)發(fā)框架

一般互聯(lián)網(wǎng)公司都會(huì)指定一個(gè)大的技術(shù)方向，然后使用統(tǒng)一的開(kāi)發(fā)框架。例如，Java 相關(guān)的開(kāi)發(fā)框架 SSH、SpringMVC、Play，Ruby 的 Ruby on Rails，PHP 的 ThinkPHP，Python 的 Django 等。

對(duì)于框架的選擇，有一個(gè)總的原則：優(yōu)選成熟的框架，避免盲目追逐新技術(shù)！

Web服務(wù)器

獨(dú)立開(kāi)發(fā)一個(gè)成熟的 Web 服務(wù)器，成本非常高，況且業(yè)界又有那么多成熟的開(kāi)源 Web 服務(wù)器，所以互聯(lián)網(wǎng)行業(yè)基本上都是“拿來(lái)主義”，挑選一個(gè)流行的開(kāi)源服務(wù)器即可。大一點(diǎn)的公司，可能會(huì)在開(kāi)源服務(wù)器的基礎(chǔ)上，結(jié)合自己的業(yè)務(wù)特點(diǎn)做二次開(kāi)發(fā)。

選擇一個(gè)Web服務(wù)器主要和開(kāi)發(fā)語(yǔ)言相關(guān)，例如，Java 的有 Tomcat、JBoss、Resin 等，PHP/Python 的用 Nginx，當(dāng)然最保險(xiǎn)的就是用 Apache 了，什么語(yǔ)言都支持。

容器

容器以docker為代表，已經(jīng)在BAT級(jí)別的公司有了較多的應(yīng)用。

• 運(yùn)維方式會(huì)發(fā)生革命性的變化：Docker 啟動(dòng)快，幾乎不占資源，隨時(shí)啟動(dòng)和停止，基于 Docker 打造自動(dòng)化運(yùn)維、智能化運(yùn)維將成為主流方式。
• 設(shè)計(jì)模式會(huì)發(fā)生本質(zhì)上的變化：?jiǎn)?dòng)一個(gè)新的容器實(shí)例代價(jià)如此低，將鼓勵(lì)設(shè)計(jì)思路朝“微服務(wù)”的方向發(fā)展。

服務(wù)層技術(shù)

1. 配置中心

將配置中心做成通用的系統(tǒng)的好處有：

• 集中配置多個(gè)系統(tǒng)，操作效率高。
• 所有配置都在一個(gè)集中的地方，檢查方便，協(xié)作效率高。
• 配置中心可以實(shí)現(xiàn)程序化的規(guī)則檢查，避免常見(jiàn)的錯(cuò)誤。比如說(shuō)檢查最小值、最大值、是否 IP 地址、是否 URL 地址，都可以用正則表達(dá)式完成。
• 配置中心相當(dāng)于備份了系統(tǒng)的配置，當(dāng)某些情況下需要搭建新的環(huán)境時(shí)，能夠快速搭建環(huán)境和恢復(fù)業(yè)務(wù)。

一般以“系統(tǒng)標(biāo)識(shí) + host + port”來(lái)標(biāo)識(shí)唯一一個(gè)系統(tǒng)運(yùn)行實(shí)例。

2. 服務(wù)中心

服務(wù)中心的實(shí)現(xiàn)一般來(lái)說(shuō)有兩種方式：服務(wù)名字系統(tǒng)和服務(wù)總線系統(tǒng)。

• 服務(wù)名字系統(tǒng)（Service Name System）

服務(wù)名字系統(tǒng)是為了將 Service 名稱解析為“host + port + 接口名稱”，但是和 DNS 一樣，真正發(fā)起請(qǐng)求的還是請(qǐng)求方。

• 服務(wù)總線系統(tǒng)

相比服務(wù)名字系統(tǒng)，服務(wù)總線系統(tǒng)更進(jìn)一步了：由總線系統(tǒng)完成調(diào)用，服務(wù)請(qǐng)求方都不需要直接和服務(wù)提供方交互了。

3. 消息隊(duì)列

傳統(tǒng)的異步通知方式是由消息生產(chǎn)者直接調(diào)用消息消費(fèi)者提供的接口進(jìn)行通知的，但當(dāng)業(yè)務(wù)變得龐大，子系統(tǒng)數(shù)量增多時(shí)，這樣做會(huì)導(dǎo)致系統(tǒng)間交互非常復(fù)雜和難以管理，因?yàn)橄到y(tǒng)間互相依賴和調(diào)用，整個(gè)系統(tǒng)的結(jié)構(gòu)就像一張蜘蛛網(wǎng)。

消息隊(duì)列就是為了實(shí)現(xiàn)這種跨系統(tǒng)異步通知的中間件系統(tǒng)。消息隊(duì)列既可以“一對(duì)一”通知，也可以“一對(duì)多”廣播。

對(duì)比蜘蛛網(wǎng)架構(gòu)，可以看到引入消息隊(duì)列后的效果：

• 整體結(jié)構(gòu)從網(wǎng)狀結(jié)構(gòu)變?yōu)榫€性結(jié)構(gòu)，結(jié)構(gòu)清晰
• 消息生產(chǎn)和消息消費(fèi)解耦，實(shí)現(xiàn)簡(jiǎn)單
• 增加新的消息消費(fèi)者，消息生產(chǎn)者完全不需要任何改動(dòng)，擴(kuò)展方便
• 消息隊(duì)列系統(tǒng)可以做高可用、高性能，避免各業(yè)務(wù)子系統(tǒng)各自獨(dú)立做一套，減輕工作量
• 業(yè)務(wù)子系統(tǒng)只需要聚焦業(yè)務(wù)即可，實(shí)現(xiàn)簡(jiǎn)單

消息隊(duì)列系統(tǒng)基本功能的實(shí)現(xiàn)比較簡(jiǎn)單，但要做到高性能、高可用、消息時(shí)序性、消息事務(wù)性則比較難。業(yè)界已經(jīng)有很多成熟的開(kāi)源實(shí)現(xiàn)方案，如果要求不高，基本上拿來(lái)用即可，例如，RocketMQ、Kafka、ActiveMQ 等。但如果業(yè)務(wù)對(duì)消息的可靠性、時(shí)序、事務(wù)性要求較高時(shí)，則要深入研究這些開(kāi)源方案，否則很容易踩坑。

網(wǎng)絡(luò)層技術(shù)

負(fù)載均衡

1. DNS

DNS 是最簡(jiǎn)單也是最常見(jiàn)的負(fù)載均衡方式，一般用來(lái)實(shí)現(xiàn)地理級(jí)別的均衡。

2. Nginx 、LVS 、F5

DNS 用于實(shí)現(xiàn)地理級(jí)別的負(fù)載均衡，而 Nginx、LVS、F5 用于同一地點(diǎn)內(nèi)機(jī)器級(jí)別的負(fù)載均衡。其中 Nginx 是軟件的 7 層負(fù)載均衡，LVS 是內(nèi)核的 4 層負(fù)載均衡，F(xiàn)5 是硬件的 4 層負(fù)載均衡。

CDN

CDN 是為了解決用戶網(wǎng)絡(luò)訪問(wèn)時(shí)的“最后一公里”效應(yīng)，本質(zhì)上是一種“以空間換時(shí)間”的加速策略，即將內(nèi)容緩存在離用戶最近的地方，用戶訪問(wèn)的是緩存的內(nèi)容，而不是站點(diǎn)實(shí)時(shí)的內(nèi)容。

CDN 經(jīng)過(guò)多年的發(fā)展，已經(jīng)變成了一個(gè)很龐大的體系：分布式存儲(chǔ)、全局負(fù)載均衡、網(wǎng)絡(luò)重定向、流量控制等都屬于 CDN 的范疇，尤其是在視頻、直播等領(lǐng)域，如果沒(méi)有 CDN，用戶是不可能實(shí)現(xiàn)流暢觀看內(nèi)容的。

幸運(yùn)的是，大部分程序員和架構(gòu)師都不太需要深入理解 CDN 的細(xì)節(jié)，因?yàn)?CDN 作為網(wǎng)絡(luò)的基礎(chǔ)服務(wù)，獨(dú)立搭建的成本巨大，很少有公司自己設(shè)計(jì)和搭建 CDN 系統(tǒng)，從 CDN 服務(wù)商購(gòu)買(mǎi) CDN 服務(wù)即可。

多機(jī)房

多機(jī)房設(shè)計(jì)最核心的因素就是如何處理時(shí)延帶來(lái)的影響，常見(jiàn)的策略有：

1. 同城多機(jī)房
2. 跨城多機(jī)房
3. 跨國(guó)多機(jī)房

多中心

多中心必須以多機(jī)房為前提，但從設(shè)計(jì)的角度來(lái)看，多中心相比多機(jī)房是本質(zhì)上的飛越，難度也高出一個(gè)等級(jí)。

簡(jiǎn)單來(lái)說(shuō)，多機(jī)房的主要目標(biāo)是災(zāi)備，當(dāng)機(jī)房故障時(shí)，可以比較快速地將業(yè)務(wù)切換到另外一個(gè)機(jī)房，這種切換操作允許一定時(shí)間的中斷（例如，10 分鐘、1 個(gè)小時(shí)），而且業(yè)務(wù)也可能有損失。因此相比多機(jī)房來(lái)說(shuō)，多中心的要求就高多了，要求每個(gè)中心都同時(shí)對(duì)外提供服務(wù)，且業(yè)務(wù)能夠自動(dòng)在多中心之間切換，故障后不需人工干預(yù)或者很少的人工干預(yù)就能自動(dòng)恢復(fù)。

多中心設(shè)計(jì)的關(guān)鍵就在于“數(shù)據(jù)一致性”和“數(shù)據(jù)事務(wù)性”如何保證，這兩個(gè)難點(diǎn)都和業(yè)務(wù)緊密相關(guān)，目前沒(méi)有很成熟的且通用的解決方案，需要基于業(yè)務(wù)的特性進(jìn)行詳細(xì)的分析和設(shè)計(jì)。

用戶層技術(shù)

1. 用戶管理

稍微大一點(diǎn)的互聯(lián)網(wǎng)業(yè)務(wù)，肯定會(huì)涉及多個(gè)子系統(tǒng)，這些子系統(tǒng)不可能每個(gè)都管理這么龐大的用戶，由此引申出用戶管理的第一個(gè)目標(biāo)：單點(diǎn)登錄（SSO），又叫統(tǒng)一登錄。單點(diǎn)登錄的技術(shù)實(shí)現(xiàn)手段較多，例如 cookie、JSONP、token 等，目前最成熟的開(kāi)源單點(diǎn)登錄方案當(dāng)屬 CAS。

除此之外，當(dāng)業(yè)務(wù)做大成為了平臺(tái)后，開(kāi)放成為了促進(jìn)業(yè)務(wù)進(jìn)一步發(fā)展的手段，需要允許第三方應(yīng)用接入，由此引申出用戶管理的第二個(gè)目標(biāo)：授權(quán)登錄?，F(xiàn)在最流行的授權(quán)登錄就是 OAuth 2.0 協(xié)議，基本上已經(jīng)成為了事實(shí)上的標(biāo)準(zhǔn)，如果要做開(kāi)放平臺(tái)，則最好用這個(gè)協(xié)議，私有協(xié)議漏洞多，第三方接入也麻煩。

2. 消息推送

消息推送根據(jù)不同的途徑，分為短信、郵件、站內(nèi)信、App 推送。除了 App，不同的途徑基本上調(diào)用不同的 API 即可完成，技術(shù)上沒(méi)有什么難度。

App 目前主要分為 iOS 和 Android 推送，iOS 系統(tǒng)比較規(guī)范和封閉，基本上只能使用蘋(píng)果的 APNS；但 Android 就不一樣了，在國(guó)外，用 GCM 和 APNS 差別不大；但是在國(guó)內(nèi)，情況就復(fù)雜多了：首先是 GCM 不能用；其次是各個(gè)手機(jī)廠商都有自己的定制的 Android，消息推送實(shí)現(xiàn)也不完全一樣。

3. 存儲(chǔ)云、圖片云

需要用到小文件存儲(chǔ)技術(shù)。簡(jiǎn)單來(lái)說(shuō)，存儲(chǔ)云和圖片云通常的實(shí)現(xiàn)都是“CDN + 小文件存儲(chǔ)”，現(xiàn)在有了“云”之后，除非 BAT 級(jí)別，一般不建議自己再重復(fù)造輪子了，直接買(mǎi)云服務(wù)可能是最快也是最經(jīng)濟(jì)的方式。

普通的文件基本上提供存儲(chǔ)和訪問(wèn)就夠了，而圖片涉及的業(yè)務(wù)會(huì)更多，包括裁剪、壓縮、美化、審核、水印等處理，因此通常情況下圖片云會(huì)拆分為獨(dú)立的系統(tǒng)對(duì)用戶提供服務(wù)。

業(yè)務(wù)層技術(shù)

拋開(kāi)業(yè)務(wù)上的差異，各個(gè)互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展最終面臨的問(wèn)題都是類(lèi)似的：業(yè)務(wù)復(fù)雜度越來(lái)越高。也就是說(shuō)，業(yè)務(wù)層面對(duì)的主要技術(shù)挑戰(zhàn)是“復(fù)雜度”。

針對(duì)業(yè)務(wù)復(fù)雜度的調(diào)整，唯一的解決辦法就是“拆”，化整為零、分而治之，將整體復(fù)雜性分散到多個(gè)子業(yè)務(wù)或者子系統(tǒng)里面去。

隨著子系統(tǒng)數(shù)量越來(lái)越多，如果達(dá)到幾百上千，另外一個(gè)復(fù)雜度問(wèn)題又會(huì)凸顯出來(lái)：子系統(tǒng)數(shù)量太多，已經(jīng)沒(méi)有人能夠說(shuō)清楚業(yè)務(wù)的調(diào)用流程了，出了問(wèn)題排查也會(huì)特別復(fù)雜。此時(shí)就要按照“高內(nèi)聚，低耦合”的原則來(lái)進(jìn)行合了，將職責(zé)關(guān)聯(lián)比較強(qiáng)的子系統(tǒng)合成一個(gè)虛擬業(yè)務(wù)域，然后通過(guò)網(wǎng)關(guān)對(duì)外統(tǒng)一呈現(xiàn)，類(lèi)似于設(shè)計(jì)模式中的 Facade 模式。

平臺(tái)層技術(shù)

運(yùn)維平臺(tái)

運(yùn)維平臺(tái)核心的職責(zé)分為四大塊：配置、部署、監(jiān)控、應(yīng)急：

• 配置：主要負(fù)責(zé)資源的管理。例如，機(jī)器管理、IP 地址管理、虛擬機(jī)管理等。
• 部署：主要負(fù)責(zé)將系統(tǒng)發(fā)布到線上。例如，包管理、灰度發(fā)布管理、回滾等。
• 監(jiān)控：主要負(fù)責(zé)收集系統(tǒng)上線運(yùn)行后的相關(guān)數(shù)據(jù)并進(jìn)行監(jiān)控，以便及時(shí)發(fā)現(xiàn)問(wèn)題。
• 主要負(fù)責(zé)系統(tǒng)出故障后的處理。例如，停止程序、下線故障機(jī)器、切換 IP 等。

運(yùn)維平臺(tái)的核心設(shè)計(jì)要素是“四化”：標(biāo)準(zhǔn)化、平臺(tái)化、自動(dòng)化、可視化。

1. 標(biāo)準(zhǔn)化

需要制定運(yùn)維標(biāo)準(zhǔn)，規(guī)范配置管理、部署流程、監(jiān)控指標(biāo)、應(yīng)急能力等，各系統(tǒng)按照運(yùn)維標(biāo)準(zhǔn)來(lái)實(shí)現(xiàn)，避免不同的系統(tǒng)不同的處理方式。標(biāo)準(zhǔn)化是運(yùn)維平臺(tái)的基礎(chǔ)，沒(méi)有標(biāo)準(zhǔn)化就沒(méi)有運(yùn)維平臺(tái)。

2. 平臺(tái)化

傳統(tǒng)的手工運(yùn)維方式需要投入大量人力，效率低，容易出錯(cuò)，因此需要在運(yùn)維標(biāo)準(zhǔn)化的基礎(chǔ)上，將運(yùn)維的相關(guān)操作都集成到運(yùn)維平臺(tái)中，通過(guò)運(yùn)維平臺(tái)來(lái)完成運(yùn)維工作。

運(yùn)維平臺(tái)的好處有：

• 可以將運(yùn)維標(biāo)準(zhǔn)固化到平臺(tái)中，無(wú)須運(yùn)維人員死記硬背運(yùn)維標(biāo)準(zhǔn)。
• 運(yùn)維平臺(tái)提供簡(jiǎn)單方便的操作，相比之下人工操作低效且容易出錯(cuò)。
• 運(yùn)維平臺(tái)是可復(fù)用的，一套運(yùn)維平臺(tái)可以支撐幾百上千個(gè)業(yè)務(wù)系統(tǒng)。

3. 自動(dòng)化

傳統(tǒng)手工運(yùn)維方式效率低下的一個(gè)主要原因就是要執(zhí)行大量重復(fù)的操作，運(yùn)維平臺(tái)可以將這些重復(fù)操作固化下來(lái)，由系統(tǒng)自動(dòng)完成。

類(lèi)似的還有監(jiān)控，有了運(yùn)維平臺(tái)后，運(yùn)維平臺(tái)可以實(shí)時(shí)收集數(shù)據(jù)并進(jìn)行初步分析，當(dāng)發(fā)現(xiàn)數(shù)據(jù)異常時(shí)自動(dòng)發(fā)出告警，無(wú)須運(yùn)維人員盯著數(shù)據(jù)看。

4. 可視化

可視化的主要目的就是為了提升數(shù)據(jù)查看效率。

測(cè)試平臺(tái)

測(cè)試平臺(tái)的核心目的是提升測(cè)試效率，從而提升產(chǎn)品質(zhì)量，其設(shè)計(jì)關(guān)鍵就是自動(dòng)化。

測(cè)試平臺(tái)的基本架構(gòu)如下：

1. 用例管理
2. 資源管理
3. 任務(wù)管理
4. 數(shù)據(jù)管理

數(shù)據(jù)平臺(tái)

數(shù)據(jù)平臺(tái)的核心職責(zé)主要包括三部分：數(shù)據(jù)管理、數(shù)據(jù)分析和數(shù)據(jù)應(yīng)用。

1. 數(shù)據(jù)管理

數(shù)據(jù)管理包含數(shù)據(jù)采集、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)訪問(wèn)和數(shù)據(jù)安全四個(gè)核心職責(zé)，是數(shù)據(jù)平臺(tái)的基礎(chǔ)功能。

2. 數(shù)據(jù)分析

數(shù)據(jù)分析包括數(shù)據(jù)統(tǒng)計(jì)、數(shù)據(jù)挖掘、機(jī)器學(xué)習(xí)、深度學(xué)習(xí)等幾個(gè)細(xì)分領(lǐng)域。

3. 數(shù)據(jù)應(yīng)用

數(shù)據(jù)應(yīng)用很廣泛，既包括在線業(yè)務(wù)，也包括離線業(yè)務(wù)。例如，推薦、廣告等屬于在線應(yīng)用，報(bào)表、欺詐檢測(cè)、異常檢測(cè)等屬于離線應(yīng)用。

管理平臺(tái)

管理平臺(tái)的核心職責(zé)就是權(quán)限管理，無(wú)論是業(yè)務(wù)系統(tǒng)、中間件系統(tǒng)，還是平臺(tái)系統(tǒng)，都需要進(jìn)行管理。如果每個(gè)系統(tǒng)都自己來(lái)實(shí)現(xiàn)權(quán)限管理，效率太低，重復(fù)工作很多，因此需要統(tǒng)一的管理平臺(tái)來(lái)管理所有的系統(tǒng)的權(quán)限。

權(quán)限管理主要分為兩部分：身份認(rèn)證、權(quán)限控制。

開(kāi)源項(xiàng)目

不要重復(fù)發(fā)明輪子，但要找到合適的輪子

如何選擇一個(gè)開(kāi)源項(xiàng)目

1. 聚焦是否滿足業(yè)務(wù)

聚焦于是否滿足業(yè)務(wù)，而不需要過(guò)于關(guān)注開(kāi)源項(xiàng)目是否優(yōu)秀。

2. 聚焦是否成熟

盡量選擇成熟的開(kāi)源項(xiàng)目，可以從以下方面考察開(kāi)源項(xiàng)目是否成熟：

• 版本號(hào)：除非特殊情況，否則不要選 0.X 版本的，至少選 1.X 版本的，版本號(hào)越高越好。
• 使用的公司數(shù)量：一般開(kāi)源項(xiàng)目都會(huì)把采用了自己項(xiàng)目的公司列在主頁(yè)上，公司越大越好，數(shù)量越多越好。
• 社區(qū)活躍度：看看社區(qū)是否活躍，發(fā)帖數(shù)、回復(fù)數(shù)、問(wèn)題處理速度等。

3. 聚焦運(yùn)維能力

如果要將項(xiàng)目應(yīng)用到線上生產(chǎn)環(huán)境，則運(yùn)維能力是必不可少的一環(huán)，否則一旦出問(wèn)題，運(yùn)維、研發(fā)、測(cè)試都只能干瞪眼，求菩薩保佑了！

• 開(kāi)源項(xiàng)目日志是否齊全
• 開(kāi)源項(xiàng)目是否有命令行、管理控制臺(tái)等維護(hù)工具，能夠看到系統(tǒng)運(yùn)行時(shí)的情況。
• 開(kāi)源項(xiàng)目是否有故障檢測(cè)和恢復(fù)的能力，例如告警、切換等。

如何使用開(kāi)源項(xiàng)目

1. 深入研究，仔細(xì)測(cè)試

• 通讀開(kāi)源項(xiàng)目的設(shè)計(jì)文檔或者白皮書(shū)，了解其設(shè)計(jì)原理。
• 核對(duì)每個(gè)配置項(xiàng)的作用和影響，識(shí)別出關(guān)鍵配置項(xiàng)。
• 進(jìn)行多種場(chǎng)景的性能測(cè)試。
• 進(jìn)行壓力測(cè)試，連續(xù)跑幾天，觀察 CPU、內(nèi)存、磁盤(pán) I/O 等指標(biāo)波動(dòng)。
• 進(jìn)行故障測(cè)試：kill、斷電、拔網(wǎng)線、重啟 100 次以上、切換等。

2. 小心應(yīng)用，灰度發(fā)布

先在非核心的業(yè)務(wù)上用，然后有經(jīng)驗(yàn)后慢慢擴(kuò)展。

3. 做好應(yīng)急，以防萬(wàn)一

如何基于開(kāi)源項(xiàng)目做二次開(kāi)發(fā)

1. 保持純潔，加以包裝

不要改動(dòng)原系統(tǒng)，而是要開(kāi)發(fā)輔助系統(tǒng)：監(jiān)控、報(bào)警、負(fù)載均衡、管理等。

2. 發(fā)明你要的輪子

選與不選開(kāi)源項(xiàng)目，核心還是一個(gè)成本和收益的問(wèn)題，并不是說(shuō)選擇開(kāi)源項(xiàng)目就一定是最優(yōu)的項(xiàng)目，最主要的問(wèn)題是：沒(méi)有完全適合你的輪子！