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

微服务架构开发在软件编程开发领域中是一种非常常见的软件开发方式了，而今天我们就一起来了解一下，基于微服务架构的系统软件在运行过程中都有哪些问题会发生。

一：Hystrix是什么

11:基本解释

Hystrix开始由Netflix(看过美剧的都知道,它是一个美剧影视制作的巨头公司)开源的，后来由SpringCloudHystrix基于这款框架实现了断路器、线程隔离等一系列服务保护功能,该框架的目标在于通过控制访问远程系统、服务和三方库的节点，从而延迟和故障提供更强大的容错能力。hystrix具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能。起到了微服务的保护机制,防止某个单元出现故障从而引起依赖关系引发故障的蔓延，终导致整个系统的瘫痪。

12:断路器的概念

断路器本身是一个开关装置，用在电路上保护线路过载，当线路中有电器发生短路的时候。“断路器”能够及时切断故障，防止发生过载、发热甚至起火等严重后果。当分布式架构中，断路器模式起到的作用也是类似的。当某个服务发生故障的时候，通过断路器的故障监控向调用方返回一个错误响应，而不是长时间的线程挂机，无限等待。这样就不会使线程因故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。

二：Hystrix解决超时问题

21：问题

假设我们前端提供了用户查询订单的功能，先请求映射到OrderController，控制器通过调用服务orderService获取订单信息，前端传过来两个参数：一个是订单id,一个是用户id,orderService需要通过用户id调取用户服务来获取用户的相关信息返回给订单服务去组装信息，假设这里是通过>

三：Hystrix的流程

Hystrix实际上的工作原理是这样的:通过command来解耦请求与返回 *** 作，在具体的实例中就是，Hystrix会对依赖的服务进行观察,通过commandtoObservable调用返回一个观察的对象，同时发起一个事件，然后用Subscriber对接受到的事件进行处理。北京北大青鸟建议在command命令发出请求后，它通过一系列的判断，顺序依次是缓存是否命中、断路器是否打开、线程池是否占满，然后它才会开始对我们编写的代码进行实际的请求依赖服务的处理，也就是Hystrixrun方法，如果在这其中任一节点出现错误或者抛出异常，它都会返回到fallback方法进行服务降级处理，当降级处理完成之后，它会将结果返回给,际的调用者,经过一系列流程处理的。

单服务器是适合微服务的。
单服务架构是一直以来的传统服务器架构，它在一台服务器上运行，然后由单一的程序提供服务。这种服务架构的好处，开发速度快，运行效率高。开始的时候你可以写出最基础的运行工作流程来，然后在以后的扩展中不断的添加功能。
单服务架构比微服务架构是因为单服务架构没有多余的服务之间的通信。像微服务架构，里面有很多微服务，它们之间的通信都是通过>

微服务是近些年被广泛提及的一个概念， 微服务架构可以理解为一个轻量级的服务治理方案， 也就是将系统的功能，通过服务的形式发布到服务器上，对服务进行组合调用，实现具体的功能，解决实际业务问题的架构风格。

微服务产生于单体应用的扩大化，随着信息化不断发展，企业对软件功能的要求越来越具体，也愈发的细致，如果通过应用程序来实现，必然是一个极其复杂而又痛苦的过程，由此诞生了微服务的概念。就是 将功能发布成服务，应用程序通过调用不同的服务来实现业务， 这种设计架构称之为微服务。

微服务架构的优点在于每个服务可以有独立的团队开发，服务之间互不干涉，保障了系统的稳定性。由于功能被拆分到更细的粒度，有效的降低了程序的复杂程度，对硬件的需求也随之降低，但是微服务也有一些不足，比如服务调用带来的系统复杂性，服务间的依赖关系也是难以管理的，如何构建合理的服务依赖是考验架构师能力的重要依据；最后，微服务架构的部署以及跟踪也是很难的。总之， 微服务架构有着自身的应用场景以及特点，了解哪些场景适合微服务比掌握微服务的具体技术更为重要， 适当的技术用在适当的场景，才能发挥合适的价值。

微服务架构是当前最流行的技术架构，主要组件有注册中心、网关、配置中心和各种微服务模块。架构灵活、易扩展、可动态扩容。

在微服务之前，系统架构经历很长时间的演变，简述如下：

1无架构

页面逻辑和业务逻辑混在一起，甚至页面直接访问数据库。

优点：因为没有太多的访问路径转换，效率是最高的；

缺点：没有分层，逻辑混乱，维护难，扩展难。

2MVC

架构

单系统，表现层、逻辑层、业务层分开，各层分工协作。

优点：逻辑清晰、分工明确、易维护。

缺点：系统集中部署，属于强耦合，某些业务模块出现异常时，会导致整个系统无法访问。

3SOA架构

面向服务的架构，多个系统分布式部署，通过消息总线进行通讯。

优点：各个系统的业务相对独立，耦合低；

缺点：消息总线负担太重，中心化太重，接口缺乏规范。

4微服务架构

一个系统，按照粒度规划，划分为很多的微服务，而每个微服务，对应一个具体的业务实现，并可拥有自己独立的数据库，整个就是微服务架构。

优点：如上，架构灵活、易扩展，在实际运营时，按需扩容，集群部署。各个微服务业务互不影响，耦合性低；

缺点：开发成本高，对部署有一定的专业性要求。

从技术而言，微服务已经是一个设计理念很成熟的架构，可满足不同层次，不同业务场景的需要，而且经过多个版本的迭代，该踩的坑也基本踩完，生态系统完整，开源组件选择多多，很有一统天下的趋势，值得尝试。

但，不要为了微服务而微服务，要根据自己实际的要求去做抉择和取舍。

比较，适合自己的，才是最好的！

微服务是近几年技术社群讨论很多的一种软件架构方式，可以说是SOA的现代版本、 时尚 版本。不过这次浪潮不是由大公司倡导的，而是由工程师们引领的。比如，它采用工程师们熟悉的RESTful接口，而不是笨重的WebService，也不需要一大堆昂贵的中间件。

那微服务为什么流行起来？按理说它们都是让软件更加模块化，使相互之间保持松耦合，从而优化系统架构。

国内流行起来的微服务架构——RestCloud

RestCloud 为了保证服务不注册中心癿高可用性，服务不注册中心通过水平扩展癿能

力允许对服务不注册中心迚行集群配置，开在网关层做了服务癿注册癿数据缓存。

Spring Cloud Eureka 是 Spring Cloud Netflix 微服务套件中癿一部分，它基于 Netflix Eureka做了二次封装。主要负责完成微服务架极中的服务治理功能。

易用性

如果你目前使用SpringBoot开发API服务则无需修改任何代码，只需引入RestCloud配置中心的jar包即可由配置中心接管所有配置，对开发人员无任何感知，如果你使用RestBoot开发平台开发API则已经是天然集成了配置中心的客户端Jar包无需任何依赖。 如果你使用php,c#开发目前RestCloud并没有提供现成的解决方案，你需要通过Rest API来接入RestCloud配置中心并自已在本地实现配置缓存管理。

稳定性

RestCloud采取全新的本地配置持久化技术，保证配置中心不会形成单点故障，因为所有的配置数据在应用则具有本地缓存和持久化技术，假定RestCloud配置中心出现故障且长时间未能恢复的情况下，应用则的程序会自动读取本地缓存配置数据 进一步假定这时应用也刚好出现故障需要重启，则本地缓存在重启后将会消失,这时应用将自动从持久层再次读取配置数据到缓存中从而恢复运行，所以RestCloud配置中心不会出现故障后影响应用的运行,RestCloud配置中心优于目前开源的大多数配置中心解决方案。

易用性

如果你目前使用SpringBoot开发API服务则无需修改任何代码，只需引入RestCloud配置中心的jar包即可由配置中心接管所有配置，对开发人员无任何感知，如果你使用RestBoot开发平台开发API则已经是天然集成了配置中心的客户端Jar包无需任何依赖。 如果你使用php,c#开发目前RestCloud并没有提供现成的解决方案，你需要通过Rest API来接入RestCloud配置中心并自已在本地实现配置缓存管理。

稳定性

RestCloud采取全新的本地配置持久化技术，保证配置中心不会形成单点故障，因为所有的配置数据在应用则具有本地缓存和持久化技术，假定RestCloud配置中心出现故障且长时间未能恢复的情况下，应用则的程序会自动读取本地缓存配置数据 进一步假定这时应用也刚好出现故障需要重启，则本地缓存在重启后将会消失,这时应用将自动从持久层再次读取配置数据到缓存中从而恢复运行，所以RestCloud配置中心不会出现故障后影响应用的运行,RestCloud配置中心优于目前开源的大多数配置中心解决方案。

网站链接：>两年前，第一次真正接触微服务的概念，但也只是简单地进行了使用，当时技术栈主要是 Spring Boot,那时 Spring Cloud 也比较流行，但是由于各种原因，并没有转向这套（甚至用 zookeeper 实现了简单的服务发现），理论上来说，用了 Spring Boot 再转向 Spring Cloud 应该是很正常的事情。当时也认为 Spring Cloud 各种理念很高级，实现上也不错，也有 Netflix 等之类的大公司背书，而且和 Spring 天然集成的，使用起来还是比较方便。当时可能觉得其他的 RPC 框架：如 Dubbo 和 Spring Cloud 相比简直差了一个档次，可能大家都认为 Spring Cloud 是未来。

从第一家公司离职后，去了另外一家公司，发现一个很奇怪的特点，这家公司的技术比较保守，基本还是十年前或者五六年前的技术架构。记得之前看过一本书上说过，技术不与时俱进，那就相当于自取灭亡，特别是技术驱动型公司，如果一直停滞不前，那就相当于你拿几十年前的武器和别人战斗，那结果自然是必然的。为什么技术要与时俱进，不是因为有了新技术就要去使用它，而是因为新技术往往可以提高业务的运转效率，同时也可以降低成本。不过在这个公司待了两个月，还是觉得有可取的地方，第一点是对代码质量的追求，由于业务的体量和特殊性（大概是亿级），所以对代码有较高的要求；第二点是对微服务整体架构的深入，虽然这个系统没有上 Spring Cloud ,甚至 Spring Boot 都没有，还是很老的一个架构，但其中微服务的思想已经有了，比如服务的拆分，服务的水平扩展，基于 Dubbo 的一些服务发现和治理，整体来说已经算是不错了，但是也总在思考，感觉还是少了什么东西。
容器化和 CI/CD

后来又到了一家比较年轻活跃的公司，接触到 Docker 的大规模使用以及 CI/CD，也是在这里，形成了整个对微服务完整生命周期的理解。 Docker 其实流行也很久了， 但是真正线上使用的并没有那么多，最近随着 Kubernetes（ k8s ） 的流行，更多公司也开始关注起来。

首先为什么服务要容器化，第一点是不再依赖于运行环境，只要有 Docker 就可以跑起来，无论你是什么发行版的 Linux 系统，还是 Windows，Mac。这有点像 JVM，屏蔽底层的细节，一次编写，到处运行，用在容器上就是一次构建，到处运行。第二点是容器化可以更好的进行持续集成，由于第一点的缘故，部署一个服务容器将非常快捷，这更加适合目前 devops 的理念。

持续集成(Continuous Integration)简称 CI ,持续部署（Continuous Deployment)简称 CD,如果微服务不把 CI/CD 放在首位，那必然整个流程就是不流畅的。有些公司还是手动本地构建包，然后 上传 到服务器上跑起来，进行这样的人肉运维，人肉上线，要么考虑一下，是不是整个 CI/CD 有问题，或者根本就没有 CI/CD 。其次 CI/CD 流程要做到每次构建自动跑单元测试，集成测试，以及 API 测试，UI 测试等等，这些流程也没有自动化的话，也谈不上完整的 CI/CD。如果没有经过这些流程把包直接上传到服务器，不出问题，那应该要烧柱香，拜拜佛。

云原生应用和服务网格

云原生应用遵循 Twelve-Factor ，云原生应用是为了解决传统应用发布升级流程缓慢、架构复杂，可维护性差而提出的的一个思想集合，集中了 微服务，devops，云等多种思想。

云原生应用应用可以跑在任意一家云服务商上，也可以实现多家服务商同时使用，同时也支持公有云和私有云的混合部署，这只是它的一个特点，更多的特点还是集中在解决传统应用面临的问题，如灰度发布，不停机发布，A/B Test, 快速回滚，服务治理等。
服务网格（Service Mesh）是一个比较新的概念，但是核心思想并不新。Spring Cloud 以框架的形式侵入到程序中来解决微服务的各种问题，理论上来说，应该是效率最高，最灵活的一种做法。但是侵入性太强，而且只能 Spring 这套，异构语言的系统玩不转。Service Mesh 从另外一个角度来解决这个问题，也就是 sidecar 和 proxy，这样虽然性能上有些损失，但是扩展性却是比较灵活的，将这些基础能力（服务发现，服务治理，熔断限流，监控等）下放到基础设施中，做到对应用程序透明，是一个不错的进步。写业务逻辑不需要再去和这些东西纠结，代码逻辑也变得十分明朗。同时这样也解决了异构语言系统的问题，无论什么语言，都是可以完美的工作在一起，简直是一个完美世界。但是但是但是 Service Mesh 由于还比较新，目前还不能进行生产环境使用，就拿目前最流行的 Istio 来说，目前只发布了 08 版本，还不能实际使用，估计 10 也不行，可能得 12 才推荐生产，所以现在就面临一个困境，Service Mesh 是一个好东西，但是我们却用不了，呜呼哀哉。

Spring Cloud 和 Service Mesh

首先两者解决问题的方式不一样，Spring Cloud 是直接的方式，Service Mesh 是委婉的方式，这可能会造就两者之后的命运。如果目前已经上了 Spring Cloud 或者其他的，系统已经具有基础的服务治理能力，先不要考虑 Service Mesh ，要先去考虑容器化和 CI/CD ；如果没有太多的 历史 负担，则是可以考虑。

总结

技术发展太快，不能停滞不前，也不能盲目追风。当年的 SSH 也只剩下了 Spring，可是有人说 Spring 只能一个季节用，但是 Service Mesh 整年都可以用，好像很有道理。最后，路漫漫而修远兮，吾将上下而求索。

---