SpringCloud学习笔记(一)

1.1微服务介绍

微服务(不是一个框架而是一种架构思想)， 是著名的OO(面向对象,ObjectOriented )专家Martin Fowler提出来的，它是用来描述将软件应用程序设计为独立部署的服务的种特殊方式。最近两年,微服务在各大技术会议、文章、书籍.上出现的频率已经让人意识到它对于软件领域所带来的影响力。微服务架构的系统是个分布式系统,按业务领域划分为独立的服务单元，有自动化运维、容错、快速演进的特点，它能够解决传统单体架构系统的痛点，同时也能满足越来越复杂的业务需求。

1.2单体架构的不足

在应用的初始阶段，单体架构无论是在开发速度、运维难度上，还是服务器的成本上都有着显著的优势。在一个产品的前景不明确的初始阶段，用单体架构是非常明智的选择。随着应用业务的发展和业务复杂度的提高，这种架构明显存在很多的不足。
主要体现在以下 3 个方面：

1. 业务越来越复杂，单体应用的代码量越来越大，代码的可读性、可维护性和可扩展性下降，新人接手代码所需的时间成倍增加，业务扩展带来的代价越来越大。
2. 随着用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限。
3. 测试的难度越来越大，单体应用的业务都在同个程序中，随着业务的扩张、复杂度的增加，单体应用修改业务或者增加业务或许会给其他业务带来定的影响，导致测试难度增加。

1.3到底什么是微服务

将一个大的应用，拆分成多个小的模块，每个模块都有自己的功能和职责，每个模块可以进行交互，这就是微服务对于微服务，业界没有严格统一的定义，但是作为“微服务”这名词的发明人，Martin Fowler对微服务的定义似乎更具有权威性和指导意义，他的理解如下：

1.3.1总结出微服务的特点

1. 按业务(功能)划分为一个独立运行的程序，即服务单元。
2. 服务之间通过 HTTP 协议相互通信。 http 是一个万能的协议 (web 应用都支持的模式)
3. 自动化部署。
4. 可以用不同的编程语言。
5. 可以用不同的存储技术。
6. 服务集中化管理。
7. 微服务是一个分布式系统。

1.3.2微服务特点的具体阐述

微服务的“微”到底需要定义到什么样的程度，这是个非常难以界定的概念，可以从以个方面来界定： 是根据代码量来定义，根据代码的多少来判断程序的大小： 是根据开发时间的长短来判断： 是根据业务的大小来划分。根据 Martin Fowler 的定义，微服务的“微”是按照业务来划分的 。一个大的业务可以拆分成若干小的业务， 个小的业务又可以拆分成若干更小的业务，业务到底怎么拆分才算合适，这需要开发人员自己去决定。

例如微博最常见的功能是微博内容、关注和粉丝，而其中微博内容又有点赞、评论等，如何将微博这个复杂的程序划分为单个的服务，需要由开发团队去决定。按业务划分的微服务单元独立部署，运行在独立的进程中 这些微服务单元是高度组件化的模块，并提供了稳定的模块边界，服务与服务之间没有任何的相合 有非常好的扩展性和复用性。传统的软件开发模式通常由 UI 团队、服务端团队、数据库和运维团队构成，相应地将软件按照职能划分为 、服务端、数据库和运维等模块。通常这些开发 员各司其职 很少有人跨职能去工作。

如果按照业务来划分服务，每个服务都需要独立的 UI 、服务端、数据库和运维。也就是说， 个小的业务的微服务需要动用 个团队的人去协作，这显然增加了团队与团队之间交流协作的成本。所以产生了跨职能团 队，这个团队负责一个服务的所有工作，包括 UI 、服务端和数据库。当这个团队只有 个人的时候，就对开发人员提出了更高的要求。

1.3.3微服务通过 HTTP 来互相通信

按照业务划分的微服务单元独立部署 并运行在各自的进程中。微服务单元之间的通信方般倾向于使用 HTTP 这种简单的通信机制，更多的时候是使用 RESTfulAPI 。这种接受请求、处理业务逻辑、返回数据的 HTTP 模式非常高效，并且这种通机制与平台和语言无关。例如用Java 写的服务可以消费用 Go 语言写的服务。

1.3.4微服务的数据库独立

在单体架构中，所有的业务都共用个数据库。随着业务量的增加，数据库的表的数量越来越多，难以管理和维护，并且数据量的增 会导致查询速度越来越慢。 例如个应用有这样几个业务：用户的信息、用户的账户、用户的购物 、数据报 服务等。典型的单体架构如微服务的个特
点就是按业务划分服务，服务与服务之间无稠合，就连数据库也是独立的个典型的微服务的架构就是每个微服务都有自己独立的数据库，数据库之间没有何联系这样做的好处在于，随着业务的不断扩张，服务与服务不需要提供数据库集成，而是提供 API 接口相互调用：还有个好
处是数据库独立，单业务的数据盆少，易于维护，数据库性能有着明显的优势，数据库的迁移也很方便。

1.3.5微服务的自动化部署（CI /CD）(持续集成持续交付)

在微服务架构中，系统会被拆分为若干个微服务，每个微服务又是一个独立的应用程序。单体架构的应用程序只需要部署一次，而微服务架构有多少个服务就需要部署多少次。随着服务数量的增加，如果微服务按照单体架构的部署方式，部署的难度会呈指数增加。业务的粒度划分得越细，微服务的数量就越多，这时需要更稳定的部署机制。随着技术的发展，尤其是 Docker容器技术的推进，以及自动化部署工具（例如开源组件 Jenkins）的出现，自动化部署变得越来越简单。

1.3.6服务集中化管理

微服务系统是按业务单元来划分服务的，服务数量越多，管理起来就越复杂，因此微服务必须使用集中化管理。目前流行的微服务框架中，例如 Spring Cloud 采用 Eureka 来注册服务和发现服务，另外， Zookeeper、 Consul 等都是非常优秀的服务集中化管理框架。

1.3.7分布式架构

分布式系统是集群部署的，由很多计算机相互协作共同构成，它能够处理海量的用户请求。当分布式系统对外提供服务时，用户是毫不知情的，还以为是一台服务器在提供服务。分布式系统的复杂任务通过计算机之间的相互协作来完成，当然简单的任务也可以在一台计算机上完
成。分布式系统通过网络协议来通信，所以分布式系统在空间上没有任何限制，即分布式服务器可以部署不同的机房和不同的地区。微服务架构是分布式架构，分布式系统比单体系统更加复杂，主要体现在服务的独立性和服务相互调用的可靠性，以及分布式事务、全局锁、全局 Id等，而单体系统不需要考虑这些复杂性。

另外，分布式系统的应用都是集群化部署，会给数据一致性带来困难。分布式系统中的服务通信依赖于网络，网络不好，必然会对分布式系统带来很大的影响。在分布式系统中，服务之间相互依赖，如果一个服务出现了故障或者是网络延迟，在高并发的情况下，会导致线程阻塞，在很短的时间内该服务的线程资源会消耗殆尽，最终使得该服务不可用。由于服务的相互依赖，可能会导致整个系统的不可用，这就是“雪崩效应”。为了防止此类事件的发生，分布式系统必然要采取相应的措施，例如“熔断机制”。

1.3.8熔断机制 Hystrix

为了防止“雪崩效应”事件的发生，分布式系统采用了熔断机制。在用 SpringCloud 构建的微服务系统中，采用了熔断器（即 Hystrix 令 组件的 C ircuit Breaker）去做熔断。例如在微服务系统中，有 a、 b、 c、 d、 e、如果此时服务 b 出现故障或者网络延迟，服务 b 会出现大量的线程阻塞，有可能在很短的时间内线程资源就被消耗完了，导致服务 b 的不可用。如果服务 b 为较 底层的服务，会影响到其他服务，导致其他服务会一直等待服务 b 的处理。

如果服务 b 迟迟不处理，大量的网络请求不仅仅堆积在服务 b，而且会堆积到依赖于服务 b 的其他服务。而因服务 b 出现故障影响的服务，也会影响到依赖于因服务 b 出现故障影响的服务的其他服务，从而由 b 开始，影响到整个系统，导致整个系统的不可用。这是一件非常可怕的事，因为服务器运营商的不可靠，必然会导致服务的不可靠，而网络服务商的不可靠性，也会导致服务的不可靠。在高并发的场景下，稍微有点不可靠，由于故障的传播性，会导致大量的服务不可用，甚至导致整个系统崩溃。

为了解决这一难题，微服务架构引入了熔断机制。当服务 b 出现故障，请求失败次数超过设定的阀值之后，服务 b 就会开启熔断器，之后服务 b 不进行任何的业务逻辑操作，执行快速失败，直接返回请求失败的信息。其他依赖于 b 的服务就不会因为得不到响应而线程阻塞，这时除了服务 b 和依赖于服务 b 的部分功能不可用外，其他功能正常。

1.4微服务的不足

凡事都有两面性，微服务也不例外，微服务相对于单体应用来说具有很多的优势，当然也有它的不足，主要体现在如下方面：

1. 微服务的复杂度
2. 分布式事务问题
3. 服务的划分（按照功能划分 还是按照组件来划分呢） 分工
4. 服务的部署（不用自动化部署 自动化部署）

1.5SpringCloud 简介

Spring Cloud 作为 Java 语言的微服务框架，它依赖于 Spring Boot，有快速开发、持续交付和容易部署等特点。 Spring Cloud 的组件非常多，涉及微服务的方方面面，井在开源社区 Spring 和 Netflix、 Pivotal 两大公司的推动下越来越完善，如今 alibaba 也加入到其中。 spring 官方 netflix alibabaSpring Cloud 在开发部署上继承了 Spring Boot 的一些优点，提高其在开发和部署上的效率。 Spring Cloud 的首要目标就是通过提供一系列开发组件和框架，帮助开发者迅速搭建一个分布式的微服务系统。

Spring Cloud 是通过包装其他技术框架来实现的，例如包装开源的 Netflix oss 组件，实现了一套通过基于注解、 Java 配置和基于模版开发的微服务框架。 Spring Cloud 提供了开发分布式微服务系统的一些常用组件，例如服务注册和发现、配置中心、熔断器、远程调用，智能路由、微代理、控制总线、全局锁、分布式会话等。

1.6SpringCloud 版本对应关系

网址：https://start.spring.io/actuator/info

1.7 SpringCloud 常用组件表

服务的注册和发现。（eureka,nacos,consul）
服务的负载均衡。(ribbon,dubbo)
服务的相互调用。（openFeign,dubbo）
服务的容错。（hystrix，sentinel）
服务网关。（gateway，zuul）
服务配置的统一管理。（config-server,nacos,apollo）
服务消息总线。(bus)
服务安全组件。(security,Oauth2.0)
服务监控。(admin) （jvm）
链路追踪。(sleuth+zipkin)

1.8微服务总体架构图

1.9总结

SpringCloud 就是微服务理念的一种具体落地实现方式，帮助微服务架构提供了必备的功能。
目前开发中常用的落地实现有三种：
Dubbo+Zookeeper 半自动化的微服务实现架构 (别的管理没有)
SpringCloud Netflix 一站式微服务架构
SpringCloud Alibaba 新的一站式微服务架构
三大公司实现的微服务

• Spring
• Netflix
• Alibaba