你好，我是陈皓，网名左耳朵耗子。
我们前面讲了那么多的弹力设计的设计模式，这里做个总结。
弹力设计总图
首先，我们的服务不能是单点，所以，我们需要在架构中冗余服务，也就是说有多个服务的副本。这需要使用到的具体技术有：
- 负载均衡 + 服务健康检查–可以使用像Nginx或HAProxy这样的技术；
- 服务发现 + 动态路由 + 服务健康检查，比如Consul或ZooKeeper；
- 自动化运维，Kubernetes 服务调度、伸缩和故障迁移。
然后，我们需要隔离我们的业务，要隔离我们的服务我们就需要对服务进行解耦和拆分，这需要使用到以前的相关技术。
-
bulkheads模式：业务分片 、用户分片、数据库拆分。
-
自包含系统：所谓自包含的系统是从单体到微服务的中间状态，其把一组密切相关的微服务给拆分出来，只需要做到没有外部依赖就行。
-
异步通讯：服务发现、事件驱动、消息队列、业务工作流。
-
自动化运维：需要一个服务调用链和性能监控的监控系统。
然后，接下来，我们就要进行能让整个架构接受失败的相关处理设计，也就是所谓的容错设计。这会用到下面的这些技术。
-
错误方面：调用重试 + 熔断 + 服务的幂等性设计。
-
一致性方面：强一致性使用两阶段提交、最终一致性使用异步通讯方式。
-
流控方面：使用限流 + 降级技术。
-
自动化运维方面：网关流量调度，服务监控。
我不敢保证上面这些技术可以解决所有的问题，但是，只要我们设计得当，绝大多数的问题应该是可以扛得住的了。
下面我画一个图来表示一下。
在上面这个图上，我们可以看到，有三大块的东西。
-
冗余服务。通过冗余服务的复本数可以消除单点故障。这需要服务发现，负载均衡，动态路由和健康检查四个功能或组件。
-
服务解耦。通过解耦可以做到把业务隔离开来，不让服务受影响，这样就可以有更好的稳定性。在水平层面上，需要把业务或用户分片分区（业分做隔离，用户做多租户）。在垂直层面上，需要异步通讯机制。因为应用被分解成了一个一个的服务，所以在服务的编排和聚合上，需要有工作流（像Spring的Stream或Akka的flow或是AWS的Simple Workflow）来把服务给串联起来。而一致性的问题又需要业务补偿机制来做反向交易。
-
服务容错。服务容错方面，需要有重试机制，重试机制会带来幂等操作，对于服务保护来说，熔断，限流，降级都是为了保护整个系统的稳定性，并在可用性和一致性方面在出错的情况下做一部分的妥协。
当然，除了这一切的架构设计外，你还需要一个或多个自动运维的工具，否则，如果是人肉运维的话，那么在故障发生的时候，不能及时地做出运维决定，也就空有这些弹力设计了。比如：监控到服务性能不够了，就自动或半自动地开始进行限流或降级。
弹力设计开发和运维
对于运维工具来说，你至少需要两个系统：
- 一个是像APM这样的服务监控；
- 另一个是服务调度的系统，如：Docker + Kubernetes。
此外，如果你需要一个开发架构来让整个开发团队在同一个标准下开发上面的这些东西，这里，Spring Cloud就是不二之选了。
关于Spring Cloud和Kubernetes，它们都是为了微服务而生，但它们没有什么可比性，因为，前者偏开发，后者偏运维。我们来看一下它们的差别。
（图片来自：Deploying Microservices: Spring Cloud vs Kubernetes）
从上表我们可以得知：
-
Spring Cloud有一套丰富且集成良好的Java库，作为应用栈的一部分解决所有运行时问题。因此，微服务本身可以通过库和运行时代理解决客户端服务发现、负载均衡、配置更新、统计跟踪等。工作模式就像单实例服务集群。（译者注：集群中master节点工作：当master挂掉后，slave节点被选举顶替。）并且一批工作也是在JVM中被管理。
-
Kubernetes不是针对语言的，而是针对容器的，所以，它是以通用的方式为所有语言解决分布式计算问题。Kubernetes提供了配置管理、服务发现、负载均衡、跟踪、统计、单实例、平台级和应用栈之外的调度工作。该应用不需要任何客户端逻辑的库或代理程序，可以用任何语言编写。
下图是微服务所需的关键技术，以及这些技术中在Spring Cloud和Kubernetes的涵盖面。
（图片来自：Deploying Microservices: Spring Cloud vs Kubernetes）
两个平台依靠相似的第三方工具，如ELK和EFK stacks, tracing libraries等。Hystrix和Spring Boot等库，在两个环境中都表现良好。很多情况下，Spring Cloud和Kubernetes可以形成互补，组建出更强大的解决方案（例如KubeFlix和Spring Cloud Kubernetes）。
下图是在Kubernetes上使用Spring Cloud可以表现出来的整体特性。要做出一个可运维的分布式系统，除了在架构上的设计之外，还需要一整套的用来支撑分布式系统的管控系统，也就是所谓的运维系统。要做到这些，不是靠几个人几天就可以完成的。这需要我们根据自己的业务特点来规划相关的实施路径。
（图片来自：Deploying Microservices: Spring Cloud vs Kubernetes）
上面这张图中，对于所有的特性，都列举了一些相关的软件和一些设计的重点，其中红色的是运维层面的和Spring Cloud和Kubernetes不相关的，绿色的Spring Cloud提供的开发框架，蓝色的是Kubernetes相关的重要功能。
从今天看下来，微服务的最佳实践在未来有可能会成为SpringCloud和Kubernetes的天下了。这个让我们拭目以待。
我在本篇文章中总结了整个弹力设计，提供了一张总图，并介绍了开发运维的实践。希望对你有帮助。
也欢迎你分享一下你对弹力设计和弹力设计系列文章的感想。
文末给出了《分布式系统设计模式》系列文章的目录，希望你能在这个列表里找到自己感兴趣的内容。
- 弹力设计篇
- 管理设计篇
- 性能设计篇
精选留言
2018-03-27 13:01:59
2020-02-05 22:39:06
2018-03-27 13:46:31
2020-05-29 11:53:07
2018-03-29 19:20:45
2022-01-09 20:54:17
2018-05-30 20:05:22
2018-05-16 21:00:49
2018-04-09 19:25:32
2018-04-05 22:54:05
2020-04-27 12:34:22
2019-12-26 20:07:05
2019-07-13 08:39:34
2019-05-14 21:11:43
2019-02-08 11:01:50
2018-03-28 13:42:41
2018-03-28 07:10:09
2018-03-27 07:31:04
2025-06-16 14:58:10
2023-03-20 14:09:25
* 冗余服务：负载均衡、服务健康检查、服务发现、动态路由、自动化运维、Kubernetes 服务调度、伸缩和故障迁移
* 服务解耦：业务分片、用户分片、数据库拆分、自包含、服务发现、事件驱动、消息队列、业务工作流、服务调用链、性能监控
* 服务容错：重试、熔断、幂等、限流、降级、网关流量调度、服务监控、两阶段提交、异步通信
专栏在 2018 年的时候说，SpringCloud 和 Kubernetes 会成为主流，现在看，应该是应验了。
https://dzone.com/articles/deploying-microservices-spring-cloud-vs-kubernetes
看完之后，觉得自己来晚了。其实当年就知道，只是心动，没有行动。
那张总图很不错，如果能够对着图讲明白弹力设计，那么……