中小团队要怎样搭建架构？腾讯大佬来教你，直接跟着大佬吃经验！

前言

在这个瞬息万变的时代，一个合适的团队架构对于企业发展至关重要。面对时代风向，腾讯等互联网巨头逐步开始了它们的变革；那么中小团队要如何搭建自己的团队架构呢？

今天给大家分享一份被称之“成为高级架构师捷径”的实用技术，腾讯T8高级架构师教大家学习的中小研发团队架构实践

平时我们看技术大会上的分享大多高大上，亿级流量、超大型研发团队，虽然值得借鉴，但由于应用场景与研发资源的差异，一般企业并不容易落地。其实，中小型研发团队在IT行业还是占大多数，他们在技术架构方面的问题较多，技术阻碍业务、跟不上业务发展的情况非常常见。

我是一个有十多年经验的 IT 老兵，曾在两家几千人的技术团队做过架构与技术管理工作，也曾在几十人至几百人的中小研发团队做过首席架构师和CTO。一个是定制的劳斯莱斯，一个是大众轿车。在互联网大厂做技术研发，大多只是一个螺丝钉。而在中小研发团队，则比较容易掌控全局。

笔者结合近几年的工作经验，摸索出了一套可直接落地、基于开源、成本低、可快速搭建的框架及架构方案。小团队也能构建大网站，中小研发团队架构实践更贴近于一般程序员的实际情况，更具应用参考价值。

本文是多年技术、经验、思考和感悟的一个集大成的总结，涵盖了架构设计技术校的方方面面，很好地解答了上述三个问题，具有非常强的指导意义，形象一点来说就是 照着做，你也能设计和 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研发团队文化是怎么”长”出来

从死气沉沉到充满激情活力，从固步自封到好学分享，这是一个有关团队文化的主题。寺庙文化传承千百年，舌尖上的美食流传至今，它们是如何形成和生长的?是参考大公司或从管理书籍.上挑选几个词语，还是脚踏实地，自己一步一步埋头干?本章与你一起探讨!