四个架构设计案例及其思维方式

Four Architecutre and Design Use Cases

Posted by     "杨波" on Friday, July 6, 2018

TOC

一、介绍

架构的本质是管理复杂性,抽象、分层、分治和演化思维是我们工程师/架构师应对和管理复杂性的四种最基本武器。

在上一篇架构之道~四种核心架构思维中,我先介绍了抽象分层分治演化这四种应对复杂性的基本武器。在本篇《架构之道~四个架构设计案例及其思维方式》中,我会通过四个案例,讲解如何综合运用这些武器,分别对小型系统,中型系统,基础架构,甚至是组织技术体系进行架构和设计。

二、小型系统案例~分布式消息系统

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

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

mq abstraction

  1. 队列其实就是类似数组一样的结构(用数组建模有个好处,有索引可以重复消费),里头存放消息(Msg),数组一头进消息,一头出消息,
  2. 左边是若干生产者(Producer),往队列里头发消息,
  3. 右边是若干消费者(Consumer),从队列里头消费消息,
  4. 对于生产者和消费者来说,他们不关心队列实现细节,所以给队列一个更抽象的名字,叫主题(Topic)。
  5. 考虑到系统的扩容和分布式能力,一般一个主题由若干个队列组成,这些队列也叫分区(Partition),而且这些队列可能还是分布在不同机器上的,例如下图中Topic A的两个队列分布在DataNode1节点上,另外两个队列分布在DataNode2节点上,这样以后Topic可以按需扩容,DataNode也可以按需增加。当然这些细节由MQ系统屏蔽,用户只关心主题,不关心底层实现。

store abstraction

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

mysql table modeling

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

下面是总体领域模型设计:

domain model

  1. 一个主题Topic对应若干个队列Queue
  2. 一个数据节点DataNode上可以住若干个队列Queue
  3. 消费者Consumer和队列Queue之间是多对多关系,通过消费者偏移Consumer Offset进行关联
  4. 一个消费者组Consumer Group里头有若干个消费者Consumer,它们共同消费同一个主题Topic

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

mq arch

  1. Admin模块管理数据库节点,生产者,消费者(组),主题,队列,消费偏移等元数据信息。
  2. Broker模块定期从Admin数据库同步元数据,接受生产者消息,按路由规则将消息存入对应的数据库表(队列)中;同时接受消费者请求,根据元数据从对应数据库表读取消息并发回消费者端。Broker模块也接受消费者定期提交消费偏移。
  3. Producer接受应用发送消息请求,将消息发送到Broker,
  4. Consumer从Broker拉取消息,供上层应用进一步消费,
  5. 客户端和Broker之间走Thrift over HTTP协议,中间通过域名走Nginx代理转发,
  6. 这个设计Broker是无状态,易于扩展。

架构思维总结

整个架构设计的思路体现了先总体抽象,再分解按模块抽象并实现,最后组合成完整的MQ系统,也就是抽象+分治。这个MQ的实现工作量并不大,属于小型系统范畴,初期设计和开发由1个架构师+2个中高级工程师可以搞定。

在初期研发和上生产之后,根据用户的不断反馈,系统设计经过多次优化和调整,符合三分架构,七分演化的演化式架构理念。目前该系统已经进入V2版本的架构和研发,其架构仍在持续演化当中,用户需求的多样性和对系统灵活性的更高要求,是系统架构演化的主要推动力。

三、中型系统案例~容器云平台架构设计

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

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

docker cloud arch

核心模块:

  1. 集群资源调度平台:屏蔽容器细节,将整个集群抽象成容器资源池,支持按需申请和释放容器资源,物理机发生故障时能够实现自动故障转移(fail over)。目前基于Mesos实现,将来可考虑替换为K8S。
  2. 镜像治理中心:基于Docker Registry,封装一些轻量的治理功能,例如权限控制,审计,镜像升级流程(从测试到UAT到生产)治理和监控等。
  3. 租户资源治理中心:类似CMDB概念,在容器云环境中,企业仍然需要对应用app,组织org,容器配额quota等相关信息进行轻量级的治理。
  4. 发布控制台:面向用户的发布管理平台,支持发布流程编排。它和其它子系统对接交互,实现基本的应用发布能力,也实现如蓝绿,金丝雀和灰度等高级发布机制。
  5. 服务注册中心:类似Netflix Eureka,支持服务的注册和发现,流量的拉入拉出操作。
  6. 网关:类似Netflix Zuul网关,接入外部流量并路由转发到内部的微服务,同时实现安全,限流熔断,监控等跨横切面功能。
  7. 认证中心:上图未显示,基于OAuth2的授权认证中心,对容器云中各个组件的访问进行集中式授权和认证。

核心流程: 1. 用户或者CI系统对应用进行集成后生成镜像,将镜像推到镜像治理中心, 2. 用户在资产治理中心申请发布,填报应用、发布和配额等相关信息,然后等待审批通过, 3. 发布审批通过,开发人员通过发布控制台发布应用, 4. 发布控制台通过查询资产治理中心获取发布规格信息, 5. 发布控制台向容器资源调度平台发出启动容器实例指令, 6. 容器资源调度平台从镜像治理中心拉取镜像并启动容器, 7. 容器内服务启动后自注册到服务注册中心,并保持定期心跳, 8. 用户通过发布控制台调用服务注册中心接口进行流量调拨,实现蓝绿,金丝雀或灰度发布等机制, 9. 网关和内部微服务客户端定期同步服务注册中心上的路由表,将流量按负载均衡策略分发到服务实例上。

架构思维总结

经过抽象梳理,我们已经得到最终容器云平台的6大关键抽象模块和模块间交互流程,下一步就是围绕这6大核心模块组织6个小的研发团队,每个团队负责一个模块的设计和实现,待每个团队完成各自的模块,再将所有模块组合拼装起来,就能最终产出我们需要的容器云平台产品。整体架构设计思路还是抽象+分治,只不过每个模块的抽象粒度更大,整个平台的规模也更大,需要投入的研发团队资源也更多,对架构师的抽象能力要求也更高。每个模块的技术负责人在研发各自的模块时,同样遵循抽象+分治的思维方式,先做抽象架构,划分子模块,安排组员实现子模块,最后拼装组合成完整模块。

由于这个平台规模较大较复杂,目前已经投入了近两个季度的时间,做第一期架构设计和研发,目前还没有完全生产化。在第一期过程中,随着对问题域的理解不断深入,架构设计经过多次调整,目前架构趋于稳定,已经进入预上线期。在后续生产落地过程中,仍然需要根据用户的反馈,借助进化的力量不断地调整和优化架构。这个符合演化式架构的思路。

四、大型系统案例~微服务基础架构

微服务架构是近年很多企业技术架构转型的趋势,实际上,微服务架构可以抽象分解为一个两层架构:上层是微服务业务架构,下层是微服务基础架构。上层业务架构由于每个企业的业务场景各不相同,所以一般很难通用化,大多企业都是定制自研。而下层基础架构由于近年业界实践的不断沉淀,已经比较通用化和模块化,其中的核心模块一般不需要自己重造轮子,重用那些在一线互联网公司已经落地并开源出来的产品就可以了。

Netflix是一家伟大的科技公司,它内部的基础架构团队很牛逼,或者说抽象能力非常强,把一些核心微服务基础组件都以模块化方式开源出来了,使得其它公司只需组合拼装这些组件就可以快速搭建微服务架构,可以说Netflix将整个行业的技术水平提升了一个层次。

波波老师近期和极客时间合作,开设了一门叫《微服务架构实战160讲》的视频课程,这门课程基于我近年在一线互联网公司(携程和拍拍贷)落地微服务基础架构的实战经验和总结。该课程为大家深度剖析微服务8大核心模块的架构和实践,以及如何使用这些模块,采用抽象+分治的架构思维,像搭积木一样轻松构建微服务基础架构,敬请大家关注。

波波的《微服务架构实战160讲》中涉及的8大模块包括

  • 服务认证授权中心Spring Security OAuth2
  • 服务配置中心Apollo
  • 服务调用链监控CAT
  • 服务网关Zuul
  • 服务限流熔断Hystrix/Turbine
  • 服务注册发现和软路由Eureka/Ribbon
  • 服务时间序列监控KairosDB
  • 服务监控告警ZMon

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

msa_building_blocks

五、技术体系架构案例

在企业的整个技术体系架构层面,最基本的思考方式还是抽象+分治,只不过问题域更大更复杂,还涉及到组织和业务架构,所以一般还要增加分层的维度来解决,下图是2016年的eBay技术体系架构[图片来自附录1]:

ebay arch 2016

我最早看到这个架构图是在2008年左右的一次all hands meeting上(当时我还在eBay中国研发中心做工程师),也就是说大致在2008年左右,eBay就已经有比较清晰的,以分层方式组织的技术体系架构。eBay当时把它的系统称为电子商务操作系统,因为据说整个系统的代码量超过Windows 7操作系统的代码量。

eBay架构分为清晰的四个抽象层次:

  • Infrastructure:底层基础设施,包括云计算,数据中心,计算/网络/存储,各种工具和监控等,国内公司一般把这一层称为运维层。
  • Platform Services:平台服务层,主要是一些框架中间件服务,包括应用和服务框架,数据访问层,表示层,消息系统,任务调度和开发者工具等等,国内公司一般把这一层称为基础框架或基础架构层。
  • Commerce Services:电商服务层,eBay作为电子商务平台多年沉淀下来的核心领域服务,相当于微服务业务层,包括登录认证,分类搜索,购物车,送货和客服等等。
  • Applications:应用层,也称用户体验+渠道层,包括eBay主站,移动端app,第三方接入渠道等。

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

platform arch

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

六、结论

  1. 架构的本质是管理复杂性,抽象、分层、分治和演化思维是架构师征服复杂性的四种根本性武器
  2. 掌握了、分层、分治和演化这四种基本的武器,你可以设计小到一个类,一个模块,一个子系统,或者一个中型的系统,也可以大到一个公司的基础平台架构,微服务架构,技术体系架构,甚至是组织架构,业务架构等等。
  3. 架构设计不是静态的,而是动态演化的。只有能够不断应对环境变化的系统,才是有生命力的系统。所以即使你掌握了抽象、分层和分治这三种基本思维,仍然需要演化式思维,在完成系统的初步架构设计之后,后续借助反馈和进化的力量推动架构的持续演进。
  4. 架构师在关注技术,开发应用的同时,需要定期梳理自己的架构设计思维,积累时间长了,你看待世界事物的方式会发生根本性变化,你会发现我们生活其中的世界,其实也是在抽象、分层、分治和演化的基础上构建起来的。另外架构设计思维的形成,会对你的系统架构设计能力产生重大影响。可以说对抽象、分层、分治和演化掌握的深度和灵活应用的水平,直接决定架构师所能解决问题域的复杂性和规模大小,是区分普通应用型架构师和平台型/系统型架构师的一个分水岭。

七、参考

  1. MicroServices at eBay

comments powered by Disqus