互聯(lián)網(wǎng)企業(yè)的基礎(chǔ)設(shè)施建設(shè)方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

30、用將日志打印到日志服務(wù)器上。數(shù)據(jù)基礎(chǔ)設(shè)施數(shù)據(jù)是最近幾年非?；鸬囊粋€領(lǐng)域。從精益數(shù)據(jù)分析到增長黑客，都是在強調(diào)數(shù)據(jù)的非凡作用。很多公司也都在通過數(shù)據(jù)推動產(chǎn)品設(shè)計、市場運營、研發(fā)等。詳細(xì)的可見之前的一篇數(shù)據(jù)雜談，對數(shù)據(jù)相關(guān)的東西做過一些總結(jié)。這里需要說明的一點是，只有當(dāng)你的數(shù)據(jù)規(guī)模真的到了單機無法處理的規(guī)模才應(yīng)該上大數(shù)據(jù)相關(guān)技術(shù)，千萬不要為了大數(shù)據(jù)而大數(shù)據(jù)。很多情況下使用單機程序+mysql就能解決的問題非得上hadoop即浪費時間又浪費人力。這里需要補充一點的是，對于很多公司，尤其是離線業(yè)務(wù)并沒有那么密集的公司，在很多情況下大數(shù)據(jù)集群的資源是被浪費的。因此誕生了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ù)處理程序消費的。這中間的過程包括日志的收集、傳輸。收集：統(tǒng)一日志服務(wù)將日志打印在日志服務(wù)上之后，需要日志收集機制將其集中起來。目前，常見的日志收集方案有：scribe、Chukwa、Kakfa和Flume。對比如下圖所示：傳輸：通過消息隊列將數(shù)據(jù)傳輸?shù)綌?shù)據(jù)處理服務(wù)中。對于日志來說，通常選擇kafka這種消息隊列即可。此外，這里還有一個關(guān)鍵的技術(shù)就是數(shù)據(jù)庫和數(shù)據(jù)倉庫間的數(shù)據(jù)同

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

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

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

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

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

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

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

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

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