一、介绍
架构的本质是管理复杂性，抽象、分层、分治和演化思维是我们工程师/架构师应对和管理复杂性的四种最基本武器。
在上一篇架构之道~四种核心架构思维中，我先介绍了抽象、分层、分治和演化这四种应对复杂性的基本武器。在本篇《架构之道~四个架构设计案例及其思维方式》中，我会通过四个案例，讲解如何综合运用这些武器，分别对小型系统，中型系统，基础架构，甚至是组织技术体系进行架构和设计。
二、小型系统案例~分布式消息系统
这个是一个真实生产化的消息系统案例，由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是无状态，易于扩展。
架构思维总结
整个架构设计的思路体现了先总体抽象，再分解按模块抽象并实现，最后组合成完整的MQ系统，也就是抽象+分治。这个MQ的实现工作量并不大，属于小型系统范畴，初期设计和开发由1个架构师+2个中高级工程师可以搞定。
在初期研发和上生产之后，根据用户的不断反馈，系统设计经过多次优化和调整，符合三分架构，七分演化的演化式架构理念。目前该系统已经进入V2版本的架构和研发，其架构仍在持续演化当中，用户需求的多样性和对系统灵活性的更高要求，是系统架构演化的主要推动力。
三、中型系统案例~容器云平台架构设计
这个也是一个实际研发中的案例。
目前不少技术组织在往DevOps（研发运维一体化）研发模式转型，目标是支持业务持续创新和规模化发展。支持DevOps的关键是需要一套DevOps基础平台，这个平台可以基于容器云构建，我们把它称为容器云平台。这个问题很大很复杂，我基于近年在一线互联网的实战经验积累+广泛调研，设计了如下容器云平台的总体抽象架构：
核心模块：
- 集群资源调度平台：屏蔽容器细节，将整个集群抽象成容器资源池，支持按需申请和释放容器资源，物理机发生故障时能够实现自动故障转移(fail over)。目前基于Mesos实现，将来可考虑替换为K8S。
- 镜像治理中心：基于Docker Registry，封装一些轻量的治理功能，例如权限控制，审计，镜像升级流程（从测试到UAT到生产）治理和监控等。
- 租户资源治理中心：类似CMDB概念，在容器云环境中，企业仍然需要对应用app，组织org，容器配额quota等相关信息进行轻量级的治理。
- 发布控制台：面向用户的发布管理平台，支持发布流程编排。它和其它子系统对接交互，实现基本的应用发布能力，也实现如蓝绿，金丝雀和灰度等高级发布机制。
- 服务注册中心：类似Netflix Eureka，支持服务的注册和发现，流量的拉入拉出操作。
- 网关：类似Netflix Zuul网关，接入外部流量并路由转发到内部的微服务，同时实现安全，限流熔断，监控等跨横切面功能。
- 认证中心：上图未显示，基于OAuth2的授权认证中心，对容器云中各个组件的访问进行集中式授权和认证。
核心流程：
- 用户或者CI系统对应用进行集成后生成镜像，将镜像推到镜像治理中心，
- 用户在资产治理中心申请发布，填报应用、发布和配额等相关信息，然后等待审批通过，
- 发布审批通过，开发人员通过发布控制台发布应用，
- 发布控制台通过查询资产治理中心获取发布规格信息，
- 发布控制台向容器资源调度平台发出启动容器实例指令，
- 容器资源调度平台从镜像治理中心拉取镜像并启动容器，
- 容器内服务启动后自注册到服务注册中心，并保持定期心跳，
- 用户通过发布控制台调用服务注册中心接口进行流量调拨，实现蓝绿，金丝雀或灰度发布等机制，
- 网关和内部微服务客户端定期同步服务注册中心上的路由表，将流量按负载均衡策略分发到服务实例上。
架构思维总结
经过抽象梳理，我们已经得到最终容器云平台的6大关键抽象模块和模块间交互流程，下一步就是围绕这6大核心模块组织6个小的研发团队，每个团队负责一个模块的设计和实现，待每个团队完成各自的模块，再将所有模块组合拼装起来，就能最终产出我们需要的容器云平台产品。整体架构设计思路还是抽象+分治，只不过每个模块的抽象粒度更大，整个平台的规模也更大，需要投入的研发团队资源也更多，对架构师的抽象能力要求也更高。每个模块的技术负责人在研发各自的模块时，同样遵循抽象+分治的思维方式，先做抽象架构，划分子模块，安排组员实现子模块，最后拼装组合成完整模块。
由于这个平台规模较大较复杂，目前已经投入了近两个季度的时间，做第一期架构设计和研发，目前还没有完全生产化。在第一期过程中，随着对问题域的理解不断深入，架构设计经过多次调整，目前架构趋于稳定，已经进入预上线期。在后续生产落地过程中，仍然需要根据用户的反馈，借助进化的力量不断地调整和优化架构。这个符合演化式架构的思路。
四、大型系统案例~微服务基础架构
微服务架构是近年很多企业技术架构转型的趋势，实际上，微服务架构可以抽象分解为一个两层架构：上层是微服务业务架构，下层是微服务基础架构。上层业务架构由于每个企业的业务场景各不相同，所以一般很难通用化，大多企业都是定制自研。而下层基础架构由于近年业界实践的不断沉淀，已经比较通用化和模块化，其中的核心模块一般不需要自己重造轮子，重用那些在一线互联网公司已经落地并开源出来的产品就可以了。
Netflix是一家伟大的科技公司，它内部的基础架构团队很牛逼，或者说抽象能力非常强，把一些核心微服务基础组件都以模块化方式开源出来了，使得其它公司只需组合拼装这些组件就可以快速搭建微服务架构，可以说Netflix将整个行业的技术水平提升了一个层次。
波波老师2018年和极客时间合作，开设了一门叫《微服务架构实战160讲》的视频课程，这门课程基于我近年在一线互联网公司（携程和拍拍贷）落地微服务基础架构的实战经验和总结。该课程为大家深度剖析微服务8大核心模块的架构和实践，以及如何使用这些模块，采用抽象+分治的架构思维，像搭积木一样轻松构建微服务基础架构，敬请大家关注。
波波的《微服务架构实战160讲》中涉及的8大模块包括
- 服务认证授权中心Spring Security OAuth2
- 服务配置中心Apollo
- 服务调用链监控CAT
- 服务网关Zuul
- 服务限流熔断Hystrix/Turbine
- 服务注册发现和软路由Eureka/Ribbon
- 服务时间序列监控KairosDB
- 服务监控告警ZMon
整体拼装起来的微服务基础架构如下图所示，这个架构是经过实践落地的，可以作为一线企业搭建微服务基础架构的参考：
五、技术体系架构案例
在企业的整个技术体系架构层面，最基本的思考方式还是抽象+分治，只不过问题域更大更复杂，还涉及到组织和业务架构，所以一般还要增加分层的维度来解决，下图是2016年的eBay技术体系架构[图片来自附录1]：
我最早看到这个架构图是在2008年左右的一次all hands meeting上（当时我还在eBay中国研发中心做工程师），也就是说大致在2008年左右，eBay就已经有比较清晰的，以分层方式组织的技术体系架构。eBay当时把它的系统称为电子商务操作系统，因为据说整个系统的代码量超过Windows 7操作系统的代码量。
eBay架构分为清晰的四个抽象层次：
- Infrastructure：底层基础设施，包括云计算，数据中心，计算/网络/存储，各种工具和监控等，国内公司一般把这一层称为运维层。
- Platform Services：平台服务层，主要是一些框架中间件服务，包括应用和服务框架，数据访问层，表示层，消息系统，任务调度和开发者工具等等，国内公司一般把这一层称为基础框架或基础架构层。
- Commerce Services：电商服务层，eBay作为电子商务平台多年沉淀下来的核心领域服务，相当于微服务业务层，包括登录认证，分类搜索，购物车，送货和客服等等。
- Applications：应用层，也称用户体验+渠道层，包括eBay主站，移动端app，第三方接入渠道等。
我本人在吸收了eBay技术体系架构的基础上，也吸收了一些阿里巴巴中台战略的思想，同时融合近年的一些业界趋势（比如大数据/AI），抽象出一个更通用的分层技术体系架构，可以作为互联网公司技术体系架构的一般性参考，如下图所示：
顺便提一下，近年阿里提出的所谓大中台，小前台战略，其实就要强化技术中台+业务中台，中台做大做强了，业务前台才可以更轻更灵活的响应业务需求的变化。
六、结论
- 架构的本质是管理复杂性，抽象、分层、分治和演化思维是架构师征服复杂性的四种根本性武器
- 掌握了、分层、分治和演化这四种基本的武器，你可以设计小到一个类，一个模块，一个子系统，或者一个中型的系统，也可以大到一个公司的基础平台架构，微服务架构，技术体系架构，甚至是组织架构，业务架构等等。
- 架构设计不是静态的，而是动态演化的。只有能够不断应对环境变化的系统，才是有生命力的系统。所以即使你掌握了抽象、分层和分治这三种基本思维，仍然需要演化式思维，在完成系统的初步架构设计之后，后续借助反馈和进化的力量推动架构的持续演进。
- 架构师在关注技术，开发应用的同时，需要定期梳理自己的架构设计思维，积累时间长了，你看待世界事物的方式会发生根本性变化，你会发现我们生活其中的世界，其实也是在抽象、分层、分治和演化的基础上构建起来的。另外架构设计思维的形成，会对你的系统架构设计能力产生重大影响。可以说对抽象、分层、分治和演化掌握的深度和灵活应用的水平，直接决定架构师所能解决问题域的复杂性和规模大小，是区分普通应用型架构师和平台型/系统型架构师的一个分水岭。