# 微服务设计的原则
# 1 设计原则
高内聚低耦合
复用
单一职责
领域驱动设计，而不是数据驱动设计，也不是界面驱动设计
边界清晰的微服务：微服务内聚合之间的领域服务和数据库实体原则上应该杜绝相互依赖（应用服务编排，事件驱动）
职能清晰的分层
不过度拆分微服务：需要有云计算、DevOps、自动化监控等能力
# 2 微服务拆分需要考虑的因素
理论上一个限界上下文内的领域模型可以设计为微服务，但是领域建模主要从业务视角出发，但在微服务拆分上还要考虑非业务因素，比如需求变更频率、高性能、安全、团队以及技术异构等因素
- 基于领域模型，围绕业务按职责单一性，功能完整性拆分
- 基于业务需求变化频率：需求变动较高的和相对稳定的业务进行分离
- 基于应用性能，把对性能有较高需求的功能拆分出去
- 基于组织架构和团队规模：拆分要避免带来组织架构和调整和团队之间的沟通成本
- 基于安全边界
- 基于技术异构等因素
- 基于资源占用因素
# 2.1 分布式数据库的选择
- 一体化分布式解决方案：数据多副本、高可用。多采用paxous协议，一次写入多数据副本，多次写入成功则算成功
- 集中式数据库+数据库中间件方案：通过中间件实现数据路由和全局数据管理。中间件和数据库单独部署
- 集中式数据库+分库类库的方案：客户端负载，适合简单读写交易场景
# 2.2 如何设计分库主键
以客户为中心，不只是一个口号，对于企业来说，数据的以客户为中心更容易提供客户一致性的服务
# 2.3 数据库的数据同步和复制
传统方式有ETL工具和定时提数的程序，在时效性上有短板
分布式架构一般采用基于数据库逻辑日志增量数据捕获技术，实现准实时的数据复制和传输，实现数据处理和应用逻辑的解耦
# 2.4 数据跨库关联查询如何处理
实体分布到不同的微服务中，但有时需要进行关联查询
- **统计：**建立面向主题的分布式数据库，数据来自不同业务微服务。采用数据库日志捕获技术，把多个微服务的数据汇总到分布式数据库中。
- **关联查询：**小表广播，在业务库中冗余代码副表。通过消息发布和订阅的领域事件驱动模式，异步刷新所有的副表数据
# 2.5 关注顺序的业务数据处理
前后序的数据通常是领域事件相关，通用的方法是把进行数据冗余在微服务之间传输和存储，这也能降低微服务间的调用。如果前序的数据为实体，也可以将前序数据做为查询条件，在本地的微服务中完成多维度的综合数据查询。只有必要时才从前序数据的微服务获取明细的数据。
既保证数据完整性，还可以降低微服务的依赖，减少跨微服务调用、提升系统性能。
# 2.6 数据中台与企业级数据集成
微服务架构提升应用弹性和高可用的能力，但造成了数据孤岛
- 按照统一数据标准，完成不同微服务和渠道业务数据的汇集和存储
- 建立主题数据模型，按照不同主题和场景对数据进行加工和处理
- 建立业务驱动的数据体系，支持业务和商业模式创新
# 2.7 分布式事务还是事件驱动
设计时平衡考虑业务拆分、数据一致性、性能和实现的复杂度，尽量避免分布式事务的产生
非实时场景数据最终一致性的问题：领域事件驱动的异步方式
# 2.8 多中心多活的设计
- 选择合适的分布式数据库
- 单元化架构设计。把若干个应用组成的业务单元作为部署的基本单位，实现同城和异地多活部署，以及跨中心弹性扩容。 设计时尽量避免跨数据中心和单元的调用
- 访问路由：接入层、应用层、数据层路由。
- 全局配置数据管理：实现各数据中心全局配置数据的统一管理。每个数据中心全局配置数据实时同步，保证数据一致性