中台以及云原生架构设计和实践

中台架构设计和实践

公共数据表

公共数据表用于存储通用且不随业务变化的数据字段。以上图为例，公共数据表包含以下字段：

• 商品ID (infoid): 唯一标识每个商品的ID。

• 发布人 (uid): 商品发布者的用户ID。

• 分类ID (cateid): 商品所属分类的ID。

• 价格 (price): 商品的价格。

• 发布时间 (timestamp): 商品的发布时间。

• 商品库存 (stocknum): 商品的库存数量。

• 商品状态 (status): 商品的状态（如上架、下架等）。

这些字段是各业务线共享的基础数据，所有业务都需要这些通用信息，因此将其统一存储在公共数据表中，便于管理和复用。

业务个性化扩展数据表

业务个性化扩展数据表用于存储各业务线的个性化数据字段。不同的业务线可能需要存储不同的额外信息，这些信息在公共数据表中没有包含。以上图为例，业务个性化扩展数据表包含以下字段：

• 商品ID (infoid): 唯一标识每个商品的ID，用于与公共数据表关联。

• key1, key2, key3, key4, key5, key6: 各种业务线特定的扩展字段，存储具体业务需要的额外信息，如"业务方实际字段1"、"业务方实际字段2"等。

具体示例如下：

• 公共数据表中有商品基本信息，如价格、分类、库存等。

• 业务个性化扩展数据表中存储具体业务线的特定字段，如"业务方实际字段1"等，这些字段的内容可能根据业务需求而变化。

关联方式

公共数据表和业务个性化扩展数据表通过商品ID（infoid）进行关联。公共数据表中的通用字段和个性化扩展表中的特定字段通过商品ID进行一一对应。这样在查询时，可以通过商品ID从公共数据表中获取通用信息，再从个性化扩展数据表中获取特定业务线的信息。

示例

假设我们有一个商品，其基本信息存储在公共数据表中，而不同业务线有不同的扩展字段：

• 公共数据表记录:

• infoid: 12345

• uid: 1001

• cateid: 10

• price: 99.99

• timestamp: 2024-06-18 12:00:00

• stocknum: 50

• status: 上架

• 业务个性化扩展数据表记录:

• infoid: 12345

• key1: value1

• key2: value2

• key3: value3

• key4: value4

• key5: value5

• key6: value6

云原生架构设计和实现

转转1.0架构

• 客户端应用层:

• 包含多个客户端应用，包括Android应用（两个）和iOS应用（两个）。

• 这些应用是用户与系统交互的入口。

• 网络层:

• 每个客户端应用都有一个对应的网络层。

• 该层负责处理客户端与服务器之间的网络通信。

• 业务逻辑层:

• 统一的业务逻辑层处理系统的核心逻辑，如商品管理、搜索、推荐和交易等功能。

• 该层是系统的核心，负责实现业务需求。

• 数据访问层:

• 数据访问层将具体的数据存取操作分成几个模块，包括商品数据访问、搜索数据访问、推荐数据访问和交易数据访问。

• 该层负责与底层数据存储进行交互，提供数据操作接口。

• 持久化层:

• 持久化层包含实际的数据存储系统，如MySQL和TiDB。

• 负责将数据永久存储，确保数据的持久性和可靠性。

• 配置中心:

• 位于图的左侧，负责系统配置管理。

• 该组件管理系统的配置信息，确保各部分能够按照正确的配置运行。

• 注册中心:

• 位于图的右侧，负责系统的服务注册和发现。

• 该组件使得各服务能够互相发现并通信，是分布式系统中必不可少的部分。

转转微服务架构2.0

• 业务逻辑层细分:

• 1.0版本：业务逻辑层是一个整体，包括商品、搜索、推荐和交易等所有业务逻辑。

• 2.0版本：业务逻辑层被细分为多个模块，分别处理不同的业务逻辑，如商品业务逻辑层、搜索业务逻辑层、推荐业务逻辑层和交易业务逻辑层。这种细分使得每个模块更加独立，便于维护和扩展。

• 层次结构更清晰:

• 1.0版本：业务逻辑层与数据访问层的界限较为模糊，业务逻辑层直接调用数据访问层。

• 2.0版本：层次结构更加清晰，每个业务逻辑层有明确的职责，并且独立处理相应的业务逻辑，减少了不同业务逻辑之间的耦合。

• 微服务架构改进:

• 1.0版本：较为集中化的架构，各业务逻辑在同一个层次处理。

• 2.0版本：转向更为细粒度的微服务架构，每个业务逻辑模块独立成微服务，增加了系统的灵活性和可扩展性。

• 注册中心和配置中心:

• 注册中心和配置中心在1.0和2.0版本中均存在，但随着业务逻辑层的细分，2.0版本中的注册中心和配置中心的重要性进一步凸显，确保了各个微服务能够正确注册、发现和配置。

• 持久化层的数据库类型调整:

• 1.0版本：使用MySQL和TiDB两种数据库，分别处理不同的数据。

• 2.0版本：仍然使用MySQL和TiDB，但随着业务逻辑的细分，数据访问层的调用变得更为明确，数据库的使用更加优化。

  
  

转转微服务架构3.0(大中台&Service Mesh实战)

• 引入“大中台”:

• 2.0版本：业务逻辑层分为商品业务逻辑层、搜索业务逻辑层、推荐业务逻辑层和交易业务逻辑层，每个业务逻辑层独立处理其特定的业务逻辑。

• 3.0版本：在业务逻辑层与数据访问层之间引入了“大中台”概念。大中台可以理解为一个共享的、综合的服务平台，负责处理跨业务逻辑层的通用功能和服务，进一步提高了资源的复用性和系统的灵活性。

• 层次结构优化:

• 2.0版本：业务逻辑层和数据访问层是直接交互的，每个业务逻辑层直接调用相应的数据访问层。

• 3.0版本：通过大中台的引入，使得各个业务逻辑层可以通过中台统一处理和访问数据，减少了各个模块之间的直接耦合，增强了系统的可维护性。

• 中台的作用:

• 集中化服务：大中台在架构中起到集中化服务的作用，提供了共享的业务能力，如用户管理、权限控制、日志记录等通用功能，从而避免了各个业务逻辑层重复实现这些功能。

• 增强灵活性：大中台可以更灵活地调整和扩展，满足不断变化的业务需求。

• 体系架构的标准化:

• 2.0版本：虽然已经实现了业务逻辑层的细分，但在具体实现和维护上可能还存在一定的复杂性。

• 3.0版本：通过引入大中台，进一步标准化了体系架构，使得各个业务逻辑层能够更加专注于自身的业务实现，其他通用服务交由中台处理。

• 配置中心和注册中心的稳定性:

• 配置中心和注册中心在2.0和3.0版本中依然存在，但随着大中台的引入，这些中心的作用更加重要，确保整个系统的配置管理和服务发现更加高效和可靠。

互联网三高架构演进拆分之道