写点什么

腾讯组织架构整改引思考:中小团队要怎样搭建架构?

  • 2019 年 1 月 17 日
  • 本文字数:5083 字

    阅读完需:约 17 分钟

腾讯组织架构整改引思考:中小团队要怎样搭建架构?

2019 年 1 月 4 日,腾讯宣布成立技术委员会,也代表之前宣布的架构调整终于拉开序幕。那么中小团队要如何搭建自己的团队架构呢?本文将会对此展开讨论……


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


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


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


一、框架篇:工欲善其事,必先利其器

如果说运维是地基,那么框架就是承重墙。农村建住房是一块砖一块砖地往上垒,而城市建大 House 则是先打地基,再建承重墙,最后才是垒砖,所以中间件的搭建和引进是建设高可用、高性能、易扩展可伸缩的大中型系统的前提。


框架篇中的每章主要由四部分组成:它是什么、工作原理、使用场景和可直接调试的 Demo。其中中间件及 Demo 是历经两家公司四年时间的考验,涉及几百个应用,100 多个库 1 万多张表,日订单从几万张到十几万,年 GMV 从几十亿到几百亿。


所有中间件与工具都是基于开源。早期我们也有部分自主研发如集中式日志和度量框架,后期在第二家公司时为了快速地搭建、降低成本、易于维护和扩展,全部改为开源。这样不仅利于个人的学习成长、知识重用和职业生涯,也利于团队的组建和人才的引进。


1、集中式缓存 Redis


缓存是计算机的难题之一,分布式缓存亦是如此。Redis 看起来非常简单,但它影响着系统的效率、性能、数据一致性。


用好它不容易,具体包括:缓存时长(复杂多维度的计算)、缓存失效处理(主动更新)、缓存键(Hash 和方便人工干预)、缓存内容及数据结构的选择、缓存雪崩的处理、缓存穿透的处理等。Redis 除了缓存的功能,还有其它功能如 Lua 计算能力、Limit 与 Session 时间窗口、分布式锁等。我们使用 ServiceStack.Redis 做客户端,使用方法详见 Demo。


2、消息队列 RabbitMQ


消息队列好比葛洲坝,有大量数据的堆积能力,然后再可靠地进行异步输出。它是 EDA 事件驱动架构的核心,也是 CQRS 同步数据的关键。为什么选择 RabbitMQ 而没有选择 Kafka,因为业务系统有对消息的高可靠性要求,以及对复杂功能如消息确认 Ack 的要求。


3、集中式日志 ELK


日志主要分为系统日志和应用日志两类。


试想一下,你该如何在一个具有几百台服务器的集群中定位到问题?如何追踪每天产生的几 G 甚至几 T 的数据?集中式日志就是此类问题的解决方案。


早期我们使用自主研发的 Log4Net+MongoDB 来收集和检索日志信息,但随着数据量的增加,查询速度却变得越来越慢。后期改为开源的 ELK,虽然易用性有所下降,但它支持海量数据以及与编程语言无关的特征。下图是 ELK 的架构图:



4、任务调度 Job


任务调度 Job 如同数据库作业或 Windows 计划任务,是分布式系统中异步和批处理的关键。我们的 Job 分为 WinJob 和 HttpJob:


  • WinJob 是操作系统级别的定时任务,使用开源的框架 Quartz.NET 实现;

  • 而 HttpJob 则是自主研发实现,采用 URL 方式可定时调用微服务。


HttpJob 借助集群巧妙地解决了 WinJob 的单点和发布问题,并集中管理所有的调度规则,调度规则有简单规则和 Cron 表达式。HttpJob 它简单易用,但间隔时间不能低于 1 分钟,毕竟通过 URL 方式来调度并不高效。


下图是 HttpJob 的管理后台:



5、度量工具 Metrics


“没有度量就没有提升”,度量是改进优化的基础,是做好一个系统的前置条件。


Zabbix 一般用于系统级别的监控,Metrics 则用于业务应用级别的监控。业务应用是个黑盒子,通过数据埋点来收集应用的实时状态,然后展示在大屏或看板上。它是报警系统和数字化管理的基础,还可以结合集中式日志来快速定位和查找问题。我们的业务监控系统使用 Metrics.NET+InfluxDB+Grafana。



6、微服务 MSA


微服务是细粒度业务行为的重用,需要与业务能力及业务阶段相匹配。


微服务框架是实现微服务及分布式架构的关键组件,我们的微服务框架是基于开源 ServiceStack 来实现。它简单易用、性能好,文档自动生成、方便调试测试,调试工具 Swagger UI、自动化接口测试工具 SoapUI。


微服务的接口开放采用我们自主研发的微服务网关,通过治理后台简单的配置即可。网关以 NIO、IOCP 的方式实现高并发,主要功能有鉴权、超时、限流、熔断、监控等,下图是 Swagger UI 调试工具:



7、搜索引擎 Solr


分库分表后的关联查询,大段文本的模糊查询,这些要如何实现呢?


显然传统的数据库没有很好的解决办法,这时可以借助专业的检索工具。全文检索工具 Solr 不仅简单易用性能好,而且支持海量数据高并发,只需实现系统两边数据的准实时或定时同步即可。下图是 Solr 的工作原理:



8、更多工具


  • 分布式协调器 ZooKeeper:ZK 工作原理、配置中心、Master 选举、Demo,一篇足以;

  • ORM 框架:Dapper.NET 语法简单、运行速度快,与数据库无关,SQL 自主编写可控,是一款适合于互联网系统的数据库访问工具;

  • 对象映射工具 EmitMapper 和 AutoMapper:EmitMapper 性能较高,AutoMapper 易用性较好;

  • IoC 框架:控制反转 IoC 轻量级框架 Autofac;

  • DLL 包管理:公司内部 DLL 包管理工具 NuGet,可解决 DLL 集中存储、更新、引用、依赖问题;

  • 发布工具 Jenkins:一键编译、发布、自动化测试、一键回滚,高效便捷故障低。


二、架构篇:思想提升

会使用以上框架并不一定能成为优秀的架构师,但一位优秀架构师一定会使用框架。架构师除了会使用工具外,还需要架构设计思想和性能调优技能。此部分以真实项目为背景,思想方法追求简单有效,内容包括企业总体架构、单个项目架构设计、统一应用分层、调试工具 WinDbg。


1、企业总体架构


当我们有了几百个上千个应用后,不仅仅需要单个项目的架构设计,还需要企业总体架构做顶层思考和指导。


大公司与小商贩的商业思维是一样的,但大公司比较难看到商业全貌和本质。而小公司又缺乏客户流量和中间件的应用场景,中型公司则兼而有之,所以企业总体架构也相对好落地。


企业总体架构需要在技术、业务、管理之间游刃有余地切换,它包括业务架构、应用架构、数据架构和技术架构。


附档是一份脱敏感信息后的真实案例,有参考 TOGAF 标准,但内容以解决公司系统的架构问题为导向、以时间为主线,包括企业商务模型、架构现状、架构规划和架构实施。


2、单个项目架构设计


应用架构设计如同施工图纸,能直接指导工程代码的实施。


上一环是功能需求,下一环是代码实施,这是架构设计的价值所在。从功能需求到用例,到用例活动图,到领域图、架构分层,到核心代码,它们之间环环相扣。做不好领域图可能源自没有做好用例活动图,因为用例活动图是领域图的上一环。关注职责、边界、应用关系、存储、部署是架构设计的核心,下图是具体案例参考:



3、统一应用分层


给应用分层这件事情很简单,但是让一家公司的几百个应用采用统一的分层结构,这可不是件简单的事情。它要做到可大可小、简单易用、支持多种场景,我们使用 IPO 方式:I 表示 Input、O 表示 Output、P 表示 Process,一进一出一处理。


应用系统的本质就是机器,是处理设备,也是一进一出一处理,IPO 方式相对于 DDD 而言更为简单实用。



4、诊断工具 WinDbg


生产环境偶尔会出现一些异常问题,而 WinDbg 或 GDB 就是解决此类问题的利器。调试工具 WinDbg 如同医生的听诊器,是系统生病时做问题诊断的逆向分析工具,Dump 文件类似于飞机的黑匣子,记录着生产环境程序运行的状态。


本文主要介绍了调试工具 WinDbg 和抓包工具 ProcDump 的使用,并分享一个真实的案例。


N 年前不知谁写的代码,导致每一两个月偶尔出现 CPU 飙高的现象。我们先使用 ProcDump 在生产环境中抓取异常进程的 Dump 文件,然后在不了解代码的情况下通过 WinDbg 命令进行分析,最终定位到有问题的那行代码。



三、公共应用篇:业务与技术的结合

先工具再框架,然后架构设计,最后深入公共应用。


公共应用因为与业务系统结合紧密,但又具有一定的独立性,所以一般自主开发,不使用开源也不方便开源。公共应用主要包括单点登录、企业支付网关、CTI 通讯网关(短信邮件微信),下面介绍单点登录和企业支付网关。


1、单点登录


应用拆分后总要合在一起,拆分是应用实施层面的拆分,合成是用户层面的合成,而合成必须解决认证和导航问题。单点登录 SSO 即只需要登录一次,便可到处访问,它是建立在用户系统、权限系统、认证系统和企业门户的基础上。


我们的凭证数据 Token 使用 JWT 标准,以解决不同语言、不同客户端、跨 WebAPI 的安全问题。


2、企业支付网关


企业支付网关集中和封装了公司的各大支付,例如支付宝、财付通、微信、预付款等。它统一了业务系统调用各支付接口的方式,简化了业务系统与支付系统的交互。它将各种支付接口统一为支付、代扣、分润、退款、退分润、补差、转账、冻结、解冻、预付款等,调用时只需选择支付类型即可。


企业支付网关将各大支付系统进行集中地设计、研发、部署、监控、维护,提供统一的加解密、序列化、日志记录和安全隔离。


四、进阶篇:从架构到管理

架构要落地、固化和提升,需要通过技术架构与组织架构的对齐来达成。从生产力到生产关系,从架构师到技术管理,你关注的角度也将发生变化。从关注技术到关注技术的商业价值、技术与业务的匹配与融合、技术团队的文化等等。


本部分内容包括技改之路、技术与业务的匹配与融合、研发团队文化是怎么长出来的,重点会介绍以下 3 个。


1、技改之路:从单块应用到微服务


技改是技术改造的简称,是技术的蜕变。这里指的是在公司技术发展的某个瓶颈阶段,按原有开发和组织方式已经无法玩下去,这时公司希望引进架构师或技术牛人,来破解当前困局。


技改之路少讲技术多讲路,我们不过多地关注技术细节和中间件的实现,而重点讲述技术改造的过程和思考。技改是大折腾,于公司于个人而言都是。小改怡情、大改伤身,所以真正高手下棋,应该是通盘无妙招,让正确的事情很容易发生,基于自然的演化来实现技术的演进。


2、技术与业务的匹配与融合


是什么在驱动公司的发展?


技术说“科学技术是第一生产力”,市场说“没有市场,哪来的业务”,运营说他自己。应该说他们都是正确的,但又不全面。这如同盲人摸象一样,引发了不少的争论,也直接或间接地导致了技术与业务的矛盾。


本文先抛出了一个启发性的问题,然后分析问题出在哪里,理解源于彼此的了解,如何去匹配与融合,最后正面回答了该问题。只有尊重事物的发展规律,加强技术与业务的之间合作,才能促进公司发展。


3、研发团队文化是怎么长出来的


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


我们要先弄清遇到的问题,然后是找到解决之道,包括管理工具、制度和行为措施,并予以贯彻并形成一种习惯,最后是总结并归纳成几个可以贴到墙上的大字,即「共治分享自视一起拼,简单有效快」,这个过程就如同花朵一般。只有这样「长」出来的文化,才能管人做事,才能成为公司或团队的执行力。


以上目录顺序不仅是架构改造的参考路径,也是架构师的成长路径。照着做,你也能够成为架构师。本文后续还会涉及框架中的其他部分,对内容进行更详细的延展分析。


我们希望能够尽量降低工具对研发人员的门槛,实现简单实用、降低成本。文章中部分 Demo 采用 C#或 Java 语言,但到了框架与架构层面,与语言本身没有太多关系。


如 RabbitMQ、Job、Redis 和集中式日志 ELK,它们服务端的部署都是一样的,只是客户端语言版本稍有不同。所有 Demo 在一段时间内都可直接运行,服务地址和管理后台亦可直接访问。


以上这些基础工作,希望能够帮助到中小型研发团队,解决大家项目中遇到的实际问题,也愿与你一起在架构方面有所成长,谢谢!


案例参考和 Demo 下载


下载地址:


https://github.com/das2017?tab=repositories


作者介绍


张辉淸,曾任中青易游 CTO、同程交通创新技术负责人、古大集团首席架构师、携程架构师等职务。带领过 30~200 人的技术团队,将其研发能力提高 1~2 个档次。现阶段主要关注技术创新、技术创业、中小研发团队的能力提升。


2019 年 1 月 17 日 07:009783

评论 4 条评论

发布
用户头像
看到.NET我就没看下去的欲望了。
2019 年 01 月 18 日 09:10
回复
你肯定是个初级的程序员
2019 年 09 月 18 日 11:36
回复
用户头像
太初级了吧。。。。
2019 年 01 月 17 日 11:53
回复
用户头像
很有见地!文中所提和我的技术栈很类似,学习了。
2019 年 01 月 17 日 08:18
回复
没有更多了
发现更多内容

2021年Android开发者跳槽指南,附超全教程文档

android 面试 移动开发

2021年Java常见面试题,面试官让我回家等通知

Java 面试 后端

2021年Java开发者常见面试题,初级Java面试题及答案

Java 面试 后端

2021年Java技术下半场在哪,35岁技术人如何转型做管理

Java 面试 后端

2021年Android笔试题总,详解Android架构进阶面试题

android 面试 移动开发

代码检查规则背景及总体介绍

百度开发者中心

最佳实践 代码规则

2021大厂Java面试经验,这位阿里P7大佬分析总结的属实到位

Java 面试 后端

2021大厂Java面试集合,作为Java程序员

Java 面试 后端

2021年Java开发突破20k有哪些有效的路径,JVM发生内存溢出的8种原因

Java 面试 后端

2021年Java笔试题总,教你抓住面试的重点

Java 面试 后端

2021年Android开发学习路线,终于彻底把握了

android 面试 移动开发

数据库排行榜|当 DB-Engines 遇见墨天轮国产数据库排行

墨天轮

MySQL 数据库 oracle TiDB 国产数据库

2021年Android程序员职业规划,阿里P7大牛亲自讲解

android 面试 移动开发

2021年Android开发者常见面试题,涨薪7K

android 面试 移动开发

2021年Android程序员职业规划,小白勿进

android 面试 移动开发

2021年Java开发突破20k有哪些有效的路径,2021Java面试笔试总结

Java 面试 后端

Github上线仅六天,收获Star超55K+,这套笔记足够你拿下90%以上的Java面试!

Java 架构 面试 后端 计算机

2021年Android开发前景如何,详解Android架构进阶面试题

android 面试 移动开发

2021年Android社招面试题精选,附答案解析

android 面试 移动开发

2021年Java开发前景如何,大厂Java面试真题精选

Java 面试 后端

2021年Android网络编程总结篇,retrofit面试

android 面试 移动开发

2021大厂Java面试必问题目,Java后端校招面试题

Java 面试 后端

2021年Java工作或更难找,华为Java面试社招

Java 面试 后端

2021年Java者未来的出路在哪里,Java开发校招面试题

Java 面试 后端

2021年Java工作或更难找,springboot源码解读与原理分析

Java 面试 后端

2021年Android社招面试题,阿里蚂蚁金服五面

android 面试 移动开发

对比会声会影与剪映哪个制作转场效果更专业

懒得勤快

2021年Java程序员职业规划,华为Java面试题目

Java 面试 后端

2021年Java网络编程总结篇,红黑树详细分析(图文详解)

Java 面试 后端

2021年Android开发学习路线,互联网行业“中年”危机

android 移动开发

2021年Android开发陷入饱和,又是一年金九银十

android 面试 移动开发

数据cool谈(第2期)寻找下一代企业级数据库

数据cool谈(第2期)寻找下一代企业级数据库

腾讯组织架构整改引思考:中小团队要怎样搭建架构?-InfoQ