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

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