写在前面
架构的本质是管理复杂性，抽象、分层、分治和演化思维 是我们工程师 / 架构师应对和管理复杂性的四种最基本武器。
在我之前写的文章 《优秀架构师必须掌握的架构思维》（点击标题查看原文） 中，我先介绍了抽象、分层、分治和演化这四种应对复杂性的基本武器。在本篇文章中，我会通过四个案例，讲解如何综合运用这些武器，分别对小型系统、中型系统、基础架构以及组织技术体系进行架构和设计。
小型系统案例：分布式消息系统这个是一个真实生产化的消息系统案例，由 1 个架构师 +2 个高级工程师设计开发，第一期研发测试到上生产约 3 个月，目前该系统日处理消息量过亿。
假定公司因为业务需要，要构建一套分布式消息系统 MQ，类似 Kafka 这样的，这个问题看起来很大很复杂，但是如果你抽丝剥茧，透过现象看本质，Kafka 这样的消息系统本质上是下图这样的抽象概念：
单个数组队列的建模是整个 MQ 系统的关键，我们知道 Kafka 使用 append only file 建模队列，存取速度快。假设我们要存业务数据需要更高可靠性，也可以用数据库表来建模数组队列，如下图所示：
一个队列 (或者一个分区) 对应一张数据库表，表中的一个记录就是一条消息，表采用自增 id，相当于数组索引。这张表是 insert only 的，且 MySQL 会自动对自增 id 建优化索引，没有其它索引，所以插入和按 id 查找速度都非常快。
下面是总体元数据模型：
至此，我们对 MQ 的抽象建模工作完成，下面的工作是将这个模型映射到具体实现，经过分解，整个系统由若干个子模块组成，每个子模块实现后拼装起来的 MQ 总体架构如下图所示：
架构思维总结：
整个架构设计的思路体现了先总体抽象，再分解按模块抽象并实现，最后组合成完整的 MQ 系统，也就是 抽象 + 分治。这个 MQ 的实现工作量并不大，属于小型系统范畴，初期设计和开发由 1 个架构师 +2 个中高级工程师可以搞定。
在初期研发和上生产之后，根据用户的不断反馈，系统设计经过多次优化和调整，符合三分架构、七分演化的 演化式架构 理念。目前该系统已经进入 V2 版本的架构和研发，其架构仍在持续演化当中，用户需求的多样性和对系统灵活性的更高要求，是系统架构演化的主要推动力。
中型系统案例：容器云平台架构设计这个也是一个实际研发中的案例。
目前不少技术组织在往 DevOps（研发运维一体化）研发模式转型，目标是支持业务持续创新和规模化发展。支持 DevOps 的关键是需要一套 DevOps 基础平台，这个平台可以基于容器云构建，我们把它称为容器云平台。这个问题很大很复杂，我基于近年在一线互联网的实战经验积累 + 广泛调研，设计了如下容器云平台的总体抽象架构：
核心模块：
核心流程：
架构思维总结：
经过抽象梳理，我们已经得到最终容器云平台的 6 大关键抽象模块和模块间交互流程，下一步就是围绕这 6 大核心模块组织 6 个小的研发团队，每个团队负责一个模块的设计和实现，待每个团队完成各自的模块，再将所有模块组合拼装起来，就能最终产出我们需要的容器云平台产品。整体架构设计思路还是 抽象 + 分治，只不过每个模块的抽象粒度更大，整个平台的规模也更大，需要投入的研发团队资源也更多，对架构师的抽象能力要求也更高。每个模块的技术负责人在研发各自的模块时，同样遵循 抽象 + 分治 的思维方式，先做抽象架构，划分子模块，安排组员实现子模块，最后拼装组合成完整模块。
由于这个平台规模较大较复杂，目前已经投入了近两个季度的时间，做第一期架构设计和研发，目前还没有完全生产化。在第一期过程中，随着对问题域的理解不断深入，架构设计经过多次调整，目前架构趋于稳定，已经进入预上线期。在后续生产落地过程中，仍然需要根据用户的反馈，借助进化的力量不断地调整和优化架构。这个符合 演化式架构 的思路。
大型系统案例：微服务基础架构微服务架构是近年很多企业技术架构转型的趋势，实际上，微服务架构可以抽象分解为一个 两层架构：上层是微服务业务架构，下层是微服务基础架构。上层业务架构由于每个企业的业务场景各不相同，所以一般很难通用化，大多企业都是定制自研。而下层基础架构由于近年业界实践的不断沉淀，已经比较通用化和模块化，其中的核心模块一般不需要自己重造轮子，重用那些在一线互联网公司已经落地并开源出来的产品就可以了。
Netflix 是一家伟大的科技公司，它内部的基础架构团队很牛，或者说抽象能力非常强，把一些核心微服务基础组件都以模块化方式开源出来了，使得其它公司只需组合拼装这些组件就可以快速搭建微服务架构，可以说 Netflix 将整个行业的技术水平提升了一个层次。
我近期和极客时间合作，开设了一门叫《微服务架构实战 160 讲》的视频课程，这门课程基于我近年在一线互联网公司（携程和拍拍贷）落地微服务基础架构的实战经验和总结。该课程为大家深度剖析微服务 8 大核心模块的架构和实践，以及如何使用这些模块，采用 抽象 + 分治 的架构思维，像搭积木一样轻松构建微服务基础架构，欢迎大家订阅学习。
《微服务架构实战 160 讲》中涉及的 8 大模块包括
整体拼装起来的微服务基础架构如下图所示，这个架构是经过实践落地的，可以作为一线企业搭建微服务基础架构的参考：
在企业的整个技术体系架构层面，最基本的思考方式还是 抽象 + 分治，只不过问题域更大更复杂，还涉及到组织和业务架构，所以一般还要增加 分层 的维度来解决，下图是 2016 年的 eBay 技术体系架构（图片来自文末参考链接）：
我最早看到这个架构图是在 2008 年左右的一次 all hands meeting 上（当时我还在 eBay 中国研发中心做工程师），也就是说大致在 2008 年左右，eBay 就已经有比较清晰的，以分层方式组织的技术体系架构。eBay 当时把它的系统称为电子商务操作系统，因为据说整个系统的代码量超过 Windows 7 操作系统的代码量。
eBay 架构分为清晰的四个抽象层次：
我本人在吸收了 eBay 技术体系架构的基础上，也吸收了一些阿里巴巴中台战略的思想，同时融合近年的一些业界趋势（比如大数据 /AI），抽象出一个更通用的分层技术体系架构，可以作为互联网公司技术体系架构的一般性参考，如下图所示：
顺便提一下，近年阿里提出的所谓大中台，小前台战略，其实就要强化技术中台 + 业务中台，中台做大做强了，业务前台才可以更轻更灵活的响应业务需求的变化。
写在最后MicroServices at eBay
标签：
