微服务架构和SpringCloud实践总结

Posted 2021-04-14 零点贪欢

在选择SpringCloud的之前，对微服务没有太多的体会和经验，我所在的开发团队也经历了从Spring MVC，Spring Boot，Spring Cloud发展的过程。这篇文章就是对这次微服务改造的经验总结。

首先介绍下什么是微服务。微服务的概念源于 2014 年 3 月 Martin Fowler 所写的一篇文章“Microservices”，文中描述了一些微服务架构的特点：

• Componentization via Services（通过服务进行组件化）

• Organized around Business Capabilities（围绕业务能力进行组织）

• Products not Projects（产品不是项目，这里我理解说的是一个持续发展的状态，因为项目和产品的一个重要的区别是是否有明确的截止日期）

• Smart endpoints and dumb pipes（智能端点和哑管道，我把他理解成一种系统的解耦）

• Decentralized Governance（分散治理，这里说的是服务的分散）

• Decentralized Data Management（分散数据管理）

• Infrastructure Automation（基础设施自动化，运维层面的支持）

• Design for failure（直译是“为失败而设计”，我觉得可以理解为容错性）

• Evolutionary Design（进化设计，可以理解为持续交付）

基于这些特点的系统架构，可以发现微服务相对于单体服务有一些自己的优势：

1. 降低业务复杂度。将业务及其数据都进行的分解，规避了复杂度的积累。每个服务功能单一，体积小，复杂度低，易于保持较高的可维护性和开发效率。

2. 服务独立部署。当某个业务发生变化时只需要重启部署相关的服务即可，无需重新编译、部署整个应用。同时也非常便于对某些服务进行横向扩展，增加系统的抗压性。

3. 技术选型灵活。每个对外提供的服务可以根据自身的业务特点使用，选择最合适的技术栈。这一点也是非常适合我们住这儿开发团队现在有Java和Python两大技术栈的现状，为今后可能遇到的情况提前考虑。

4. 提高系统容错性。传统架构下，某一业务逻辑发生问题，极有可能在系统内部蔓延并影响其他业务，造成整个应用不可用，就是我们常说的“雪崩”。在微服务架构下可以通过熔断，重试，服务降级等措施提高应用的容错性，防止雪崩的发生。

5. 扩展性灵活。传统架构在进行横向扩展的时候是要将整个应用复制到不同节点上。当不同的业务组件在扩展上出现差异的时候，微服务架构便可以从容应对，根据实际需求对每个服务进行扩展。

我在年前做的关于微服务架构分享的时候也曾提到过，虽然微服务架构有很多优点，但是也有他的不足，比如运维的成本较高，要求较高的运维能力，开发团队要具备DevOps能力，要面对分布式系统的复杂性，对异步的处理，测试的增加等等。所以说，任何一种架构都有自己的特点，如何选择适当的架构来应对业务的发展才是最重要的。

 

Spring / Spring MVC / Spring Boot / Spring Cloud 到底都是什么？

可能很多人都会搞不清楚这四个到底都是什么，简单的讲，Spring 框架是一个分层架构，目的是降低企业程序开的复杂性。是由 7 个定义良好的模块组成，具体包括核心容器（IoC），Spring Context，Spring AOP，Spring Dao，Spring ORM，Spring Web，Spring MVC。其中IoC和AOP是Spring的核心和精髓。而Spring MVC是Spring其中的一个模块。具体来说，Spring MVC是全功能的构建 Web 应用程序的 MVC 实现。所以说Spring MVC是一个MVC框架，通过Model-View-Controller模式来很好地将数据、业务与展现进行分离。

从上面介绍可以发现Spring框架功能很强大，而实现这些功能需要很多复杂的配置。Spring Boot框架的出现就是解决这个问题，它的作用很简单，核心就是自动配置。Spring Boot是Spring主推的一个原则：convention over configuration（约定大于配置）。Spring Boot官网上的一段介绍应该能非常清楚的表明其作用：“Spring Boot 使您能轻松地创建独立的、生产级的、基于 Spring 且能直接运行的应用程序。我们对 Spring 平台和第三方库有自己的看法，所以您从一开始只会遇到极少的麻烦。”

Spring Cloud是一套有序框架的集合，可以看出它是并不是一个框架，是一系列的框架。它利用 Spring Boot 的开发便利性巧妙地简化了分布式系统基础设施的开发。Spring Cloud的工具框架目前共集成了 19 个子项目，包括：

• Spring Cloud Config，配置中心，利用 git 集中管理程序的配置。

• Spring Cloud Netflix，集成众多 Netflix 的开源软件。

• Spring Cloud Bus，消息总线，利用分布式消息将服务和服务实例连接在一起，用于在一个集群中传播状态的变化 。

• Spring Cloud for Cloud Foundry，利用 Pivotal Cloudfoundry 集成你的应用程序。

• Spring Cloud Foundry Service Broker，为建立管理云托管服务的服务代理提供了一个起点。

• Spring Cloud Cluster，基于 Zookeeper、Redis、Hazelcast、Consul 实现的领导选举和平民状态模式的抽象和实现。

• Spring Cloud Consul，基于 Hashicorp Consul 实现的服务发现和配置管理。

• Spring Cloud Security，在 Zuul 代理中为 OAuth2 rest 客户端和认证头转发提供负载均衡。

• Spring Cloud Sleuth Spring Cloud，应用的分布式追踪系统和 Zipkin、HTrace、ELK 兼容。

• Spring Cloud Data Flow，一个云本地程序和操作模型，组成数据微服务在一个结构化的平台上。

• Spring Cloud Stream，基于 Redis、Rabbit、Kafka 实现的消息微服务，简单声明模型用以在 Spring Cloud 应用中收发消息。

• Spring Cloud Stream App Starters，基于 Spring Boot 为外部系统提供 Spring 的集成。

• Spring Cloud Task，短生命周期的微服务，为 Spring Boot 应用简单声明添加功能和非功能特性。

• Spring Cloud Task App Starters。

• Spring Cloud Zookeeper，服务发现和配置管理基于 Apache Zookeeper。

• Spring Cloud for Amazon Web Services，快速和亚马逊网络服务集成。

• Spring Cloud Connectors，便于 PaaS 应用在各种平台上连接到后端像数据库和消息经纪服务。

• Spring Cloud Starters，项目已经终止并且在 Angel.SR2 后的版本和其他项目合并。

• Spring Cloud CLI，插件用 Groovy 快速的创建 Spring Cloud 组件应用。

其中，Spring Cloud的核心主要包括：

• 分布式/版本化配置。

• 服务注册和发现。

• 路由。

• 服务和服务之间的调用。

• 负载均衡。

• 断路器。

• 分布式消息传递。

我们用一张图来展示各个核心功能以及他们之间的关系：解释一下这张图中各组件的运行流程：

• 所有请求都统一通过 API 网关（Zuul）来访问内部服务。

• 网关接收到请求后，从注册中心（Eureka）获取可用服务。

• 由 Ribbon 进行均衡负载后，分发到后端的具体实例。

• 微服务之间通过 Feign 进行通信处理业务。

• Hystrix 负责处理服务超时熔断。

• Turbine 监控服务间的调用和熔断相关指标。

 

这篇文章主要介绍了微服务的一些相关知识和技术框架，在下一篇文章会介绍微服务改造的一些实践和经验。