产品级微服务的八大原则ppt课件.pptx

一 微服务概念 1 微服务的内部结构 2 资源 Resources 作为由服务所暴露的应用协议以及表示域对象的消息之间的映射器 通常情况下 它们比较轻便 用于检查请求的完备性 并提供根据业务事务的输出来返回一个协议特定的响应 3 域模型 几乎所有在域模型中的业务逻辑都代表了业务域 在这些对象中 服务跨越多个领域进行协调 而库作用于域实体的集合 而且往往持续性支持 4 服务协作 如果一个服务需要另一服务进行协作 那么一些逻辑就需要与外部服务进行通信 网关打包域对象的请求和响应 封装消息并传递至远程服务 它可能会使用理解底层协议的客户机来处理请求 响应周期 5 域存储库 除了最简单的情况 或当一个服务作为聚合其他服务所拥有的资源的聚合器之外 微服务需要能够在几个请求之间储存域的对象 通常这是通过使用对象关系映射或使用满足持久性要求的复杂性的更轻便的数据映射器实现 通常情况下 这个逻辑块被封装在一组由域存储库使用的专用对象中 6 二 微服务的误区 7 一 数据驱动的迁移反模式 可以分割成粗粒度的数据和服务 然后再进一步的分割成更小的微服务和数据 你可能要频繁地进行服务调整 粒度太小 合并微服务 粒度太大 分割成更小的微服务 数据迁移要比源代码迁移更复杂 更容易出错 理想情况下只为微服务迁移数据一次 理解数据迁移的风险性是避免这种反模式的第一步 8 二 超时反模式 服务不可用 服务消费者会在毫秒级的时间内得到通知 它可以返回错误信息或者尝试连接 但是如果服务接收了请求但是不响应 服务消费者该怎么办 可以无限等待或者设置一个超时时间 9 三 使用熔断器设计模式 这种设计模式就像家里的电器的保险丝一样 当负载过大 或者电路发生故障或异常时 电流会不断升高 为防止升高的电流有可能损坏电路中的某些重要器件或贵重器件 烧毁电路甚至造成火灾 保险丝会在电流异常升高到一定的高度和热度的时候 自身熔断切断电流 从而起到保护电路安全运行的作用 10 四 共享反模式 微服务的目标之一就是尽量少的共享 这会帮助微服务确定它的有界上下文 服务更容易的测试和部署 服务之间依赖越多 服务则更难被隔离 不要把所有共享的代码放在一个库中 比如common jar 而是根据它们的逻辑划分成更小的库 比如security jar persistence jar dateutils jar 11 五 到达报告反模式 数据库的非独立性 影响微服务的性能 尤其是复杂报告的查询 批处理程序成批地将微服务的数据倒入到报告的数据库中 但是问题和HTTPpullmodel一样 这会带来数据库的非独立性 微服务数据库格式的改变也会影响报告服务 12 五 到达报告反模式 Event basedpushmodel 也叫datapump 虽然相对复杂 但是不会违背微服务的原则 13 六 沙粒陷阱 采用微服务架构的时候最大的挑战之一就是服务粒度的问题 微服务的服务粒度多大合适 服务粒度至关重要 它会影响应用的性能 健壮性 可靠性 可测性 设置发布模型 当服务的粒度太小的时候就会遇到沙粒陷阱 微服务的微并不意味着服务越小越好 但是多小是小 14 六 沙粒陷阱 分析服务编排 服务的范围和功能 分析数据库事务 15 七 无因的开发者陷阱 没有考虑tradeoff 发布 改变控制 测试都深受影响 16 八 随大流陷阱 微服务是现在的潮流 所以你选择了微服务 还没有仔细的分析你的商业需求 商业驱动 组织架构和技术环境 这就是随大流陷阱 微服务并不适合所有的场景 避免这个陷阱的方式充分理解微服务的好处和短处 俗话说 知己知彼 百战不殆 好处 发布 易于发布测试 易于测试改变控制 更容易的改变一个服务的功能模块 规模可扩展短处Team组织改变性能可靠性降低运维难度加大 17 九 静态契约陷阱 要为你的服务设计版本号 有两种实现方式 在header中加入版本号 或者在服务的schema中加入版本号 18 十 我们到了吗 这个陷阱发生在你不知道远程调用要花多长时间的情况 50秒 平均多长时间呢 长尾的延迟呢 首先你应该测量服务的调用时间 至少能知道一个服务远程调用的大概时间 然后你应该评估不同的服务通讯协议的性能 比如REST JMS AMQP等 当然性能也不是唯一个衡量远程通讯协议的因素 19 十一 REST陷阱 如果把REST作为唯一的通讯方式 就有可能掉入这个陷阱 比如如何处理异步通讯 http1 1是blocking的 如何在一个事务中管理多次服务调用 如何支持广播 你应该考虑两种类型的消息标准作为微服务架构中的消息传递 特定平台的标准和平台无关的标准 特定平台的标准比如JMSforjava 平台无关的比如AMQP 使用消息系统的好处可以异步请求 还可以实现广播的方式 还可以实现事务请求 20 二 微服务的事务管理 21 一 事务有四个基本要素 ACID A Atomicity 原子性 整个事务中的所有操作 要么全部完成 要么全部失败 不可能停滞在中间某个环节 事务在执行过程中发生错误 会被回滚 Rollback 到事务开始前的状态 就像这个事务从来没有执行过一样 C Consistency 一致性 一个事务可以封装状态改变 除非它是一个只读的 事务必须始终保持系统处于一致的状态 不管在任何给定的时间并发事务有多少 I Isolation 隔离性 隔离状态执行事务 使它们好像是系统在给定时间内执行的唯一操作 如果有两个事务 运行在相同的时间内 执行相同的功能 事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统 这种属性有时称为串行化 为了防止事务操作间的混淆 必须串行化或序列化请求 使得在同一时间仅有一个请求用于同一数据 D Durability 持久性 在事务完成以后 该事务对数据库所作的更改便持久的保存在数据库之中 并不会被回滚 22 传统事务管理 23 二 两阶段提交协议 2PC 应用程序调用事务协调器中的提交方法事务协调器将联络事务中涉及的每个数据库 并通知它们准备提交事务 这是第一阶段的开始 接收到准备提交事务通知后 数据库必须确保能在被要求提交事务时提交事务 或在被要求回滚事务时回滚事务 如果数据库无法准备事务 它会以一个否定响应来回应事务协调器 事务协调器收集来自各数据库的所有响应 在第二阶段 事务协调器将事务的结果通知给每个数据库 24 二 两阶段提交协议 2PC 25 三 可靠事件模式 可靠事件模式属于事件驱动架构 当某件重要事情发生时 例如更新一个业务实体 微服务会向消息代理发布一个事件 消息代理会向订阅事件的微服务推送事件 当订阅这些事件的微服务接收此事件时 就可以完成自己的业务 也可