使用Java后端技術(shù)的目的就是構(gòu)建業(yè)務(wù)應(yīng)用，為用戶提供在線或者離線服務(wù)戚揭。因此诱告，一個業(yè)務(wù)應(yīng)用需要哪些技術(shù)、依賴哪些基礎(chǔ)設(shè)施就決定了需要掌握的后端技術(shù)有哪些毫目∈叻龋縱觀整個互聯(lián)網(wǎng)技術(shù)體系再結(jié)合公司的目前狀況，筆者認(rèn)為必不可少或者非常關(guān)鍵的后端基礎(chǔ)技術(shù)/設(shè)施如下圖所示：

image

這里的后端基礎(chǔ)設(shè)施主要指的是應(yīng)用在線上穩(wěn)定運行需要依賴的關(guān)鍵組件或者服務(wù)镀虐。開發(fā)或者搭建好以上的后端基礎(chǔ)設(shè)施箱蟆，一般情況下是能夠支撐很長一段時間內(nèi)的業(yè)務(wù)的。此外刮便，對于一個完整的架構(gòu)來說空猜，還有很多應(yīng)用感知不到的系統(tǒng)基礎(chǔ)服務(wù)，如負(fù)載均衡恨旱、自動化部署辈毯、系統(tǒng)安全等，并沒有包含在本章的描述范圍內(nèi)搜贤。

1. 統(tǒng)一請求入口-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)，可以選擇自己實現(xiàn)猾警。也可以使用開源軟件實現(xiàn)孔祸，如Kong和Netflix Zuul。API網(wǎng)關(guān)一般架構(gòu)如下圖所示：

image

但是以上方案的一個問題是由于所有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)生過大的請求壓力。

2. 業(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ù)管理平臺、廣告投放平臺等趾痘。相比起在線業(yè)務(wù)應(yīng)用慢哈，其特點: 數(shù)據(jù)保密性高、壓力小永票、并發(fā)量小卵贱、允許故障的發(fā)生。

業(yè)務(wù)應(yīng)用基于后端的基礎(chǔ)框架開發(fā)侣集，針對Java后端來說键俱，應(yīng)該有以下幾個框架：

• MVC框架：統(tǒng)一開發(fā)流程、提高開發(fā)效率世分、屏蔽一些關(guān)鍵細(xì)節(jié)的Web/后端框架编振。典型的如SpringMVC、Jersey以及國人開發(fā)的JFinal以及阿里的WebX臭埋。

• IOC框架：實現(xiàn)依賴注入/控制反轉(zhuǎn)的框架党觅。Java中最為流行的Spring框架的核心就是IOC功能。

• ORM框架：能夠屏蔽底層數(shù)據(jù)庫細(xì)節(jié)斋泄，提供統(tǒng)一的數(shù)據(jù)訪問接口的數(shù)據(jù)庫操作框架，額外地能夠支持客戶端主從镐牺、分庫炫掐、分表等分布式特性。MyBatis是目前最為流行的ORM框架睬涧。此外募胃，Spring ORM中提供的JdbcTemplate也很不錯。當(dāng)然畦浓，對于分庫分表痹束、主從分離這些需求，一般就需要自己實現(xiàn)讶请，開源的則有阿里的TDDL祷嘶、當(dāng)當(dāng)?shù)膕harding-jdbc（從datasource層面解決了分庫分表屎媳、讀寫分離的問題，對應(yīng)用透明论巍、零侵入）烛谊。此外，為了在服務(wù)層面統(tǒng)一解決分庫分表嘉汰、讀寫分離丹禀、主備切換、緩存鞋怀、故障恢復(fù)等問題双泪，很多公司都是有自己的數(shù)據(jù)庫中間件的，比如阿里的Cobar密似、360的Atlas（基于MySQL-Proxy）焙矛、網(wǎng)易的DDB等；開源的則有MyCat（基于Cobar）和Kingshard,其中Kingshard已經(jīng)有一定的線上使用規(guī)模辛友。MySQL官方也提供了MySQL Proxy, 可以使用lua腳本自定義主從薄扁、讀寫分離、分區(qū)這些邏輯废累，但其性能較差邓梅，目前使用較少。

• 緩存框架：對Redis邑滨、Memcached這些緩存軟件操作的統(tǒng)一封裝日缨，能夠支持客戶端分布式方案、主從等掖看。一般使用Spring的RedisTemplate即可匣距，也可以使用Jedis做自己的封裝，支持客戶端分布式方案哎壳、主從等毅待。

• JavaEE應(yīng)用性能檢測框架：對于線上的JavaEE應(yīng)用，需要有一個統(tǒng)一的框架集成到每一個業(yè)務(wù)中檢測每一個請求归榕、方法調(diào)用尸红、JDBC連接、Redis連接等的耗時刹泄、狀態(tài)等外里。Jwebap是一個可以使用的性能檢測工具，但由于其已經(jīng)很多年沒有更新特石，有可能的話建議基于此項目做二次開發(fā)盅蝗。

一般來說，以上幾個框架即可以完成一個后端應(yīng)用的雛形姆蘸。

3. 緩存墩莫、數(shù)據(jù)庫芙委、搜索引擎、消息隊列

緩存贼穆、數(shù)據(jù)庫题山、搜索引擎、消息隊列這四者都是應(yīng)用依賴的后端基礎(chǔ)服務(wù)故痊，他們的性能直接影響到了應(yīng)用的整體性能顶瞳，有時候你代碼寫的再好也許就是因為這些服務(wù)導(dǎo)致應(yīng)用性能無法提升上去。

• 緩存：緩存通常被用來解決熱點數(shù)據(jù)的訪問問題愕秫，是提高數(shù)據(jù)查詢性能的強大武器慨菱。在高并發(fā)的后端應(yīng)用中，將數(shù)據(jù)持久層的數(shù)據(jù)加載到緩存中戴甩，能夠隔離高并發(fā)請求與后端數(shù)據(jù)庫符喝，避免數(shù)據(jù)庫被大量請求擊垮。目前常用的除了在內(nèi)存中的本地緩存甜孤，比較普遍的集中緩存軟件有Memcached和Redis协饲。其中Redis已經(jīng)成為最主流的緩存軟件。

• 數(shù)據(jù)庫：數(shù)據(jù)庫可以說是后端應(yīng)用最基本的基礎(chǔ)設(shè)施缴川≤猿恚基本上絕大多數(shù)業(yè)務(wù)數(shù)據(jù)都是持久化存儲在數(shù)據(jù)庫中的。主流的數(shù)據(jù)庫包括傳統(tǒng)的關(guān)系型數(shù)據(jù)庫（MySQL把夸、PostgreSQL）以及最近幾年開始流行的NoSQL（MongoDB而线、HBase）。其中HBase是用于大數(shù)據(jù)領(lǐng)域的列數(shù)據(jù)庫恋日，受限于其查詢性能膀篮，一般并不用來做業(yè)務(wù)數(shù)據(jù)庫。

• 搜索引擎：搜索引擎是針對全文檢索以及數(shù)據(jù)各種維度查詢設(shè)計的軟件岂膳。目前用的比較多的開源軟件是Solr和Elasticsearch誓竿，都是基于Lucence來實現(xiàn)的，不同之處主要在于termIndex的存儲谈截、分布式架構(gòu)的支持等烤黍。Elasticsearch由于對集群的良好支持以及高性能的實現(xiàn)，已經(jīng)逐漸成為搜索引擎的主流開源方案傻盟。

• 消息隊列：數(shù)據(jù)傳輸?shù)囊环N方式就是通過消息隊列。目前用的比較普遍的消息隊列包括為日志設(shè)計的Kafka以及重事務(wù)的RabbitMQ等嫂丙。在對消息丟失不是特別敏感且并不要求消息事務(wù)的場景下娘赴，選擇Kafka能夠獲得更高的性能；否則跟啤，RabbitMQ則是更好的選擇诽表。此外唉锌，ZeroMQ則是一種實現(xiàn)消息隊列的網(wǎng)絡(luò)編程Pattern庫，位于Socket之上竿奏，MQ之下袄简。

4. 文件存儲

不管是業(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)用的瓶頸或者必須提高文件存儲的性能從而提升整個系統(tǒng)的性能時矾兜，那么最為直接和簡單的做法就是拋棄傳統(tǒng)機械硬盤损趋，用SSD硬盤替代。像現(xiàn)在很多公司在解決業(yè)務(wù)性能問題的時候椅寺，最終的關(guān)鍵點往往就是SSD浑槽。這也是用錢換取時間和人力成本最直接和最有效的方式。在數(shù)據(jù)庫部分描述的SSDB就是對LevelDB封裝之后返帕，利用SSD硬盤的特性的一種高性能KV數(shù)據(jù)庫桐玻。

至于HDFS，如果要使用上面的數(shù)據(jù)荆萤，是需要通過Hadoop的镊靴。類似xx on Yarn的一些技術(shù)就是將非Hadoop技術(shù)跑在HDFS上的解決方案。

5. 統(tǒng)一認(rèn)證中心

統(tǒng)一認(rèn)證中心链韭，主要是對APP用戶偏竟、內(nèi)部用戶、APP等的認(rèn)證服務(wù)敞峭，包括：

• 用戶的注冊踊谋、登錄驗證、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使用缨伊。

6. 單點登錄系統(tǒng)

目前很多大的在線Web網(wǎng)站都是有單點登錄系統(tǒng)的摘刑，通俗的來說就是只需要一次用戶登錄，就能夠進入多個業(yè)務(wù)應(yīng)用（權(quán)限可以不相同）刻坊，非常方便用戶的操作枷恕。而在移動互聯(lián)網(wǎng)公司中，內(nèi)部的各種管理谭胚、信息系統(tǒng)甚至外部應(yīng)用同樣也需要單點登錄系統(tǒng)徐块。

目前，比較成熟的灾而、用的最多的單點登錄系統(tǒng)應(yīng)該是耶魯大學(xué)開源的CAS, 可以基于https://github.com/apereo/cas/tree/master/cas-server-webapp來定制開發(fā)的胡控。

基本上，單點登錄的原理都類似下圖所示：

image

7. 統(tǒng)一配置中心

在Java后端應(yīng)用中旁趟，一種讀寫配置比較通用的方式就是將配置文件寫在Propeties昼激、YAML、HCON等文件中锡搜，修改的時候只需要更新文件重新部署即可橙困，可以做到不牽扯代碼層面改動的目的。統(tǒng)一配置中心耕餐，則是基于這種方式之上的統(tǒng)一對所有業(yè)務(wù)或者基礎(chǔ)后端服務(wù)的相關(guān)配置文件進行管理的統(tǒng)一服務(wù), 具有以下特性：

• 能夠在線動態(tài)修改配置文件并生效

• 配置文件可以區(qū)分環(huán)境（開發(fā)凡傅、測試、生產(chǎn)等）

• 在Java中可以通過注解肠缔、XML配置的方式引入相關(guān)配置

百度開源的Disconf和攜程的Apollo是可以在生產(chǎn)環(huán)境使用的方案夏跷，也可以根據(jù)自己的需求開發(fā)自己的配置中心，一般選擇Zookeeper作為配置存儲明未。

8. 服務(wù)治理框架

對于外部API調(diào)用或者客戶端對后端API的訪問槽华，可以使用HTTP協(xié)議或者RESTful（當(dāng)然也可以直接通過最原始的socket來調(diào)用）。但對于內(nèi)部服務(wù)間的調(diào)用趟妥，一般都是通過RPC機制來調(diào)用的猫态。目前主流的RPC協(xié)議有：

• RMI

• Hessian

• Thrift

• Dubbo

這些RPC協(xié)議各有優(yōu)劣點，需要針對業(yè)務(wù)需求做出最好的選擇。

這樣懂鸵，當(dāng)你的系統(tǒng)服務(wù)在逐漸增多，RPC調(diào)用鏈越來越復(fù)雜行疏，很多情況下匆光，需要不停的更新文檔來維護這些調(diào)用關(guān)系。一個對這些服務(wù)進行管理的框架可以大大減少因此帶來的繁瑣的人力工作酿联。

傳統(tǒng)的ESB（企業(yè)服務(wù)總線）本質(zhì)就是一個服務(wù)治理方案终息，但ESB作為一種proxy的角色存在于Client和Server之間，所有請求都需要經(jīng)過ESB贞让，使得ESB很容易成為性能瓶頸周崭。因此，基于傳統(tǒng)的ESB喳张，更好的一種設(shè)計如下圖所示：

image

如圖，以配置中心為樞紐，調(diào)用關(guān)系只存在于Client和提供服務(wù)的Server之間僚害，就避免了傳統(tǒng)ESB的性能瓶頸問題奥帘。對于這種設(shè)計，ESB應(yīng)該支持的特性如下：

• 服務(wù)提供方的注冊舅桩、管理

• 服務(wù)消費者的注冊酱虎、管理

• 服務(wù)的版本管理、負(fù)載均衡擂涛、流量控制读串、服務(wù)降級、資源隔離

• 服務(wù)的容錯撒妈、熔斷

阿里開源的Dubbo則對以上做了很好的實現(xiàn)恢暖，也是目前很多公司都在使用的方案；當(dāng)當(dāng)網(wǎng)的擴展項目Dubbox則在Dubbo之上加入了一些新特性踩身。目前胀茵，Dubbo已經(jīng)被阿里貢獻給Apache，處于incubating狀態(tài)挟阻。在運維監(jiān)控方面琼娘，Dubbo本身提供了簡單的管理控制臺dubbo-admin和監(jiān)控中心dubbo-monitor-simple。Github上的dubboclub/dubbokeeper則是在其之上開發(fā)的更為強大的集管理與監(jiān)控于一身的服務(wù)管理以及監(jiān)控系統(tǒng)附鸽。

此外脱拼，Netflix的Eureka也提供了服務(wù)注冊發(fā)現(xiàn)的功能，其配合Ribbon可以實現(xiàn)服務(wù)的客戶端軟負(fù)載均衡坷备，支持多種靈活的動態(tài)路由和負(fù)載均衡策略熄浓。

9. 統(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和Yahoo的Oozie是Hadoop的流式工作管理引擎愕提，也可以作為統(tǒng)一調(diào)度中心來使用。當(dāng)然皿哨，你也可以使用Cron或者Quartz來實現(xiàn)自己的統(tǒng)一調(diào)度中心浅侨。

• 根據(jù)Cron表達(dá)式調(diào)度任務(wù)

• 動態(tài)修改、停止证膨、刪除任務(wù)

• 支持任務(wù)分片執(zhí)行

• 支持任務(wù)工作流：比如一個任務(wù)完成之后再執(zhí)行下一個任務(wù)

• 任務(wù)支持腳本如输、代碼、url等多種形式

• 任務(wù)執(zhí)行的日志記錄椎例、故障報警

對于Java的Quartz這里需要說明一下：這個Quartz需要和Spring Quartz區(qū)分挨决，后者是Spring對Quartz框架的簡單實現(xiàn)也是目前使用的最多的一種調(diào)度方式。但其并沒有做高可用集群的支持订歪。而Quartz雖然有集群的支持脖祈，但是配置起來非常復(fù)雜。現(xiàn)在很多方案都是使用Zookeeper來實現(xiàn)Spring Quartz的分布式集群刷晋。

此外盖高，當(dāng)當(dāng)網(wǎng)開源的elastic-job則在基礎(chǔ)的分布式調(diào)度之上又加入了彈性資源利用等更為強大的功能。

10. 統(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)用將日志打印到日志服務(wù)器上。

11. 數(shù)據(jù)基礎(chǔ)設(shè)施

數(shù)據(jù)是最近幾年非成ǔ火的一個領(lǐng)域谦秧。從《精益數(shù)據(jù)分析》到《增長黑客》，都是在強調(diào)數(shù)據(jù)的非凡作用。很多公司也都在通過數(shù)據(jù)推動產(chǎn)品設(shè)計疚鲤、市場運營锥累、研發(fā)等。這里需要說明的一點是集歇，只有當(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ù)讓非Hadoop系的技術(shù)可以利用大數(shù)據(jù)集群的資源维贺，能夠大大提高資源的利用率它掂，如Docker on Yarn。

數(shù)據(jù)高速公路

接著上面講的統(tǒng)一日志服務(wù)溯泣，其輸出的日志最終是變成數(shù)據(jù)到數(shù)據(jù)高速公路上供后續(xù)的數(shù)據(jù)處理程序消費的虐秋。這中間的過程包括日志的收集和傳輸。

• 收集：統(tǒng)一日志服務(wù)將日志打印在日志服務(wù)上之后垃沦，需要日志收集機制將其集中起來客给。目前，常見的日志收集方案有：Scribe肢簿、Chukwa靶剑、Kakfa和Flume。對比如下圖所示：

image

此外池充，Logstash也是一個可以選擇的日志收集方案桩引，不同于以上的是，它更傾向于數(shù)據(jù)的預(yù)處理收夸，且配置簡單坑匠、清晰，經(jīng)常以ELK（Elasticsearch + Logstash + Kibana）的架構(gòu)用于運維場景中卧惜。

• 傳輸：通過消息隊列將數(shù)據(jù)傳輸?shù)綌?shù)據(jù)處理服務(wù)中厘灼。對于日志來說，通常選擇Kafka這個消息隊列即可序苏。

此外手幢，這里還有一個關(guān)鍵的技術(shù)就是數(shù)據(jù)庫和數(shù)據(jù)倉庫間的數(shù)據(jù)同步問題，即將需要分析的數(shù)據(jù)從數(shù)據(jù)庫中同步到諸如Hive這種數(shù)據(jù)倉庫時使用的方案忱详∥Ю矗可以使用Apache Sqoop進行基于時間戳的數(shù)據(jù)同步，此外，阿里開源的Canal實現(xiàn)了基于binlog增量同步监透，更加適合通用的同步場景桶错，但是基于Canal還是需要做不少的業(yè)務(wù)開發(fā)工作。

離線數(shù)據(jù)分析

離線數(shù)據(jù)分析是可以有延遲的胀蛮，一般針對的是非實時需求的數(shù)據(jù)分析工作院刁，產(chǎn)生的也是延遲一天的報表。目前最常用的離線數(shù)據(jù)分析技術(shù)除了Hadoop還有Spark粪狼。相比Hadoop退腥，Spark性能上有很大優(yōu)勢，當(dāng)然對硬件資源要求也高再榄。其中狡刘，Hadoop中的Yarn作為資源管理調(diào)度組件除了服務(wù)于MR還可以用于Spark（Spark on Yarn），Mesos則是另一種資源管理調(diào)度系統(tǒng)困鸥。

對于Hadoop嗅蔬，傳統(tǒng)的MR編寫很復(fù)雜，也不利于維護疾就，可以選擇使用Hive來用SQL替代編寫MR澜术。而對于Spark，也有類似Hive的Spark SQL猬腰。

此外鸟废，對于離線數(shù)據(jù)分析，還有一個很關(guān)鍵的就是數(shù)據(jù)傾斜問題姑荷。所謂數(shù)據(jù)傾斜指的是region數(shù)據(jù)分布不均侮攀，造成有的結(jié)點負(fù)載很低，而有些卻負(fù)載很高厢拭，從而影響整體的性能兰英。處理好數(shù)據(jù)傾斜問題對于數(shù)據(jù)處理是很關(guān)鍵的。

實時數(shù)據(jù)分析

相對于離線數(shù)據(jù)分析供鸠，實時數(shù)據(jù)分析也叫在線數(shù)據(jù)分析畦贸，針對的是對數(shù)據(jù)有實時要求的業(yè)務(wù)場景，如廣告結(jié)算楞捂、訂單結(jié)算等薄坏。目前，比較成熟的實時技術(shù)有Storm和Spark Streaming寨闹。相比起Storm胶坠，Spark Streaming其實本質(zhì)上還是基于批量計算的。如果是對延遲很敏感的場景繁堡，還是應(yīng)該使用Storm沈善。除了這兩者乡数，F(xiàn)link則是最近很火的一個分布式實時計算框架，其支持Exactly Once的語義闻牡，在大數(shù)據(jù)量下具有高吞吐低延遲的優(yōu)勢净赴，并且能夠很好的支持狀態(tài)管理和窗口統(tǒng)計，但其文檔罩润、API管理平臺等都還需要完善玖翅。

實時數(shù)據(jù)處理一般情況下都是基于增量處理的，相對于離線來說并非可靠的割以，一旦出現(xiàn)故障（如集群崩潰）或者數(shù)據(jù)處理失敗金度，是很難對數(shù)據(jù)恢復(fù)或者修復(fù)異常數(shù)據(jù)的。因此結(jié)合離線+實時是目前最普遍采用的數(shù)據(jù)處理方案严沥。Lambda架構(gòu)就是一個結(jié)合離線和實時數(shù)據(jù)處理的架構(gòu)方案审姓。

此外，實時數(shù)據(jù)分析中還有一個很常見的場景：多維數(shù)據(jù)實時分析祝峻，即能夠組合任意維度進行數(shù)據(jù)展示和分析。目前有兩種解決此問題的方案：ROLAP和MOLAP扎筒。

• ROLAP：使用關(guān)系型數(shù)據(jù)庫或者擴展的關(guān)系型數(shù)據(jù)庫來管理數(shù)據(jù)倉庫數(shù)據(jù)莱找，以Hive、Spark SQL嗜桌、Presto為代表奥溺。

• MOLAP：基于數(shù)據(jù)立方體的多位存儲引擎，用空間換時間骨宠，把所有的分析情況都物化為物理表或者視圖浮定。以Druid、Pinot和Kylin為代表层亿，不同于ROLAP（Hive桦卒、Spark SQL）, 其原生的支持多維的數(shù)據(jù)查詢。

如上一小節(jié)所述匿又，ROLAP的方案大多數(shù)情況下用于離線數(shù)據(jù)分析方灾，滿足不了實時的需求，因此MOLAP是多維數(shù)據(jù)實時分析的常用方案碌更。對于其中常用的三個框架裕偿，對比如下：

其中痛单，Druid相對比較輕量級嘿棘，用的人較多，比較成熟旭绒。

數(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嗦锐、Impala、Hive都是這種工具沪曙。如果想進一步提供給需求方更加直觀的ui操作界面奕污，可以搭建內(nèi)部的Hue。

image

12. 故障監(jiān)控

對于面向用戶的線上服務(wù)液走，發(fā)生故障是一件很嚴(yán)重的事情碳默。因此，做好線上服務(wù)的故障檢測告警是一件非常重要的事情缘眶≈龈可以將故障監(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也很不錯婚肆，涵蓋了系統(tǒng)監(jiān)控租副、JVM監(jiān)控、應(yīng)用監(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)先級處理面哼。

• 使用微信做為告警軟件，能夠在節(jié)省短信成本的情況下扫步，保證告警的到達(dá)率魔策。

故障告警之后，那么最最關(guān)鍵的就是應(yīng)對了河胎。對于創(chuàng)業(yè)公司來說闯袒，24小時待命是必備的素質(zhì)，當(dāng)遇到告警的時候游岳，需要盡快對故障做出反應(yīng)政敢，找到問題所在，并能在可控時間內(nèi)解決問題胚迫。對于故障問題的排查喷户，基本上都是依賴于日志的。只要日志打的合理访锻，一般情況下是能夠很快定位到問題所在的褪尝，但是如果是分布式服務(wù)闹获，并且日志數(shù)據(jù)量特別大的情況下，如何定位日志就成為了難題河哑。這里有幾個方案：

• 建立ELK（Elasticsearch + Logstash + Kibana）日志集中分析平臺避诽，便于快速搜索、定位日志璃谨。搭配Yelp開源的Elastalert可以實現(xiàn)告警功能沙庐。

• 建立分布式請求追蹤系統(tǒng)（也可以叫全鏈路監(jiān)測系統(tǒng)），對于分布式系統(tǒng)尤是微服務(wù)架構(gòu)睬罗，能夠極大的方便在海量調(diào)用中快速定位并收集單個異常請求信息轨功，也能快速定位一條請求鏈路的性能瓶頸。唯品會的Mercury容达、阿里的鷹眼古涧、新浪的WatchMan、Twitter開源的Zipkin基本都是基于Google的Dapper論文而來花盐，大眾點評的實時應(yīng)用監(jiān)控平臺CAT則在支持分布式請求追蹤（代碼侵入式）的基礎(chǔ)上加入了細(xì)粒度的調(diào)用性能數(shù)據(jù)統(tǒng)計羡滑。此外，Apache正在孵化中的HTrace則是針對大的分布式系統(tǒng)諸如HDFS文件系統(tǒng)算芯、HBase存儲引擎而設(shè)計的分布式追蹤方案柒昏。而如果你的微服務(wù)實現(xiàn)使用了Spring Cloud，那么Spring Cloud Sleuth則是最佳的分布式跟蹤方案熙揍。還需要提到的是职祷，Apache孵化中的SkyWalking是基于分布式追蹤的一個完備的APM（應(yīng)用性能監(jiān)測）系統(tǒng)，其最大的一個特點就是基于Java agent + instrument api届囚，對業(yè)務(wù)代碼無任何侵入有梆，Pinpoint則是類似的另一個已經(jīng)用于生產(chǎn)環(huán)境的APM系統(tǒng)。

出處：https://github.com/superhj1987/pragmatic-java-engineer/blob/master/book/chapter1-servertech/server-basic.md