四个架构设计案例及其思维⽅式
⼀、介绍
架构的本质是管理复杂性，抽象、分层、分治和演化思维是我们⼯程师/架构师应对和管理复杂性的四种最基本武器。
在上⼀篇中，我先介绍了抽象、分层、分治和演化这四种应对复杂性的基本武器。在本篇《架构之道~四个架构设计案例及其思维⽅式》中，我会通过四个案例，讲解如何综合运⽤这些武器，分别对⼩型系统，中型系统，基础架构，甚⾄是组织技术体系进⾏架构和设计。
⼆、⼩型系统案例~分布式消息系统
这个是⼀个真实⽣产化的消息系统案例，由1个架构师+2个⾼级⼯程师设计开发，第⼀期研发测试到上⽣产约3个⽉，⽬前该系统⽇处理消息量过亿。
假定公司因为业务需要，要构建⼀套分布式消息系统MQ，类似Kafka这样的，这个问题看起来很⼤很复杂，但是如果你抽丝剥茧，透过现象看本质，kafka这样的消息系统本质上是下图这样的抽象概念：
1. 队列其实就是类似数组⼀样的结构（⽤数组建模有个好处，有索引可以重复消费），⾥头存放消息(Msg)，数组⼀头进消息，⼀头出
消息，
2. 左边是若⼲⽣产者(Producer)，往队列⾥头发消息，
3. 右边是若⼲消费者(Consumer)，从队列⾥头消费消息，
4. 对于⽣产者和消费者来说，他们不关⼼队列实现细节，所以给队列⼀个更抽象的名字，叫主题(Topic)。
5. 考虑到系统的扩容和分布式能⼒，⼀般⼀个主题由若⼲个队列组成，这些队列也叫分区(Partition)，⽽且这些队列可能还是分布在不
同机器上的，例如下图中Topic A的两个队列分布在DataNode1节点上，另外两个队列分布在DataNode2节点上，这样以后Topic可以按需扩容，DataNode也可以按需增加。当然这些细节由MQ系统屏蔽，⽤户只关⼼主题，不关⼼底层实现。
单个数组队列的建模是整个MQ系统的关键，我们知道Kafka使⽤append only file建模队列，存取速度快。假设我们要存业务数据需要更⾼可靠性，也可以⽤数据库表来建模数组队列，如下图所⽰：
⼀个队列(或者⼀个分区)对应⼀张数据库表，表中的⼀个记录就是⼀条消息，表采⽤⾃增id，相当于数
组索引。这张表是insert only的，且MySql会⾃动对⾃增id建优化索引，没有其它索引，所以插⼊和按id查速度都⾮常快。
下⾯是总体领域模型设计：
1. ⼀个主题Topic对应若⼲个队列Queue
2. ⼀个数据节点DataNode上可以住若⼲个队列Queue
3. 消费者Consumer和队列Queue之间是多对多关系，通过消费者偏移Consumer Offset进⾏关联
4. ⼀个消费者组Consumer Group⾥头有若⼲个消费者Consumer，它们共同消费同⼀个主题Topic
⾄此，我们对MQ的抽象建模⼯作完成，下⾯的⼯作是将这个模型映射到具体实现，经过分解，整个系统由若⼲个⼦模块组成，每个⼦模块实现后拼装起来的MQ总体架构如下图所⽰：
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基础平台，这个平台可以基于容器云构建，我们把它称为容器云平台。这个问题很⼤很复杂，我基于近年在⼀线互联⽹的实战经验积累+⼴泛调研，设计了如下容器云平台的总体抽象架构：
核⼼模块：
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将整个⾏业的技术⽔平提升了⼀个层次。
波波⽼师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），抽象出⼀个更通⽤的分层技术体系架构，可以作为互联⽹公司技术体系架构的⼀般性参考，如下图所⽰：
顺便提⼀下，近年阿⾥提出的所谓⼤中台，⼩前台战略，其实就要强化技术中台+业务中台，中台做⼤做强了，业务前台才可以更轻更灵活的响应业务需求的变化。
六、结论
1. 架构的本质是管理复杂性，抽象、分层、分治和演化思维是架构师征服复杂性的四种根本性武器
2. 掌握了、分层、分治和演化这四种基本的武器，你可以设计⼩到⼀个类，⼀个模块，⼀个⼦系统，或者⼀个中型的系统，也可以⼤到
⼀个公司的基础平台架构，微服务架构，技术体系架构，甚⾄是组织架构，业务架构等等。
3. 架构设计不是静态的，⽽是动态演化的。只有能够不断应对环境变化的系统，才是有⽣命⼒的系统。所以即使你掌握了抽象、分层和
分治这三种基本思维，仍然需要演化式思维，在完成系统的初步架构设计之后，后续借助反馈和进化的⼒量推动架构的持续演进。4. 架构师在关注技术，开发应⽤的同时，需要定期梳理⾃⼰的架构设计思维，积累时间长了，你看待世界事物的⽅式会发⽣根本性变
化，你会发现我们⽣活其中的世界，其实也是在抽象、分层、分治和演化的基础上构建起来的。另外架构设计思维的形成，会对你的系统架构设计能⼒产⽣重⼤影响。可以说对抽象、分层、分治和演化掌握的深度和灵活应⽤的⽔平，直接决定架构师所能解决问题域的复杂性和规模⼤⼩，是区分普通应⽤型架构师和平台型/系统型架构师的⼀个分⽔岭。
七、参考
1.

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。