腾讯海量业务架构的演进

无论是 QQ、Qzone，还是腾讯视频和 QQ 音乐，它们中的每一个都是腾讯的重量级产品。从0开始，经过一段时间的发展，每一款产品最终均坐拥数亿用户。它们能取得成功，与其背后成功的业务架构设计息息相关。这些产品的业务架构是如何设计并不断演进的？为解答心中疑惑，InfoQ 记者采访了 ArchSummit 全球架构师峰会专题出品人腾讯云原生架构总经理肖世广。

作为前 QQ 技术总监，肖世广2008年进入腾讯，曾先后负责 QQ、Qzone、腾讯视频、QQ 音乐、腾讯广告、QQ 农牧场等互联网产品的技术运营管理工作。之后，他进入腾讯云，负责云原生架构，以及面向云开发者和云生态的技术中台建设。

从宏观层面看，架构设计大体分为技术架构设计和业务架构设计。

肖世广认为，所谓业务架构设计，是指在对业务深度理解的前提下，从某一逻辑视角出发，对业务场景进行解构，再进行架构的过程。在此过程中，需要界定各业务模块的边界，设计业务的流程体系。

“从系统论的角度而言，这些工作的本质和技术架构很类似，因为都建立在抽象及建立模型的基础上。换句话说，业务架构与技术架构有相通之处。”他说。

腾讯明星产品的业务架构演进

在肖世广看来，业务架构的演进往往伴随着技术架构的演进。总体而言，QQ、Qzone、腾讯视频和 QQ 音乐的业务架构演进大致经过六个阶段。

1.单体应用

在早期时，应用业务规模较小，业务逻辑也相对简单。为快速开发和快速迭代，肖世广称“大多采用单体应用的模式，并未过多关注应用间通用的业务逻辑的抽象，各应用在业务架构上呈接近独立的形态”。

2.SOA

随着业务规模的扩大，以及各应用业务逻辑的逐渐丰富，团队将各应用间最重要的业务逻辑进行了抽象和封装，形成公共服务，以提高业务逻辑的复用性，降低研发和维护成本。业务架构开始初步分层，从通用业务逻辑抽象出的服务在设计和实现方面更重通用性、扩展性，特定的业务逻辑则强调可快速迭代和灵活性。业务架构在这一阶段开始初步解耦。

3.微服务

在这一时期，团队对各应用的业务逻辑进行了更细粒度的抽象和封装，各服务逐步向更细粒度的形态转变。在技术架构上，引入了微服务治理框架，业务架构的分层与解耦彻底完成。

4.SET 治理

随着业务更进一步的发展，以及用户量的增加，小概率的业务异常事件成为常态。此时，业务在用户体验、容灾和数据安全方面有了更高要求。划 SET 而治之的业务架构理念随即产生，其按一定的规则把不同用户划分在不同 SET 里，各 SET 在业务逻辑上完整闭环，减少单个逻辑域的用户数，降低了小概率业务异常的发生率。同时，业务分流的设计也降低了技术架构的整体挑战。

5.全国多区域 SET 容灾

随着业务规模的爆炸式增长，用户分布在全国甚至世界各地，就近访问、异地容灾、全网调度的诉求越来越高，所以多区域 SET 的容灾模式成为业务部署模式的必然选择。

肖世广介绍了一个多区域 SET 容灾的案例。2015 年 8 月 12 日， 天津发生特大爆炸事故，但腾讯部署在天津数据中心的所有业务并未受到影响，因为7000万 QQ 在线用户“无感知的”迁移到上海和深圳两地。“这是互联网史上最大的在线用户数迁移，是互联网的一个里程碑，这要归功于多区域 SET 容灾的功劳。”他说。

6.云原生及业务中台

2018年9月30日，腾讯进行大的组织架构调整，制定了“开源协同，自研上云”的战略。肖世广表示，作为腾讯的核心业务线，QQ、Qzone、腾讯视频等业务在业务架构方面的沉淀逐步向整个公司输出。

同时，这些应用也开始全量上云，拥抱云原生。“此前，我们经历过 SOA 、微服务、SET 治理、以及全国多区域 SET 容灾的阶段。因此，对我们而言，上云算是驾轻就熟。这个过程中，我们在技术体系上以 CI/CD、DevOps、微服务、容器为基础要素，更进一步地将业务架构进行了整体再造和梳理，各个团队在与其它部门共用努力下，逐步构建起了业务中台。”他说。

业务架构演进的三个关键词

整个业务架构的演进可以用三个词来概括：模块化、功能化、专业化。在业务早期，因为更侧重快速迭代而轻业务架构建设；在业务发展的中后期，逐步加重业务架构的建设，最终构建起业务中台，在极大提高可复用性、避免重复建设、提高内部协同的情况下，同时又能保证业务前端的灵活性和可快速迭代性。

对企业而言，它需要让业务架构去适应不同的业务特性。其中的关键在于合理的抽象与分层。企业可以根据业务发展的阶段，选择不同的方式重构业务架构，解决历史债务，让业务架构跟上业务的发展。

业务架构的演进要以模块化、功能化和专业化为宗旨，让业务研发人员更加聚焦业务功能逻辑的开发，提高业务开发效率。甚至，业务功能也能抽象出来形成不同类型的技术中台，但中台建设不仅涉及到业务和技术，更涉及到组织架构，这非一日之功。

肖世广表示，中台虽好，但并不是“银弹”，企业还需要根据自身所处的阶段选择适当的体系建设，切忌拔苗助长。

业务架构设计的挑战与困难

从挑战方面看，业务架构设计的挑战和困难主要在于协同，因为它需要和各个业务部门持续沟通，以便更好地梳理和抽象出业务逻辑模块，“尤其是建设业务中台时，这种协同就面临更大的挑战，因为涉及到组织架构层面”。

业务架构设计的挑战与困难主要在于以下几个方面：

1. 高性能：海量业务规模下，企业对服务的性能要求非常高；
2. 服务高可用：想给用户带来良好的体验，这要求终端与后台服务具备稳定、高可用等；
3. 多区域容灾：为了让用户持续拥有良好的体验，当地区级的小概率灾难出现时，这要求我们能做到服务与数据的多地容灾；
4. 低成本：海量业务规模下，成本耗费是巨大的，因此，架构设计需要综合考虑实施、基础环境、物理资源、持续运营等多种成本；
5. 微服务的立体化监控：为了给用户带来良好的体验，业务异常需要被快速发现，及时解决，微服务的立体化监控必不可少，因为它能从多维度的关键链路数据相互佐证系统是否在稳定运营。
6. 可运维性：运维的服务保障对业务稳定运营至关重要，海量业务的运维更是一种考验
7. 敏捷开发：业务在快速发展，业务架构的设计是否有利于敏捷开发、快速迭代，这尤为重要。
8. 持续集成：业务在快速发展，业务架构的设计是否有利于快速测试、验证、上线，这同样非常重要。

互联网产品业务架构设计的六大特点

在腾讯工作超过10年，并且负责过 QQ、Qzone、腾讯视频和 QQ 音乐等产品的技术研发，肖世广深谙互联网产品的业务架构设计之道。在他看来，互联网产品的业务架构设计特点在于业务架构设计往往伴随着技术架构的设计，业务和技术相辅相成，互为反馈回路。

大体上，互联网产品的业务架构设计具有六大特点：

1. 快速迭代：互联网产品的增长是爆炸式增长，快速迭代、快速试错、快速改变策略适应用户需求。
2. 海量用户带来的高并发和大存储：互联网用户基数大，海量的用户访问带来大量的并发与用户数据存储。
3. 支持高效的弹性伸缩：互联网产品的平均生命周期相对较短，用户数在短期内可能会暴增也可能会暴跌，这要求架构设计时可能做到高效的弹性伸缩，应对不可预期的用户行为。
4. 跨区域甚至跨国数据中心：互联网是无国界的，互联网产品的用户可能来自世界各地，为用户提供就近访问的同时，也需要具备异地容灾的能力。
5. 从客户端、业务端、服务端到 IaaS 和 PaaS 的全方位监控能力：互联网产品的流量经过的链路较长，这对产品的质量监控提出更高要求，多端监控数据与基础环境监控数据相互关联、相互佐证数据的准确性，提高监控的准确率。
6. 业务安全设计：互联网是开放的，同时也是高风险的，用户的数据、行为泄露都可能会给业务与用户带来巨大损失。

对业务架构设计的思考

从技术转到业务领域，这让肖世广对技术和业务的认识更加清晰和全面。他认为，技术角色和业务角色的差别主要体现在所需的知识结构和思维模型方面。在知识结构方面，技术倾向于垂直，而业务倾向于水平。业务的目标是解决社会的某个问题或满足某个潜在需求，要想做好业务，就需要对社会有足够的理解，因此要有足够的人文素养，这也是业务角色所需的知识结构倾向于水平的原因。

在思维模型方面，业务角色所需要的思维模型比技术角色更加多元，因为业务角色面对的是社会，而社会是一个复杂系统。

长期的技术工作塑造了肖世广系统论视角和缜密的逻辑思维能力。“我认为，这些是一个人核心底层思维能力的一部分，它能让我们快速看清事物本质。从个人经历而言，一旦具备这些思维能力后，学习新东西非常快，原因在于具备这些底层核心思维能力后，事物往往可以触类旁通。”他说。

关于业务架构设计，他提出了自己的想法：

一，要从用户体验的角度思考，无论是产品设计还是架构设计，最终目的都是为了让用户有更好的体验，所以在设计时要多思考这个设计对用户的影响是什么，影响面有多大。

二，从业务价值的角度思考。技术与业务相辅相成，但思维不被技术约束，要思考如何让业务的价值得到充分体现。

三，从商业价值的角度思考。商业价值不仅仅在于创造了什么，同时也可以是优化或节约了什么。

四，从面向未来的角度思考。技术发展是无止境的，未来的趋势在哪里？当前的现状与未来还有哪些差距？到达未来的关键路径是什么？

作为“从技术到业务的思维转变“专题出品人，肖世广将在9月11-12日的ArchSummit全球架构师峰会（深圳站）联合更多高综合能力的技术人，分享如何从最熟悉的开发跨越到陌生的业务/产品，一起来听听“因技术而入门，因产品而出门”的心态、意识、和思维的转变经验吧！