1、 互聯(lián)網(wǎng)企業(yè)的基礎(chǔ)設(shè)施建設(shè)方案架構(gòu)文摘 微信號(hào) ArchDigest功能介紹 每天一篇架構(gòu)領(lǐng)域重磅好文，涉及一線互聯(lián)網(wǎng)公司的互聯(lián)網(wǎng)應(yīng)用架構(gòu)、大數(shù)據(jù)、機(jī)器學(xué)習(xí)等各個(gè)熱門(mén)領(lǐng)域。對(duì)于一個(gè)互聯(lián)網(wǎng)企業(yè)，后端服務(wù)是必不可少的一個(gè)組成部分。拋開(kāi)業(yè)務(wù)應(yīng)用來(lái)說(shuō)，往下的基礎(chǔ)服務(wù)設(shè)施做到哪些才能夠保證業(yè)務(wù)的穩(wěn)定可靠、易維護(hù)、高可用呢？縱觀整個(gè)互聯(lián)網(wǎng)技術(shù)體系再結(jié)合公司的目前狀況，個(gè)人認(rèn)為必不可少或者非常關(guān)鍵的后端基礎(chǔ)技術(shù)/設(shè)施如下圖所示：這里的后端基礎(chǔ)設(shè)施主要指的是應(yīng)用在線上穩(wěn)定運(yùn)行需要依賴(lài)的關(guān)鍵組件/服務(wù)等。開(kāi)發(fā)或者搭建好以上的后端基礎(chǔ)設(shè)施，一般情況下是能夠支撐很長(zhǎng)一段時(shí)間內(nèi)的業(yè)務(wù)的。此外，對(duì)于一個(gè)完整的架構(gòu)來(lái)說(shuō)，

2、還有很多應(yīng)用感知不到的系統(tǒng)基礎(chǔ)服務(wù)，如負(fù)載均衡、自動(dòng)化部署、系統(tǒng)安全等，并沒(méi)有包含在本文的描述范圍內(nèi)。API網(wǎng)關(guān)在移動(dòng)app的開(kāi)發(fā)過(guò)程中，通常后端提供的接口需要以下功能的支持：負(fù)載均衡API訪問(wèn)權(quán)限控制用戶(hù)鑒權(quán)一般的做法，使用nginx做負(fù)載均衡，然后在每個(gè)業(yè)務(wù)應(yīng)用里做API接口的訪問(wèn)權(quán)限控制和用戶(hù)鑒權(quán)，更優(yōu)化一點(diǎn)的方式則是把后兩者做成公共類(lèi)庫(kù)供所有業(yè)務(wù)調(diào)用。但從總體上來(lái)看，這三種特性都屬于業(yè)務(wù)的公共需求，更可取的方式則是集成到一起作為一個(gè)服務(wù)，既可以動(dòng)態(tài)地修改權(quán)限控制和鑒權(quán)機(jī)制，也可以減少每個(gè)業(yè)務(wù)集成這些機(jī)制的成本。這種服務(wù)就是API網(wǎng)關(guān)(/pzxwhc/article/details/49

3、873623)，可以選擇自己實(shí)現(xiàn)，也可以使用開(kāi)源軟件實(shí)現(xiàn)，如Kong。如下圖所示：但是以上方案的一個(gè)問(wèn)題是由于所有api請(qǐng)求都要經(jīng)過(guò)網(wǎng)關(guān)，它很容易成為系統(tǒng)的性能瓶頸。因此，可以采取的方案是：去掉api網(wǎng)關(guān)，讓業(yè)務(wù)應(yīng)用直接對(duì)接統(tǒng)一認(rèn)證中心，在基礎(chǔ)框架層面保證每個(gè)api調(diào)用都需要先通過(guò)統(tǒng)一認(rèn)證中心的認(rèn)證，這里可以采取緩存認(rèn)證結(jié)果的方式避免對(duì)統(tǒng)一認(rèn)證中心產(chǎn)生過(guò)大的請(qǐng)求壓力。業(yè)務(wù)應(yīng)用和后端基礎(chǔ)框架業(yè)務(wù)應(yīng)用分為：在線業(yè)務(wù)應(yīng)用和內(nèi)部業(yè)務(wù)應(yīng)用。在線業(yè)務(wù)應(yīng)用：直接面向互聯(lián)網(wǎng)用戶(hù)的應(yīng)用、接口等，典型的特點(diǎn)就是：請(qǐng)求量大、高并發(fā)、高可用、對(duì)故障的容忍度低。內(nèi)部業(yè)務(wù)應(yīng)用：這個(gè)是面向公司內(nèi)部的應(yīng)用。比如，內(nèi)部數(shù)據(jù)管理

4、平臺(tái)、廣告投放平臺(tái)等。相比起在線業(yè)務(wù)應(yīng)用，其特點(diǎn): 數(shù)據(jù)保密性高、壓力小、并發(fā)量小、允許故障的發(fā)生。業(yè)務(wù)應(yīng)用基于后端的基礎(chǔ)框架開(kāi)發(fā)，針對(duì)Java后端來(lái)說(shuō)，應(yīng)該有的幾個(gè)框架如下：MVC框架：從十年前流行的Struts1、2到現(xiàn)在最為推崇的SpringMVC、Jersey以及國(guó)人開(kāi)發(fā)的JFinal、阿里的WebX等等，這些框架尤其是后面流行的這些都是各有千秋的。選型的主要因素是看你的團(tuán)隊(duì)是否有一個(gè)對(duì)某框架能夠做二次開(kāi)發(fā)、定制的人在。很多時(shí)候，針對(duì)這些通用的框架，你是需要做一些特定的開(kāi)發(fā)才能滿足特定的需求的。比如，很多團(tuán)隊(duì)傳遞參數(shù)使用的都是UnderScore的命名法(下劃線連接單詞)，但是Java

5、中確是使用LowCamel命名的。對(duì)于SpringMVC，可以通過(guò)注解的alias來(lái)指定，但這樣需要對(duì)每一個(gè)參數(shù)都要指定alias有點(diǎn)效率太低，此外ModelAttribute也不支持別名，更好的方式是在框架層面統(tǒng)一對(duì)參數(shù)做Camel命名的轉(zhuǎn)換達(dá)到目的。IOC框架：ioc帶來(lái)的好處無(wú)須多言。目前Java中最為流行的Spring自誕生就天然支持IOC。ORM框架：MyBatis是目前最為流行的orm框架。此外，Spring ORM中提供的JdbcTemplate也很不錯(cuò)。當(dāng)然，對(duì)于分庫(kù)分表、主從分離這些需求，一般就需要實(shí)現(xiàn)自己的ORM框架來(lái)支持了，像阿里的tddl、當(dāng)當(dāng)?shù)膕harding-jdb

6、c(從datasource層面解決了分庫(kù)分表、讀寫(xiě)分離的問(wèn)題，對(duì)應(yīng)用透明、零侵入)。此外，為了在服務(wù)層面統(tǒng)一解決分庫(kù)分表、主從分離、主備切換、緩存、故障恢復(fù)等問(wèn)題，很多公司都是有自己的數(shù)據(jù)庫(kù)中間件的，比如阿里的Cobar、360的Atlas、網(wǎng)易的DDB，還有官方提供的MySQL Proxy以及開(kāi)源的MyCat、kingshard和收費(fèi)的oneproxy。目前，線上有一定規(guī)模使用的應(yīng)該是kingshard，當(dāng)然如果不缺錢(qián)也可以上oneproxy。緩存框架：緩存框架主要指的是對(duì)redis、memcached這些緩存服務(wù)器的操作統(tǒng)一封裝，一般使用Spring的RedisTemplate即可，也可以

7、使用jedis做自己的封裝，支持客戶(hù)端分布式方案、主從等。JavaEE應(yīng)用性能檢測(cè)框架：對(duì)于線上的JavaEE應(yīng)用，需要有一個(gè)統(tǒng)一的框架集成到每一個(gè)業(yè)務(wù)中檢測(cè)每一個(gè)請(qǐng)求、方法調(diào)用、jdbc連接、redis連接等的耗時(shí)、狀態(tài)等。jwebap是一個(gè)可以使用的性能檢測(cè)工具，但由于其已經(jīng)很多年沒(méi)有更新，有可能的話建議基于此項(xiàng)目做二次開(kāi)發(fā)。一般來(lái)說(shuō)，以上幾個(gè)框架即可以完成一個(gè)后端應(yīng)用的雛形。對(duì)于這些框架來(lái)說(shuō)，最為關(guān)鍵的是根據(jù)團(tuán)隊(duì)技術(shù)構(gòu)成選擇最合適的，有能力開(kāi)發(fā)自己的框架則更好。此外，這里需要提供一個(gè)后端應(yīng)用的模板或生成工具(如maven的archetype)給團(tuán)隊(duì)成員使用，可以讓大家在開(kāi)發(fā)新的應(yīng)用的時(shí)候

8、，迅速的生成雛形應(yīng)用，而無(wú)需再做一些框架搭建的重復(fù)性勞動(dòng)。緩存、數(shù)據(jù)庫(kù)、搜索引擎、消息隊(duì)列緩存、數(shù)據(jù)庫(kù)、搜索引擎、消息隊(duì)列這四者都是應(yīng)用依賴(lài)的后端基礎(chǔ)服務(wù)，他們的性能直接影響到了應(yīng)用的整體性能，有時(shí)候你代碼寫(xiě)的再好也許就是因?yàn)檫@些服務(wù)導(dǎo)致應(yīng)用性能無(wú)法提升上去。緩存如緩存五分鐘法則所講：如果一個(gè)數(shù)據(jù)頻繁被訪問(wèn)，那么就應(yīng)該放內(nèi)存中。這里的緩存就是一種讀寫(xiě)效率都非常高的存儲(chǔ)方案，能夠應(yīng)對(duì)高并發(fā)的訪問(wèn)請(qǐng)求，通常情況下也不需要持久化的保證。但相對(duì)其他存儲(chǔ)來(lái)說(shuō)，緩存一般是基于內(nèi)存的，成本比較昂貴，因此不能濫用。緩存可以分為：本地緩存和分布式緩存。本地緩存：主要指的是內(nèi)存中的緩存機(jī)制。在Java中，Goog

9、le Guava中就提供了本地緩存的實(shí)現(xiàn)機(jī)制。當(dāng)然使用Java的ConncurrentHashMap你也可以實(shí)現(xiàn)自己的本地緩存方案。分布式緩存：指的單獨(dú)的緩存服務(wù)。幾年前比較流行的是memcached，但其只是一個(gè)KV的存儲(chǔ)，支持的數(shù)據(jù)結(jié)構(gòu)太少?，F(xiàn)在最為流行的就是Redis，能夠支持豐富的數(shù)據(jù)結(jié)構(gòu)，基于事件驅(qū)動(dòng)的單線程非阻塞IO也能夠應(yīng)對(duì)高并發(fā)的場(chǎng)景。集群方案除了官方的redis cluster, 目前比較流行的還有豌豆莢的codis、twitter的twemproxy。對(duì)于緩存的使用，需要注意以下幾點(diǎn)：緩存的失效機(jī)制：當(dāng)給某一個(gè)key設(shè)置了有效期，那么緩存何時(shí)對(duì)此key進(jìn)行刪除呢？一般來(lái)說(shuō)會(huì)

10、有以下幾種方式：守護(hù)進(jìn)程定時(shí)去掃描key，找到已經(jīng)失效的key，然后刪除讀取key的時(shí)候先去判斷key是否失效，如果失效則刪除并返回空。緩存的淘汰機(jī)制：是當(dāng)緩存內(nèi)存達(dá)到上限時(shí)如何刪除緩存中的key。Redis提供了以下數(shù)據(jù)淘汰策略：對(duì)于其具體的實(shí)現(xiàn)機(jī)制，可以參考Redis設(shè)計(jì)與實(shí)現(xiàn)一書(shū)volatile-lru：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集中挑選最近最少使用的數(shù)據(jù)淘汰volatile-ttl：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集中挑選將要過(guò)期的數(shù)據(jù)淘汰volatile-random：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集中任意選擇數(shù)據(jù)淘汰allkeys-lru：從數(shù)據(jù)集中挑選最近最少使用的數(shù)據(jù)淘汰allkeys-random

11、：從數(shù)據(jù)集中任意選擇數(shù)據(jù)淘汰no-enviction（驅(qū)逐）：禁止驅(qū)逐數(shù)據(jù)緩存的更新機(jī)制: 通常來(lái)說(shuō)有四種方式：Cache aside, Read through, Write through, Write behind caching，具體的可見(jiàn)陳皓大神的這篇總結(jié)：緩存更新的套路。緩存的服務(wù)過(guò)載保護(hù)：緩存的服務(wù)過(guò)載指的是由于緩存失效，而引起后端服務(wù)的壓力驟增，進(jìn)一步產(chǎn)生雪崩效應(yīng)。這個(gè)現(xiàn)象和緩存更新是相關(guān)的，采取何種策略在緩存失效的時(shí)候去更新緩存直接決定了服務(wù)過(guò)載的保護(hù)機(jī)制。通常的分為客戶(hù)端和服務(wù)端的應(yīng)對(duì)方案。前者的方案有：基于超時(shí)的簡(jiǎn)單模式、基于超時(shí)的常規(guī)模式、基于刷新的簡(jiǎn)單模式、基于刷新的

12、常規(guī)模式、基于刷新的續(xù)費(fèi)模式。后者的方案則是很常見(jiàn)的流量控制和服務(wù)降級(jí)。具體的可以看美團(tuán)技術(shù)團(tuán)隊(duì)總結(jié)的這篇文章： HYPERLINK /s?_biz=MjM5NjQ5MTI5OA=&mid=2651745239&idx=1&sn=60490558770ade79fd9f1e88f9c7c0ac&scene=21 l wechat_redirect t _blank Cache應(yīng)用中的服務(wù)過(guò)載案例研究。數(shù)據(jù)庫(kù)數(shù)據(jù)庫(kù)是后端開(kāi)發(fā)中非常常見(jiàn)的一個(gè)服務(wù)組件。對(duì)于數(shù)據(jù)庫(kù)的選型，要根據(jù)業(yè)務(wù)的特點(diǎn)和數(shù)據(jù)結(jié)構(gòu)的特點(diǎn)來(lái)決定。從存儲(chǔ)介質(zhì)上，數(shù)據(jù)庫(kù)可以分為：內(nèi)存數(shù)據(jù)庫(kù)： 數(shù)據(jù)主要存儲(chǔ)在內(nèi)存中，同時(shí)也可以采取措施對(duì)數(shù)據(jù)

13、進(jìn)行持久化到硬盤(pán)中。如Redis、H2DB的內(nèi)存模式。對(duì)于這種數(shù)據(jù)庫(kù)，由于內(nèi)存成本昂貴，因此一定要做好存儲(chǔ)的量化分析、容量預(yù)估，防止內(nèi)存不足造成服務(wù)不可用。硬盤(pán)數(shù)據(jù)庫(kù)：數(shù)據(jù)存儲(chǔ)在硬盤(pán)上的這種數(shù)據(jù)庫(kù)是最為常見(jiàn)的。MySQL、Oracle、Postgresql、HBASE、H2DB、SqlLite等等都是硬盤(pán)數(shù)據(jù)庫(kù)。此外，SSDB是基于SSD硬盤(pán)的KV數(shù)據(jù)庫(kù)，支持的數(shù)據(jù)接口很豐富，是Redis的另外一個(gè)選擇。從存儲(chǔ)數(shù)據(jù)類(lèi)型、數(shù)據(jù)模式上，數(shù)據(jù)庫(kù)可以分為：關(guān)系型數(shù)據(jù)庫(kù)：MySQL、Oracle、Postgresql都是關(guān)系型數(shù)據(jù)庫(kù)的，是采用關(guān)系模型(關(guān)系模型指的就是二維表格模型，而一個(gè)關(guān)系型數(shù)據(jù)庫(kù)就是

14、由二維表及其之間的聯(lián)系所組成的一個(gè)數(shù)據(jù)組織)來(lái)組織數(shù)據(jù)的數(shù)據(jù)庫(kù)。非關(guān)系型數(shù)據(jù)庫(kù)：非關(guān)系型數(shù)據(jù)庫(kù)是相對(duì)關(guān)系型數(shù)據(jù)庫(kù)來(lái)講的。以鍵值對(duì)存儲(chǔ)，且結(jié)構(gòu)不固定，每一個(gè)元組可以有不一樣的字段，每個(gè)元組可以根據(jù)需要增加一些自己的鍵值對(duì)，這樣就不會(huì)局限于固定的結(jié)構(gòu)，可以減少一些時(shí)間和空間的開(kāi)銷(xiāo)。但是，其沒(méi)有關(guān)系型數(shù)據(jù)庫(kù)那種嚴(yán)格的數(shù)據(jù)模式，并不適合復(fù)雜的查詢(xún)以及需要強(qiáng)事務(wù)管理的業(yè)務(wù)。非關(guān)系型數(shù)據(jù)庫(kù)又可以分為：KV數(shù)據(jù)庫(kù)：主要以(key,value)鍵值對(duì)存儲(chǔ)數(shù)據(jù)的數(shù)據(jù)庫(kù)。以Redis、RocksDB(levelDB)、SSDB為代表。文檔數(shù)據(jù)庫(kù)：總體形式上也是鍵值對(duì)的形式，但是值里面又可以有各種數(shù)據(jù)結(jié)構(gòu)：數(shù)組、鍵

15、值對(duì)、字符串等等。以mongodb、couchdb為代表。列數(shù)據(jù)庫(kù)：也叫作稀疏大數(shù)據(jù)庫(kù)，一般是用來(lái)存儲(chǔ)海量數(shù)據(jù)的。相對(duì)于行數(shù)據(jù)庫(kù)，這種數(shù)據(jù)庫(kù)是以列為單位存儲(chǔ)數(shù)據(jù)在介質(zhì)上的。以Hbase、Cassendra為代表。和數(shù)據(jù)庫(kù)相關(guān)的一個(gè)很重要的就是數(shù)據(jù)庫(kù)的索引。有一種說(shuō)法是：“掌握了索引就等于掌握了數(shù)據(jù)庫(kù)”。暫且不去評(píng)判此說(shuō)法是否真的準(zhǔn)確，但索引的確關(guān)系著數(shù)據(jù)庫(kù)的讀寫(xiě)性能。需要對(duì)數(shù)據(jù)庫(kù)的索引原理做到足夠的了解才能更好的使用各種數(shù)據(jù)庫(kù)。通常來(lái)說(shuō)，Mysql、Oracle、Mongodb這些都是使用的B樹(shù)作為索引，是考慮到傳統(tǒng)硬盤(pán)的特點(diǎn)后兼顧了讀寫(xiě)性能以及范圍查找需求的選擇，而Hbase用得LSM則是為

16、了提高寫(xiě)性能對(duì)讀性能做了犧牲。搜索引擎搜索引擎也是后端應(yīng)用中一個(gè)很關(guān)鍵的組件，尤其是對(duì)內(nèi)容類(lèi)、電商類(lèi)的應(yīng)用，通過(guò)關(guān)鍵詞、關(guān)鍵字搜索內(nèi)容、商品是一個(gè)很常見(jiàn)的用戶(hù)場(chǎng)景。比較成熟的開(kāi)源搜索引擎有Solr和Elasticsearch，很多中小型互聯(lián)網(wǎng)公司搜索引擎都是基于這兩個(gè)開(kāi)源系統(tǒng)搭建的。它們都是基于Lucence來(lái)實(shí)現(xiàn)的，不同之處主要在于termIndex的存儲(chǔ)、分布式架構(gòu)的支持等等。對(duì)于搜索引擎的使用，從系統(tǒng)熟悉、服務(wù)搭建、功能定制，需要花費(fèi)較長(zhǎng)時(shí)間。在這個(gè)過(guò)程中，需要注意以下問(wèn)題：搜索引擎與公司現(xiàn)有數(shù)據(jù)系統(tǒng)的集成?，F(xiàn)有的持久化、供搜索的數(shù)據(jù)的載體是什么, 如何讓搜索引擎在全量和增量建索引過(guò)程中

17、無(wú)縫集成原來(lái)的數(shù)據(jù)載體，才能發(fā)揮搜索引擎自身的實(shí)時(shí)性, 水平擴(kuò)展性(性能與容量和機(jī)器數(shù)量成正比)等優(yōu)勢(shì)。和數(shù)據(jù)庫(kù)一樣，對(duì)搜索引擎的索引機(jī)制也需要做到深入的了解。更為詳細(xì)的對(duì)于搜索引擎的工程化實(shí)踐可以參考有贊工程師的這篇文章：有贊搜索引擎實(shí)踐(工程篇)（/hsydj/p/5303050.html）。另外，搜索引擎還可以用在數(shù)據(jù)的多維分析上，就是GrowingIO、MixPanel中的可以任意維度查詢(xún)數(shù)據(jù)報(bào)表的功能。當(dāng)然，druid也許是一個(gè)更好的實(shí)現(xiàn)多維分析的方案，官方也有其與es的比較：http:/druid.io/docs/latest/comparisons/druid-vs-elasti

18、csearch.html。消息隊(duì)列軟件的組織結(jié)構(gòu)，從開(kāi)始的面向組件到SOA、SAAS是一個(gè)逐漸演變的過(guò)程。而到了今天微服務(wù)盛行的時(shí)代，你都不好意思說(shuō)自己的系統(tǒng)只是單一的一個(gè)系統(tǒng)而沒(méi)有解耦成一個(gè)個(gè)service。當(dāng)然，小的系統(tǒng)的確沒(méi)有拆分的必要性，但一個(gè)復(fù)雜的系統(tǒng)拆成一個(gè)個(gè)service做微服務(wù)架構(gòu)確實(shí)是不得不做的事情。那么問(wèn)題就來(lái)了，service之間的通信如何來(lái)做呢？使用什么協(xié)議？通過(guò)什么方式調(diào)用？都是需要考慮的問(wèn)題。先拋開(kāi)協(xié)議不談，service之間的調(diào)用方式可以分為同步調(diào)用以及異步調(diào)用。同步調(diào)用的方式無(wú)需多說(shuō)，那么異步調(diào)用是怎么進(jìn)行的呢？一種很常見(jiàn)的方式就是使用消息隊(duì)列，調(diào)用方把請(qǐng)求放到

19、隊(duì)列中即可返回，然后等待服務(wù)提供方去隊(duì)列中去獲取請(qǐng)求進(jìn)行處理，然后把結(jié)果返回給調(diào)用方即可（可以通過(guò)回調(diào)）。異步調(diào)用就是消息中間件一個(gè)非常常見(jiàn)的應(yīng)用場(chǎng)景。此外，消息隊(duì)列的應(yīng)用場(chǎng)景還有以下：解耦：一個(gè)事務(wù)，只關(guān)心核心的流程，需要依賴(lài)其他系統(tǒng)但不那么重要的事情，有通知即可，無(wú)須等待結(jié)果。最終一致性：指的是兩個(gè)系統(tǒng)的狀態(tài)保持一致，要么都成功，要么都失敗，可以有一定的延遲，只要最終達(dá)到一致性即可。廣播：這是消息隊(duì)列最基本的功能。生產(chǎn)者只需要發(fā)布消息，無(wú)須關(guān)心有哪些訂閱者來(lái)消費(fèi)消息。錯(cuò)峰與流控：當(dāng)上下游系統(tǒng)處理能力不同的時(shí)候就需要類(lèi)似消息隊(duì)列的方式做為緩沖區(qū)來(lái)隔開(kāi)兩個(gè)系統(tǒng)。目前主流的消息隊(duì)列軟件，主要有以

20、下幾種：ActiveMQ：Java中最為簡(jiǎn)單的消息隊(duì)列，是對(duì)JMS的實(shí)現(xiàn)，沒(méi)有規(guī)定消息的順序、安全、重發(fā)等特性。RabbitMQ：是對(duì)AMQP協(xié)議的實(shí)現(xiàn)，對(duì)于消息的順序性、安全、重發(fā)等都做了很好的支持。比較適合不允許數(shù)據(jù)丟失、有事務(wù)需求的業(yè)務(wù)場(chǎng)景下的消息傳輸。Kafka：是基于Log的消息隊(duì)列，底層依賴(lài)于文件的順序讀取，是append-only的。適合對(duì)數(shù)據(jù)丟失不敏感、強(qiáng)調(diào)性能的一些海量日志傳輸場(chǎng)景中。是最近幾年大數(shù)據(jù)領(lǐng)域很火的一個(gè)技術(shù)。ZeroMQ：是一個(gè)網(wǎng)絡(luò)編程的Pattern庫(kù)，將常見(jiàn)的網(wǎng)絡(luò)請(qǐng)求形式（分組管理，鏈接管理，發(fā)布訂閱等）模式化、組件化，簡(jiǎn)而言之socket之上、MQ之下。對(duì)于

21、MQ來(lái)說(shuō)，網(wǎng)絡(luò)傳輸只是它的一部分，更多需要處理的是消息存儲(chǔ)、路由、Broker服務(wù)發(fā)現(xiàn)和查找、事務(wù)、消費(fèi)模式（ack、重投等）、集群服務(wù)等。文件存儲(chǔ)不管是業(yè)務(wù)應(yīng)用、依賴(lài)的后端服務(wù)還是其他的各種服務(wù)，最終還是要依賴(lài)于底層文件存儲(chǔ)的。通常來(lái)說(shuō)，文件存儲(chǔ)需要滿足的特性有：可靠性、容災(zāi)性、穩(wěn)定性，即要保證存儲(chǔ)的數(shù)據(jù)不會(huì)輕易丟失，即使發(fā)生故障也能夠有回滾方案，也要保證高可用率。在底層可以采用傳統(tǒng)的RAID作為解決方案，再上一層，目前hadoop的hdfs則是最為普遍的分布式文件存儲(chǔ)方案，當(dāng)然還有NFS、Samba這種共享文件系統(tǒng)也提供了簡(jiǎn)單的分布式存儲(chǔ)的特性。此外，如果文件存儲(chǔ)確實(shí)成為了應(yīng)用的瓶頸或者必

22、須提高文件存儲(chǔ)的性能從而提升整個(gè)系統(tǒng)的性能時(shí)，那么最為直接和簡(jiǎn)單的做法就是拋棄傳統(tǒng)機(jī)械硬盤(pán)，用SSD硬盤(pán)替代。像現(xiàn)在很多公司在解決業(yè)務(wù)性能問(wèn)題的時(shí)候，最終的關(guān)鍵點(diǎn)往往就是SSD。這也是用錢(qián)換取時(shí)間和人力成本最直接和最有效的方式。在數(shù)據(jù)庫(kù)部分描述的SSDB就是對(duì)LevelDB封裝之后，利用SSDB的特性的一種高性能KV數(shù)據(jù)庫(kù)。至于HDFS，如果要使用上面的數(shù)據(jù)，是需要通過(guò)hadoop的。類(lèi)似xx on yarn的一些技術(shù)就是將非hadoop技術(shù)跑在hdfs上的解決方案(當(dāng)然也是為了使用MR)。統(tǒng)一認(rèn)證中心統(tǒng)一認(rèn)證中心，主要是對(duì)app用戶(hù)、內(nèi)部用戶(hù)、app等的認(rèn)證服務(wù)，包括：用戶(hù)的注冊(cè)、登錄驗(yàn)證、

23、token鑒權(quán)內(nèi)部信息系統(tǒng)用戶(hù)的管理和登錄鑒權(quán)App的管理，包括app的secret生成，app信息的驗(yàn)證(如驗(yàn)證接口簽名)等。之所以需要統(tǒng)一認(rèn)證中心，就是為了能夠集中對(duì)這些所有app都會(huì)用到的信息進(jìn)行管理，也給所有應(yīng)用提供統(tǒng)一的認(rèn)證服務(wù)。尤其是在有很多業(yè)務(wù)需要共享用戶(hù)數(shù)據(jù)的時(shí)候，構(gòu)建一個(gè)統(tǒng)一認(rèn)證中心是非常必要的。此外，通過(guò)統(tǒng)一認(rèn)證中心構(gòu)建移動(dòng)app的單點(diǎn)登錄也是水到渠成的事情(模仿web的機(jī)制，將認(rèn)證后的信息加密存儲(chǔ)到本地磁盤(pán)中供多個(gè)app使用)。單點(diǎn)登錄系統(tǒng)目前很多大的在線web網(wǎng)站都是有單點(diǎn)登錄系統(tǒng)的，通俗的來(lái)說(shuō)就是只需要一次用戶(hù)登錄，就能夠進(jìn)入多個(gè)業(yè)務(wù)應(yīng)用(權(quán)限可以不相同)，非常方便用

24、戶(hù)的操作。而在移動(dòng)互聯(lián)網(wǎng)公司中，內(nèi)部的各種管理、信息系統(tǒng)同樣也需要單點(diǎn)登錄系統(tǒng)。目前，比較成熟的、用的最多的單點(diǎn)登錄系統(tǒng)應(yīng)該是耶魯大學(xué)開(kāi)源的CAS, 可以基于/apereo/cas/tree/master/cas-server-webapp來(lái)定制開(kāi)發(fā)的。此外，國(guó)人開(kāi)源的kisso的這個(gè)也不錯(cuò)。基本上，單點(diǎn)登錄的原理都類(lèi)似下圖所示：統(tǒng)一配置中心在Java后端應(yīng)用中，一種讀寫(xiě)配置比較通用的方式就是將配置文件寫(xiě)在propeties、yaml、HCON文件中，修改的時(shí)候只需要更新文件重新部署即可，可以做到不牽扯代碼層面改動(dòng)的目的。統(tǒng)一配置中心，則是基于這種方式之上的統(tǒng)一對(duì)所有業(yè)務(wù)或者基礎(chǔ)后端服務(wù)的相關(guān)

25、配置文件進(jìn)行管理的統(tǒng)一服務(wù), 具有以下特性：能夠在線動(dòng)態(tài)修改配置文件并生效配置文件可以區(qū)分環(huán)境(開(kāi)發(fā)、測(cè)試、生產(chǎn)等)使用方便: 在java中可以通過(guò)注解、xml配置的方式引入相關(guān)配置disconf是可以在生產(chǎn)環(huán)境使用的一個(gè)方案，也可能根據(jù)自己的需求開(kāi)發(fā)自己的配置中心(可以選擇zookeeper作為配置存儲(chǔ))。服務(wù)治理框架對(duì)于外部API調(diào)用或者客戶(hù)端對(duì)后端api的訪問(wèn)，可以使用http協(xié)議或者說(shuō)restful(當(dāng)然也可以直接通過(guò)最原始的socket來(lái)調(diào)用)。但對(duì)于內(nèi)部服務(wù)間的調(diào)用，一般都是通過(guò)RPC機(jī)制來(lái)調(diào)用的。目前主流的RPC協(xié)議有：RMIHessianThriftDubbo這些RPC協(xié)議各有

26、優(yōu)劣點(diǎn)，需要針對(duì)業(yè)務(wù)需求做出相應(yīng)的最好的選擇。這樣，當(dāng)你的系統(tǒng)服務(wù)在逐漸增多，RPC調(diào)用鏈越來(lái)越復(fù)雜，很多情況下，需要不停的更新文檔來(lái)維護(hù)這些調(diào)用關(guān)系。一個(gè)對(duì)這些服務(wù)進(jìn)行管理的框架可以大大節(jié)省因此帶來(lái)的繁瑣的人力工作。傳統(tǒng)的ESB(企業(yè)服務(wù)總線)本質(zhì)就是一個(gè)服務(wù)治理方案，但esb作為一種proxy的角色存在于client和server之間，所有請(qǐng)求都需要經(jīng)過(guò)esb，使得esb很容易成為性能瓶頸。因此，基于傳統(tǒng)的esb，更好的一種設(shè)計(jì)如下圖所示：如圖，以配置中心為樞紐，調(diào)用關(guān)系只存在于client和提供服務(wù)的server之間，就避免了傳統(tǒng)esb的性能瓶頸問(wèn)題。對(duì)于這種設(shè)計(jì)，esb應(yīng)該支持的特性如

27、下：服務(wù)提供方的注冊(cè)、管理服務(wù)消費(fèi)者的注冊(cè)、管理服務(wù)的版本管理、負(fù)載均衡、流量控制、服務(wù)降級(jí)等服務(wù)的容錯(cuò)、熔斷等阿里開(kāi)源的dubbo則對(duì)以上做了很好的實(shí)現(xiàn)，也是目前很多公司都在使用的方案。但由于某些原因，dubbo現(xiàn)已不再維護(hù)，推薦大家使用當(dāng)當(dāng)后來(lái)維護(hù)的dubbox。統(tǒng)一調(diào)度中心在很多業(yè)務(wù)中，定時(shí)調(diào)度是一個(gè)非常普遍的場(chǎng)景，比如定時(shí)去抓取數(shù)據(jù)、定時(shí)刷新訂單的狀態(tài)等。通常的做法就是針對(duì)各自的業(yè)務(wù)依賴(lài)Linux的cron機(jī)制或者java中的quartz。統(tǒng)一調(diào)度中心則是對(duì)所有的調(diào)度任務(wù)進(jìn)行管理，這樣能夠統(tǒng)一對(duì)調(diào)度集群進(jìn)行調(diào)優(yōu)、擴(kuò)展、任務(wù)管理等。azkaban和oozie是hadoop的流式工作管理引

28、擎，也可以作為統(tǒng)一調(diào)度中心來(lái)使用。當(dāng)然，你也可以使用cron或者quartz來(lái)實(shí)現(xiàn)自己的統(tǒng)一調(diào)度中心。根據(jù)cron表達(dá)式調(diào)度任務(wù)動(dòng)態(tài)修改、停止、刪除任務(wù)支持任務(wù)工作流：比如一個(gè)任務(wù)完成之后再執(zhí)行下一個(gè)任務(wù)任務(wù)支持腳本、代碼、url等多種形式任務(wù)執(zhí)行的日志記錄、故障報(bào)警對(duì)于Java的quartz這里需要說(shuō)明一下：這個(gè)quartz需要和spring quartz區(qū)分，后者是spring對(duì)quartz框架的簡(jiǎn)單實(shí)現(xiàn)也是目前使用的最多的一種調(diào)度方式。但其并沒(méi)有做高可用集群的支持。而quartz雖然有集群的支持，但是配置起來(lái)非常復(fù)雜?，F(xiàn)在很多方案都是使用zookeeper來(lái)實(shí)現(xiàn)spring quartz

29、集群的。這里有一個(gè)國(guó)人開(kāi)源的uncode-shcedule對(duì)此實(shí)現(xiàn)的還不錯(cuò)，可以根據(jù)自己的業(yè)務(wù)需求做二次開(kāi)發(fā)。此外，當(dāng)當(dāng)開(kāi)源的elastic-job則在此之上又加入了彈性資源利用等更為強(qiáng)大的功能。統(tǒng)一日志服務(wù)日志是開(kāi)發(fā)過(guò)程必不可少的東西。有時(shí)候，打印日志的時(shí)機(jī)、技巧是很能體現(xiàn)出工程師編碼水平的。畢竟，日志是線上服務(wù)能夠定位、排查異常最為直接的信息。通常的，將日志分散在各個(gè)業(yè)務(wù)中非常不方便對(duì)問(wèn)題的管理和排查。統(tǒng)一日志服務(wù)則使用單獨(dú)的日志服務(wù)器記錄日志，各個(gè)業(yè)務(wù)通過(guò)統(tǒng)一的日志框架將日志輸出到日志服務(wù)器上?？梢酝ㄟ^(guò)實(shí)現(xiàn)log4j后者logback的appender來(lái)實(shí)現(xiàn)統(tǒng)一日志框架，然后通過(guò)RPC調(diào)

30、用將日志打印到日志服務(wù)器上。數(shù)據(jù)基礎(chǔ)設(shè)施數(shù)據(jù)是最近幾年非常火的一個(gè)領(lǐng)域。從精益數(shù)據(jù)分析到增長(zhǎng)黑客，都是在強(qiáng)調(diào)數(shù)據(jù)的非凡作用。很多公司也都在通過(guò)數(shù)據(jù)推動(dòng)產(chǎn)品設(shè)計(jì)、市場(chǎng)運(yùn)營(yíng)、研發(fā)等。詳細(xì)的可見(jiàn)之前的一篇數(shù)據(jù)雜談，對(duì)數(shù)據(jù)相關(guān)的東西做過(guò)一些總結(jié)。這里需要說(shuō)明的一點(diǎn)是，只有當(dāng)你的數(shù)據(jù)規(guī)模真的到了單機(jī)無(wú)法處理的規(guī)模才應(yīng)該上大數(shù)據(jù)相關(guān)技術(shù)，千萬(wàn)不要為了大數(shù)據(jù)而大數(shù)據(jù)。很多情況下使用單機(jī)程序+mysql就能解決的問(wèn)題非得上hadoop即浪費(fèi)時(shí)間又浪費(fèi)人力。這里需要補(bǔ)充一點(diǎn)的是，對(duì)于很多公司，尤其是離線業(yè)務(wù)并沒(méi)有那么密集的公司，在很多情況下大數(shù)據(jù)集群的資源是被浪費(fèi)的。因此誕生了xx on yarn一系列技術(shù)讓非

31、hadoop系的技術(shù)可以利用大數(shù)據(jù)集群的資源，能夠大大提高資源的利用率，如Docker on yarn(Hulu的VoidBox)。數(shù)據(jù)高速公路接著上面講的統(tǒng)一日志服務(wù)，其輸出的日志最終是變成數(shù)據(jù)到數(shù)據(jù)高速公路上供后續(xù)的數(shù)據(jù)處理程序消費(fèi)的。這中間的過(guò)程包括日志的收集、傳輸。收集：統(tǒng)一日志服務(wù)將日志打印在日志服務(wù)上之后，需要日志收集機(jī)制將其集中起來(lái)。目前，常見(jiàn)的日志收集方案有：scribe、Chukwa、Kakfa和Flume。對(duì)比如下圖所示：傳輸：通過(guò)消息隊(duì)列將數(shù)據(jù)傳輸?shù)綌?shù)據(jù)處理服務(wù)中。對(duì)于日志來(lái)說(shuō)，通常選擇kafka這種消息隊(duì)列即可。此外，這里還有一個(gè)關(guān)鍵的技術(shù)就是數(shù)據(jù)庫(kù)和數(shù)據(jù)倉(cāng)庫(kù)間的數(shù)據(jù)同

32、步問(wèn)題，即將需要分析的數(shù)據(jù)從數(shù)據(jù)庫(kù)中同步到諸如hive這種數(shù)據(jù)倉(cāng)庫(kù)時(shí)使用的方案。比較簡(jiǎn)單的、用的也比較多的可以使用sqoop進(jìn)行基于時(shí)間戳的數(shù)據(jù)同步，此外，阿里開(kāi)源的canal實(shí)現(xiàn)了基于binlog增量同步，更加適合通用的同步場(chǎng)景，但是基于canal你還是需要做不少的業(yè)務(wù)開(kāi)發(fā)工作的。推薦另一款國(guó)人開(kāi)源的MySQL-Binlog（/qiangzigege/MySQL-Binlog?_t_t_t=0.026644081874147685），原理和canal類(lèi)似，默認(rèn)提供了任務(wù)的后臺(tái)管理功能，只需要實(shí)現(xiàn)接收到binlog后的處理邏輯即可。離線數(shù)據(jù)分析離線數(shù)據(jù)分析是可以有延遲的，一般針對(duì)是非實(shí)時(shí)需求的

33、數(shù)據(jù)分析工作，產(chǎn)生的也是T-1的報(bào)表。目前最常用的離線數(shù)據(jù)分析技術(shù)除了Hadoop還有Spark。相比Hadoop、Spark性能上有很大優(yōu)勢(shì)，當(dāng)然對(duì)硬件資源要求也高。對(duì)于Hadoop，傳統(tǒng)的MR編寫(xiě)很復(fù)雜，也不利于維護(hù)，可以選擇使用hive來(lái)用sql替代編寫(xiě)mr，但是前提務(wù)必要對(duì)hive的原理做到了解。可以參見(jiàn)美團(tuán)的這篇博文來(lái)學(xué)習(xí)：Hive SQL的編譯過(guò)程（/hive-sql-to-mapreduce.html）。而對(duì)于Spark，也有類(lèi)似Hive的Spark SQL。此外，對(duì)于離線數(shù)據(jù)分析，還有一個(gè)很關(guān)鍵的就是數(shù)據(jù)傾斜問(wèn)題。所謂數(shù)據(jù)傾斜指的是region數(shù)據(jù)分布不均，造成有的結(jié)點(diǎn)負(fù)載很低

34、，而有些卻負(fù)載很高，從而影響整體的性能。因此，處理好數(shù)據(jù)傾斜問(wèn)題對(duì)于數(shù)據(jù)處理是很關(guān)鍵的。對(duì)于Hive的數(shù)據(jù)傾斜，可見(jiàn)：Hive大數(shù)據(jù)傾斜總結(jié)（/ggjucheng/archive/2013/01/03/2842860.html）。對(duì)于Spark的傾斜問(wèn)題，可見(jiàn)： HYPERLINK /s?_biz=MjM5NjQ5MTI5OA=&mid=2651745207&idx=1&sn=3d70d59cede236eb1cb4f7374387a235&scene=21 l wechat_redirect Spark性能優(yōu)化指南高級(jí)篇。實(shí)時(shí)數(shù)據(jù)分析相對(duì)于離線數(shù)據(jù)分析，實(shí)時(shí)數(shù)據(jù)分析也叫在線數(shù)據(jù)分析，針對(duì)的是

35、對(duì)數(shù)據(jù)有實(shí)時(shí)要求的業(yè)務(wù)場(chǎng)景，如廣告結(jié)算、訂單結(jié)算等。目前，比較成熟的實(shí)時(shí)技術(shù)有Storm和Spark Streaming。相比起Storm、Spark Streaming其實(shí)本質(zhì)上還是基于批量計(jì)算的。如果是對(duì)延遲很敏感的場(chǎng)景，還是應(yīng)該使用Storm。對(duì)于實(shí)時(shí)數(shù)據(jù)分析，需要注意的就是實(shí)時(shí)數(shù)據(jù)處理結(jié)果寫(xiě)入存儲(chǔ)的時(shí)候，要考慮并發(fā)的問(wèn)題，雖然對(duì)于Storm的bolt程序來(lái)說(shuō)不會(huì)有并發(fā)的問(wèn)題，但是寫(xiě)入的存儲(chǔ)介質(zhì)是會(huì)面臨多任務(wù)同時(shí)讀寫(xiě)的。通常采用的方案就是采用時(shí)間窗口的方式對(duì)數(shù)據(jù)做緩沖后批量寫(xiě)入。此外，實(shí)時(shí)數(shù)據(jù)處理一般情況下都是基于增量處理的，相對(duì)于離線來(lái)說(shuō)并非可靠的，一旦出現(xiàn)故障(如集群崩潰)或者數(shù)據(jù)處

36、理失敗，是很難對(duì)數(shù)據(jù)恢復(fù)或者修復(fù)異常數(shù)據(jù)的。因此結(jié)合離線+實(shí)時(shí)是目前最普遍采用的數(shù)據(jù)處理方案。Lambda架構(gòu)（/article/2014-07-08/2820562-Lambda-Linkedln）就是一個(gè)結(jié)合離線和實(shí)時(shí)數(shù)據(jù)處理的架構(gòu)方案。數(shù)據(jù)即席分析離線和實(shí)時(shí)數(shù)據(jù)分析產(chǎn)生的一些報(bào)表是給數(shù)據(jù)分析師、產(chǎn)品經(jīng)理參考使用的，但是很多情況下，線上的程序并不能滿足這些需求方的需求。這時(shí)候就需要需求方自己對(duì)數(shù)據(jù)倉(cāng)庫(kù)進(jìn)行查詢(xún)統(tǒng)計(jì)。針對(duì)這些需求方，SQL上手容易、易描述等特點(diǎn)決定了其可能是一個(gè)最為合適的方式。因此提供一個(gè)SQL的即席查詢(xún)工具能夠大大提高數(shù)據(jù)分析師、產(chǎn)品經(jīng)理的工作效率。Presto、Impal

37、a、Hive都是這種工具。如果想進(jìn)一步提供給需求方更加直觀的ui操作界面，可以搭建內(nèi)部的Hue。故障監(jiān)控對(duì)于面向用戶(hù)的線上服務(wù)，發(fā)生故障是一件很?chē)?yán)重的事情。因此，做好線上服務(wù)的故障檢測(cè)告警是一件非常重要的事情?？梢詫⒐收媳O(jiān)控分為以下兩個(gè)層面的監(jiān)控：系統(tǒng)監(jiān)控：主要指的對(duì)主機(jī)的帶寬、CPU、內(nèi)存、硬盤(pán)、IO等硬件資源的監(jiān)控。這可以使用開(kāi)源的nagios、cacti等開(kāi)源軟件進(jìn)行監(jiān)控。目前，市面上也有很多第三方服務(wù)能夠提供對(duì)于主機(jī)資源的監(jiān)控，如監(jiān)控寶等。對(duì)于分布式服務(wù)集群（如Hadoop、Storm、Kafka、flume等集群）的監(jiān)控則可以使用ganglia。此外，小米開(kāi)源的OpenFalcon也

38、很不錯(cuò)，涵蓋了系統(tǒng)監(jiān)控、JVM監(jiān)控等，也支持自定義的監(jiān)控機(jī)制。業(yè)務(wù)監(jiān)控：是在主機(jī)資源層面以上的監(jiān)控，比如app的pv、uv數(shù)據(jù)異常、交易失敗等。需要業(yè)務(wù)中加入相關(guān)的監(jiān)控代碼，比如在異常拋出的地方，加一段日志記錄。監(jiān)控還有一個(gè)關(guān)鍵的步驟就是告警。告警的方式有很多種：郵件、im、短信等?？紤]到故障的重要性不同、告警的合理性、便于定位問(wèn)題等因素，有以下建議：告警日志要記錄發(fā)生故障的機(jī)器id，尤其是在集群服務(wù)中，如果沒(méi)有記錄機(jī)器id，那么對(duì)于后續(xù)的問(wèn)題定位會(huì)很困難。要對(duì)告警做聚合，不要每一個(gè)故障都單獨(dú)進(jìn)行告警，這樣會(huì)對(duì)工程師造成極大的困擾。要對(duì)告警做等級(jí)劃分，不能對(duì)所有告警都做同樣的優(yōu)先級(jí)處理。使用微

39、信做為告警軟件，能夠在節(jié)省短信成本的情況下，保證告警的到達(dá)率。故障告警之后，那么最最關(guān)鍵的就是應(yīng)對(duì)了。對(duì)于創(chuàng)業(yè)公司來(lái)說(shuō)，24小時(shí)待命是必備的素質(zhì)，當(dāng)遇到告警的時(shí)候，需要盡快對(duì)故障做出反應(yīng)，找到問(wèn)題所在，并能在可控時(shí)間內(nèi)解決問(wèn)題。對(duì)于故障問(wèn)題的排查，基本上都是依賴(lài)于日志的。只要日志打的合理，一般情況下是能夠很快定位到問(wèn)題所在的，但是如果是分布式服務(wù)，并且日志數(shù)據(jù)量特別大的情況下，如何定位日志就成為了難題。這里有幾個(gè)方案：建立ELK(Elastic+Logstash+Kibana)日志集中分析平臺(tái)，便于快速搜索、定位日志。對(duì)于ELK的介紹，可以見(jiàn)：使用Elasticsearch + Logstas

40、h + Kibana搭建日志集中分析平臺(tái)實(shí)踐（/使用elasticsearch-logstash-kibana搭建日志集中分析平臺(tái)實(shí)踐/）建立分布式請(qǐng)求追蹤系統(tǒng)(也可以叫全鏈路監(jiān)測(cè)系統(tǒng))，對(duì)于分布式系統(tǒng)尤其是微服務(wù)架構(gòu)，能夠極大的方便在海量調(diào)用中快速定位并收集單個(gè)異常請(qǐng)求信息，也能快速定位一條請(qǐng)求鏈路的性能瓶頸。唯品會(huì)的 HYPERLINK /s?_biz=MzAwMDU1MTE1OQ=&mid=2653547643&idx=1&sn=c06dc9b0f59e8ae3d2f9feb734da4459&scene=21&srcid=0808MaLgymxNlsh4Z31oWKUi l wechat_redirect Mercury、阿里的鷹眼、新浪的Wat