微服务架构的软件运行可能存在哪些问题？

微服务架构开发在软件编程开发领域中是一种非常常见的软件开发方式了，而今天我们就一起来了解一下，基于微服务架构的系统软件在运行过程中都有哪些问题会发生。一：Hystrix是什么?1.1:基本解释Hystrix开始由Netflix(看过美剧的都知道,它是一个美剧影视制作的巨头公司)开源的，后来由SpringCloudHystrix基于这款框架实现了断路器、线程隔离等一系列服务保护功能,该框架的目标在于通过控制访问远程系统、服务和三方库的节点，从而延迟和故障提供更强大的容错能力。hystrix具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能。起到了微服务的保护机制,防止某个单元出现故障.从而引起依赖关系引发故障的蔓延，终导致整个系统的瘫痪。1.2:断路器的概念断路器本身是一个开关装置，用在电路上保护线路过载，当线路中有电器发生短路的时候。“断路器”能够及时切断故障，防止发生过载、发热甚至起火等严重后果。当分布式架构中，断路器模式起到的作用也是类似的。当某个服务发生故障的时候，通过断路器的故障监控向调用方返回一个错误响应，而不是长时间的线程挂机，无限等待。这样就不会使线程因故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。二：Hystrix解决超时问题2.1：问题假设我们前端提供了用户查询订单的功能，先请求映射到OrderController，控制器通过调用服务orderService获取订单信息，前端传过来两个参数：一个是订单id,一个是用户id,orderService需要通过用户id调取用户服务来获取用户的相关信息返回给订单服务去组装信息，假设这里是通过http请求的，我们有一个单独的工程叫做：userService部署在其他的服务器上。但是这个服务器宕机了，这时候订单服务调取用户信息就失败了，然后查询订单整个请求就失败了!由一个服务的宕机就导致整个查询都失败了，牵一发而动全身。三：Hystrix的流程Hystrix实际上的工作原理是这样的:通过command来解耦请求与返回操作，在具体的实例中就是，Hystrix会对依赖的服务进行观察,通过command.toObservable调用返回一个观察的对象，同时发起一个事件，然后用Subscriber对接受到的事件进行处理。昆明北大青鸟http://www.kmbdqn.cn/建议在command命令发出请求后，它通过一系列的判断，顺序依次是缓存是否命中、断路器是否打开、线程池是否占满，然后它才会开始对我们编写的代码进行实际的请求依赖服务的处理，也就是Hystrix.run方法，如果在这其中任一节点出现错误或者抛出异常，它都会返回到fallback方法进行服务降级处理，当降级处理完成之后，它会将结果返回给,际的调用者,经过一系列流程处理的。

一般情况下，每个微服务之间是独立的，如果某个服务宕机，只会影响到当前服务，而不会对整个业务系统产生影响。但是，服务端可能会在多个微服务之间产生一条链式调用，并把整合后的信息返回给客户端。在调用过程中，如果某个服务宕机或者网络不稳定可能造成整个请求失败。因此，为了应对微服务的链式调用异常，我们需要在设计微服务调用链时不宜过长，以免客户端长时间等待，以及中间环节出现错误造成整个请求失败。此外，可以考虑使用消息队列进行业务解耦，并且使用缓存避免微服务的链式调用从而提高该接口的可用性。

如果大家了解微服务和分布式服务器架构等技术的话，那么对于如何解决系统运行中出现的BUG造成的破坏和损失这些问题也应该有自己独到的见解吧。

今天，电脑培训http://www.kmbdqn.cn/就一起来了解一下，在服务器运行过程中出现的问题都有哪些解决方法。

随着微服务和分布式云架构的崛起，Web变得日趋复杂，“随机性”的故障因此变得越来越难以预测，而我们对这些系统的依赖却与日俱增。

这些故障给公司造成巨大损失，也给用户带来很大的麻烦，影响他们进行在线购物、交易或打断他们的工作。

即使是一些简单的故障也会触及公司的底线，因此，宕机时间就成为很多工程团队的KPI。

2017年，有98%的企业表示，一小时的宕机时间将给他们带来超过10万美元的损失。

一次服务中断有可能让一个公司损失数百万美元。

近，英国航空的CEO透露，2017年5月发生的一次技术故障造成数千名乘客滞留机场，给公司造成8000千万英镑的损失。

企业需要想办法解决这些问题，因为等到下一次事故发生就为时已晚。

为此，混沌工程应运而生。

混沌工程旨在将故障扼杀在襁褓之中，也就是在故障造成中断之前将它们识别出来。

通过主动制造故障，测试系统在各种压力下的行为，识别并修复故障问题，避免造成严重后果。

混沌工程将预想的事情与实际发生的事情进行对比，通过“有意识地搞破坏”来提升系统的弹性。

混沌工程简史混沌工程先出现在互联网巨头公司中，这些公司拥有大规模的分布式系统，因为这些系统太过复杂，他们需要一些新的手段来测试它们。

2010年NetflixEngTools团队开发出了ChaosMonkey。

当时，Netflix从物理基础设施迁移到AWS上，为了保证AWS实例的故障不会给Netflix的用户体验造成影响，他们开发了这个工具，用来测试系统。

2011年SimianArmy诞生，在ChaosMonkey的基础上增加了故障注入模式，可以测试更多的故障场景。

Netflix认为，云的特点是冗余和容错，但没有哪个组件能够保证100%的可用性，所以他们必须设计出一种云架构，在这种架构里，个体组件的故障不会影响到整个系统。

2012年Netflix在GitHub上开源了ChaosMonkey，并声称他们“已经找到了应对主要非预期故障的解决方案。

通过经常性地制造故障，我们的服务因此变得更有弹性。

”2014年Netflix团队创建了一种新的角色，叫作混沌工程师。

BruceWong发明了这个角色，并由DanWoods在Twitter上向广大的工程社区推广。

DanWoods解释说，“我从KoltonAndrus那里学到了更多有关混沌工程的知识，他把它叫作故障注入测试”。

2014年10月，当时Gremlin的联合创始人KoltonAndrus还在Netflix，他们在SimianArmy的基础上提出了故障注入测试(FIT)概念，开发者可以更灵活地控制注入故障的“杀伤力范围”。

因为SimianArmy有时候会造成非常严重的故障，所以Netflix的开发者对它抱有疑虑，而FIT可以更好地控制故障粒度，于是他们就由此想出了混沌工程这个概念。

---