在传统的IT行业软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。到后面引入了SOA服务化，但是，由于SOA早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。最终SOA看起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。总结一下，太重了。侵入性强

相比传统SOA的服务实现方式，微服务更具有灵活性、可实施性以及可扩展性，其强调的是一种独立测试、独立部署、独立运行的软件架构模式。

微服务架构诞生于SOA，提倡将单一的应用程序按功能划分为更小的服务单元，服务之间采用通用轻量化机制进行通信，能够将服务单独部署到生产环境。

互联网行业的高速发展，需求变化快，用户群体大，要求系统架构上能灵活构建，易于扩展，还要考虑可伸缩性，高可用性等等。这些需求催生出微服务架构。

微服务不是银弹(不能解决所有的问题)，同样前面说的单体应用和SOA架构也没有过时，需要结合自己的业务场景来选择合适的架构。

在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。

• Spring Cloud是一系列框架的有序集合，具有丰富的生态。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，主要功能包括服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。
• ServiceComb作为功能完善的微服务框架，包括应用框架代码生成、服务注册发现、服务配置管理、服务监控、服务调用追踪等功能，为开发者提供端到端的应用DevOps体验。
• Apache Dubbo是一款高性能、轻量级的开源服务框架，提供了六大核心能力：面向接口代理的高性能RPC调用，智能容错和负载均衡，服务自动注册和发现，高度可扩展能力，运行期流量调度，可视化的服务治理与运维。

微服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台，使部署、管理和服务功能交付变得更加简单。

微服务架构模式涉及：

• 微服务之间的RPC通信。
• 分布式微服务实例和服务发现。
• 配置外置，动态、集中的配置管理。
• 提供熔断、隔离、限流、负载均衡等微服务治理能力。
• 分布式事务管理能力。
• 调用链、集中日志采集和检索。

下面问问详细来看下：

微服务之间的RPC通信（Remote Procedure Call，远程过程调用） 。微服务架构模式要求微服务之间通过RPC进行通信，不采用其他传统的通信方式，比如共享内存、管道等。常见的RPC通信协议包括REST、gRPC、Web Service等。使用RPC通信，能够降低微服务之间的耦合，提升系统的开放性，减少技术选型的限制。一般建议采用业界标准协议，比如REST。对于性`能要求非常高的场景，也可以考虑私有协议。

分布式微服务实例和服务发现。 微服务架构特别强调 架构的弹性，业务架构需要支持微服务多实例部署来满足业务流量的动态变化。微服务设计一般会遵循无状态设计原则，符合该原则的微服务扩充实例，能够带来处理性能的线性提升。

配置外置及动态、集中的配置管理 。配置管理中间件给所有微服务提供统一的配置管理视图，有效降低配置管理的复杂性。搭配治理控制台，可以在微服务运行态对微服务的行为进行调整。

提供熔断、隔离、限流、负载均衡等微服务治理能力 。微服务架构存在一些常见的故障模式，通过这些治理能力，容灾措施，能够减少故障对于整体业务的影响，避免雪崩效应。

分布式事务管理能力 。常见的分布式事务处理模式包括Saga、TCC、无侵入式等。分布式事务管理可以降低处理分布式事务一致性问题的难度。

调用链、集中日志采集和检索。查看日志仍然是分析系统故障最常用的手段，调用链信息可以帮助界定故障和分析性能瓶颈。

• Spring Cloud来源于Spring，质量、稳定性、持续性都可以得到保证。
• Spirng Cloud天然支持Spring Boot，更加便于业务落地。
• Spring Cloud发展非常的快。
• Spring Cloud是Java领域最适合做微服务的框架。
• 相比于其它框架，Spring Cloud对微服务周边环境的支持力度最大。
• 对于中小企业来讲，使用门槛较低。开源

优点：

• 产出于Spring大家族，社区生态完善
• 有Spring Boot这个独立干将可以省很多事,内嵌的web服务器，起不依赖，自动化配置，各种微服务组件兼容性好。
• Spring Cloud 活跃度很高，教程很丰富，遇到问题很容易找到解决方案。
• 提供了注解的方式来自动化配置，轻轻松松几行代码就完成了熔断、均衡负责、服务中心的各种平台功能。

缺点

• Spring Cloud也有一个缺点，只能使用Java开发，SDK侵入性强，sdk版本差距较大时需要对代码进行修改，对于废弃的api寻找一些新的替代，不适合小型独立的项目。

整理来讲，Spring Cloud对于中小型互联网公司来说是一种福音，因为这类公司往往没有实力或者没有足够的资金投入去开发自己的分布式系统基础设施，使用Spring Cloud一站式解决方案能在从容应对业务发展的同时大大减少开发成本。同时，随着近几年微服务架构和Docker容器概念的火爆，也会让Spring Cloud在未来越来越“云”化的软件开发风格中立有一席之地，尤其是在五花八门的分布式解决方案中提供了标准化的、全站式的技术方案，意义可能会堪比当年Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。

从上图可以看出Spring Cloud各个组件相互配合，合作支持了一套完整的微服务架构。

• 其中Eureka负责服务的注册与发现，很好地将各服务连接起来,不过现在已经不维护了
• Hystrix负责监控服务之间的调用情况，连续多次失败进行熔断保护。
• Hystrix dashboard，Turbine 负责监控Hystrix的熔断情况，并给予图形化的展示。
• Spring Cloud Config提供了统一的配置中心服务。当配置文件发生变化的时候，Spring Cloud Bus负责通知各服务去获取最新的配置信息。
• 所有对外的请求和服务，我们都通过Zuul来进行转发，起到API网关的作用。
• 最后我们使用Sleuth Zipkin将所有的请求数据记录下来，方便我们进行后续分析。

Spring Cloud从设计之初就考虑了绝大多数互联网公司架构演化所需的功能，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。这些功能都是以插拔的形式提供出来，方便我们系统架构演进的过程中，可以合理的选择需要的组件进行集成，从而在架构演进的过程中会更加平滑、顺利。

Spring Cloud提供了标准化的、全站式的技术方案，意义可能会堪比当前Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。

服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port，以及暴露服务自身状态以及访问协议等信息。

服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。

Spring Cloud Netflix是对Netflix开发的一套分布式服务框架的封装，包括服务的发现和注册，负载均衡、断路器、REST客户端、请求路由等。

负载均衡是高可用网络基础架构的关键组件，通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。