请选择 进入手机版 | 继续访问电脑版

设为首页 收藏本站
思科社区 关注
思科社区

搜索
热搜: 邮件服务器
查看: 415|回复: 1

【原创翻译】一篇看尽微服务的设计模式(2)

[复制链接]
发表于 2020-2-9 15:54:49 | 显示全部楼层 |阅读模式
4.观测模式
A. 日志聚合
问题
我们来考虑这样一个用例:某个应用程序包括了那些在多台机器上运行的多个服务实例,各种请求横跨在这些多个服务实例之中。同时,每个服务实例都会生成一种标准格式的日志文件。那么我们如何针对某个特定的请求,通过各种日志来理解该应用程序的行为呢?
解决方案
显然,我们需要一个集中化的日志服务,将各个服务实例的日志予以聚合,以便用户对日志进行搜索和分析。他们可以针对日志中可能出现的某些消息,配置相应的警告。例如:PCFPivotal Cloud Foundry)平台拥有一个日志聚合器,它从每种元素(如:路由器、控制器等)中收集与应用相关的日志。而AWS Cloud Watch也具有相似的功能。
B. 性能指标
问题
当各种服务组合随着微服务架构变得越来越复杂时,监控交易的完整性,并能够在出现问题时及时发出警告,就显得尤为重要了。那么我们该如何收集与应用相关的性能指标呢?
解决方案
为了收集不同操作的统计信息,并提供相应的报告和警告,我们一般会用两种模式来聚集各项指标:
1.  推式 将各项指标推给专门的指标服务,如:NewRelicAppDynamics
2.  拉式 从指标服务处拉取各项指标,如:Prometheus
C. 分布式跟踪
问题
在微服务架构中,横跨多个服务的请求是比较常见的。某个服务需要通过横跨多个服务去执行一到多项操作,才能处理一些特定的请求。那么,我们该如何通过跟踪某个端到端的请求,以获知出现的问题呢?
解决方案
我们需要一种具有如下特性的服务:
1.  为每个外部请求分配一个唯一的ID
2.  将该外部请求ID传给所有的服务。
3.  在所有的日志消息中都包含该外部请求ID
4.  在集中式服务中,记录处理外部请求的相关信息,包括:开始时间、结束时间、和执行时间。
SpringCloud Slueth + Zipkin server,是一种常见的实现方式。
D. 健康检查
问题
我们在实施微服务架构的过程中,可能会碰到某个服务虽已启动,但是无法处理交易的情况。那么,我们该如何通过负载均衡的模式,来确保请求不会“落入”失败的实例中呢?
解决方案
每个服务都需要有一个端点,通过诸如/health的参数,对应用进行健康检查。该API需要能够检查主机的状态,其他服务与基础设施的连接性,以及任何特定的逻辑关系。
SpringBoot Actuator不但能够实现端点的健康检查,还能够被定制实施。
5.横切关注点模式(Cross-CuttingConcern Patterns
A. 外部配置
问题
通常情况下,一个服务需要去调用其他的服务和数据库。在诸如开发、QAQuality Assurance,质量保证)、UATUser Acceptance Test,用户验收测试)、和生产环境中,端点的URL、或某些配置的属性会有所不同。因此,有时候我们需要对这些服务的各种属性进行重构、和重新部署。那么我们如何避免在配置变更中修改代码呢?
解决方案
外部化externalize)所有的配置,包括各个端点的URL和信任凭据,以保证应用程序在启动时、或运行中能够加载它们。
SpringCloud配置服务器提供了向GitHub进行属性外部化的选项,并将其作为环境属性予以加载。此法保证了应用程序能够在启动时就被访问到,或是在不重启服务器的情况下实现刷新。
B. 服务发现模式
问题
当微服务初具规模时,我们需要考虑如下两个关于调用服务方面的问题:
1.  由于采用了容器技术,IP地址往往被动态地分配给不同的服务实例。因此,每次当IP地址发生变化时,consumer服务可能会受到影响,需要我们手动更改。
2.  consumer需要记住每个服务的URL,这就倒退成了紧耦合的状态。
那么,consumer或路由器该如何获知所有可用的服务实例与位置呢?
解决方案
我们需要创建一个服务注册表,来保存每个producer服务的元数据(metadata)。一个服务实例在启动时,应当被注册到表中;而在关闭时,需从表中被注销。consumer或路由器通过查询该注册表,就能够找到服务的位置。producer服务也需要对该注册表进行健康检查,以确保能够消费到那些可用的、且正在运行的服务实例。我们一般有两种服务发现的类型:客户端和服务器端。使用客户端发现的例子是Netflix Eureka;而使用服务器端发现的例子是AWS ALB
C. 断路器模式
问题
有时候,某个服务在调用其他服务,以获取数据的时候,会出现下游服务(downstream service)“掉线”的情况。它一般会带来两种结果:
1.  该请求持续发往该掉线服务,直至网络资源耗尽和性能降低。
2.  用户产生不可预料的、较差的使用体验。
那么我们该如何避免服务的连锁故障,并妥善处置呢?
解决方案
consumer应该通过一个代理来调用某项远程服务,就像电路中的断路器一样。当出现持续失败的数量超过设定阈值时,断路器就会“跳闸”一段时间,从而导致所有调用远程服务的尝试被立即切断。在超过设定时间之后,断路器只允许有限数量的测试请求通过。而如果这些请求成功了,那么断路器将恢复正常运行;否则判定为故障依旧,并重新开始新的定时周期。
Netflix Hystrix就很好地使用了该断路器模式。它可以在断路器“跳闸”的时候,帮助您定义一种回退机制,以提供更好的用户体验。
D. 蓝绿部署模式
问题
在微服务架构中,一个应用程序可以有多个微服务。如果我们为了部署一个增强版,而停止所有的服务,那么停机时间一旦过长,就会对业务造成影响。况且,这对于回退来说也将会是一场噩梦。那么我们该如何避免、或减少部署过程中服务的停机时间呢?
解决方案
我们可以采用蓝绿部署的策略,以减少或消除停机时间。在蓝、绿两个相同的生产环境中,我们假设绿色环境有着当前真实的实例,而蓝色环境具有应用程序的最新版本。在任何时候,只有一个环境能够处理所有真实的流量,并对外提供服务。如今,所有的云服务平台都能提供基于蓝绿部署的选项。如果您想了解具体内容,请参看:https://dzone.com/articles/blue-green-deployment-for-cloud-native-application
当然,我们还可以采用许多其他的微服务架构模式,如:Sidecar模式链式微服务Chained Microservice)、分支微服务Branch Microservice)、事件溯源模式Event Sourcing Pattern)、和持续交付方式等。
【原标题】Design Patterns for Microservices  (作者: Rajesh Bhojwani  )
原文链接:https://dzone.com/articles/design-patterns-for-microservices
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
发表于 2020-2-10 11:25:24 | 显示全部楼层
感谢版主分享,谢谢!

相关链接:
【原创翻译】一篇看尽微服务的设计模式(1)
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
您需要登录后才可以回帖 思科 CCO 登录 | 思科 CCO 注册   

本版积分规则

Archiver | 思科社区  

GMT+8, 2020-3-28 23:18 , Processed in 0.097709 second(s), 36 queries .

京ICP备11014401号-17

© 2020 思科系统.版权所有 重要声明 | 保密声明 | 隐私权政策 | 商标 |

快速回复 返回顶部 返回列表