前言

今天给大家分享的是，腾讯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张雪峰

本书内容丰富，涵盖业务分析、领域建模、分布式系统架构、中间件和工具、微服务架构、技术管理及文化建设等主题。本书是作者近几年在一线互联网公司生产实践的基础上，加上自己的系统化和体系化思考之后，沉淀下来的干货。对于-线架构师深入理解互联网分布式系统的架构设计并指导生产实践，本书具有非常大的参考价值。---微服务技术专家，拍拍贷基础框架研发总监杨波