大话 Spring Cloud
Spring Cloud 下的工程
- Spring Cloud 各组件超时总结
- Spring Cloud 各组件重试总结
-
Spring Cloud Feign:
feign client 的 retry 及超时设置：feign client 默认的 connectTimeout 为 10s，readTimeout 为 60. 单纯设置 timeout，可能没法立马见效，因为默认的 retry 为 5 次. 因此，如果期望 fail fast 的话，需要同时自定义 timeout 以及 retry 的参数，而且要确保反向代理，比如 nginx 的 proxy_connect_timeout 以及 proxy_read_timeout 要大于 feign 的配置才能见效，不然对外部用户感知到的还是 nginx 的 504 Gateway Time-out，起不到 fallback 的效果。
超时配置
常见问题：
1，FeignClient 接口，不能使用@GettingMapping 之类的组合注解；
2，FeignClient 接口中，如果使用到@PathVariable ，必须指定其 value；
3，解决 Feign/Ribbon 第一次请求失败 Spring Cloud Config：依靠 git 仓库实现的中心化配置管理。配置资源可以映射到 Spring 的不同开发环境中，但是也可以使用在非 Spring 应用中。
Spring Cloud Netflix：不同的 Netflix OSS 组件的集合：Eureka、Hystrix、Zuul、Archaius 等。
Spring Cloud Bus：事件总线，利用分布式消息将多个服务连接起来。非常适合在集群中传播状态的改变事件（例如：配置变更事件）
Spring Cloud Consul：服务发现和配置管理，由 Hashicorp 团队开发。
Spring Cloud Netflix
- 服务发现：Eureka-server 实例作为服务提供者，可以注册到服务注册中心，Eureka 客户端可以通过 Spring 管理的 bean 发现实例；
- 断路器：利用注解，可以创建一个简单的 Hystrix 客户端；通过 Java 配置文件可以创建内嵌的 Hystrix 控制面板；
- 声明式 REST 客户端：使用 Feign 可以创建声明式、模板化的 HTTP 客户端；
- 客户端负载均衡器：Ribbon
- 路由器和过滤器：Zuul 可以在微服务架构中提供路由功能、身份验证、服务迁移、金丝雀发布等功能，详见 模块架构图 ZUUL。
Dubbo vs Spring Cloud
微服务环境层级
九大特性
——来自 Martin Fowler 的 Microservices
- 服务组件化
- 按业务组织团队
- 做“产品”的态度
- 智能端点与哑管道
- 去中心化治理
- 去中心化管理数据
- 基础设施自动化
- 容错设计
- 演进式设计
怎样使一个微服务 “产品就绪”
——来自 Susan Fowler-Rigetti 原文不详，引自：实现微服务，每个组织都会面临的 6 个挑战
- 稳定性和可靠性
使用微服务，会带来更多的变更和更快的部署，这就导致了不稳定性。她称，一个可靠的微服务应该是能够被其客户、依赖和生态所信任的。她认为稳定性和可靠性是息息相关的，大多数稳定性需求会伴随可靠性需求。一条在进入生产环境前具备多个阶段的部署流水线就是一个很好的例子。
- 可扩展性和性能
大多数人认为他们能够通过微服务无偿获得可扩展性，但这对于巨大的规模而言并非如此。随着流量的增加，它们应该得到适当的扩展。
许多语言在设计上就无法做到高效的扩展，因为它们无法做到并发、分区和高效。这使得用那些语言开发的微服务难以得到合理的扩展。Fowler-Rigetti 谢绝指出具体的语言，但她说，“我很肯定自己能想到一些。”
她解释道，可扩展性是指微服务能够处理多少请求 (译者：可扩展性是指系统为应对业务增加而对自身进行相应扩展的能力，有些时候也作伸缩性，即在业务缩减的时候，系统规模做相应的收缩)，性能则是指服务能够多好地处理这些任务 (译者：这应该叫 QoS)。一个高性能的服务应该合理地使用资源、高效地处理任务、快速地处理请求。
如果微服务无法得到预期的扩展，那么其出现故障的概率会急剧上升。延迟的增长会导致低下的可用性。
- 容错和灾备
为了保证可用性这个终极目标，开发者需要确保任何微服务出现故障后均不会导致系统宕掉。因此开发者需要知道所有的故障模式，并且做好备份工作，以应对故障的发生。
成功灾备的关键是健壮的弹性测试，它包括代码测试、负载测试，以及含其它主动性测试的混沌测试。每个故障模式都应该在生产环境中复现，以观察能否 “存活”。
给定微服务环境的复杂度和复杂的依赖链，故障是难以避免的（译者：总觉得这句话本来就有问题）。微服务必须能够承受来自内部和外部的故障。
- 监控和文档
Fowler-Rigetti 说，“我发现在微服务架构中，系统的状态永远和上一秒不同。如果你不知晓系统的状态，在系统故障时你将无法得知，这会导致最终的失败。”
拥有一款好的监控工具来展示系统在任意时刻的状态，这是很关键的。缺少良好的监控工具是造成服务中断的第二大原因。
日志是监控的本质部分，因为你将几乎不可能复现 bug。知晓发生了什么的唯一方式就是确保你在那时记录了系统的状态。唯一的手段便是合理的日志记录。这使得我们能够轻松信任服务。
文档对于每个开发者而言都是阻碍，但它确实是关键的。它移除了技术债务，并使得团队新成员能够赶上进度。
Oldest comments (0)