单元化架构产生的原因

• 应对增长
  传统架构无法处理日益增长的互联网用户需求
• 扩容
  需要新架构更近一部提升了系统的扩展能力
• 系统稳定性
  新架构需要高可用、相对独立和故障隔离使整体系统更稳定
• 灰度发布
  系统和组件都纳入版本管理，按需部署进行灰度发布

核心问题

• 应用扩展性
  • 应用由单体进化到分布式
  • 应用扩展达到上限
  • 数据库无法支撑应用层的扩展
• 数据中心扩展性
  • 单数据中心上限受物理因素限制
  • 系统需求超过单数据中心如何扩展
  • 应用如何在多数据中心灵活切换
• 容错性
  • 应用
    • 组件冗余
    • 数据冗余
    • 时间冗余（重试）
  • 数据中心
    • 系统冗余（多地部署）
    • 数据冗余（数据复制）

单元化架构进化史

分层（Layer）架构

• 系统以微服务的形式满足内外的业务需求
• 以SOA或微服务架构为技术指导原则来构建各种服务
• 按照特定规则将不同微服务分配到不同层，并定义层与层之间的依赖（接口）
• 层自主权高、逻辑清洗、单向依赖，满足大部分系统需求
• 架构层的扩展性上线受许多因素制约
  

分段（Segment）架构

• Agile开发方式、虚拟化和容器化可以在同一架构层中通过隔离和自主权划分为更细粒度的逻辑段（Segment）
• 根据业务能力，在每一层中将不同组件划分到不同段中
• 实现手段
  • Runtime partitioning
  • Multi-tenancy
  • Platform as a service
• 分段架构无法实现一个自由扩展的、自包含的去中心化系统
  

单元化架构

• 将系统按数据特征和功能垂直地划分为一个个单元
• 一个单元就是一个能完成所有业务操作的自包含集合
  包含业务所需的所有服务，数据及资源
• 一个单元可以被独立地部署、管理及监控
  部署在一个或多个数据中心，提升整体系统的扩展上限
• 单元化架构下，系统仍然分层
  • 层的任意组件都属于且仅属于统一单元
  • 上层调用下层时仅依赖于本单元内的层

单元化架构成员介绍

组件

• 组件时单元化架构里最小的原子单位
• 一个组件就是代表一组业务功能或服务
• 组件自定义范围和形态，在其定义域内独立运行
• 组件依赖于其他组件，也可以被其他组件依赖

单元与组件

• 一个单元由一个或多个组件组成
• 一个单元就是一组从设计到实现被分配到一个部署单位的组件
• 一个单元就是一个可以被构建、部署和管理的不可分割的完备组件

名称和版本

• 所有单元都必须被命名，且为全局唯一
• 命名的主要作用是为后续发布和管理
• 单元也会迭代和金华，必须以版本管理的形式来控制
• 单元内的组件也必须被命名和版本化管理

独立性

• 所有单元必须是独立的，才能达成容错、容灾
• 所有单元是可以被独立部署
• 设计单元时，各单元功能是独立的
  • 逻辑无重叠
  • 避免不必要的依赖

完备性

• 一个业务功能在一个单元内完成，避免跨单元功能
• 按逻辑划分为单元，相关业务场景应置于同一单元，达成逻辑完备
• 一个单元能提供的功能，其所需服务和数据都要划分到同一单元内

独立部署

• 一个单元就是一个可以被独立部署的组件
• 设计单元的最终目的是该单元独立部署
• 三级迭代
  • 单元内各组件可以独立迭代
  • 各个单元可以独立迭代
  • 系统作为多个单元的集合可以整体迭代

单元内外通信

• 一个单元由一组或多组组件构成，并对外声明其功能
• 单元的功能必须提供某种网络访问接口，内部的组件不能直接暴露，只能通过统一的ingress对外提供服务
• 如果单元对外界有依赖，必须通过egress进行访问
• 单元内的组件可以通过允许的通信协议互相通信

何时使用单元化架构：突破扩展上限

• 系统能力或用户数发展至单机房或单数据中心成为瓶颈
• 多机房部署而不改造架构，引起的跨机房调用性能降低
• 数据库主库单点，连接数有限，不能支持应用的持续发展
• 系统所服务的用户数量超过了阈值，单数据中心无法支撑起增长
  超十亿用户微信、支付宝、Google、Facebook、Whatsapp等