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

微服务架构开发在软件编程开发领域中是一种非常常见的软件开发方式了，而今天我们就一起来了解一下，基于微服务架构的系统软件在运行过程中都有哪些问题会发生。一：Hystrix是什么11:基本解释Hystrix开始由Netflix(看过美剧的都知道,它是一个美剧影视制作的巨头公司)开源的，后来由SpringCloudHystrix基于这款框架实现了断路器、线程隔离等一系列服务保护功能,该框架的目标在于通过控制访问远程系统、服务和三方库的节点，从而延迟和故障提供更强大的容错能力。hystrix具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能。起到了微服务的保护机制,防止某个单元出现故障从而引起依赖关系引发故障的蔓延，终导致整个系统的瘫痪。12:断路器的概念断路器本身是一个开关装置，用在电路上保护线路过载，当线路中有电器发生短路的时候。“断路器”能够及时切断故障，防止发生过载、发热甚至起火等严重后果。当分布式架构中，断路器模式起到的作用也是类似的。当某个服务发生故障的时候，通过断路器的故障监控向调用方返回一个错误响应，而不是长时间的线程挂机，无限等待。这样就不会使线程因故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。二：Hystrix解决超时问题21：问题假设我们前端提供了用户查询订单的功能，先请求映射到OrderController，控制器通过调用服务orderService获取订单信息，前端传过来两个参数：一个是订单id,一个是用户id,orderService需要通过用户id调取用户服务来获取用户的相关信息返回给订单服务去组装信息，假设这里是通过>微服务是一种基于有界上下文的，松散耦合的面向服务的架构。

什么场景下适用微服务？什么阶段时适用微服务？

设计的微服务系统的组织，其产生的架构设计应等价于组织间的沟通结构。

这句话的意思是说，原始组织之间的结构最好能映射到设计的微服务系统架构上。比如一个系统包含订单、商品、用户等功能，现实中分别由A、B、C三个小组进行开发维护，那么如果要拆分为微服务的架构，最好就能拆分为订单服务、商品服务、用户服务三个微服务，对应A、B、C三个现实的小组结构。

微服务并不是适合任何阶段，最好的方式就是随着项目的扩大或者团队的扩大时，逐步演进到微服务。因为单体应用会随着规模的扩大而逐渐增加内耗，导致生产力降低。微服务的目标是在规模扩大时，使得生产力能维持在一个稳定的水准之上。

微服务生产力超过单体的拐点，一般来说是指当团队人数规模达到百人时。当然，这也不是绝对的，需要团队负责人自己视情况进行评估。

如果在项目一开始就设计微服务的架构，一路上会遇到极大的困难与风险。比如业务模块边界的划分、无法预估的业务或者技术复杂性，这些都会耗费更多的人力和时间，甚至最终导致项目失败。

建议的方式就是由单体演进，我们可以在单体阶段不断摸索和沉淀业务和技术上的问题，随着越来越清晰的认知，再加上日渐增加的复杂度，可以考虑逐步拆分部分服务出来，朝着微服务架构的方向演进。

微服务架构中服务与服务各有不同，相互之间也应该按照层级的方式进行编排。有的与业务无关的服务天然属于底层基础服务，有的与业务有关联的服务则属于聚合了基础服务的聚合服务。

在常见的公司微服务总体架构中，一般的架构表现就如下所示：

有了各个层级的服务之后，中台的概念和战略就显得很自然。

服务注册与发现是微服务架构得以运转的核心功能，它不提供任何业务功能，仅仅用来进行服务的发现和注册，并对服务的健康状态进行监控和管理。其核心的工作原理：

现在注册中心比较多，主流的有Eureka、Consul、Zookeeper、Nacos等。

网关是整个系统对外暴露的唯一入口，它封装了系统内的所有微服务，对外看来，别人只知道也只能通过网关才可以和系统进行交互。网关对所有请求进行非业务功能的处理，然后再将请求发送给内部指定的微服务进行业务上的处理。总的来说，网关最主要的功能如下：

现在常见的网关有Kong、Zuul、Spring Cloud Gateway等；

在实际应用中，一个微服务体系架构的系统可以有多个网关用来应对不同的使用场景，比如公司内网网关、外网网关、提供给第三方调用的网关等；

微服务在启动和运行的过程中，经常会需要读取一些配置信息，这些配置信息拥有如下的特点：

如上这些特点和需求，催生了配置中心的出现。现在主流的配置中心有Spring Cloud Config、Nacos、Apollo等；

在微服务架构中，一次调用请求可能贯穿多个服务，这些服务可能是由不同的团队使用不同的技术开发而成的，如果出现调用失败需要排查问题时，如何能快速地复现调用现场，发现问题出在哪个服务哪个服务器上就成了全链路监控需要解决的问题。

全链路监控的基本原理都是：

全链路监控主流工具有CAT、Zipkin、Pinpoint、Skywalking等；

在微服务架构体系中，服务之间的调用是很频繁的，一旦某些服务出现故障或者高延迟，会很可能造成级联故障，如果客户端还在不停重试，将会加剧问题的严重性，最终导致整个系统彻底崩溃。

断路器的设计与实现有助于防止多服务之间的级联故障，允许我们构建具有容错性和高d性的微服务架构系统，当某些服务不可用时，提供服务熔断和服务降级功能，保证系统的其它部分仍能正常运行。

断路器的三个状态和含义如下：

主流常见的断路器有Hystrix、Sentinel等；

如果使用了容器技术，那么容器编排、发布、治理就成了避不开的话题。主流的技术如下：

各大容器云厂商基本都是使用基于k8s的容器治理方案，k8s也已经成为该领域事实上的标准了。

如上是自己在极客时间App上学习《微服务架构核心20讲》的笔记，该课程一天就能学完，没有实现微服务的细节，是高屋建瓴地讲解微服务架构的蓝图，带你鸟瞰整个微服务架构，推荐学习。

---