原文:談?wù)劵ヂ?lián)網(wǎng)后端基礎(chǔ)設(shè)施

作者颯然hang是ETouch隨身云的架構(gòu)師，中華萬年歷就是其公司作品底瓣，專注于JavaEE、系統(tǒng)架構(gòu)蕉陋、大數(shù)據(jù)等后端技術(shù)捐凭；在基礎(chǔ)框架、數(shù)據(jù)統(tǒng)計凳鬓、推薦系統(tǒng)茁肠、DSP、廣告平臺方面有一定的實踐經(jīng)驗; 更多信息可見 http://rowkey.me

獲得作者授權(quán)村视，轉(zhuǎn)載此文官套，以饗中生代讀者！

對于一個互聯(lián)網(wǎng)企業(yè)蚁孔，后端服務(wù)是必不可少的一個組成部分奶赔。拋開業(yè)務(wù)應(yīng)用來說，往下的基礎(chǔ)服務(wù)設(shè)施做到哪些才能夠保證業(yè)務(wù)的穩(wěn)定可靠杠氢、易維護站刑、高可用呢？縱觀整個互聯(lián)網(wǎng)技術(shù)體系再結(jié)合公司的目前狀況鼻百，個人認為必不可少或者非常關(guān)鍵的后端基礎(chǔ)技術(shù)/設(shè)施如下圖所示：

Api網(wǎng)關(guān)

業(yè)務(wù)應(yīng)用和后端基礎(chǔ)框架

緩存绞旅、數(shù)據(jù)庫、搜索引擎温艇、消息隊列

文件存儲

統(tǒng)一認證中心

單點登錄系統(tǒng)

統(tǒng)一配置中心

服務(wù)治理框架

統(tǒng)一調(diào)度中心

統(tǒng)一日志服務(wù)

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

故障監(jiān)控

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

Api網(wǎng)關(guān)

在移動app的開發(fā)過程中，通常后端提供的接口需要以下功能的支持：

負載均衡

api訪問權(quán)限控制

用戶鑒權(quán)

一般的做法奈泪，使用nginx做負載均衡适贸，然后在每個業(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)(http://blog.csdn.net/pzxwhc/article/details/49873623)，可以選擇自己實現(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)一認證中心卦停，在基礎(chǔ)框架層面保證每個api調(diào)用都需要先通過統(tǒng)一認證中心的認證，這里可以采取緩存認證結(jié)果的方式避免對統(tǒng)一認證中心產(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ù)管理平臺控嗜、廣告投放平臺等。相比起在線業(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中確是使用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伊滋。此外，為了在服務(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即可匹涮，也可以使用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)用的時候，迅速的生成雛形應(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中侈百，Google Guava中就提供了本地緩存的實現(xiàn)機制。當(dāng)然使用java的ConncurrentHashMap你也可以實現(xiàn)自己的本地緩存方案翰铡。

分布式緩存：指的單獨的緩存服務(wù)钝域。幾年前比較流行的是memcached，但其只是一個KV的存儲锭魔，支持的數(shù)據(jù)結(jié)構(gòu)太少±ぃ現(xiàn)在最為流行的就是Redis，能夠支持豐富的數(shù)據(jù)結(jié)構(gòu)迷捧，基于事件驅(qū)動的單線程非阻塞IO也能夠應(yīng)對高并發(fā)的場景织咧。集群方案除了官方的redis cluster, 目前比較流行的還有豌豆莢的codis、twitter的twemproxy漠秋。

對于緩存的使用笙蒙，需要注意以下幾點：

緩存的失效機制：當(dāng)給某一個key設(shè)置了有效期，那么緩存何時對此key進行刪除呢庆锦？一般來說會有以下幾種方式：

守護進程定時去掃描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：從數(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ī)模式、基于刷新的簡單模式星著、基于刷新的常規(guī)模式氛悬、基于刷新的續(xù)費模式则剃。后者的方案則是很常見的流量控制和服務(wù)降級耘柱。具體的可以看美團技術(shù)團隊總結(jié)的這篇文章：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ù)進行持久化到硬盤中。如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ù)庫就是由二維表及其之間的聯(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ù)庫那種嚴格的數(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ù)組旷痕、鍵值對、字符串等等顽冶。以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ù)庫”圾亏。暫且不去評判此說法是否真的準確，但索引的確關(guān)系著數(shù)據(jù)庫的讀寫性能封拧。需要對數(shù)據(jù)庫的索引原理做到足夠的了解才能更好的使用各種數(shù)據(jù)庫志鹃。通常來說，Mysql泽西、Oracle曹铃、Mongodb這些都是使用的B樹作為索引，是考慮到傳統(tǒng)硬盤的特點后兼顧了讀寫性能以及范圍查找需求的選擇捧杉，而Hbase用得LSM則是為了提高寫性能對讀性能做了犧牲陕见。

搜索引擎

搜索引擎也是后端應(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)的集成≌＃現(xiàn)有的持久化岗宣、供搜索的數(shù)據(jù)的載體是什么, 如何讓搜索引擎在全量和增量建索引過程中無縫集成原來的數(shù)據(jù)載體，才能發(fā)揮搜索引擎自身的實時性, 水平擴展性(性能與容量和機器數(shù)量成正比)等優(yōu)勢淋样。

和數(shù)據(jù)庫一樣耗式，對搜索引擎的索引機制也需要做到深入的了解。

更為詳細的對于搜索引擎的工程化實踐可以參考有贊工程師的這篇文章：有贊搜索引擎實踐(工程篇)

另外趁猴，搜索引擎還可以用在數(shù)據(jù)的多維分析上刊咳，就是GrowingIO、MixPanel中的可以任意維度查詢數(shù)據(jù)報表的功能儡司。當(dāng)然娱挨，druid也許是一個更好的實現(xiàn)多維分析的方案，官方也有其與es的比較：http://druid.io/docs/latest/comparisons/druid-vs-elasticsearch.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)用方把請求放到隊列中即可返回氮帐，然后等待服務(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)刁岸。

目前主流的消息隊列軟件，主要有以下幾種：

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之下缩抡。對于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)用的瓶頸或者必須提高文件存儲的性能從而提升整個系統(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)一認證中心

統(tǒng)一認證中心，主要是對app用戶事镣、內(nèi)部用戶步鉴、app等的認證服務(wù)，包括

用戶的注冊璃哟、登錄驗證氛琢、token鑒權(quán)

內(nèi)部信息系統(tǒng)用戶的管理和登錄鑒權(quán)

App的管理，包括app的secret生成随闪，app信息的驗證(如驗證接口簽名)等阳似。

之所以需要統(tǒng)一認證中心，就是為了能夠集中對這些所有app都會用到的信息進行管理铐伴，也給所有應(yīng)用提供統(tǒng)一的認證服務(wù)撮奏。尤其是在有很多業(yè)務(wù)需要共享用戶數(shù)據(jù)的時候，構(gòu)建一個統(tǒng)一認證中心是非常必要的当宴。此外畜吊，通過統(tǒng)一認證中心構(gòu)建移動app的單點登錄也是水到渠成的事情(模仿web的機制，將認證后的信息加密存儲到本地磁盤中供多個app使用)即供。

單點登錄系統(tǒng)

目前很多大的在線web網(wǎng)站都是有單點登錄系統(tǒng)的定拟，通俗的來說就是只需要一次用戶登錄于微，就能夠進入多個業(yè)務(wù)應(yīng)用(權(quán)限可以不相同)逗嫡，非常方便用戶的操作。而在移動互聯(lián)網(wǎng)公司中株依，內(nèi)部的各種管理驱证、信息系統(tǒng)同樣也需要單點登錄系統(tǒng)。目前恋腕，比較成熟的抹锄、用的最多的單點登錄系統(tǒng)應(yīng)該是耶魯大學(xué)開源的CAS, 可以基于https://github.com/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)配置文件進行管理的統(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é)議有：

RMI

Hessian

Thrift

Dubbo

這些RPC協(xié)議各有優(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)該支持的特性如下：

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

服務(wù)消費者的注冊雏节、管理

服務(wù)的版本管理胜嗓、負載均衡、流量控制钩乍、服務(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的流式工作管理引擎彭羹，也可以作為統(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ù)雜。現(xiàn)在很多方案都是使用zookeeper來實現(xiàn)spring quartz集群的泳叠。這里有一個國人開源的uncode-shcedule對此實現(xiàn)的還不錯作瞄，可以根據(jù)自己的業(yè)務(wù)需求做二次開發(fā)茶宵。

統(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ù)器上。

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

數(shù)據(jù)是最近幾年非称桥海火的一個領(lǐng)域内列。從《精益數(shù)據(jù)分析》到《增長黑客》，都是在強調(diào)數(shù)據(jù)的非凡作用背率。很多公司也都在通過數(shù)據(jù)推動產(chǎn)品設(shè)計话瞧、市場運營、研發(fā)等寝姿。詳細的可見之前的一篇《數(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ù)讓非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ù)同步問題骨坑，即將需要分析的數(shù)據(jù)從數(shù)據(jù)庫中同步到諸如hive這種數(shù)據(jù)倉庫時使用的方案。比較簡單的柬采、用的也比較多的可以使用sqoop進行基于時間戳的數(shù)據(jù)同步欢唾，此外且警，阿里開源的canal實現(xiàn)了基于binlog增量同步，更加適合通用的同步場景礁遣，但是基于canal你還是需要做不少的業(yè)務(wù)開發(fā)工作的振湾。推薦另一款國人開源的MySQL-Binlog，原理和canal類似亡脸，默認提供了任務(wù)的后臺管理功能押搪，只需要實現(xiàn)接收到binlog后的處理邏輯即可。

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

離線數(shù)據(jù)分析是可以有延遲的浅碾，一般針對是非實時需求的數(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的編譯過程淳地。而對于spark，也有類似hive的spark sql帅容。

此外颇象，對于離線數(shù)據(jù)分析，還有一個很關(guān)鍵的就是數(shù)據(jù)傾斜問題并徘。所謂數(shù)據(jù)傾斜指的是region數(shù)據(jù)分布不均遣钳，造成有的結(jié)點負載很低，而有些卻負載很高麦乞，從而影響整體的性能蕴茴。因此，處理好數(shù)據(jù)傾斜問題對于數(shù)據(jù)處理是很關(guān)鍵的路幸。對于hive的數(shù)據(jù)傾斜荐开，可見:hive大數(shù)據(jù)傾斜總結(jié)付翁。對于spark的傾斜問題简肴，可見：Spark性能優(yōu)化指南——高級篇。

實時數(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真椿。

對于實時數(shù)據(jù)分析鹃答，需要注意的就是實時數(shù)據(jù)處理結(jié)果寫入存儲的時候，要考慮并發(fā)的問題突硝，雖然對于storm的bolt程序來說不會有并發(fā)的問題测摔，但是寫入的存儲介質(zhì)是會面臨多任務(wù)同時讀寫的。通常采用的方案就是采用時間窗口的方式對數(shù)據(jù)做緩沖后批量寫入解恰。

此外锋八，實時數(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ù)分析產(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意鲸。

故障監(jiān)控

對于面向用戶的線上服務(wù)，發(fā)生故障是一件很嚴重的事情。因此怎顾，做好線上服務(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)控等，也支持自定義的監(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é)省短信成本的情況下，保證告警的到達率唁奢。

故障告警之后霎挟，那么最最關(guān)鍵的就是應(yīng)對了。對于創(chuàng)業(yè)公司來說麻掸，24小時待命是必備的素質(zhì)酥夭，當(dāng)遇到告警的時候，需要盡快對故障做出反應(yīng)脊奋，找到問題所在熬北，并能在可控時間內(nèi)解決問題。對于故障問題的排查诚隙，基本上都是依賴于日志的讶隐。只要日志打的合理，一般情況下是能夠很快定位到問題所在的久又，但是如果是分布式服務(wù)巫延，并且日志數(shù)據(jù)量特別大的情況下，如何定位日志就成為了難題地消。這里有幾個方案：

建立ELK(Elastic+Logstash+Kibana)日志集中分析平臺炉峰，便于快速搜索、定位日志脉执。對于ELK的介紹讲冠，可以見：使用Elasticsearch + Logstash + Kibana搭建日志集中分析平臺實踐

建立分布式請求追蹤系統(tǒng)(也可以叫全鏈路監(jiān)測系統(tǒng))，對于分布式系統(tǒng)尤其是微服務(wù)架構(gòu)适瓦，能夠極大的方便在海量調(diào)用中快速定位并收集單個異常請求信息竿开，也能快速定位一條請求鏈路的性能瓶頸。Google的Dapper玻熙、唯品會的Mercury否彩、阿里的鷹眼、新浪的WatchMan都是類似的思路嗦随。此外列荔，騰訊的染色日志機制本質(zhì)上也是在鏈路追蹤之上根據(jù)響應(yīng)信息做了染色機制敬尺。

以上是本人實踐的一些經(jīng)驗。由于知識有限贴浙，難免有紕漏砂吞，敬請指出。

http://www.rowkey.me/blog/2016/08/27/server-basic-tech-stack/