Spring Cloud微服务架构解决方案详细介绍—叩丁狼Java培训
1、微服务架构
目前微服务是非常火的架构或者说概念，也是在构建大型互联网项目时采用的架构方式。
单体架构
在软件设计中，经常提及和使用经典的3层模型，即表示层、业务逻辑层和数据访问层。
表示层：用于直接和用户交互，也称为交互层，通常是网页、UI 等。
业务逻辑层：即业务逻辑处理层，例如用户输入的信息要经过业务逻辑层的处理后，才能展现给用户。
数据访问层：用于操作数据库，用户在表示层会产生大量的数据，通过数据访问层对数据库进行读写操作。
虽然在软件设计中划分了经典的3层模型，但是对业务场景没有划分。一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包，部署在一台服务器上。
单体架构图如下所示：
单体架构的优点
部署简单由于是完整的结构体，可以直接部署在一个服务器上即可。
技术单一 项目不需要复杂的技术栈，往往一套熟悉的技术栈就可以完成开发。
用人成本低 单个程序员可以完成业务接口到数据库的整个流程。
单体架构的缺点
系统启动慢 , 一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长
系统错误隔离性差、可用性差，任何一个模块的错误均可能造成整个系统的宕机
可伸缩性差;系统的扩容只能只对这个应用进行扩容，不能做到对某个功能点进行扩容
线上问题修复周期长;任何一个线上问题修复需要对整个应用系统进行全面升级
微服务架构
就目前来看微服务并没有一个 严格 的定义 每一个人对 微服务 的理解都是不一样的 . Martin Fowler在它的博客中是这样表述微服务的微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法每一个服务运行在自己的进程中服务间通信采用的轻量级通信机制通(常用HTTP 资源 API ). 这些服务围绕业务能力构建并且可通过全自动部署机制独立部署这些服务公用一个最小型的集中式的管理服务可用不同的语言开发，使用不同的数据存储技术。
微服务微服务的的优点优点
易于开发和维护:一个微服务只会关注一个特定的业务功能,所以它业务清晰、代码量少。开发和维护单个微服务相当简单。而整个应用是若干个微服务构建而成的，所以整个应用也被维持在一个可控状态。
单个微服务启动较快 单个微服务代码量较少，所以启动会比较快。
局部修改容易部署：单个应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
技术栈不受限：在微服务架构中，可以结合项目业务及团队的特点，合理选择技术栈。例如某些服务可以使用关系型数据库Mysql有些服务。可以使用非关系型数据库如redis;甚至可根据需求，部分微服务使用Java开发，部分微服务使用Node.js开发。
按需收缩可根据需求，实现细粒度的扩展。例如，系统中的某个微服务遇到了瓶颈，可以结合这个微服务的业务特点，增加内存、升级CPU或者增加节点。
微服务的缺点
运维要求较高： 更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行。而在微服务中，需要保证几十甚至几百个服务正常运行与协作，这给运维带来了很大的挑战。
分布式固有的复杂性：使用微服务构建的是分布式 系统。对于一个分布式系统，系统容错、网络延迟等都会带来巨大的挑战。
接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务 API ，可能所有使用该接口的微服务都需要调整。
2、Spring Cloud 简介
简介
Spring Cloud并不是一个项目而是一组项目的集合在Spring Cloud中包含了很多的子项目每一个子项目都是一种微服务开发过程中遇到的问题的一种解决方案它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
Spring Cloud的版本介绍
当我们通过搜索引擎查找一些Spring Cloud 的文章或者示例的时候往往可以在依赖中看到很多不同版本的名字 , 比如 : Angel.SR6, Brixton.SR5等。 那么，为什么 Spring Cloud 没有像其他的 Spring 的项目使用类似1.x.x 版本命名规则呢?
由于Spring Cloud不像Spring社区其他项目那样相对独立，它是拥有诸多子项目的大型综合项目。可以说是对微服务架构解决方案的综合套件的组合，起包含的各个子项目也都是进行独立的更新和迭代，各自都维护自己的发布版本号。因此，每一个Spring Cloud的版本都会包含多个不同版本的子项目，为了管理每一个版本的子项目清单避免Spring Cloud的版本号与其子项目的版本号相混淆，没有采用版本号的方式，而是通过命名的方式。
我们也可以在spring的官网上查看到对应的最新稳定版本信息 :
并且也可以看到最新Edgware.SR4稳定版对应的子项目的各个版本号。
关于Spring Cloud的历史版本信息我们可以在github上查看到 :
我们本次讲解的是最新的稳定版本Edgware.SR4 ,是基于Spring Boot 1.5.14.RELEASE版本实现的。
3、Spring Boot 实现微服务
在正式学习Spring Cloud 之前我们先使用Spring Boot实现一个微服务。
业务非常简单：
1、商品微服务：通过商品id 查询商品的服务;
2、订单微服务：通过订单id 查询订单数据，同时需要调用商品微服务查询出订单详情数据对应的商品数据。
3、对于商品微服务而言，商品微服务是服务的提供者，订单微服务是服务的消费者2、对于订单微服务而言，订单微服务是服务的提供者，人是服务的消费者。
3.1 实现商品微服务
3.1.1 pom .xml文件的配置
3.1.2 创建实体Item
3.1.3 编写ItemService
3.1.4 编写ItemController
3.1.5 程序入口
3.1.6 创建配置文件
在src/main/resources目录下创建一个application.properties配置文件在该文件中可以配置如下内容
server.port=8081
指定服务启动占用的端口
3.1.7 启动项目进行访问
3.2 实现订单微服务
3.2.1 pom.xml文件的配置
3.2.2 创建实体Order
3.2.3 创建实体OrderDetail
3.2.4 复制Item实体
3.2.5 编写OrderService该Service实现的根据订单Id查询订单的服务，为了方便测试，我们将构造数据实现，不采用查询数据库的方式。
3.2.6 实现ItemService
3.2.7 完善OrderService
3.2.8 编写OrderController
3.2.9 编写启动类
3.2.10 创建配置文件
在src/main/resources 目录下创建一个application.properties 配置文件在该文件中可以配置如下内容
server.port=8082
3.2.11 启动测试
3.3 发现问题与解决问题
3.3.1 问题描述
在刚才的服务调用过程中我们的商品服务地址是直接写死在程序中存在硬编码问题
如果商品微服务部署了多个，那么我们订单微服务如何去调用呢?
3.3.2 问题处理
关于硬编码的问题我们可以使用配置文件处理，我们可以将地址信息编写到配置文件中然后读取配置文件获取请求地址信息。
在配置文件中加入如下配置：
itcast.item.url=http://127.0.0.1:8081/item/
修改ItemService的实现通过@Value 注解获取该值
2. 如果商品微服务部署了多个那么我们订单微服务如何去调用呢?
关于这个问题有的开发人员可能会想 . 我们可以将多个商品微服务的地址配置到配置文件中，然后在进行读取配置文件的地址进行调用听起来好像可以，但是我们需要考虑以后问题就是后期维护的问题。
如果商品微服务的我们又添加或者减少了一个部署，相应的我们需要去更改配置文件的内容;
如果商品微服务的ip地址发送了改变，那么我们也需要相应的修改配置文件的地址。
所以我们自己这样实现比较麻烦。
我们可以使用服务注册于发现机制来完成。
4 Spring Cloud快速入门
服务注册于发现机制架构图如下：
可以看出：
1、服务提供者将服务注册到注册中心
2、服务消费者通过注册中心查找服务
3、查找到服务后进行调用(这里就是无需硬编码 url 的解决方案)
4.1 注册中心 Eureka
Spring Cloud提供了多种注册中心的支持，如： Eureka 、 ZooKeeper 等。推荐使用Eureka 。
Spring Cloud Eureka是Spring Cloud Netflix 微服务套件中的一部分，它基于Netflix Eureka做了二次封装。主要负责完成微服务架构中的服务治理功能。