腾讯这次调整架构，只是为了去增强所谓的To B能力，但没涉及核心，比如破除内部数据壁垒，而很多对腾讯反思的核心是缺乏与数据算法驱动时代相适应的大中台。缺乏强有力的中台，这个才是腾讯未来面临的最大挑战。从这个意义上说，腾讯此次组织架构的调整仍面临较大挑战，要补短板并不少，未来恐怕仍需回到提高数据运用能力这一核心上来，那才是真正变革的方向。

腾讯曾经的创新能力很大程度上来源于产品驱动的各个小组织，它们与市场充分接触，洞悉市场需求，在产品开发过程中迅速收到市场反馈并且做出调整。但在ABC时代，尽管前台仍然需要不断开发新产品，如果没有中台的算法能力加持，未免会显得后劲不足。

所谓超级接口化，就是把自己内部功能化的业务，都转化成对外服务化的业务。AWS云服务平台诞生的初衷是为了支撑亚马逊快速发展的内部需要，但现在，已经有几百万的企业，大到通用电气这样的公司，小到最普通的创业公司加盟什么小吃店最赚钱，都在使用亚马逊的云服务，仅AWS一项服务就为亚马逊带来每年超百亿的收入。相对应地，阿里云从服务“光棍节”起步，如今也在为许多企业提供服务，这不仅为阿里带来了丰厚的收入，更重要的是，在市场接受各种复杂情形挑战的阿里云，其云计算能力也不断得以增强，从而可以进一步支撑阿里内部其他业务的发展需要。而阿里云本身，也成为阿里集团的一项非常重要的业务。这与AWS的发展道路何其相似。

互联网创业公司的架构

当大洋彼岸的亚马逊市值突破万亿的时候，同为科技公司的腾讯、阿里或许都会在心里自我掂量，自己与亚马逊之间还有多大的差距。实际上，亚马逊的三大支柱业务（Prime、Marketplace和AWS）中，AWS云服务才是把亚马逊变成超级接口化公司的主要力量。

于是，前端业务中公共、通用的业务便沉淀到这个作为中台的事业部，从而有效避免了重复功能建设和维护带来的重复投资，大大降低了打通“烟囱式”系统间交互的集成和协作的高昂成本，并且随着业务的不断沉淀，“中台”本身也在持续发展，进而能够有效支持系统对来自客户、市场的反馈和信息进行快速的响应。

目前阿里巴巴集团前端包括淘宝、天猫、聚划算等在内的超过25个业务单元，都不是直接独立构建在阿里云的平台之上，而是构建在后端阿里云技术平台和前端业务之间的“共享业务事业部”之上，“共享业务事业部”就是中台战略中所谓的“中台”。

早在2015年就启动的阿里巴巴中台战略给出了部分答案。所谓中台化，就是将整个集团的数据运营能力和产品技术能力都整合起来，对前台业务形成强有力的支撑。也即，构建“大中台、小前台”的机制，后台统一起来以算法驱动，为前台提供技术支持，而前台则立足于产品驱动，注重方方面面的产品体验。

随着ABC（A代表人工智能、B代表大数据、C代表云计算）时代的到来，腾讯原来的组织架构面对新变化有点难以适应，面对新的挑战也应对乏力。以人工智能、大数据和云计算为代表的新技术的成熟，让人感慨腾讯现有的面向移动互联网的组织架构已经落后了整整一个时代。

马化腾表示，这是一次面对未来的进化，是腾讯迈向下一个20年的主动革新与升级迭代。但与其说这次调整是腾讯的主动革新，倒不如说是在严峻的形势逼迫下，腾讯不得不做出的被动反击。

近期，腾讯控股组织架构迎来历史上第三次优化调整。其中最为引入瞩目的是将云业务单列为一个事业群，这也是腾讯控股时隔6年后的再一次大规模组织架构调整。

万人员工规模是互联网公司跨越式发展的分水岭,因此这里我们只针对一万人以.上的几家核心互联网巨头进行复盘。人是互联网公司最核心的资产，探究企业人力结构的分配，能够拆解出哪些业务部门得到了充分的资源和支持，从更真实的角度还原企业。京东70%以上的员工是仓储配送，美团60%以上的员工是BD，阿里巴巴40%的员工是运营与客服。

组织架构与产品矩阵是互联网公司两大最重要的发展逻辑,而这两大核心因素又是相互决定的。由于所处赛道不同，产品发展逻辑的不同，也造就了几大互联网巨头截然不同的基础组织架构。作为社交龙头，腾讯的产品决定资源;作为电商龙头，阿里巴巴的GMV决定资源;作为流量龙头,字节跳动的数据决定资源;而作为本地生活的龙头，美团的单量决定资源。

如何在体量巨大的前提下还保持高速发展和创新活力，是每一个巨头要面临的最重要的问题，也是掩盖在业绩之下最深层的问题。对组织而言，管理和内部文化就是命运，本系列报告希望溯源腾讯、阿里、美团、快手、字节等核心互联网公司组织架构的变动及背后的逻辑，跳脱出财务研究的框架，从更真实的视角去探讨公司的治理体系及发展方向。

互联网巨头的体量不仅反映在业绩与用户规模上，更深层次的还反映在员工的数量上。当我们在讨论美团、腾讯、阿里、字节等等互联网巨头的时候，要随时记得，我们讨论的对象是员工体量5万到10万人之间的公司，而这些公司从1万人发展到5万人，可能只需要短短的几年时间。

研发效率低下，在很大程度上是劳动资料的问题，CI/CD是研发人员的必备工具。2019年，自如想重做CI/CD，对研发人员进行了一次摸底调研，发现研发人员对当前流程体系的满意度平均只有5.76分。

在2019年之前，自如研发的全生命周期是没有完全数字化的，一个项目的开发周期、测试周期、上线周期、人员投入等数据是不完整的，90%的项目没有管理，开发人员根据倒排时间进行排期上线。项目的线上质量指标也基本是原始状态，研发效率低下。

可以发现，占比最高的3个问题变成了代码错误、产品设计缺陷、数据原因，其中代码错误占比45%。稳定性问题终于不再是系统故障的首要原因。

最后是环境问题，代码分支、环境变量、开关配置经常出现测试环境与生产环境不一致等问题；人工参与过多，很多人为问题导致线上代码污染，进而引发故障。

其次是集群耦合太大，数个中心共用一个MQ、一个Redis实例，经常发生业务部门A的队列拥堵导致业务部门B的业务不可用，一个中间件瘫痪，整个公司的业务停转。经排查发现，这个情形与2.1.2小节介绍到的单体架构相似，原因是历史研发人员为了方便，直接复制中间件配置代码，导致业务应用虽然做了解耦和独立，中间件的依赖却没有分开。

首先是版本问题，各中心使用的MQ、Elasticsearch、Redis版本都极其老旧。以Elasticsearch为例，当时最新版本已经到了6.x，生产集群使用的还是2.x版本，导致许多陈旧、低效的语法仍在使用，一些中间件新的特性没有用于生产。

2018年年底，基础平台团队的成立是自如系统从“易变”走向“稳定”的转折点。基础平台重新盘点了线上故障类型，抓住核心短板，发现当时最迫切的问题是中间件的

2019年之前，自如某业务线的系统在30天内出现了13次线上故障，基本达到2天一次的故障频率，面对如此高频的线上问题，开发工程师疲于奔命，根本无暇迭代新功能，一线业务人员对系统也怨声载道。如何保证系统稳定性、功能可用是当时开发团队最为困扰的问题。

自如的技术架构经过10年发展，达到目前的架构状态，并非一蹴而就，而是跟随业务的增长不断迭代和演化的。在这个迭代过程中，我们总结了许多当时遇到的问题，相信与众多中小型互联网公司有不少相似之处。本节会通过一些数据来解析自如在云原生架构落地之前遇到的3个问题—稳定性问题、研发效率问题和流程体系问题。

技术中台：相比于业务中台和数据中台，技术中台是自如目前能力域最多、最为成熟的中台。技术中台包括两部分：一部分侧重业务能力域，如用户登录、权限系统、敏感词系统、即时通信、推送服务、搜索服务；另一部分侧重基础架构，如配置中心、注册中心、监控报警、混沌工程、网关、熔断限流、业务开关、服务治理、流量染色。技术中台是自如业务研发使用最高频的能力，是工程效能最核心的部分。

数据中台：数据中台基本上是最能有效赋能业务的通用能力域集合，核心的能力是自如的定价系统、用户档案、楼盘档案、业主档案、推荐系统，这些核心数据奠定了前台业务快速响应、多维度聚合数据的基础。

业务中台：主要整合各条业务的通用业务能力，如卡券中心、评价中心、价格中心、消息中心等至少能给2条业务线复用的能力才会抽象成中台能力。自如业务中台的建设还不是很成熟，真正可以复用的核心能力还在不断完善中。

2020年，伴随着容器、Kubernetes的广泛传播，自如对持续交付流程做了颠覆性重构，完全改变了之前的发布部署方式，对环境、分支模型都进行了重新定义，成为整个自如的技术演进过程中一个新的里程碑。

2019年，自如开始搭建DevOps体系，所有应用运维往SRE（Site Reliability Engineer，站点可靠性工程师）方向转型，开始学编码，准备为Kubernetes落地储备人才。自如建设了大量的平台功能，如网关、监控报警、配置中心、消息队列平台、权限平台、用户中心等，使技术中台已具雏形。

到了2018年7月，基础平台成立，自如开始对已有的持续交付流程进行重构，引入大量开源技术栈，如Spring Cloud、Nacos、Pinpoint、Graylog、Apollo等，使各个业务线通用的能力得到下沉，同时建设了第二机房，使自如的架构第一次具备了同城灾备的能力。

2015年到2018年是架构服务化的阶段，这时自如业务蓬勃发展，长租、短租、优品、家装、服务等多条业务线崛起，各个业务线开始构建独立的专属服务，此时Java开始逐步替代PHP，成为新业务线使用的语言。各个服务间开始通过RPC进行通信。这个阶段自如从单体架构迈向了分布式架构，度过爆发性增长的3年。

2015年之前，自如以资产应用为主，管理房源信息、合同信息、客户信息，为了快速迭代业务，主语言以PHP为主，代码仓库以SVN来管理。到目前为止，老应用还存在部分未下线的功能，但是历史代码已经达到了1GB。

经过10年的发展，自如的业务规模和业务领域都大大增加。在业务规模巨增的背后，是自如业务系统的飞速演进。自如的技术发展大概经历了如下几个阶段。

自如先把业主的房源收集上来，然后进行精致的装修，为租客打造全新体验的租住和服务产品。同时，自如通过开发App、小程序、线下管家使这一匹配模式更加高效。

首先是供需错配，因为信息差异，业主找不到放心的租客，租客找不到诚信的业主。其次是装修错配，业主房子的新旧程度、装修风格差异性极大，对于租客而言，房子品质的可选范围非常有限。最后是服务错配，租客租到房子后，基本上都是“自扫门前雪”，厕所、客厅、厨房等公共区域脏乱差、噪声大等问题非常突出。

左侧的C是业主，作为市场的供给方，业主有房源，想要更快捷、更安全、更高收益地出租。业主的痛点是找不到合适的租客、拿不到高的租金，同时，业主也没有精力打理房屋托管租期内的事宜。右侧的C是租客，作为市场的需求方，广大租客的核心痛点是找不到合适的房源、享受不到优质的租房服务。

针对流量逐步从线下转到线上、业务线从1条到10条、访客从1万到20万的业务场景，我们应该选择什么样的架构呢？本节会为读者呈现一个典型的中型互联网公司的技术架构变迁过程。

自如是提供租房产品和服务的O2O互联网品牌，成立于2011年10月，目前已为近50万业主、300万自如客提供服务，管理房源超过100万间。自如的主要客群是租房用户，由于租房这个动作并不像电商、社交一样高频，因此自如的互联网属性也很少有高并发、高流量的特征。

然而，中台在企业中落地很难，经过几年的发展，真正落地中台架构的企业很少。现在又有很多企业在质疑中台，在拆中台。并不是中台架构不好，而是企业要根据自己的业务特性和当前所处阶段去选择是否要用中台。

支持业务更加快速迭代：通用的能力域可以快速支持新业务线落地，比如新的业务也需要登录、订单的能力，完全不用从0到1构建一套新的体系，直接用中台的能力即可。

架构重要的功能之一就是避免重复开发、提升复用能力。在这种背景下，如何避免重复造轮子，如何利用同样的能力快速支撑相似的业务需求是架构需要考虑的问题，于是中台思想应运而生。

随着阿里巴巴“大中台、小前台”概念的提出，一线大厂纷纷建立自己的中台体系，公认比较成熟有效的是数据中台、业务中台、技术中台。中台的本质是进一步提升应用系统的复用性，当组织规模扩大，更多业务场景纷纷涌现时，各部门之间会形成一个个“系统烟囱”。在“系统烟囱”中，重复冗余的功能不断被造出来。

性能变慢：微服务一般有一个很长的调用链路，链路过长导致整体接口的性能变慢，响应时间（Response Time，RT）会变长。

粒度难定义：微服务拆成几个合适？什么样的功能模块需要独立成一个微服务？服务拆分的粒度是不好准确定义的，倘若拆得过粗，不利于服务间解耦；如果拆得过细，则会导致应用爆炸，增加系统的复杂性。

复杂度高：微服务采用RPC或REST等方式进行交互，需要考虑网络抖动、消息丢失、幂等、分布式事务等问题，代码的逻辑处理更加复杂。

高可用：随着微服务增多、链路增长，异常也会被分散，一个微服务异常可以通过线程池隔离，利用熔断等技术避免故障扩散和雪崩，大大增加了整个系统的高可用性。

技术独立：各个微服务之间可以用不同的技术栈，服务端应用可以用Java、Go、Python等多种语言实现，数据库可以是MySQL、MongoDB、HBase等不同的类型。

自治性更强：一个微服务就是一个独立的实体，它可以独立部署、升级，微服务与微服务之间通过REST等标准接口进行通信，微服务只与其上下游有关，各个微服务之间更加独立。

分布式架构2.0阶段不仅是在部署上实现分布式，应用的边界也更加清晰，从单一架构的大单一职责，拆分出一些大的应用，逐步形成多种服务之间的分布式调用。还是以电商为例，这里可能会拆分出用户服务、订单服务、商品服务、库存服务四大应用，应用之间通过接口进行交互，调用形式可能是REST或者RPC。

负载均衡一般分为硬负载和软负载，常见的负载均衡算法有轮询、加权、地址散列、最少链接等。有了负载均衡后，不会因为某一个服务的宕机而导致整体服务不可用，架构的可用性大大加强。除了应用的分布式，根据业务量的大小，数据库也会进行水平或垂直拆分，通过分布式架构赋予整体架构高负载的能力。

随着业务的不断增长，用户的访问越来越多，单一应用对磁盘、CPU、内存、数据库的访问要求也越来越高。一台服务器一个应用的配置开始捉襟见肘，更改任何一个小的功能模块，整个应用都要重新进行编译和部署。同时，当有多个需求并行时，发布效率会非常低下，整体的功能耦合性非常大，一个小功能的变动可能会引起整个应用不可用。多种功能的强耦合迫使单体架构走向分布式架构。

在业务发展早期，业务功能往往比较单一，为了快速支持业务，一般一台服务器、一个应用、一个数据库，就足够支撑起一个单一的业务功能。比如电商业务，登录、下单、商品、库存都在一个单一的应用中进行管理和维护。单体架构在业务发展早期非常轻便，易于搭建开发环境，易于测试和部署。

在Web应用发展早期，大部分工程都是将所有的服务和功能模块打包到一个单一的应用中，如以War包的形式运行在Tomcat进程中，直接与数据库和文件系统交互。

平台（Platform）：一般来说，是一个领域或方向上的生态系统，是很多解决方案的集大成者，提供了很多服务、接口、规范、标准、功能、工具等。

服务（Service）：一组对外提供业务处理能力的功能，服务需要使用明确的接口方式（比如Web Service、RESTful等）。服务描述里应该包括约束和策略（比如参数、返回值、通信协议、数据格式等）。

模块（Module）：基于业务数据或一组相关功能按照特定维度的逻辑划分，也可以看作各种功能按照某种分类的聚合。例如，电商系统可以从业务上划分为用户模块、商品模块、订单模块、支付模块、物流模块等。模块使一个复杂的软件变得更加容易管理和维护。

组件（Component）：一组可以复用的业务功能的集合，包含一些对象及其行为。组件可以直接用作业务系统的组成部分，颗粒度一般小于模块，也是一种功能的聚合形式，比如日志组件、权限组件等。

框架（Framework）：通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，往往是基于一组类库或工具，在特定领域里根据一定的规则组合而成。

技术架构一般是指实现应用架构的关键技术栈，如Spring Cloud、ZooKeeper、RocketMQ、Redis、MySQL、Elasticsearch等中间件，以及各种核心流程的时序图、状态图等信息。

应用架构一般是指根据业务场景设计出应用的层次结构，制定好应用间的调用、交互方式，确保它们能够融合在一起并满足业务需要。比如，电商系统的应用架构可能有用户中心、权限中心、登录系统、商品中心、搜索引擎、推荐体系、订单系统、交易系统等。应用架构体现的是用什么样的微服务去支持功能的实现。

功能架构一般是指产品具备的细分功能。例如，电商系统的功能架构可细分为用户管理、登录注册、商品管理、仓库管理、订单管理、购物车管理、支付管理等核心模块。功能架构图体现的是一个产品的核心功能模块。

业务架构一般是指业务的关键流程、组织形式、信息流。以电商为例，业务架构包括选品、采购、仓储、物流、供应商、订单等一系列的业务版块。业务架构体现的主要是业务模式和流程，核心是定义业务痛点，厘清功能需求和非功能性需求。

我们常听到各种关于架构的名词，比如业务架构、功能架构、应用架构、技术架构、物理架构等，很多读者可能分不清，这里我们简单梳理一下这几个架构的区别。

可扩展性。市场和用户总是在不断变化的，为了适应业务的高速迭代，尤其是一些2B企业的个性化需求，架构要求能够在最小的改动成本下满足更多的需求。这要求架构可以根据客户群的不同和市场需求的变化进行调整。

易维护性。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映给现有系统。一个易于维护的系统可以有效降低技术支持的费用。

可用性和可靠性。由于软件系统对于用户的商业经营和管理来说极为重要68岁农村老人创业计划书，因此软件系统必须非常可靠。可用性和可靠性虽然是两个不同的属性，但本质都是为了提升业务连续性，使企业的业务尽可能不中断。

通俗地来讲，技术架构就是对软件系统各个维度进行不同模块化的抽象，通过抽象使原本复杂的工程变得易于理解和分工实现。就像泰勒提出的科学管理，通过标准化的作业流程和分工，原本混沌复杂的软件工程被拆分出前端、后端、质量、运维等多个岗位。以后端为例，根据不同的岗位职责，按照康威定律又被拆分出不同的组织，比如订单组、用户组、交易组等，进而使整体的生产力大大提升。因此，架构的本质是抽象分类，进而指导软件系统的实现。

软件架构（Software Architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。

本节将从架构的定义出发，介绍几类常见的架构形态及其演变路径，从单体到分布式、从分布式到微服务、从微服务到中台。并不是最新的架构就是最好的，符合企业当下业务形态的架构才是好架构。那么，如何选择符合自己业务的架构呢？让我们从了解每个架构的特点开始。

本章首先介绍企业级架构的演变过程你想做个什么样的小生意，包括大部分企业都会经历的单体架构、分布式架构、微服务架构，以及最近几年比较火爆的中台架构；然后结合自如的业务特性介绍自如技术架构的历史变迁，还原一个中型互联网公司的架构演进之路。相信很多读者在读完本章后，能够找到自己企业的影子。

引用王小川老师在中国计算机大会（CNCC）分享的一句话：“技术与业务的关系就像汽车，汽车有三大组件—车轮、发动机、方向盘，分别代表了3种技术与业务的关系，分别是技术支持、技术驱动、技术颠覆。”95%的企业是技术支持型企业，一般都是先追求业务的快速迭代试错，架构一般会滞后于业务的发展，在架构跟不上业务的迭代速度，或有巨大的历史技术债务出现时，技术架构才会进行新一轮的迭代。同时，没有任何一个架构是“银弹”，凡是能够解决当下企业面临的问题的架构就是好架构。

在云原生架构出现之前，大家谈论最多的是微服务架构。有的企业可能只有一种架构，有的企业经历过多种架构的演变。架构的选择与企业当前所处的阶段

专题： 少儿英语加盟   肯德基加盟   成都创业项目