ReaderMX.
高可用架构

腾讯专家10年沉淀：后海量时代的架构设计

高高可用架构约 12 分钟

01

 背景
腾讯面向内部开发者的海量服务之道系列课程颇具名气，它为司内外海量用户提供互联网服务的经验传承。无数开发者尤其是后台技术栈的开发者都获益于这些课程，从而成长起来。本篇我们将提炼这个核心课程精髓，供广泛开发者参考。
海量服务的核心是可用性，最终的目的是用高可用性来支撑海量用户的海量请求。无论是意识、方法论、价值观还是手段，都体现了对于某个方面的方式方法的高可用性追求。下述是海量服务之道的课程，同时这里也列出业界的三个最重要分布式理论：
Image
最近几年，大量互联网产品的体量也逐渐壮大。日活大几千万甚至上亿的产品不在少数，不一一列举。业界也涌现了非常多技术，如各种 rpc 框架、docker、云计算、微服务、Service Mesh、分布式存储、DevOps、NoSQL、大数据、各种计算框架等等。
正是因为这些技术的蓬勃发展，才支撑了越来越大量级的各种互联网服务公司。反过来说，从移动互联网发展起来之后，智能终端用户量的爆发，突破了 PC 时代的互联网服务的使用场景，互联网/移动互联网服务的用户规模也越来越大，加速了这些支撑大规模互联网服务公司的技术发展。总的来说，技术发展和实际应用从来都是相辅相成的。
到了移动互联网发展的后半场，海量技术已经成为了标配。在架构设计上，到底还能做什么或者要考虑什么，才能体现出一个架构的设计精良？这个问题值得思考。
个人理解的后海量时代的架构设计，更应该要考虑的是系统性和内部、外部之间的逻辑关系和复杂度。总结了以下几个方面（海量服务之道只是列举部分并非全部能力）：
Image
海量服务的架构都非常复杂，涉及 Android、iOS、H5 等各种端的展现和访问接入。后端也有接入层、业务逻辑层、基础层之分。有内存 Cache、分布式 Cache，NoSQL 和 RDBMS 关系型数据库，可能还有离线处理部分，有时为了解耦还会引入 MessageQueue、消息总线等。
不仅分层分级，还会有各种同构或者异构的子系统。这些子系统之间有相互依赖和复杂的调用关系。还会有很多第三方的依赖，有不同类型的接口定义和协议交互方式等等。
怎么去界定每个模块的功能定义？每一个模块和子系统怎么做到高内聚低耦合以及相互隔离？因此在海量基础的架构设计中，第一个要考虑的问题就是架构的边界。

02

架构的边界

架构边界要考虑的点如下：

  • 边界思维、边界意识，探索边界、扩张边界

  • 职责分离、防火隔离
  • 契约精神
  • 高内聚、低耦合、层次分明
举个例子：在开发一个 App，需要和后台通过 HTTP 来交互。那么首先要明确的有以下几个问题：

  • 协议通信的 layout 怎么定义？一般分包头和包体。

  • 终端和后台有几次交互，每次交互的请求和返回字段是什么？
  • 采用什么样的协议交互，JSON、JCE、ProtocolBuffers ？
  • 错误码怎么定义？是否有二级错误码？头部一个错误码，代表整体的错误和异常情况，比如登录过期等。而包体有错误码定义，标识当前请求的返回情况。
在项目中，终端和后台是通过 HTTP Post 来交互的，定义了 layout，JCE 来做为交互协议的具体格式，定义了如下 Jce 结构（为了简化，这里只示例请求包体）。注：JCE 是 TAF（腾讯内部使用多年的基于微服务的统一应用框架TAF，Total Application Framework，从2017年开源 ） 框架中客户端和服务端的通信协议，类似thrift和pb协议。
struct ReqHead {
            Int cmdId;
            ...
}
struct Request {
            ReqHead head;
            vector<char> body;
}
struct PkgReq {
            PkgReqHead head;
            Request request;
}
HTTP Body 分为 3 部分：
部分
解析
YYB(3bytes)

三个字节的 magic bytes，用于做标识终端和后台协议。

0x00000002

(版本,4bytes 网络字节序)

4 个字节网络字节序的版本号，用来区分不同协议定义版本，也偏于扩充每一次终端和后台的交互。

PkgReq
PkgReqHead

用 ReqHead.cmdId 来区分，body 对应具体的 Jce 结构。例如 Cmd1，定义了对应的 Request 和 Response 结构，结尾必须是 Request 和 Response，并且 Response 的第 0 个 tag 必须是 Int 类型，明确了 ret >= 0，为命令字成功，ret < 0 为失败，便于在接入层统一监控和统计。

Request

ReqHead

body
Struct Cmd1Request {
}
Struct Cmd1Response {
            Int ret;
}
所有的 Jce 定义全部在一个文件 Protocol.jce，新加的 Cmd 定义也全部在这个文件中。上传 svn/git，所有终端和后台开发，都要从唯一的地方去更新或者获取。Protocol.jce 有 4 个内容：定义 HTTP Body 的交互 Layout、 所有头部或者公共的 Jce 结构、 所有 Cmd 对应的 Request、Response 结构和所有的头部错误码定义和枚举定义。
至此，Protocol.jce 成为终端和后台有且仅有的唯一边界，并且按照约定的规范来更新，这成为大家共同遵守的契约。
后台服务支持到终端的 TCP 长连接，是更高效的 Request/Response 命令字符交互方式，用于替换 HTTP 形式的交互，同时也方便做后台到终端的 Server Push。而通过 HTTP 的命令字请求，只支持 Request/Response 的形式。Android 终端的 Google 官方消息推送方案  GCM（Google Cloud Message）无法在国内使用， 不像 iOS 系统，有统一的 APNS。国内厂商都有自己的消息推送通道，比如小米、华为、Oppo、Vivo、魅族等。
如果终端在线时，后台可以使用 TCP 长连接通道，直接向终端 Push 运营信息，就可以实时触达到终端设备。但是终端不在线时，就无法推送。为了更实时的让终端用户收到这些运营信息（例如最新的游戏资讯），就不得不连接终端手机厂商的消息推送通道。
有些第三方消息推送方案已经支持了上述能力，例如腾讯内的信鸽（腾讯的移动推送服务）等，但是长连接通道已经存在，也无需接入更多的第三方 SDK，若希望后台对消息通道提供更加可控和更加灵活的消息推送方式，需接入厂商消息通道。
涉及到后台到终端的消息推送的业务诉求，也比较多：

  • 能支持厂商通道，在终端设备不在线时也能收到消息推送（除非用户手动关闭消息接收提醒）。

  • 支持定时发送。

  • 支持对所有在线设备群发消息。

  • 需要对消息的接收能做确认，至少包含在线设备的网络层发送成功（通过已有的 TCP 长连接通道）、终端设备确认接收成功（终端收到推送消息时通过长连接通道发送 ACK 确认消息到后台）。

  • 发送失败的消息，能按照一定的策略重发。

  • 业务方要能查询发送消息的状态，并支持条件订阅。

  • Android 和 iOS 希望能有一套统一的消息推送方式，减少上层业务使用 PUSH系统的成本，并且屏蔽不同终端设备的差异。

从上述业务诉求看得出这是一套逻辑相对复杂的系统，处理也比较复杂，要考虑的因素会比较多。最重要的是要这套系统整合自有长连接通道。值得注意的是 Android 厂商消息通道、iOS APNS，而且 Android 厂商各家通道之间的通讯方式、接口和字段定义都是完全不同的，更不用提 APNS 和自有的长连接通道（自有长连接通道是给命令字设计的）。同时要考虑诸多复杂逻辑如：消息的存储、终端设备的在线状态、如果不在线则如何判断机型信息而选择对应的厂商通道、通过长连接通道的网络发送的成功与否、终端设备收到后的消息确认。如果是 iOS 用户，则要考虑 APNS 证书到期情况等问题。
除了对整个系统做架构设计和模块拆分之外，开发者还设计了一套通用的 PUSH API，采用 TAF+JCE 的标准 RPC 接口形式。这套接口完全屏蔽上述所有的复杂逻辑，只需按照一套统一的接口方式，提交推送消息就可以，并且业务层可以通过消息队列订阅推送消息发送状态（会预先定义好状态类型，比如待发发送、发送中、网络成功、收到确认等）。整体架构图如下所示：
Image
PushAPI.jce 成为整个 PUSH 子系统的对外唯一边界，非常清晰简单，并没有任何其他接口暴露给业务层。业务层也无需了解任何内部细节，更不用关心各个厂商通道的差异性，甚至无需关心所推送用户的设备是 Android 还是 iOS。接口定义如下：
interface PushAPI
{
//单设备推送
int pushSingleDevice(PushSingleDeviceReq req, out PushSingleDeviceRsp rsp);
//多设备推送
int pushMultiDevice(PushMultiDeviceReq req, out PushMultiDeviceRsp rsp);
//全量在线设备推送
int pushAllOnlineDevice(PushAllOnlineDeviceReq req, out PushAllOnlineDeviceRsp rsp);
 //全量设备推送
int pushAllDevice(PushAllDeviceReq req, out PushAllDeviceRsp rsp);
};
Push 子系统内部实现也体现了高内聚、低耦合的设计原则。业务层和 Push 子系统职责分离，同时 Push 子系统内部保证高可用和容错能力，业务层提交给 Push 子系统的消息推送任务，会持久化存储，不会因为用户终端设备状态异常或者内部处理异常而丢失，真正做到防火隔离。

03

架构的组织属性

系统架构和组织架构、团队分工有关。系统架构和组织架构关联后，当组织架构边界和系统架构边界重合时，要认真对待架构边界问题，同时对高内聚、低耦合的要求要更高。
有一段时间，后台逻辑需要依赖另一个团队提供的接口，后台全部模块都是 TAF 服务，对方是 L5（内部使用的名字服务，用来做服务注册和发现），也是公司内部的一种负载均衡解决方案，可以用 mod、cmd （是L5用来做名字服务的标识）两个值标识一个服务接口，使用 L5 提供的 C API 来从本机部署的 L5 Agent 里获取一个有效 IP、Port，进而进行消息发送。
但是完全无法做为一种接口调用方式，非常原始和复杂，基本上要调用一个L5 提供的接口，需要做如下步骤：

  • 在要调用 L5 的机器上部署 L5 Agent。

  • 在代码中通过 L5 的 API 获取要调用的 IP 和 port，所调用的服务接口由指定的 mod、cmd 两个参数来标识。

  • 组包，包括 PDU 结构的头部和包体。

  • 通过 tcp 连接发送。

可以看到这种接口调用方式暴露了太多细节给主调方，调用过程也比较复杂，有以下问题：

  • 每台主调机器需要部署 L5 Agent，这是 SNG 运维在维护，MIG 运维无法很好的支持。

  • 调用方代码重复很多。

  • 无法监控和统计成功率。

  • 边界很模糊，或者说边界很厚。

  • 查问题很麻烦，因为 L5 后端的接入层没有很完善的结果。

为此，开发者设计了一个转换层服务 PDUBridgeServer（一个协议适配后台模块），实现如下功能和收益：

  • 提供统一 taf 接口给所有需要调用 L5 接口的 taf 服务。

  • 只需要在 PDUBridgeServer 的机器上部署 L5 Agent。

  • PDUBridgeServer 中支持对所有 mod、cmd 所标识接口的监控和告警，会加上一个字符串描述来更直观的看监控统计数据。

监控统计效果如下：

Image

当时遇到一个问题，开发者监控到的某个 mod、cmd 接口的异常率高达 10+%，开发者看到的是 PDUBrige 到 L5 的异常率，而对方看的是 L5 到 B 之间的异常率，因为 L5 本身是有负载均衡策略，根据后端的负载情况会拒绝主调调用，导致 PDUBridge 到 L5 的异常率高，后面开发者通过修改 L5 的参数，异常率降低了很多。我们推测是 L5 的负载阈值比较高，具体是什么阈值不得而知。因为这些问题，非常影响效率和团队关系。

虽然加了一层调用，但是处理非常简单，只有 ms 级的耗时增加，将 PDUBridgeServer 做为两个组织的边界，通过监控来直观反应接口调用质量和流量统计，减少了部署成本，也方便 taf 主调服务去调用（直接通过 taf 接口而非 L5 原生接口去调用）。

由以上案例可以看出：架构边界和组织架构边界重合时，或者说在考虑系统架构时，要考虑组织的边界。例如要有简单明确的调用接口方式，做好监控和统计、告警，以及系统的整体反馈，大家的认识要一致，确定好统一的目标和衡量指标。例如异常率的定义、成功率等，不能不对等或者理解不一致。这样才能更好的交流和界定职责和边界，否则会带来很多团队协作问题。例如推诿、争端等，效率也会极其低下。

04

架构的反馈
架构的反馈是人从系统架构中直接或间接得到的信息，进而去优化和完善架构。包括但不限于健康度、运行状况、调用链、性能数据、业务运行数据、数据流、日统计、数据趋势等等。

众所周知，监控和告警是为了发现问题、定位问题以及更好地解决问题。但是整个系统只是监控、告警和统计，远远不足以反应整个架构的系统性运行状态。因此，将这些能反映架构运行状态的所有手段，统称为架构的反馈。既然是架构运行的反馈，必然对系统本身的优化和完善，也会有作用。

讲个亲身经历，我们在一次重构应用宝 App 搜索和内容搜索时，转辗了几个团队。由于用了开源的 ElasticSearch 解决方案，不能很好的和 TAF 的机制很好的结合，例如自动伸缩、负载均衡和容灾容错等，开发者成员做了不少工作来整合。同时为了更好的监控搜索系统的运行状况，和搜索业务的整体情况，例如 Query 分析、刷量等问题，也做了不少监控告警统计。其实这些工作，都是为了更好的反馈整个搜索系统。

Image

App 搜索因为各种利益（刷关键词、刷自己、刷对手等），经常会有刷关键词的情况存在。对后台来说，如何识别刷量请求、识别后如何处理、应对刷量带来的突发流量压力等，都成为要考虑的问题。一般的做法，识别到刷量请求后（比如明显的请求特征 GUID 聚集等）会拒绝请求。「堵不如疏」，在识别到刷量请求后，系统直接从 Cache 中正常返回搜索结果，不走后续复杂的 Query 分析、ES 搜索、召回、排序等耗时环节。这种做法会迷惑刷量用户，并且在后续的搜索结果曝光、点击、下载等一系列后续数据上报环节，都会带上后台识别出来的刷量标识（会保证刷量标识不会在终端被篡改），在后续数据处理环节也能识别并具备剔除刷量请求以保证上报数据不受影响。

基于 TAF 的 PP 监控（全称是Property Plus监控。允许用户通过自定义维度与自定义指标，上报特性， 它由维度名、指标值、以及对应的指标统计方法构成。），开发者做了一个 Query 监控，其能反应 Query 的请求量情况趋势和耗时对比。某个违禁词本身在后台已经被识别为刷量，并且从下图可以看出，请求量波动比较大、耗时非常低，正常都在 100 多ms，而这个 Query 的耗时是 2ms。

实际的情况，某个违禁词是刷量，波动非常大，在时间分布上也比较集中，因为识别为刷量，会命中 Cache，因此搜索耗时非常小。

Image

 大数据 A/B testing 算法对照监控图

常规意义上的监控和告警、统计，已经无法更好地反映系统整体的运行情况，需要更全面、系统化的方式来反映。同时，也能通过这些体系化的监控统计手段，来回馈架构，对架构的进一步演化提供依据。或者从另一个层面来讲，监控和统计被赋予了更多的意义。

参考阅读：


本文由高可用架构转载。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿

KEEP THE THREAD GOING

更多来源文章