单元化架构
为何需要：不断增长的海量用户的需求
所谓单元，是指一个能完成所有业务操作的自包含集合，在这个集合中包含了所有业务所需的所有服务，以及分配给这个单元的数据
- 根据用户单元化
核心问题
- 扩展性
- 数据库的瓶颈限制了应用的扩展
- 数据中心扩展性
- 物理因素所制约
- 容错性
演进
分层（根据技术以服务形式划分） ->
分段（根据业务能力隔离） ->
单元化架构（独立开发运行的一套套系统）
组件
- 单元化架构的最小原子单位
- 在一定域内 拥有一定业务功能的服务
- 组件间有依赖和约束关系
名称与版本
- 全局唯一的名称
- 以版本管理的形式来控制单元的演化
独立性
设计单元的最终目的就是单元独立开发部署
完备性
相关业务场景置于同一单元 逻辑完备
业务单元之间应减少交集
通信
单元间的通信都必须通过某种统一的网络接口进行
单元内的组件通过可被允许的通信协议进行通信
什么时候用
- 要异地多活
- 系统功能与地域强关联
- 高可用、容灾
- 要突破扩展上限
- 突破单点（机房、数据库）瓶颈
设计
设计原则
- 透明性：对开发者与基础设施来说 服务与哪个单元是不重要的
- 系统、数据可被切分
- 业务自包含、自治
要素
业务切分
- 系统根据功能、用户等进行切分拆散到不同单元
使用DDD或者其他什么方式来切分，很像微服务，但切分业务单元时不可避免的会出现一些交集，要保证跨单元操作尽量少，这种拆分与组织架构与业务流程强相关并且可能会反过来影响组织架构，拆分的粒度可参考微服务，需要不断迭代演进。
另外一种是根据用户的地域或者类型等维度根据不同的单元来服务不同的用户，但怎么说，系统中肯定会有一些共同需要有的数据，可以使用数据的复制机制来解决，这样子若数据需同步，则需要一个分布式的ID生成方案来保证不会冲突。这种方式可能会由于用户的不均出现热点单元与冷单元，需要二次拆分或者合并，并且当用户切分维度发生改变时要继续将用户数据同步到新的单元上去。
最后一种方式，是根据数据进行切分，可以参考分库分表
单元路由
- 考虑流量在各个云、中间件间的路由
单元间或者单元内的组件之间通信都是通过各种中间件、代理、网关等来进行，这主要是为了安全与解耦
对于外网的访问，可以使用不同的显式入口、或者在请求里携带标志位来进行路由
外网的请求来到单元网关，网关需进行判断是否接收该请求，以此是否继续路由到单元内部
应用层的处理方式将会进行网络过滤，业务逻辑不必关心
再来到中间件层 最后是数据层
数据复制
- 数据复制的一些问题 一致性 延迟等等
当跨单元需要大量数据时，数据复制是比较好的方式
- 单元间直接复制
- 通过中台复制
根据业务场景选择强一致、最终一致、评估失败的业务的影响