微服务架构解决方案介绍

1、微服务架构

目前微服务是非常火的架构或者说概念，也是在构建大型互联网项目时采用的架构方式。

1.1 单体架构

在软件设计中，经常提及和使用经典的3层模型，即表示层、业务逻辑层和数据访问层。

·表示层：用于直接和用户交互，也称为交互层，通常是网页、UI 等。

·业务逻辑层：即业务逻辑处理层，例如用户输入的信息要经过业务逻辑层的处理后，才能展现给用户。

·数据访问层：用于操作数据库，用户在表示层会产生大量的数据，通过数据访问层对数据库进行读写操作。

虽然在软件设计中划分了经典的3层模型，但是对业务场景没有划分。一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包，部署在一台服务器上。

单体架构图如下所示：

1.1.1 单体架构的优点

·部署简单由于是完整的结构体，可以直接部署在一个服务器上即可。

·技术单一 项目不需要复杂的技术栈，往往一套熟悉的技术栈就可以完成开发。

·用人成本低 单个程序员可以完成业务接口到数据库的整个流程。
 

1.1.2 单体架构的缺点

系统启动慢 , 一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长

系统错误隔离性差、可用性差，任何一个模块的错误均可能造成整个系统的宕机

·可伸缩性差;系统的扩容只能只对这个应用进行扩容，不能做到对某个功能点进行扩容

·线上问题修复周期长;任何一个线上问题修复需要对整个应用系统进行全面升级
 

1.2 微服务架构

就目前来看微服务并没有一个 严格 的定义 每一个人对 微服务 的理解都是不一样的 . Martin Fowler在它的博客中是这样表述微服务的

博客地址 : https://martinfowler.com/articles/microservices.html

微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法每一个服务运行在自己的进程中服务间通信采用的轻量级通信机制通（常用HTTP 资源 API ). 这些服务围绕业务能力构建并且可通过全自动部署机制独立部署这些服务公用一个最小型的集中式的管理服务可用不同的语言开发，使用不同的数据存储技术。

微服务架构架构如如下图所示下图所示:

1.2.1 微服务微服务的的优点优点

·易于开发和维护:一个微服务只会关注一个特定的业务功能,所以它业务清晰、代码量少。开发和维护单个微服务相当简单。而整个应用是若干个微服务构建而成的，所以整个应用也被维持在一个可控状态。

·单个微服务启动较快 单个微服务代码量较少，所以启动会比较快。

·局部修改容易部署：单个应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。

·技术栈不受限：在微服务架构中，可以结合项目业务及团队的特点，合理选择技术栈。例如某些服务可以使用关系型数据库Mysql有些服务。可以使用非关系型数据库如redis;甚至可根据需求，部分微服务使用Java开发，部分微服务使用Node.js开发。

·按需收缩可根据需求，实现细粒度的扩展。例如，系统中的某个微服务遇到了瓶颈，可以结合这个微服务的业务特点，增加内存、升级CPU或者增加节点。

1.2.2 微服务的缺点

·运维要求较高： 更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行。而在微服务中，需要保证几十甚至几百个服务正常运行与协作，这给运维带来了很大的挑战。

·分布式固有的复杂性：使用微服务构建的是分布式 系统。对于一个分布式系统，系统容错、网络延迟等都会带来巨大的挑战。

·接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务 API ，可能所有使用该接口的微服务都需要调整。

2、Spring Cloud 简介

2.1 简介

Spring Cloud项目的官方网址： https://projects.spring.io/spring-cloud/

Spring Cloud并不是一个项目而是一组项目的集合在Spring Cloud中包含了很多的子项目每一个子项目都是一种微服务开发过程中遇到的问题的一种解决方案它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

2.2 子项目介绍

2.3 Spring Cloud的版本介绍

当我们通过搜索引擎查找一些Spring Cloud 的文章或者示例的时候往往可以在依赖中看到很多不同版本的名字 , 比如 : Angel.SR6, Brixton.SR5等。 那么，为什么 Spring Cloud 没有像其他的 Spring 的项目使用类似1.x.x 版本命名规则呢?

由于Spring Clou