Springboot/Springcloud微服务架构

2019-01-23 07:40:31来源：博客园阅读 ()

1. 什么是微服务？

　　微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务之间是松耦合的，同时微服务之间，通常是采用轻量级的基于 HTTP 的 RESTful API通信机制互相沟通，互相配合。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境。

2. 微服务有什么特点？

(1).复杂度可控

在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。

(2).独立部署

独立部署由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。

(3).技术选型灵活

微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，所以需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。

(4).容错

当某一组件发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。

(5).扩展

单块架构应用也可以实现横向扩展，当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

3. Spring Boot / Cloud 都做了那些事情?

(1).什么是 Spring Boot？

Spring Boot使用了特定的方式来进行配置，其设计目的是用来简化新 Spring 应用的初始搭建以及开发过程，从而使开发人员不再需要定义样板化的配置. Spring Boot 不是什么新的框架，它默认配置了很多框架的使用方式，Spring Boot 简化了基于 Spring 的应用开发，通常我们想要集成的常用框架，它都有对应的组件支持，通过少量的代码就能创建一个独立的、产品级别的 Spring 应用.

Spring Boot的核心功能 :

(1) 起步依赖

SpringBoot工程继承spring-boot-starter-parent后已经具备版本锁定等配置了，然后对于我们需要的某种功能添加起步依赖，起步依赖会进行依赖的传递，这些依赖组合在一起即支持某项功能。简单的说，起步依赖就是将具备某种功能的坐标打包到一起，并提供一些默认的功能。

Spring Boot配置文件的加载：

传递依赖时会依次从resources目录下加载application.yml和application.properties配置文件。

(2).自动配置

Spring Boot的自动配置是一个运行时（更准确地说，是应用程序启动时）的过程，考虑了众多因素，才决定 Spring配置应该用哪个，不该用哪个。该过程是Spring自动完成的。

SpringBoot可以简化开发的一个主要原因就是采用了默认配置，所谓约定大于配置就是这个意思。在没有自己指定配置的时候使用默认配置的原理，如若需要更改配置，则需要在application.properies或者application.yml配置中添加对应属性。

Spring Boot自动配置运行原理：

(1). SpringBoot项目运行类启动，就是添@SpringBootApplication注解的类。

先看@SpringBootApplication

@SpringBootConfiguration：标记当前类为主配置类
@EnableAutoConfiguration：开启自动配置
@ComponentScan：扫描主类所在的同级包以及下级包里的被注解的Bean

(2).自动配置的核心功能是由@EnableAutoConfiguration这个注解提供的。

@Import(AutoConfigurationImportSelector.class)导入的配置功能，

AutoConfigurationImportSelector里有一个selectImports方法，这个方法里有一个configurations，返回的configurations对象中包含待配置的class的类名集合。

在方法里调用了getCandidateConfigurations方法, 而这个方法里又调用了SpringFactoriesLoader下的loadFactoryNames方法, loadFactoryNames方法会扫描META-INF/spring.factories文件, 这文件列出了哪些需要自动配置。

但是自动配置类是否会被自动配置，还需要满足类上边注明的条件判断注解。

这里使用非常常用的DataSourceAutoConfiguration类来做例子讲解一下自动配置的流程。首先进入这个类，可以上面的几个注解。简单介绍一下这几个注解的作用。

@Configuration注解：声明此类为配置类。

@ConditionalOnClass注解：判断classpath下是否存在后面指定的类，因为我这里没有引入对应的类，所以会报红，所以这个自动配置也并没有生效。

@EnableConfigurationProperties注解：启用ConfigurationProperties功能，这个注解后面指定的类就是需要映射属性到配置文件的属性类。这里的配置文件是指application.properties文件.(如若要修改默认配置，可在此配置文件添加自定义属性和值得键值对)

@Import注解：数据库配置相关的类，有的自动配置类时没这个注解的，比如RedisAutoConfiguration类，所以这个看具体情况，但是前面三个注解是必须的。

附：常见org.springframework.boot.autoconfigure.condition包下的条件注解意思

@ConditionalOnBean：当容器里有指定的bean的条件下。

@ConditionalOnMissingBean：当容器里不存在指定bean的条件下。

@ConditionalOnClass：当类路径下有指定类的条件下。

@ConditionalOnMissingClass：当类路径下不存在指定类的条件下。

@ConditionalOnProperty：指定的属性是否有指定的值，比如@ConditionalOnProperties(prefix=”xxx.xxx”, value=”enable”, matchIfMissing=true)，代表当xxx.xxx为enable时条件的布尔值为true，如果没有设置的情况下也为true。

Spring Boot的使用：

(1). 创建一个maven工程，该工程为普通的java工程即可。

(2). SpringBoot要求项目要继承SpringBoot的起步依赖spring-boot-starter-parent

(3). 提供SpringBoot引导类。

(4). 在引导类同级包或者子级包中创Controller类。

(2).什么是Spring Clound？

Spring Cloud 是一系列框架的有序集合，它是基于Spring Boot实现的微服务架构开发工具，并且为微服务中设计的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策精选、分布式会话和集群状态管理等操作提供了一套简单的开发方式，这些操作都可以用 Spring Boot 的开发风格做到一键启动和部署。

Spring Cloud 原理详解及核心组件使用：

推荐博文:https://blog.csdn.net/qq_41701956/article/details/83829539

4.微服务、Springboot、Springcloud他们三者之间又有什么关系?

(1).微服务是一种架构的理念，提出了微服务的设计原则，从理论为具体的技术落地提供了指导思想。

(2).Spring Boot 是一套快速配置脚手架，可以基于 Spring Boot 快速开发单个微服务。

(3).Spring Cloud基于 Spring Boot 实现服务治理工具包;Spring Boot 专注于快速、方便集成的单个微服务个体;Spring Cloud 关注全局的服务治理框架。Spring Boot / Cloud 是微服务实践的最佳落地方案。

Spring Cloud 和Dubbo分布式架构的对比.

(1).从两个公司的背景来谈

Dubbo是阿里巴巴服务化治理的核心框架，并被广泛应用于中国各互联网公司;Spring Cloud 是大名鼎鼎的 Spring 家族的产品。阿里巴巴是一个商业公司，虽然也开源了很多的顶级的项目，但从整体战略上来讲，仍然是服务于自身的业务为主。Spring 专注于企业级开源框架的研发，不论是在中国还是在世界上使用都非常广泛，开发出通用、开源、稳健的开源框架是他们的主业。

(2).从社区活跃度这个角度来对比

Dubbo 虽然也是一个非常优秀的服务治理框架，并且在服务治理、灰度发布、流量分发这方面做的比 Spring Cloud 还好，除过当当网在此基础上增加了 rest 支持外，已有两年多的时间几乎没有任何更新了。在使用过程中出现问题，开发者提交到 GitHub 的 Issue 也少有回复。相反 Spring Cloud 自从发展到现在，仍然在不断的高速发展。从 GitHub 上提交代码的频度和发布版本的时间间隔就可以看出，现在 Spring Cloud 即将发布 2.0 版本，到了后期会更加完善和稳定。

(3).从整个大的平台架构来讲

Dubbo 框架只是专注于服务之间的治理，如果我们需要使用配置中心、分布式跟踪这些内容都需要自己去集成，这样无形中增加了使用 Dubbo 的难度。Spring Cloud 几乎考虑了服务治理的方方面面，更有 Spring Boot 的支持，开发起来非常的便利和简单。

(4).从技术发展的角度来讲

Dubbo 刚出来的那会技术理念还是非常先进，解决了各大互联网公司服务治理的问题，中国的各中小公司也从中受益不少。经过了这么多年的发展，互联网行业也是涌现了更多先进的技术和理念，Dubbo 一直停滞不前，自然有些掉队，有时候我个人也会感到有点可惜，如果 Dubbo 一直沿着当初的那个路线发展，并且延伸到周边，今天可能又是另一番景象了。

(5).两者使用特点

首先springcloud对比dubbo，最大的特点之一就是使用Restful的模式进行交互，dubbo是基于RPC进行通信的，而Restful是基于Http协议进行的，从协议的角度上来说Http和RPC都是基于TCP进行研发的协议，Http是最广泛的，不仅支持浏览器还支持各种APP通信，这么来说吧Http就是大家都在用的协议，而RPC是针对某一个平台某一个环节针对性开发的自定义协议，Http由于大众化，所以本身协议会有点笨重，解析起来自然也比RPC要慢，这也是RPC的优势之一，但是Http具有良好的跨平台性质

微服务 vs 传统开发

1.分工不同，以前我们可能是一个一个模块，现在可能是一人一个系统。

2.架构不同，服务的拆分是一个技术含量很高的问题，拆分是否合理对以后发展影响巨大。

3.部署方式不同，如果还像以前一样部署估计累死了，自动化运维不可不上。

4.容灾不同，好的微服务可以隔离故障避免服务整体 down 掉，坏的微服务设计仍然可以因为一个子服务出现问题导致连锁反应。

5.给数据库带来的挑战

每个微服务都有自己独立的数据库，那么后台管理的联合查询怎么处理?这是大家普遍遇到的一个问题。

有如下三种处理方案：

(1).严格按照微服务的划分来做，微服务相互独立，各微服务数据库也独立，后台需要展示数据时，调用各微服务的接口来获取对应的数据，再进行数据处理后展示出来，这是标准的用法，也是最麻烦的用法。

(2).将业务相关的表放到一个库中，将业务无关的表严格按照微服务模式来拆分，这样既可以使用微服务，也避免了数据库各种切换导致后台统计难以实现，是一个折中的方案。

(3).数据库严格按照微服务的要求来切分，以满足业务高并发，实时或者准实时将各微服务数据库数据同步到 NoSQL 数据库中，在同步的过程中进行数据清洗，用来满足后台业务系统的使用，推荐使用 Mongodb、Hbase 等。

第一种方案适合业务较为简单的小公司;第二种方案，适合想在原有系统之上，慢慢演化为微服务架构的公司;第三种适合大型高并发的互联网公司。