架构设计案例

原文 杨波 InfoQ https://mp.weixin.qq.com/s/FsZUYnfEnDZ0dAsJ3hcA5Q

小型系统案例：分布式消息系统

这个是一个真实生产化的消息系统案例，由 1 个架构师 +2 个高级工程师设计开发，第一期研发测试到上生产约 3 个月，目前该系统日处理消息量过亿。

假定公司因为业务需要，要构建一套分布式消息系统 MQ，类似 Kafka 这样的，这个问题看起来很大很复杂，但是如果你抽丝剥茧，透过现象看本质，Kafka 这样的消息系统本质上是下图这样的抽象概念：

队列其实就是类似数组一样的结构（用数组建模有个好处，有索引可以重复消费），里头存放消息 (Msg)，数组一头进消息，一头出消息；

左边是若干生产者 (Producer)，往队列里头发消息；

右边是若干消费者 (Consumer)，从队列里头消费消息；

对于生产者和消费者来说，他们不关心队列实现细节，所以给队列一个更抽象的名字，叫主题 (Topic)；

考虑到系统的扩容和分布式能力，一般一个主题由若干个队列组成，这些队列也叫分区 (Partition)，而且这些队列可能还是分布在不同机器上的，例如下图中 Topic A 的两个队列分布在 DataNode1 节点上，另外两个队列分布在 DataNode2 节点上，这样以后 Topic 可以按需扩容，DataNode 也可以按需增加。当然这些细节由 MQ 系统屏蔽，用户只关心主题，不关心底层实现。

单个数组队列的建模是整个 MQ 系统的关键，我们知道 Kafka 使用 append only file 建模队列，存取速度快。假设我们要存业务数据需要更高可靠性，也可以用数据库表来建模数组队列，如下图所示：

一个队列 (或者一个分区) 对应一张数据库表，表中的一个记录就是一条消息，表采用自增 id，相当于数组索引。这张表是 insert only 的，且 MySQL 会自动对自增 id 建优化索引，没有其它索引，所以插入和按 id 查找速度都非常快。

下面是总体元数据模型：

一个主题 Topic 对应若干个队列 Queue

一个数据节点 DataNode 上可以住若干个队列 Queue

消费者 Consumer 和队列 Queue 之间是多对多关系，通过消费者偏移 Consumer Offset 进行关联

一个消费者组 Consumer Group 里头有若干个消费者 Consumer，它们共同消费同一个主题 Topic

至此，我们对 MQ 的抽象建模工作完成，下面的工作是将这个模型映射到具体实现，经过分解，整个系统由若干个子模块组成，每个子模块实现后拼装起来的 MQ 总体架构如下图所示：

Admin 模块管理数据库节点，生产者，消费者 (组)，主题，队列，消费偏移等元数据信息。

Broker 模块定期从 Admin 数据库同步元数据，接受生产者消息，按路由规则将消息存入对应的数据库表 (队列) 中；同时接受消费者请求，根据元数据从对应数据库表读取消息并发回消费者端。Broker 模块也接受消费者定期提交消费偏移。

Producer 接受应用发送消息请求，将消息发送到 Broker；

Consumer 从 Broker 拉取消息，供上层应用进一步消费；

客户端和 Broker 之间走 Thrift over HTTP 协议，中间通过域名走 Nginx 代理转发；

这个设计 Broker 是无状态，易于扩展。

中型系统案例：容器云平台架构设计

这个也是一个实际研发中的案例。

目前不少技术组织在往 DevOps（研发运维一体化）研发模式转型，目标是支持业务持续创新和规模化发展。支持 DevOps 的关键是需要一套 DevOps 基础平台，这个平台可以基于容器云构建，我们把它称为容器云平台。这个问题很大很复杂，我基于近年在一线互联网的实战经验积累 + 广泛调研，设计了如下容器云平台的总体抽象架构：

核心模块：

集群资源调度平台：屏蔽容器细节，将整个集群抽象成容器资源池，支持按需申请和释放容器资源，物理机发生故障时能够实现自动故障转移 (fail over)。目前基于 Mesos 实现，将来可考虑替换为 K8S。

镜像治理中心：基于 Docker Registry，封装一些轻量的治理功能，例如权限控制，审计，镜像升级流程（从测试到 UAT 到生产）治理和监控等。

租户资源治理中心：类似 CMDB 概念，在容器云环境中，企业仍然需要对应用 app，组织 org，容器配额 quota 等相关信息进行轻量级的治理。

发布控制台：面向用户的发布管理平台，支持发布流程编排。它和其它子系统对接交互，实现基本的应用发布能力，也实现如蓝绿，金丝雀和灰度等高级发布机制。

服务注册中心：类似 Netflix Eureka，支持服务的注册和发现，流量的拉入拉出操作。

网关：类似 Netflix Zuul 网关，接入外部流量并路由转发到内部的微服务，同时实现安全，限流熔断，监控等跨横切面功能。

核心流程：

用户或者 CI 系统对应用进行集成后生成镜像，将镜像推到镜像治理中心；

用户在资产治理中心申请发布，填报应用、发布和配额等相关信息，然后等待审批通过；

发布审批通过，开发人员通过发布控制台发布应用；

发布控制台通过查询资产治理中心获取发布规格信息；

发布控制台向容器资源调度平台发出启动容器实例指令；

容器资源调度平台从镜像治理中心拉取镜像并启动容器；

容器内服务启动后自注册到服务注册中心，并保持定期心跳；

用户通过发布控制台调用服务注册中心接口进行流量调拨，实现蓝绿，金丝雀或灰度发布等机制；

网关和内部微服务客户端定期同步服务注册中心上的路由表，将流量按负载均衡策略分发到服务实例上。

大型系统案例：微服务基础架构

服务认证授权中心 Spring Security OAuth2

服务配置中心 Apollo

服务调用链监控 CAT

服务网关 Zuul

服务限流熔断 Hystrix/Turbine

服务注册发现和软路由 Eureka/Ribbon

服务时间序列监控 KairosDB

服务监控告警 ZMon

整体拼装起来的微服务基础架构如下图所示，这个架构是经过实践落地的，可以作为一线企业搭建微服务基础架构的参考：

技术体系架构案例

分为清晰的四个抽象层次：

Infrastructure： 底层基础设施，包括云计算，数据中心，计算 / 网络 / 存储，各种工具和监控等，国内公司一般把这一层称为运维层。

Platform Services： 平台服务层，主要是一些框架中间件服务，包括应用和服务框架，数据访问层，表示层，消息系统，任务调度和开发者工具等等，国内公司一般把这一层称为基础框架或基础架构层。

Commerce Services： 电商服务层，eBay 作为电子商务平台多年沉淀下来的核心领域服务，相当于微服务业务层，包括登录认证，分类搜索，购物车，送货和客服等等。

Applications： 应用层，也称用户体验 + 渠道层，包括 eBay 主站，移动端 app，第三方接入渠道等。

我本人在吸收了 eBay 技术体系架构的基础上，也吸收了一些阿里巴巴中台战略的思想，同时融合近年的一些业界趋势（比如大数据 /AI），抽象出一个更通用的分层技术体系架构，可以作为互联网公司技术体系架构的一般性参考，如下图所示：

顺便提一下，近年阿里提出的所谓大中台，小前台战略，其实就要强化技术中台 + 业务中台，中台做大做强了，业务前台才可以更轻更灵活的响应业务需求的变化。