左耳听风_052_51_弹力设计篇之弹力设计总结
你好，我是陈浩网名左尔多house.我们前面讲了那么多的弹力设计的设计模式，所以在这里呢做个总结。
首先呢我们的服务不能是单点，所以我们需要在架构中啊冗于服务啊，也就是说有多个服务的副本。
那需要使用到的具体技术呢有以下三种。
那第一种呢是负载均衡，加上服务健康检查，可以使用像engineers或者HA proxy这样的技术。
那第二种呢是服务发现加上动态路由，加上服务健康检查，比如council或者zookeeper.那第三种呢是自动化运维，比如cooper、 netives服务、调度伸缩和故障牵引。
然后呢我们就需要隔离我们的业务。
那要隔离我们的服务呢，我们就需要对服务啊进行解耦和拆分。
那这个呢就需要使用到以前的相关技术。
那第一个呢是括bhes模式，包括业务分片用户分片数据库拆分。
那第二呢是自包含系统。
所谓的自包含的系统呢，就是从单体到微服务的中间状态。
他把一组密切相关的微服务啊给拆分出来，只需要做到没有外部依赖就行。
那第三呢是异步通讯，包括服务发现、事件驱动、消息、队列、业务工作流。
那第四呢是自动化运维，就是需要一个服务调用电和性能的监控系统。
然后呢，接下来啊我们就要进行能让整个架构接受失败的相关处理设计啊，也就是所谓的容错设计。
那这个呢会用到这样一些技术。
那第一呢在错误方面啊，调用重试熔断，加上服务的幂等项设计。
那第二呢，在一致性方面，强一致性是用两阶段提交最终一致性，使用异务通讯方式。
那第三呢在流控方面使用限流和降解技术。
呃，第四呢，在自动化运维方面啊，使用网关、流量调度，还有服务监控。
我不敢保证有这些技术啊可以解决所有的问题。
但是呢只要我们设计得当，绝大多数的问题啊应该是可以扛得住的了。
我在文中呢画了一个图来表示，在这个图上呢我们可以看到有三大块的东西。
那第一块呢是冗余服务，通过冗余服务的副本数可以消除单点故障。
那这个呢需要服务发现负载均衡、动态路由和健康检查四个功能或者组件。
那第二块呢是服务解耦。
那通过解耦呢，可以做到把业务隔离开来，不让服务间受影响。
那这样呢就可以有更好的稳定性。
在水平层面上呢，需要把业务或者用户分片分区，在垂直层面上呢需要一补通讯启式。
因为应用被分解成了一个一个的服务，所以在服务的编排和聚合上呢，需要有工作流来把服务给串联起来。
而仪式性的问题呢又需要业务补偿机制来做反向交易。
那第三块呢是服务容错，在服务容错方面需要有重试的机制。
重试的机制呢会带来密种操作。
那对于服务保护来说啊，熔断、限流、降级都是为了保护整个系统的稳定性，并在可用性和一致性方面啊，在出错的情况下做一部分的妥协。
那当然呢除了这一切的架构设计之外呢，你还需要一个或者多个自动运维的工具。
否则呢如果是人肉运维的话，那么在故障发生的时候啊，不能及时的做出运维决定，也就空有这些弹力设计了。
比如监控到服务性能不够了啊，就自动的或半自动的开始进行限流或者降级。
前面呢我总结了弹力设计的总图。
那接着呢我们来说弹力设计的开发和运维。
那对于运维工具来说呢，你至少需要两个系统。
那一个呢是像APM这样的服务监控。
那另一个呢是服务调度的系统，比如docker加上cubper netice.此外呢，如果你需要一个开发架构，来让整个开发团队在同一个标准下开发上面的这些东西。
那么在这里呢，spring cloud啊就是不二之选了。
那关于spring cloud和couper natives啊，他们都是为了微服而生，但他们没有什么可比性。
因为前者啊偏开发，后者呢偏运维。
我们通过文中的这张表格来看一下它们的差别。
从表中呢我们可以得知，那spring cloud呢有一套丰富并且集成良好的java库作为应用栈的一部分，解决所有运行时的问题。
因此呢微服务本身啊可以通过库和运行时代理解决，客户端服务，发现负载均衡、配置更新和统计跟踪等。
那工作模式呢就像单实力服务集群，并且啊一批工作也是在GVM中管理的。
另外呢couper natives它不是针对语言的，而是针对容器的了。
所以呢它是以通用的方式为所有的语言解决分布式计算的问题couper netities呢提供了配置管理服务，发现负载均衡、跟踪统计单、实力、平台级和应用站之外的调度工作。
那这个应用啊不需要任何客户端逻辑的库或者代理程序，可以用任何语言来编写。
我在文中呢用了一张图，总结了微服务所需的关键技术。
还有呢这些技术中the spring cloud和coronnatives的涵盖面两个平台呢，依靠相似的第三方工具，比如ELK和EFK、 stacks和tracing libraries等。
Histicks和spring boot.这些库能在两个环境中表现都很好。
很多情况下呢，spring cloud和proper natice可以形成互补，组建出更强大的解决方案。
我们再来看文中下面这张图，它呢展示了在酷睿netice上使用spring cloud可以表现出来的整体特性。
要做出一个可以运维的分布式系统。
啊，除了在架构上的设计之外呢，还需要一整套的用来支撑分布式系统的管控系统，也就是所谓的运维系统。
那要做到这些呢，不是靠几个人几天就可以完成的那这个呢需要我们根据自己的业务特点来规划相关的实施路径。
那这张图中呢对于所有的特性啊，我都列举了一些相关的软件和一些设计的重点。
那其中红色的呢是运维层面的，与spring cloud和cupnenetice不相关的那绿色的呢是spring cloud提供的开发框架，蓝色的呢是cooonnetice相关的重要功能。
从今天看下来啊，微服务的最佳时践啊，在未来啊有可能会成为spring cloud和coronnatives的天下了。
那就让我们拭目以待吧。
我在本节课中呢总结了整个弹力设计提供了一张总图，并且呢介绍了开发运维的实践，希望能对你有帮助。
也欢迎你分享一下你对弹力设计和弹力设计系列文章的感想。
文末呢我给出了分布式系统模式系列文章的目录，希望能在这个列表里啊找到自己感兴趣的内容。