前言

今天給大家分享的是，騰訊T8高級架構師教大家學習的中小研發團隊架構實踐PDF，被稱之“成為高級架構師捷徑”的實用技術，希望大家能夠喜歡！！！

互聯技術經過幾十年的發展，已經從“鐵器時代”進入“機器時代”。得益于開源運動的蓬勃發展，以及技術的日益開放，原本只有大公司才能擁有的技術和系統已經是“舊時王謝堂前燕，飛入尋常百姓家”了，中小團隊甚至初創公司都能夠基于這些技術和系統快速完成系統的開發，使團隊能夠更加聚焦于業務的發展。

但這并不意味著簡單采用“拿來主義”就萬事大吉，中小團隊在構建系統架構的時候往往面臨幾個核心問題 首先 類似的技術和方案太多 具體該用哪個并不是一目了然的 其次，即使選定了具體技術或方案，如果沒有經驗積累，這些技術和方案的最佳實踐和注意事項（俗稱“坑”）是很難預先知道的；最后，構建一個完整的大網站需要的技術投很多，如果沒有系統的指導，則很可能是 摸著石頭過、河”，進入“踩坑填坑的循環。

本文是多年技術、經驗、思考和感悟的一個集大成的總結，涵蓋了架構設計技術校的方方面面，很好地解答了上述三個問題，具有非常強的指導意義，形象一點來說就是 照著做，你也能設計和 BAT 一樣好的架構！！

主要內容簡介

本文結合作者近幾年的工作經驗，總結了一套可直接落地、基于開源、成本低、可快速搭建的中小研發團隊架構實踐方法。

全文共5篇22章，開篇是本文的導讀;

架構篇是設計思想的提升，包括企業總體架構、應用架構設計、統一應用分層等;

框架篇主講中間件和工具的使用，包括消息隊列、緩存、Job、集中式日志、應用監控和微服務等;

公共應用篇是技術與業務的結合，包括單點登錄和企業支付網關:進階篇是從架構到管理，包括技改案例、技術與業務的匹配與融合等。

從架構、框架、公共應用，到案例實戰和技術管理，本文將大公司的工程理念壓縮應用到中小研發團隊，使小團隊也能構建大網站。

2企業總體架構

企業總體架構是什么，有什么用，具體怎么做呢？以筆者曾任職的公司為案例，一起來探討這個問題 家公司當時有 200 個研發人員和 200 多臺服務器，筆者剛進這家公司時，他們的系統，總是出現各種問題 例如，日常發布系統時或訪問量稍微過大時系統就會出現很多故障，而且找不到故障發生的根本原因 筆者進公司后的主 務就是對這個系統進行升級改造，花了一個半月的時間寫了一份企業總體架構設計文檔。

3應用架構設計

有幾個問題要與讀者 起探討 你做架構設計了嗎？你認為要不要做架構設計？你的公司有沒有做架構設計？在筆者得到的答案中 大部分人認為要做架構設計，但自己卻很少做，自己經歷的公司也很少做架構設計 這里是矛盾的，難道大部分人和公司都犯錯了嗎？ 應該不是這樣！

4統一應用分層:

應用分層這件事情看起來很簡單，但每個程序員都有自己的 套方法，哪怕是初學者。如何讓一家公司的幾百 應用采用統一的分層結構，并得到大部分程序員的認同呢？

5生產環境診斷工具WinDbg

生產環境偶爾會出現- -些異常問題，WinDbg 或GDB是解決此類問題的利器。調試工具WinDbg如同醫生的聽診器，是系統“生病”時進行診斷的逆向分析工具。Dump文件類似于飛機的黑匣子，記錄生產環境程序運行的狀態。本章主要介紹調試工具WinDbg和抓包工具ProcDump的使用，并分享一個真實的案例。多年前不知誰寫的代碼，導致每一兩個月偶爾出現CPU飆高的現象。我們先使用ProcDump在生產環境中抓取異常進程的Dump文件,然后在不了解代碼的情況下通過WinDbg命令進行分析,最終定位有問題的那行代碼。

6 RabbitMQ快速入門及應用

使用過分布式中間件的人都知道，中間件使用起來并不復雜，常用的客戶端API就那么幾個，比我們日常編寫程序時用到的API要少得多。但是分布式中間件在中小研發團隊中使用得并不多，為什么會這樣呢?原因是中間件的職責相對單-一， 客戶端的使用雖然簡單，但整個環境搭起來卻不容易。所以對于中間件的使用，我們重點放在解決門檻問題上，把服務端環境搭好(生產環境可直接使用云或運維解決)，把中間件的基本職責和功能介紹好，把客戶端Demo寫好，讓程序員“抬抬腳”，在調試代碼中即可輕松入門。根據我們以往的經驗，初次接觸也可以自主快速學習。文字描述和Demo以實用為主，能用代碼說明的就不用文字。以下是消息隊列RabbitMQ的快速入門及應用。

7 redis快速入門及應用

Redis的使用難嗎?不難。Redis 用好容易嗎?不容易。Redis 的使用雖然不難，但與業務結合的應用場景特別多、特別密切，用好并不容易。我們希望通過簡單的文字介紹及Demo,讀者即可輕松、快速入門并學會應用。

8任務調度Job

Job類似于數據庫中的作業，多用于實現定時執行任務。適用場景主要包括定時輪詢數據庫同步、定時處理數據和定時郵件通知等。我們的Job分為操作系統級別定時任務WinJob和HttpJob ,其中, WinJob使用開源的任務調度框架Quartz.NET+ZooKeeper實現，HttpJob的服務端是自主開發實現的，可以直接定時調用計劃任務(如微服務)。

9應用監控系統Metrics

應用監控系統Metrics 由Metrics.NET+InfluxDB+Grafana 組合而成，通過客戶端Metrics.NET在業務代碼中埋點, Metrics.NET會把收集的數據存儲在InfluxDB數據庫中,然后通過Grafana來展示監控數據。其中, InfluxDB服務端部署的版本號是1.3.1, Grafana部署的版本號是4.0.1。

10集中式日志ELK

日志可分為系統日志、應用日志和業務日志，系統日志給運維人員使用，應用日志給研發人員使用，業務日志給業務操作人員使用。這里主要講解應用日志，通過應用日志來了解應用的信息和狀態，以及分析應用錯誤發生的原因等。隨著系統的日益復雜，大數據時代的來臨，需要幾十甚至上百臺的服務器是常有的事，因此迫切需要有一-套針對日志且能夠集中式管理的產品。ELK就實現了集中式日志管理，統一-涵蓋了分布式日志收集、檢索、統計、分析，以及對日志信息的Web管理等集中化管控。

11微服務架構MSA

微服務架構MSA是Microservice Architecture的簡稱，它是一種架構模式，它提倡將單一應用程序劃分成一-組小的服務，服務之間互相通信、互相配合,為用戶提供最終價值。

12搜索服務Solr

Apache Solr 是-一個開源的搜索服務器，Solr 使用JAVA 語言開發，主要基于HTTP和Apache Lucene實現。Apache Lucene是- -個高效的、基于Java的全文檢索庫。另外一個基于Lucene的搜索服務器是Elasticsearch,由于項目歷史原因，以及工程師有Solr 的使用經驗，我們選擇了Solr 而不是Elasticsearch。 如果是一個全新的項目，則Elasticsearch也是當下不錯的選擇。

13分布式協調器ZooKeeper

Apache ZooKeeper是由Apache Hadoop 的子項目發展而來的，于2010年11月正式成為Apache的頂級項目。

ZooKeeper是一個開放源代碼的分布式協調服務。它具有高性能、高可用的特點，同時具有嚴格的順序訪問控制能力(主要是寫操作的嚴格順序性)。基于對ZAB協議.( ZooKeeper Atomic Broadcast, ZooKeeper 原子消息廣播協議)的實現，它能夠很好地保證分布式環境中數據的一致性。也正是基于這樣的特性，使得ZooKeeper成為解決分布式數據一致性問題的利器。

14小工具合集

當每月發布次數變得越來越多時，如超過500 次，則發布工作人員的工作量會翻倍增長,此時由人工發布操作失誤引起的風險會變得越來越大。為了提高項目的發布效率，也為了降低由人工操作失誤帶來的風險，需要引進持續集成工具。

15 一鍵發布和測試之持續集成工具Jenkins

Jenkins是-一個用Java語言編寫的開源的持續集成工具,最開始被稱為Hudson,Jenkins在持續集成領域市場份額中居于主導地位，被各種規模的團隊用于用各種語言實現的各類項目中。例如，C#、Java、Ruby、Groovy、Grails、 php等。

16單點登錄

單點登錄的英文全稱是Single Sign On，簡稱SSO。即用戶只需要登錄一次，就可以在個，人權限范圍內，訪問所有相互信任的應用功能模塊，不管整個應用群的內部有多么復雜，對用戶而言，都是一個統-一的整體。用戶訪問Web系統的整個應用群與訪問單個系統一樣，登錄和注銷分別只要一次就夠了。

17企業支付網關

企業支付網關又叫聚合支付，由統-支付服務、 統一支付通知和統一支付后臺三部分組成，本章我們主要介紹前兩部分。將企業支付網關獨立出來非常有必要，它是企業未來金融事業部的基礎 當前價值也很大。

18技改之路:從單體應用到微服務

技改是技術改造的簡稱，是技術的蛻變。本章所談的技改指的是在公司技術發展的某個瓶頸階段,按原有的開發和組織方式已經無法“玩下去”，這時公司希望引進架構師或技術牛，人來破解當前困局。技改對于公司和技術人員而言都非常難得，參與者多，主導者少。筆者有幸前后主導過3次OTA系統的技改，規模有大有小，每次技改環境和問題雖不一樣，但還是有套路可循的。技改之路少講技術多講“路”，我們不過多地關注技術細節和中間件的實現，而重點講述技改的過程和對技改的思考。

19機票垂直搜索引擎之性能優化

20.上云紀要

21技術與業務的匹配與融合

技改是技術改造的簡稱，是技術的蛻變。本章所談的技改指的是在公司技術發展的某個瓶頸階段,按原有的開發和組織方式已經無法“玩下去”，這時公司希望引進架構師或技術牛，人來破解當前困局。技改對于公司和技術人員而言都非常難得，參與者多，主導者少。筆者有幸前后主導過3次OTA系統的技改，規模有大有小，每次技改環境和問題雖不一樣，但還是有套路可循的。技改之路少講技術多講“路”，我們不過多地關注技術細節和中間件的實現，而重點講述技改的過程和對技改的思考。

22研發團隊文化是怎么”長”出來

從死氣沉沉到充滿激情活力，從固步自封到好學分享，這是一個有關團隊文化的主題。寺廟文化傳承千百年，舌尖上的美食流傳至今，它們是如何形成和生長的?是參考大公司或從管理書籍.上挑選幾個詞語，還是腳踏實地，自己一步一步埋頭干?本章與你一起探討!

因為內容實在是太多了，小編在此就不做過多的介紹了，需要本技術文檔的朋友，可以轉發關注小編，私信小編“技術”來獲取！！！

專家力薦學習

本書從實戰出發,通過-一個個實例闡明架構中的種種方法論如何落地，如何在架構落地的過程中保持技術的前瞻性和柔性，如何有效地避免過度設計。作者以CTO的視角講述了帶領技術團隊，從業務和技術痛點入手，快速搭建小而美的整體架構的過程。本書背后的分析思想和設計思路，對于快速發展的中小團隊是非常值得借鑒的經驗。一百度 資深架構師杜亞明

代碼混亂、結構不清晰、開發效率低、發布周期長、發布出錯率高、排查問題困難困擾著很多互聯網研發團隊，也曾是我和作者一起需要面對的問題。 本書第18章技改之路，我是親歷者和見證者，整個過程我與作者一起拼搏奮斗，至今難忘，受益匪淺!-洋碼頭資深架構師 戈建華

本書是作者多年技術、經驗、思考和感悟的一-個集大成的總結，涵蓋了架構設計技術棧的方方面面，具有非常強的指導意義，形象一點來說就是:照著做，你也能設計和BAT一樣好的架構!

一《從零開始學架構》作者，資深技術專家李運華

本書從框架、架構、公共應用和性能調優，到康威定律、技術與業務的匹配與融合等，從生產力到生產關系，從架構師到技術管理，均有涉及，這是一個架構師的進階之路，也是作者的心路歷程，值得各位讀者參考!-餓了么CTO張雪峰

本書內容豐富，涵蓋業務分析、領域建模、分布式系統架構、中間件和工具、微服務架構、技術管理及文化建設等主題。本書是作者近幾年在一線互聯網公司生產實踐的基礎上，加上自己的系統化和體系化思考之后，沉淀下來的干貨。對于-線架構師深入理解互聯網分布式系統的架構設計并指導生產實踐，本書具有非常大的參考價值。---微服務技術專家，拍拍貸基礎框架研發總監楊波