前言

为了实现数据驱动、能使用数据进行竞争、或者使用数据在规模上驱动价值，今天的架构和组织都面临挑战，之前的文章《如何从单一数据湖移动到分布式数据网格》对此中痛点深表同感（阅读下文前，鼓励你先读这篇文章）。它提供了另一种视角，这一视角已经引起了许多组织的注意，并为不同的未来带来了希望。虽然最初的文章描述了这个方法，但它也留下了很多设计和实现的细节，让人去想象。我无意在本文中作明确的界定，从而扼杀了围绕数据网格实现的想象力和创造力。这里，将阐明数据网格的架构方面，作为推动范式向前发展的垫脚石。

写这篇文章更多是作为一个续集。它总结了数据网格方法，列举了它的基础原则，以及这些原则所驱动的高级逻辑架构。在以后的文章中深入研究数据网格核心组件的详细架构之前，高级逻辑模型是必要的基础。因此，如果您正在寻找数据网格的具体工具和方法，这篇文章可能会让您失望。如果您正在寻找一种简单的、与技术无关的模型来建立一种通用语言，那就来吧。

数据的巨大鸿沟

我们所说的数据到底是什么?答案取决于你问的是谁。今天提到的数据，可以分为运营数据和分析数据。运营数据位于由微服务提供的业务功能背后的数据库中，具有事务性，保持当前状态并满足运行业务的应用程序的需求。分析数据是对业务事实随时间推移产生的临时和聚合视图，通常用于建模以提供回顾或未来视角的洞见;它也用于训练ML模型或提供分析报告。

技术、架构和组织设计的当前状态反映了这两个数据平面的分歧——两个层次，既集成而又分离。这种分歧导致了一个脆弱的架构。许多人试图连接这两个数据平面，将数据从运营平面流动到分析平面，然后再返回到运营平面。然而不断失败的ETL（提取、转换、加载）作业和不断增长的迷宫般的数据管道的复杂性变得越发常见。

分析数据平面本身分为两大主要架构和技术栈: [数据湖](bliki: DataLake)和数据仓库;数据湖支持数据科学访问模式，数据仓库支持分析和商业智能报告访问模式。而同时，数据仓库正试图支持数据科学工作流程，数据湖也试图为数据分析和商业智能服务。本文将先把这两个技术栈之间的交错放在一边，数据网格最初的文章探讨了现有分析数据平面架构所面临的挑战。

数据网格认可并尊重这两个层面之间的差异:数据的性质和拓扑、不同的用例、数据消费者的角色，以及最终它们的不同访问模式。然而，它试图在不同的结构(基于领域的倒置模型和拓扑，而不是基于技术栈)下连接这两个平面，并将重点放在分析数据平面上。当今管理两种数据原型的可用技术中，都不应该导致组织、团队和工作人员的分离。在我看来，运营性和事务性数据的技术和拓扑是相对成熟的，并且主要由微服务架构驱动;数据隐藏在每个微服务内部，通过微服务的api控制和访问。当然，真正实现混合云本地操作数据库的这解决方案还有创新空间，但从架构的角度来看，它已经满足了业务的需求。然而，管理和获取分析数据仍存在大量的摩擦。这，就是数据网格的重点所在。

我相信，在未来的某个时刻，我们的技术将会发展，使这两各数据层面能更加紧密地联系在一起，但现在，建议先把关注点分离。

数据网格的核心原则和逻辑架构

网格目标是为了构建一个基础底座，便于从大规模分析数据获得价值，以及适应历史事物的不同维度变化，如数据环境的不断变化、数据源和消费者的扩散、用例所需的转换和处理的多样性、变化响应速度的改变。为了实现这一目标，我建议，任何数据网格实现都应遵循以下四个基本原则:

1. 面向领域的分析数据所有权和架构
2. 数据即产品
3. 自服务的数据基础平台
4. 联合计算治理

这些原则的实践、技术和实现会随着时间的推移而变化和成熟，但这些原则不会改变。

这四项原则合起来应该是必要和充分的;在解决不兼容数据竖井或运营成本增加的问题时，实现形式可弹性伸缩。下面，让我们深入研究每个原则，然后设计支持它的概念性架构。

原则一：领域所有权

数据网格的核心是将责任分散并分配给最接近数据的人，以支持持续的变化和可伸缩性。问题是，我们如何分解和分散数据生态系统的组件及其所有权。这里的组件由分析数据、元数据和为其提供服务所需的计算组成。

数据网格按组织单元的边界分解。而我们现在的组织单元是基于它们的业务领域划分的。这种划分的持续变化和演化(在大多数情况下)将影响到领域的的限界上下文。因此，使业务领域的限界上下文成为数据所有权分布的良好候选对象。

在本文中，我将继续使用与最初写作相同的用例，“一家数字媒体公司”。可以想象，媒体公司会根据域划分其运营，并从而划分支持运营的系统和团队。如“播客”领域，会有相应的系统和团队管理播客发布及其主机; 又比如“艺人”领域，也会有相应的系统和团队负责上线及付款。数据网格认为分析数据的所有权和服务应该尊重这些领域。例如，管理“播客”领域的团队，在为播客发布提供API的同时，还应该负责提供“已发布的播客”的历史数据和其他相关指标，比如“听众人数”。要更深入地了解这一原则，请参见[《面向领域的数据分解和所有权》](How to Move Beyond a Monolithic Data Lake to a Distributed Data
Mesh)。

逻辑架构：面向领域的数据和计算

为了促进这样的划分，我们需要对分析数据的按领域建模。在这个架构模型中，领域与组织其他部分的接口不仅包括运营能力，还包括对领域服务的分析数据的访问。例如，“播客”领域提供了运营API来“创建一个新的播客集”，但也提供了一个分析数据接口来检索“过去n个月的所有播客集数据”。这意味着架构模型必须消除任何摩擦或耦合，以让领域能服务于它们的分析数据，并独立于其他领域发布计算数据的代码。为了规模化，架构必须支持领域团队在发布和部署其运营或分析数据系统方面的自主权。

下面的示例演示了面向领域的数据所有权原则。这些图只是逻辑表示和示例性的。它们并非是完整的。每个领域可以发布一个或多个运营api，以及一个或多个分析数据接口。

当然，每个领域都可以依赖于其他领域的运营和分析数据接口。在下面的例子中，“播客”领域作为消费者，从“用户”领域获取“用户更新”的分析数据，从而能通过“播客听众人数统计”数据集提供一个播客听众人数的视图。

注意:在示例中，我使用了命令式语言（动宾）来访问运营数据或功能，如“支付艺人”。这只是为了强调访问运营数据和分析数据的意图之间的区别。我认识到，在实践中，运营性API是通过声明性更强的接口实现的，比如RESTful资源访问或GraphQL查询。

原则二：数据即产品

现有分析数据架构的挑战之一是对于发现、理解、信任和最终使用高质量数据的高摩擦和成本。如果不加以解决，随着提供数据领域的系统和团队数量的增加，这个问题只会随着数据网格划分而加剧。这将是去中心化第一原则的结果。数据即产品原则旨在解决数据质量和古老的数据竖井问题;或如Gartner所称的“黑暗数据”问题——“组织在常规业务活动中收集、处理和存储的信息资产，但通常不会用于其他目的”。领域提供的分析数据应该被视为产品，数据的消费者应该被视为客户——需要被满足的客户。

原文中列举了一系列能力，包括可发现性、安全性、可探索性、可理解性、可信赖性等，这是数据网格在支撑数据即产品时应该提供的能力。它还详细描述了角色，比如组织必须引入的领域数据PO，负责确保数据作为产品交付的客观度量。度量包括数据质量，减少数据消耗的前置时间，以及一般通过净推广者评分获得的数据用户满意度。

领域数据PO必须深入了解数据用户是谁，他们如何使用数据，以及他们习惯使用什么方式获取数据。这种对数据用户的深入了解能促使数据产品接口的设计满足用户需求。实际上，对于网格上的大多数数据产品，都有一些传统的用户画像，他们拥有独特的工具和期望，比如数据分析师和数据科学家。所有数据产品都可以通过开发标准化接口实现。数据用户与PO之间的对话是建立数据产品接口的必要环节。

每个领域将包括数据产品开发者，她们负责构建、运维和提供领域的数据产品，数据产品开发者将与该领域的其他开发人员一起工作。每个领域团队可以提供一个或多个数据产品。也可以组建新的团队来提供那些不适合现有运营领域的数据产品。

注:与过去的模式相比，这是一种反向的责任模式。数据质量的责任向上游转移，尽可能接近数据的来源。

逻辑架构：数据产品作为架构量子

在体系结构上，为了支持数据作为一种产品，领域可以自主地服务或消费，数据网格引入了数据产品的概念作为其架构量子。架构量子，在《演进式架构》中定义为最小的架构单元，它可以独立部署，具有高度的功能内聚性，并包含其功能所需的所有结构元素。

数据产品是网格上的节点，它封装了其功能所需的三个结构组件，作为产品提供对领域分析数据的访问。

• 代码
• 数据管道代码， 以消费、转换和服务那些从领域的运营系统或上游数据产品接收的数据
• api代码，以提供对数据、语义和语法模式、可观察性指标和其他元数据的访问
• 强制特征的代码，例如访问控制策略、合规性、来源等
• 数据与元数据
• 这就是这里的目的所在，以多种语言的形式来获取潜在的分析和历史数据。
• 根据领域数据的性质及其消费模型，数据可以展现为事件、批处理文件、关系表、图形等多种形式，同时维护相同的语义。
• 为了数据的可用性，需要一组相关的元数据，包括数据计算文档、语义和语法声明、质量指标等；数据固有的元数据，例如它的语义定义；以及传递计算治理用于实现预期行为特性(如访问控制策略)的元数据。
• 基础设施
• 基础架构组件支持构建、部署和运行数据产品的代码，以及存储和访问大数据和元数据。

下面的示例建立在前一节的基础上，将数据产品演示为架构量子。图中内容仅为示例，并不打算包括所有完整的设计和实现细节。虽然这仍然是一种逻辑表示，但正在接近最终物理实现。

注意：过去，管道(代码)被视为独立于它们所产生的数据的组件; 通常基础设施，如仓库或湖泊存储帐户的实例，会在许多数据集之间共享，而数据网格模型不同于过去的这些范例。数据产品是所有组件(代码、数据和基础设施)的组合，其粒度与领域的限界上下文相同。

原则三：自服务数据平台

正如您所想象的那样，要构建、部署、执行、监视和访问一个简单的元素(一个数据产品)，需要配置和运行大量的基础设施;提供此基础设施需要特定的技能，很难在每个领域复制。最重要的是，团队能够自主拥有其数据产品的唯一方法是访问基础设施的高阶抽象，从而消除配置和管理数据产品生命周期的复杂性和摩擦。这就需要一种新的原则，即将自服务数据基础设施作为一个平台来实现领域自治。

数据平台，可以视为用于运行和监视服务的交付平台的扩展。然而，今天支撑数据产品的底层技术栈看起来与服务交付平台非常不同。这只是由于大数据技术栈与运营平台的分歧。例如，领域团队可能将他们的服务部署为Docker容器，交付平台使用Kubernetes进行编排;然而，相邻的数据产品可能在一个Databricks集群上以Spark作业的形式运行其管道代码。数据网格需要配置和连接这两组非常不同的基础设施，而在此之前，两组基础设施不需要这种级别的互操作性和互联性。我个人的希望是，能看到运营和数据基础设施的融合。例如，可能在同一个编排系统（例如Kubernetes）上运行Spark。

实际上，为了让普通开发人员、领域现有的开发人员能够访问及开发相关的分析数据产品，除了简化配置之外，自服务平台还需要提供新型的工具和接口。自服务数据平台必须创建工具，以支持领域数据产品开发人员在工作中能创建、维护和运行数据产品，而不需要具备特定的专业知识;自服务基础设施必须包括降低当前成本和构建数据产品所需的专有功能。原文内容中，还包括了自服务数据平台提供的一系列功能，包括可伸缩的多语言数据存储的访问、数据产品格式定义、数据管道声明和编排、数据产品血缘、计算和数据本地化等。

逻辑架构：一个多平面的数据平台

自助服务平台功能可以分为多个类别，或在模型中称之为平面。注意:一个平面代表了一个整合而又分离的层次存在。类似于物理和意识的层，或网络中的控制层和数据层。平面既不是层，也不意味着强层次访问模型。

自服务平台可以有多个平面，每个平面为不同的用户提供服务。在以下示例中，列出了三种不同的数据平台平面:

• 数据基础设施平面：底层基础设施的配置，以支撑运行数据产品的组件和产品的网格。这包括提供分布式文件存储、存储帐户、访问控制管理系统、数据产品内部代码运行的编排、在数据产品图形上提供分布式查询引擎，等等。这是一个相当底层的数据基础设施生命周期管理平面，希望只有其他数据平台或者高级数据产品开发人员直接使用这个接口。
• 数据产品开发者体验平面：这是典型的数据产品开发人员使用的主界面。这个界面对数据产品开发人员工作流程所需的许多复杂性进行了抽象，比数据基础设施平面更高层。它使用简单的声明式接口来管理数据产品的生命周期。它自动实现切面上的公共关注点，这些关注点被定义为一组标准和全局约定，应用于所有数据产品及其接口。
• 数据网监督平面：有一组功能最好在网格级别综合提供：如数据产品的连接全景图。虽然每个能力的实现可能依赖于单独的数据产品功能，但在网格级别上提供这些功能更方便。例如，通过搜索或浏览数据产品的网格的功能，为特定用例提供发现数据产品的能力;或者通过执行一个数据语义查询，将多个数据产品关联起来以创建更高层次的洞察力，该查询可以跨网格上的多个数据产品进行操作。

下面的模型仅作为示例而非完整的。虽然平面的层次结构是可取的，但并不意味着严格的层次结构。

原则四：联合计算治理

如你所见，数据网格遵循分布式系统架构;各数据产品集合具有独立生命周期，很可能也由独立的团队构建和部署。然而，对于大多数用例来说，若要以更高阶数据集、洞察或机器智能的形式获得价值，就需要这些独立的数据产品进行交互;将它们关联起来，创建并集，找到交集，或在它们上进行其他图形或集合操作。为了让这成为可能，数据网格实现需要一个治理模型，它应该包含去中心化和领域自治、通过全局标准化实现交互操作和动态拓扑，最重要的是能由平台自动执行决策。我称之为联合计算治理。决策模型由领域数据产品PO和数据平台PO组成联合领导小组，他们具有各自领域的决策权，同时创建并遵守一组全局规则(适用于所有数据产品及其接口的规则)，以确保一个健康和可交互的生态系统。这决策小组中有不同的职责，需要在集中和去中心化中作一个平衡，需要衡量哪些决策应该领域自治，哪些需要针对所有领域进行全局决策。最终，全球决策只有一个目的，即通过发现和组合数据产品，来创建交互和复合网络效应。

数据网格中治理的优先级不同于传统的分析型数据管理系统治理。尽管它们最终都从数据中获取价值，但传统的数据治理依靠的是：集中决策、建立支持少量变更的数据全球规范化。相比之下，数据网格的联合计算治理更拥抱变化和支持多重解释上下文。

Placing a system in a straitjacket of constancy can cause fragility to evolve.
给一个系统穿上一件恒定的紧身衣可能会导致脆弱性的进化
-- C.S. Holling, ecologist

逻辑架构：嵌入在网格中的计算策略

联合计算治理发挥作用需要的必要条件：一个支持性的组织架构、激励模型和架构，从而在尊重本地域自治的同时，又能达成全局决策和标准，并有效地实施全局策略。

正如前面所提到的，对于哪些需要全局标准化并推动所有领域及其数据产品的实现和执行，哪些该留给领域自治，这两者如何取得平衡是一门艺术。例如，领域数据模型的建模就应该交给最熟悉该领域的去实现，像如何定义“播客受众”数据模型的语义和语法都应该留给“播客领域”团队。然而，相比之下，如何确定“播客听众”则是一个全局关注的问题。播客听众是“用户”群体中的一员，限界上下文的上游可以跨越领域的边界，并在其他领域中被发现，也如“用户播放流”。统一的身份识别让“用户”既可以是“播客听众”，也可以是“播放流的听众”。

下面是数据网格治理模型中涉及的元素的示例。这不是一个完整的例子，只是表明了全局层面的关注点。

许多前数据网格治理的实践，作为一种集中式的功能，已不再适用于数据网格范式。例如，过去强调以黄金数据集认证作为治理的中心（即经过集中的质量控制和认证过程并被标记为值得信赖的数据集），现已不再适用。在前面的数据治理模式中,数据（无论质量和格式）从运营侧的数据库中提取和集中存储在一个仓库或一个湖,再需要一个集中的团队进行清洁、协调和加密过程; 这集中团队通常在一个集中的治理组的管理之下。而数据网格完全以去中心化处理这个问题。领域数据集只有通过领域内预期的数据产品质量指标及符合全局标准化规则后，才成为数据产品。领域数据产品PO最了解知道生成数据的领域操作细节，所以由他们去决定如何度量其领域内的数据质量。另一方面，尽管有这种领域内的决策和自治，数据产品还需要遵循由全局联合治理团队定义并由平台自动化的全球标准的质量和规范建模。

下表显示了数据治理的集中式(数据湖、数据仓库)模型与数据网格的对比。

原则总结和高阶逻辑体系结构

总结一下，我们讨论了支撑数据网格的四个原则:

• 领域所有权：这样，创建和消费数据的生态系统可以随着数据源的数量、用例的数量和数据访问模型的多样性的增加而扩展;并且只需增加网格上的自治节点。
• 数据即产品：让数据使用者可以轻松发现、理解和安全地使用高质量数据，并享受愉快的体验;包括跨越多个领域的数据。
• 自服务数据平台：这样，领域团队就可以使用平台抽象自主地创建和使用数据产品，从而隐藏了构建、执行和维护安全且可互操作的数据产品的复杂性。
• 联合数据治理：这样，数据用户就可以从独立数据产品的聚合和关联中获得价值——网格就像一个遵循全球互操作性标准的生态系统;以计算方式融入平台的标准。

这些原则驱动逻辑架构模型，该模型将分析数据和操作数据更紧密地结合在同一个域中，同时尊重它们的基础技术差异。这些差异包括分析数据的托管位置、处理操作服务和分析服务的不同计算技术、查询和访问数据的不同方式，等等。

希望到目前为止，我们已经建立了一种通用的语言和逻辑思维模型，我们可以共同向前推进，进一步详细描述网格组件的蓝图，如数据产品、平台和所需的标准化。

原文：Data Mesh Principles and Logical Architecture

从前，有这么一个团队，他们按照不同的业务类型把人员划分了 3 个小队，一个是专注 To C 零售相关业务的，一个专注与 To B 对公业务的，还有一个是专门开发管理一些内部使用的系统的。

恰好，他们 3 个团队使用的架构和技术栈非常类似，比如 Spring Boot 全家桶中的常客Eureka、Spring Cloud Gateway 等，每边的业务又都需要一系列的用户鉴权验证操作。有一天，老板来一看就拍桌子了，“你看这 Eureka、这 gateway（网关）、这鉴权服务！这么类似的东西你们怎么搞了三套！明显浪费资源啊！！微服务不就是要方便重用资源嘛，那谁（架构师）快来收拾收拾看怎么合并一下吧”。

于是，苦 B 的架构师开始埋头梳理架构......

几天后我碰见这位架构师朋友，他立马就开始向我吐糟：“你说前端吧，业务不同，大家分开做没毛病，顶多看看有什么共用模块可以抽取一下做个控件库啥的。说后端吧，反正也在准备建中台了，之后按着业务流程，用领域分析的方式走一下总还是能把这些梳理出来的。老板这么忽然而来去关注服务注册啊、服务网关啊这些基础的设施，你说合起来嘛好像也可以，但是我怎么心里总觉得有点不太确定。”

业务价值导向架构决策

前不久，老马（Martin Fowler）正好写了这么一篇文章（中文翻译供参考），里面提到一种从业务价值出发的决策方式，我在这里且把它概括为“业务导向一中心，得失衡量两基本”，简称【一个中心，两个基本点】。

在做架构决策的时候，可用性 / 扩展性 / 延时等特性总是互相制衡的。我们需要有【一个中心】，也就是要选择出最最重要的点，或者说有个优先级排序。而选出这个中心的出发点，是聚焦业务价值（而非技术价值）。正如 Martin 文中提到的例子，我们会期望一个交易系统有 5 个 9 的高可用，但如果我们要求一个公司内部的 OA 系统做到 5 个 9，就有点过分了。这个区别就在于不同系统提供的业务价值是大不同的。

在决定了一个中心之后，可以进一步问自己两个问题，也就是【两个基本点】。

• 得： 如果这个决策 / 组件顺利工作，那它能贡献多大的业务价值？
• 失： 万一这个决策 / 组件出了问题，它对业务的影响有多大呢？

在项目立项或者申报的时候，大家往往都喜欢考虑“得”，这事要成了就怎么怎么的。但若单纯是这个思路，那很多的技术改进或者优化就排不上了。像是定期的灾备演练，你说不重要那不可能，尤其是银行之类的系统，但你说算不算优先级很高呢？它总是很容易会被一些看似更重要的业务功能的优先级所超越，而导致一拖再拖。直到某天台风真的来了，主机房被淹了，这才发现停服几天损失居然如此之大。可见，只有正反都想透了才能保证思虑更周全。

那我们就尝试用这套方法，聚焦到这次的问题上来分析一下。为了更好地发散，我们可以先从两个基本点开始，然后再来收敛一个中心。究竟，这 3 个团队可以 / 应该共用一个 API 网关吗？

两个基本点

先来看看“得”（初心 / 好处）

• 增加业务重用：如果共用一个 API 网关，3 个团队共用的业务功能 API 是不是可以更容易地得到复用？如果服务能更好地复用，那是不是意味着我们可以更快地提供业务所需的功能？ 如果是更快的话，那这里还可以尝试进一步展开，比如说我们现在已有 / 预计有多少这样共用 API ？
• 减少代码冗余：如果共用一个 API 网关，那至少能减少类似的功能重复开发和冗余。那再展开的话，如果共用了不需要再开发网关了，这里能省多少时间？
• 减少硬件资源投入：资源部署还是需要硬件支撑的，这里的网关通常用的是集群（cluster），例如 3 个组件同时启动。如果共用一组网关，也少部署了另外两组网关（6个）服务，那硬件上能省多少？
• 降低运维成本：除了让组件运行起来，还得有人对应的去监控管理运维。每少一个组件都应该减轻了一定的运维成本，也让架构简单一些。

上面都是一些拍脑袋出来的点，实际分析的时候如果能有业务数据支撑就更好了。

再来看看“失”（挑战 / 风险）

• 网关出问题的业务影响：因为通常是集群，如果只是其中一个网关有问题，那应该只要及时解决一下应该没什么影响。万一全部都挂了，那本是影响对应的业务线无法访问，合并后就有可能导致 3 个业务线都无法访问。这里还可以再展开一下，
  • 这里的风险影响级别？（明显业务影响是高的）
  • 对应的出问题机率又是多少呢？（可以类比洪水机率描述，比如一年一遇 / 三年一遇 / 多少年来暂时未发生过？）
  • 万一它真出现问题了，我们有没有办法及时预警发现然后马上修复？（比如能马上重启解决？有充分的灾备演练和文档说明？还是说只能听天由命到时研究？）
  • 执行解决方案后，估计服务暂停时间（downtime）大概会是多少？（如 3 - 5 分钟内？30 - 60 分钟？半天？）这段服务暂停时间对业务的影响是什么？

• 网关出问题的责任归属问题：即出问题之后由哪个团队负责修复。这个就和康威定律相关了。以前就自己组管自己的组件分得很清晰，那如果之后三个组都用同一个网关，出事之后，
  • 谁主力去负责修复呢？怎么分工？
  • 这个人是否有足够的知识去了解和分析事故的影响范围及有能力去修复？至少有能力找到对应的专家修复？

• 开发和发布等进度的协作问题：大家知道在网关里面最简单还是需要配置一下后台服务的对应关系（mapping），有时候还会新增和修改一下的。那合并之后也就是 3 个团队都需要对这个代码库有控制权，而且会分别按自己的进度修改和发布。这时候，要求：
  • 3 个团队统一代码库
  • 然后还得大家协商好协作方式（如分支策略、发布策略等）
  • 再展开一下的话，就得再看看 3 个团队对于网关的改动 / 部署的频率分别是怎样的？冲突的机率多不多？

• 各团队对网关的安全性 / 可用性 / 延时等要求不同：理想中的网关是单纯的转发，但实际的网关很多团队会慢慢混入更多的功能，比如：
  • 加上 traceId 做全链路追踪？
  • 在网关中截获 HTTP header 做校验？
  • 甚至在网关中就需要连接 Redis 进行认证鉴权？

当一个组件目的不那么单纯的时候，出现问题的机率自然也会上升。例如可能那个 ToC 团队因为被撸羊毛撸怕了，所以需要很高的安全性，但对于内部系统的团队来说，这部分的安全就有点过了，增加的复杂度反而让运维压力更大。

如果这种不一致性比较大，那我们在抽取公共服务共用的时候，有没有办法把共用部分变得更单纯简单？（有可能某些团队就需要作架构调整，如把额外的功能移到另一个非共用组件上。）

一个中心

分析到这里，可能你又会有一种感觉——似乎每一点能列出来的都有道理，但是我依然做不了决定，这就是因为还欠缺了【一个中心】帮助我们做收敛和取舍。

我们可以先假设一个背景：这是在一个超级大公司里面

在这里钱和人都不是大问题，但服务的安全可靠是最重要的。

这时候再去回顾就会发现有些点会忽然变得无关紧要。比如对于硬件资源投入的节省，那简直就是九牛一毛无足轻重，即使是代码冗余和运维成本上，影响也不那么大。反过来说，大公司可能对安全性和可用性都更加关注，即使是偶发的短时间的服务不可用也足以让公司股价波动。大公司的条条框框也让多个团队共用一个代码库去协同更加困难。那如果这么思考，看起来如果合并的话风险就太高了，而且收益也并不显著。

另外一个可能的策略是不原样共用，而是先尽量把一些纯粹的功能抽取出来作为共用服务，而把一些团队特有的特性考虑迁移到另外一些服务里面。但这个就涉及到搬哪些内容、搬到哪里和怎么搬的问题。如果抛开具体情况，这个也说不清，暂且先不细说。

回过头来再假设另外一个背景：这是在一个互联网初创小团队

融资的钱烧得太快了，活下去的关键就是快速迭代出新功能验证市场需求。

那这时候，架构的简洁和部署资源的各种节省都是很有必要的。服务的尽量重用和灵活也会对进度有明显帮助。相反，因为初期用户还不多，公司影响力也不算那么大，偶然如果只是 3 - 5 分钟的服务受影响，其实造成的影响还是可控的。在这种情况下，可能我们从一开始就会选择共用一个网关，准备好救火的文档，准备好救火队员的轮值表，尽量把风险控制在一个非常短的时间内。

总结

架构设计最好玩也是最让人纠结的地方就在于各种抉择。

虽说现在有很多技术手段让我们的架构演进更加轻量和灵活，让大家不用再承受那么孤注一掷的压力，但一个深思熟虑的抉择还是可以让团队少走弯路的。

【一个中心，两个基本点】，看似一个网关的故事，其实可以用于架构调整和重构决策的方方面面，希望可以给各位在抉择路上提供多一套思路，远离选择困难的苦海，阿弥陀佛 ^_^