【SpringCloud】Spring Cloud基本介绍

回顾

架构分类

单体架构

• 单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。

• 优点：

  • 架构简单
  • 部署成本低

• 缺点：

  • 耦合度高（维护困难、升级困难）
    

分布式架构

• 分布式架构：根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。

• 优点：

  • 降低服务耦合
  • 有利于服务升级和拓展

• 缺点：

  • 服务调用关系错综复杂
    

• 分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考：

  • 服务拆分的粒度如何界定？
  • 服务之间如何调用？
  • 服务的调用关系如何管理？

人们需要制定一套行之有效的标准来约束分布式架构。

微服务架构

什么是微服务

• 微服务的概念源于2014年3月Martin Fowler（马丁·福勒）所写的一篇文章：https://martinfowler.com/microservices。
• 微服务架构风格是一种将一个单体应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常是基于HTTP协议的RESTful API)。这些服务围绕业务能力构建，并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。

优点

• 逻辑清晰，项目复杂度降低：通过对共享业务更加细粒度的拆分，一个服务只需要关注一个特定的业务领域，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，开发、维护会更加简单；
• 技术选型更加灵活：每个微服务都有不同的团队来维护，所以可以结合业务特性自由选择技术栈；
• 可扩展性更强：可以根据每个微服务的性能要求和业务特点对服务进行灵活扩展；
• 独立部署：单个微服务的代码量比较小，使得发布更加高效；
• 容错性：如果某一个服务发生故障，可以通过重试、降级等机制实现容错；

缺点

• 性能降低，微服务的间通过REST、RPC等形式进行交互，通信的延时会受到较大的影响；
• 提升了运维的难度（版本发布、问题排查、配置管理、监控)；
• 数据一致性的问题;

微服务的架构特征：

• 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
• 自治：团队独立、技术独立、数据独立，独立部署和交付
• 面向服务：服务提供统一标准的接口，与语言和技术无关
• 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。

因此，可以认为微服务是一种经过良好架构设计的分布式架构方案 。

微服务架构面临的挑战

• 微服务粒度大小难以划分，需要设计人员对业务有很好的掌握；
• 分布式复杂性，主要体现在分布式事务、网络延迟、系统容错等问题解决难度较大；
• 微服务之间通信成本较高，对微服务之间网络稳定性、通信速度要求较高；
• 由于微服务数量较大，运维人员运维、部署有较大的挑战

技术挑战

• 微服务架构的主要目的是实现业务服务的解耦；
• 对服务进行治理（服务的注册与发现、服务与服务之间的调用、熔断限流、负载均衡、链路追踪、分布式配置中心、服务路由等）；

微服架构的设计原则

微服务概念

提供者(Provider)

• 提供接口供其他项目调用的项目

消费者(Consumer)

• 调用提供者接口的项目
  

RPC和Restful

• RPC:RPC远程过程调用（Remote Procedure Call）的缩写形式，主要是基于TCP/IP协议的。
• Restful:Restful是一种网络应用程序的设计风格和开发方式，基于HTTP协议，可以使用XML格式定义或JSON格式定义。

集群

• 集群就是单机的多实例，在多个服务器上部署多个服务，每个服务就是一个节点，部署N个节点，处理业务的能力就提升 N倍（大约），这些节点的集合就叫做集群。

分布式

• 分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC或Restful方式通信。

总结

• 单体架构：简单方便，高度耦合，扩展性差，适合小型项目。例如：学生管理系统
• 分布式架构：松耦合，扩展性好，但架构复杂，难度大。适合大型互联网项目，例如：京东、淘宝
• 微服务：一种良好的分布式架构方案
  • 优点：拆分粒度更小、服务更独立、耦合度更低
  • 缺点：架构非常复杂，运维、监控、部署难度提高
• SpringCloud是微服务架构的一站式解决方案，集成了各种优秀微服务功能组件

服务拆分和远程调用

• 何分布式架构都离不开服务的拆分，微服务也是一样。

服务拆分原则

• 不同微服务，不要重复开发相同业务
• 微服务数据独立，不要访问其它微服务的数据库
• 微服务可以将自己的业务暴露为接口，供其它微服务调用
  

服务拆分示例

cloud-demo：父工程，管理依赖

• order-service：订单微服务，负责订单相关业务
• user-service：用户微服务，负责用户相关业务

说明：

• 订单微服务和用户微服务都必须有各自的数据库，相互独立
• 订单服务和用户服务都对外暴露Restful的接口
• 订单服务如果需要查询用户信息，只能调用用户服务的Restful接口，不能查询用户数据库

思考

方案该怎么落地？选用什么样的技术栈？全球的互联网公司都在积极尝试自己的微服务落地方案。
其中在Java领域最引人注目的就是SpringCloud提供的方案了。

主流的微服务框架

Spring Cloud Netflix概述

• Spring Cloud Netflix诞生的三个原因

  • Spring家族中的大部分项目都是客户端项目，缺少服务端项目和分布式项目的经验；
  • Netflix开源其分布式领域的中间件，叫做Netflix OSS；
  • Dubbo的出现，让Spring母公司(Privotal)感受到了威胁，它需要保持或增值自身价值。

• Spring母公司缺少分布式项目的经验，而Netflix OSS的开源组件正好涉及分布式领域的核心功能，双方一拍即合，合作诞生的Spring Cloud Netflix项目用于为快速构建分布式系统提供统一的开发模式。

• Spring Cloud Netflix是Spring Boot和Netflix OSS在Spring Cloud规范下的集成。其中，Netflix OSS是由Netflix公司开发的一套开源框架和组件库。

Netflix OSS

Netflix OSS

• Netflix OSS（Netflix Open Source Software）即Netflix开源软件。
• Netflix由于做视频的原因，访问量非常的大，从而促使其技术快速的发展在背后支撑着，也正是如此，Netflix开始把整体的系统往微服务上迁移。
• Netflix毫无保留的把一整套微服务架构核心技术栈开源了出来，叫做Netflix OSS，依靠开源社区的力量不断的壮大。

毕马威：颠覆性公司和商业模式报告

• 报告显示Amazon、Apple、Alibaba、Airbnb、Netflix、Google、DJI、Microsoft、Facebook、Baidu、Tencent等公司是最具颠覆性的公司
• 其中Netflix和阿里巴巴分别为第3位和第5位，他们都是对Spring Cloud做出巨大贡献的公司

Netflix是什么，与Spring Cloud有什么关系

• 首先，Netflix是一家做视频的网站，可以这么说该网站上的美剧应该是最火的
• Netflix由于做视频的原因，访问量非常的大，从而促使其技术快速的发展在背后支撑着，也正是如此，Netflix开始把整体的系统往微服务上迁移。
• Netflix的微服务做的不是最早的，但是确是最大规模的在生产级别微服务的尝试。也正是这种大规模的生产级别尝试，在服务器运维上依托AWS云。当然AWS云同样受益于Netflix的大规模业务不断的壮大。[(AWS)Amazon Web Services(亚马逊网络服务)]
• Netflix的微服务大规模的应用，在技术上毫无保留的把一整套微服务架构核心技术栈开源了出来，叫做Netflix OSS，也正是如此，在技术上依靠开源社区的力量不断的壮大。
• Spring Cloud是构建微服务的核心，而Spring Cloud是基于Spring Boot来开发的
• Pivotal在Netflix开源的一整套核心技术产品线的同时，做了一系列的封装，就变成了Spring Cloud；虽然Spring Cloud到现在为止不只有Netflix提供的方案可以集成，还有很多方案，但Netflix是最成熟的。

Netflix OSS的开源组件

Eureka：服务注册和发现

• 它提供了一个服务注册中心、服务发现的客户端，还有一个方便的查看所有注册的服务的界面。 所有的服务使用Eureka的服务发现客户端来将自己注册到Eureka的服务器上。

Zuul：网关

• 所有的客户端请求通过这个网关访问后台的服务。他可以使用一定的路由配置来判断某一个URL由哪个服务来处理。并从Eureka获取注册的服务来转发请求

Ribbon，即负载均衡

• Zuul网关将一个请求发送给某一个服务的应用的时候，如果一个服务启动了多个实例，就会通过Ribbon来通过一定的负载均衡策略来发送给某一个服务实例。

Feign，服务客户端

• 服务之间如果需要相互访问，可以使用RestTemplate，也可以使用Feign客户端访问。它默认会使用Ribbon来实现负载均衡。

Hystrix，监控和断路器

• 我们只需要在服务接口上添加Hystrix标签，就可以实现对这个接口的监控和断路器功能。Hystrix Dashboard，监控面板，他提供了一个界面，可以监控各个服务上的服务调用所消耗的时间等。

Turbine，监控聚合

• 使用Hystrix监控，我们需要打开每一个服务实例的监控信息来查看。而Turbine可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。这样就不需要挨个打开一个个的页面一个个查看。

Spring Cloud

Spring Cloud简介

• Spring Cloud是基于Spring Boot的一整套实现微服务的框架。
• 他提供了微服务开发所需的配置管理、服务注册与发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。
• 最重要的是跟Spring Boot框架一起使用的话，会让你非常方便开发微服务架构的服务。
• 官网：https://spring.io/projects/spring-cloud/

Spring Cloud特征

• 分布式/版本化配置
• 服务注册和发现
• 路由
• 服务与服务之间的请求调用
• 负载均衡
• 断路器
• 全局锁
• 领导选举和集群状态
• 分布式消息传递

版本

• 本教程使用版本：Spring Cloud Hoxton.SR12

版本依赖关系

Spring Cloud所有的子项目都依赖Spring Boot框架，所以Spring Boot框架的版本号和Spring Cloud的版本号之间也存在依赖及兼容的关系，如下图所示：

Spring Cloud 规范下的实现

• 在Spring Cloud这个规范下，有很多实现，比如：Spring-Cloud-Bus、Spring-Cloud-Gateway、Spring-Cloud-Netflix等等。
• 在这些实现中，绝大部分组件都使用“别人已经造好的轮子”，然后基于Spring Cloud规范进行整合，使用者只需要使用非常简单的配置即可完成微服务架构下复杂的需求。
• 这也是Spring 团队最厉害的地方，他们很少重复造轮子，最早的Spring 框架，它只提供了IOC和AOP两个核心功能，对于ORM、MVC等其他功能，Spring都提供了非常好的兼容性，比如：Hibernate、MyBatis、Spring MVC、Strus2。
• 只有在别人提供的东西不够好的情况下，Spring团队才会考虑自己研发。比如Strus2经常有安全漏洞，所以Spring团队自己研发了Spring MVC框架。再比如Spring-Cloud-Netflix中的Zuul网关，因为性能及版本迭代较慢，所以Spring团队孵化了一个Spring Cloud Gateway来取代Zuul。
• Spring团队一直在不断地为开发者解决一些技术复杂度高的问题，使开发者能够更高效地专注于业务开发的工作。从Spring到Spring Boot,再到Spring Cloud,都是如此。

本教程中选用的组件