标签：架构设计 服务 -- 子域 笔记 API 模式 上下文

需求--必须解决的问题
结果上下文--好处、弊端、问题
相关模式--前导、后续、替代、泛化、特化

服务拆分相关模式及原则
1、根据业务能力分解模式，围绕业务功能组织服务
2、根据子域分解模式，围绕领域驱动设计（DDD）来组织服务
3、单一职责原则
4、闭包原则

自动化部署/服务管理平台--基于虚拟机、容器、serverless...

可观测性服务
1、健康检测API
2、日志聚合--集中式日志服务器（检索、触发报警）
3、分布式追踪--每一个请求分配唯一ID
4、异常跟踪--程序异常发送到异常跟踪服务
5、应用指标
6、审计日志--记录用户行为
###########################################

定于架构
1、将应用程序的需求提炼为各种关键请求,定义系统操作（抽象领域模型-->确定系统操作）
2、确认如何分解服务
3、确定每个服务的API

DDD领域设计模型
1、子域
领域驱动为每一个子域定义单独的领域模型，子域是领域的一部分
2、限界上下文
领域模型的边界称为限界上下文，每一个限界上下文对应一个服务或者一组服务

定义服务API
1、把系统操作分配给服务
2、确定支持服务协作所需的API

进程间通讯交互方式：一对一、一对多；同步、异步模式

API版本管理
消息格式
1、基于文本格式：JSON、XML
2、二进制格式：THRIFT、PROTOCOL、BUFFERS、AVRO

远程调用保护机制
1、网络超时
2、限制客户端向服务器发出请求的数量
3、断路器模式--失败的比例超过一定的阈值就启动断路器，后续调用立刻生效。
经过一段时间后，客户端继续尝试，如调用成功则接触断路器

服务发现机制
1、部署平台实现服务发现机制（服务器端发现、第三方注册模式）
2、程序级别实现服务发现机制（客户端发现、自注册模式）

标签：架构设计,服务,--,子域,笔记,API,模式,上下文
来源： https://www.cnblogs.com/codechange/p/16489825.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。