微服务--SpringCloud

第一章 微服务与 Spring Cloud

1.1 架构的衍进

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

互联网产品常常面临庞大的用户量，日均数十亿 PV 的高并发， PB 级别的数据存储等问题的挑战，同时要求保证系统的高可用和弹性伸缩，并且能够根据需要进行快速迭代扩展，这些都对于系统架构提出了很高的要求。

互联网架构从简到繁的演进至今，大体上可分为这么几个阶段：单一应用架构 -> 垂直应用架构 -> 微服务架构。

1.1.1 单一应用架构

当网站流量很小时，只需要一个应用，将所有的功能都部署在一起，用来减少部署节点和成本。这时，用于简化增删改查工作量的数据访问框架(ORM)是关键。我们更加关注的是简化开发工作。如图1-1：

1. 特点：

• 所有的功能集中在一个工程中。
• 应用与数据库分开部署。
• 通过部署应用集群和数据库集群来提高系统的性能。

1. 优点：

• 项目架构简单，前期开发成本低，周期短，小型项目的首选。

1. 缺点：

• 全部功能集中在一个工程中，代码耦合，对于大型项目不易扩展及维护。
• 提高系统性能只能通过扩展集群，成本高。
• 单点容错率低。

1.1.2 垂直应用架构·

当访问量逐渐增大，功能逐渐复杂起来，单一应用架构就显得有些捉襟见肘，由于所有的功能都写在同一个工程中，整个工程会越来越庞大越来越臃肿，每次发布上线拆分代码版本和合并代码版本都将成为噩梦，同时，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。如图1-2：

 

1. 特点：

• 将项目以单一应用架构的方式，将一个大应用拆分成为几个互不干扰的应用。
• 应用于应用之间互不相干，功能和数据都会存在冗余。

1. 优点：

• 通过垂直拆分，防止单体项目无限扩大。
• 系统间相互独立。

1. 缺点：

• 项目拆分之后，项目与项目之间存在数据冗余，耦合性较大。
• 提高系统性能只能通过扩展集群，成本高，并且存在瓶颈。

1.1.3 微服务架构

当垂直应用越来越多，应用与应用之间的交互不可避免，这时需要将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务，使前端应用能更快速的响应多变的市场需求。如图1-3：

1. 特点：

• 系统服务层完全独立，并且抽取成一个一个的独立服务。
• 微服务遵循单一原则。
• 使用服务中心进行服务注册与发现。
• 每个服务有自己的独立数据源。
• 微服务之间采用 RESTful 等轻量协议传输。

1. 优点：

• 通过分解巨大单体式应用为多个服务方法解决了复杂性问题。
• 可以更加精准的制定每个服务的优化方案，提高系统可维护性。
• 微服务架构模式是每个微服务独立的部署，可以使每个服务独立扩展。
• 微服务架构采用去中心化思想，服务之间采用 RESTful 等轻量协议通信。

1. 缺点：

• 微服务过多，服务治理成本高，对系统运维团队挑战大。
• 分布式系统开发的技术成本高（容错、分布式事务等），对团队挑战大。

1.2 关于微服务

1.2.1 什么是微服务

ThoughtWorks 公司的首席科学家 Martin Fowler说 ：

简而言之，微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。

James Lewis 和 Martin Fowler说：

简言之，Microservices 架构风格就像是把小的服务开发成单一应用的形式， 运行在其自己的进程中，并采用轻量级的机制进行通信（一般是 HTTP 资源 API）。这些服务都是围绕业务能力来构建，通过全自动部署工具来实现独立部署。这些服务，其可以使用不同的编程语言和不同的数据存储技术，并保持最小化集中管理。

1.2.2 微服务的特点

1. 独立部署，灵活扩展：传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件为单位进行部署。
2. 资源的有效隔离：每个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成，有效避免了服务之间争用数据库和缓存资源所带来的问题。
3. 按业务组织团队：微服务的设计思想也改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构，而微服务的设计思想对团队的划分有着一定影响，使团队组织的划分更倾向于垂直架构。当然，垂直划分只是一个理想的架构，实际在企业中并不会把团队组织架构拆分的这么绝对。

 

1.2.3 微服务的优缺点

1. 优点：

• 每个服务足够内聚，足够小，代码容易理解、开发效率提高。
• 微服务能够被小团队单独开发。
• 微服务是松耦合的，是有功能意义的服务，无论在开发阶段或部署阶段都是独立的；
• 每个服务可以各自进行扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上。

• 容错性提高，一个服务的内存泄露并不会让整个系统瘫痪。
• 微服务能使用不同的语言开发，并且系统不会被长期限制在某个技术栈上。

缺点：

• 微服务把原有的项目拆成多个独立工程，增加了开发和测试的复杂度。
• 微服务架构需要保证不同服务之间的数据一致性，引入了分布式事务和异步补偿机制，为设计和开发带来一定挑战。
• 当服务数量增加，管理复杂性增加。

1.2.4 微服务常见组件

微服务虽然带来了架构上的优势，但同时也引入了复杂性，我们需要使用一些组件来解决技术复杂性提高之后带来的问题：

1. 服务注册中心：每个服务实例在启动时，需要想注册中心注册自己的IP地址等信息。服务在调用别的服务接口时，就可以通过注册中心，查询到其他服务的实例，向实例发起请求。
2. 负载均衡：由于服务可以有多个实例，所以不管是来自外部客户端的请求，还是微服务系统内部服务之间发起的请求，都需要引入负载均衡的机制，来发挥多实例集群的作用。负载均衡有两种：服务器端负载均衡和客户端负载均衡，各自具有代表性意义的实现分别是Nginx和Ribbon。
3. 服务网关：服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能。根据公司流量规模的大小网关可以是一个，也可以是多个。
4. 配置中心：将本地化的配置信息（Properties、XML、YAML等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。配置部分可以单独使用高可用的分布式配置中心，确保一个配置服务出现问题时，其他服务也能够提供配置服务。
5. API 管理：以方便的形式编写及更新API文档，并以方便的形式供调用者查看和测试。通常需要加入版本控制的概念，以确保服务的不同版本在升级过程中都能够提供服务。
6. 集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件集成到统一的界面框架下，让用户能够在统一的界面中使用系统。
7. 分布式事务：对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务）保证数据的一致性。根据业务的不同，适当地牺牲一些数据的一致性要求，确保数据的最终一致性。
8. 调用链：记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。同时统计各个服务的调用次数，确保比较热的服务能够被分配更多的资源。
9. 支撑平台：系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么就需要将大部分的工作自动化。这时，需要合适的支撑平台或工具来中和这些微服务架构带来的弊端。

1.2.5 Spring Cloud 与微服务架构

Spring Cloud 由 Spring 官方开发维护，基于 Spring Boot 开发，提供了一整套完整的微服务解决方案。Spring Cloud 的技术选型是中立的，目前大多数的组件都来源于 Netflix 公司的开源产品，包括服务中心 Eureka ，服务网关 Zuul 、负载均衡组件 Ribbon 等等。并且这些组件都可以随需扩展和替换。

在早些年，国内互联网公司盛行采用阿里巴巴公司在 Github 开源的 Dubbo 组件来架构系统应用。但是，Dubbo 在未来的定位并不是要成为一个微服务的整体解决方案，而是专注于 RPC 领域，成为微服务一个重要的组件。以致于微服务衍生出的服务治理的需求，阿里巴巴再次启动开源项目予以支持，比如最近宣布开源的 Spring Cloud Alibaba ，其中 Dubbo 可以做为组件使用 Nacos 作为服务中心整合进入 Spring Cloud 的生态。

从技术选型的角度上来讲，两相比较， Dubbo 和 Spring Cloud ，如果只是图方便和快捷，完全可以使用 Spring Cloud 全家桶来构建微服务，但是， Spring Cloud 服务之间的调用是通过 RESTful 来进行通信，这种调用协议从效率上讲是比较低下的，当然， Dubbo 服务之间的调用是通过 RPC 来进行的，相比较 RESTful 这种形式，性能肯定会超出很多，但是 Dubbo 的生态却又有些令人担心，如果其余的技术栈都需要重新选型，那么无疑将耗费大量的人力。不过无需担心，前段时间刚刚从 Apache 毕业的 Spring Cloud Alibaba 开源项目已经为我们完美的解决了这个问题，其中的一个组件 Dubbo Spring Cloud 就是为了使 Dubbo 无缝接入 Spring Cloud 。

 

1.3 Spring Cloud 与中间件

1.3.1 什么是中间件

近年来，越来越多的领域已经离不开计算机、网络技术以及通用技术了。并且随着计算机技术的迅猛发展，更多的软件被要求在很多不同的网络协议、不同的硬件生产厂商以及不同的网络平台上运营。所以这导致开发人员需要面临数据离散、操作困难、系统匹配程度低及需要开发多种运用程序来达到运营的目的。所以，中间件的产生，极大程度上减轻了开发者的负担，使得软件运行更有效率。中间件带给应用系统的，不只是开发的简便、开发周期的缩短，也减少了系统的维护、 运行和管理的工作量，还减少了计算机总体费用的投入。

 

中间件是一类软件的总称，不是单独的一个软件。是提供系统软件和应用软件之间连接的软件，以便于软件各部件之间的沟通，特别是应用软件对于系统软件的集中的逻辑，是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源。

 

也就是说，关于中间件，我们可以理解为：是一类能够为一种或多种应用程序合作互通、资源共享提，同时还能够为该应用程序提供相关的服务的软件。中间件的本质可以归为技术架构，常见的中间件有服务治理中间件、配置中心、全链路监控、分布式事务、分布是定时任务、消息中间件、API网关、分布式缓存、数据库中间体等。

 

中间件技术的发展方向，将聚焦于消除信息孤岛，推动无边界信息流，支撑开放、动态、多变的互联网环境中的复杂应用系统，实现对分布于互联网之上的各种自治信息资源（计算资源、数据资源、服务资源、软件资源）的简单、标准、快速、灵活、可信、高效能及低成本的集成、协同和综合利用，提高组织的IT基础设施的业务敏捷性，降低总体运维成本，促进IT与业务之间的匹配。中间件技术正在呈现出业务化、服务化、一体化、虚拟化等诸多新的重要发展趋势。

 

1.3.2 什么是 Spring Cloud

Spring Cloud从字面理解，就是致力于分布式系统、云服务的框架。Spring Cloud是整个Spring家族中新的成员， 是最近云服务火爆的必然产物。

Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁定，领导选举，分布式会话，集群状态）。使用Spring Cloud开发人员可以快速站起来实现这些模式的服务和应用程序。它们适用于任何分布式环境，包括开发人员自己的笔记本电脑，裸机数据中心和Cloud Foundry等托管平台。

1.3.3 Spring Cloud 项目模块

Spring Cloud为开发人员提供了快速构建分布式系统中的一些常见模式组件：

1.3.4 Spring Cloud 组件介绍

1.Eureka

作用：云端服务发现，一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移。

简介：Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块。有两个组件构成：Eureka服务端和Eureka客户端。Eureka服务端用作服务注册中心，支持集群部署；Eureka客户端是一个java客户端，用来处理服务注册与发现。 在应用启动时，Eureka客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。

2.Feign

 

作用：使得编写java http客户端变得更容易。

简介：Feign是Netflix开发的声明式、模板化的HTTP客户端，在 Spring Cloud 中使用 Feign，可以做到使用 HTTP 请求访问远程服务，就像调用本地方法一样的，开发者完全感知不到这是在调用远程方法，更感知不到在访问 HTTP 请求。

3.Ribbon

作用：提供云端负载均衡，有多种负载均衡策略可供选择，可配合服务发现和断路器使用。

简介：Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。

4.Hystrix

作用：熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。

简介：为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。

5.Zuul

作用：Zuul 是在云平台上提供动态路由,监控,弹性,安全等边缘服务的框架。

简介：为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。

6.Spring Cloud Sleuth

作用：日志收集工具包，封装了Dapper和log-based追踪以及Zipkin和HTrace操作，为SpringCloud应用实现了一种分布式追踪解决方案。

7.Spring Cloud Config

作用：配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git以及Subversion。

简介：SpringCloud Config提供服务器端和客户端。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。这个还是静态的，得配合Spring Cloud Bus实现动态的配置更新。

8.Spring Cloud Gateway

作用：Spring Cloud官方推出的第二代网关框架，取代Zuul网关。网关作为流量的，在微服务系统中有着非常作用，网关常见的功能有路由转发、权限校验、限流控制等作用。

简介：Spring Cloud Gateway 作为 Spring Cloud 生态系中的网关，旨在为微服务架构提供一种简单而有效的统一的 API 路由管理方式，统一访问接口，基于 Filter 链的方式提供了网关基本的功能。

Spring Cloud 的增强生态

 

1.4.1 Spring Cloud 分布式事务

 

在微服务如火如荼的情况下，越来越多的项目开始尝试改造成微服务架构，微服务即带来了项目开发的方便性，又提高了运维难度以及网络不可靠的概率。采用 Spring Cloud 框架搭建微服务架构，这势必会引发分布式事务处理的思考。

1.4.2 Spring Cloud 与 Dubbo

Dubbo 经常与 Spring Cloud 拿来比较，其实从背景上讲， Dubbo 是来源于阿里团队，是阿里巴巴服务化治理的核心框架，并被广泛应用于阿里巴巴集团的各成员站点； Spring Cloud 是来源于 Spring 团队，它是 Spring Source 的产物， Spring 社区的强大背书可以说是 Java 企业界最有影响力的组织了，除了 Spring Source 之外，还有 Pivotal 和 Netfix 是其强大的后盾与技术输出。其中 Netflix 开源的整套微服务架构套件是 Spring Cloud 的核心。从定位上讲， Dubbo 是一款高性能的 Java RPC 框架；而 Spring Cloud 是一个完整的微服务解决方案。

Spring Cloud 本质上并不是去真正开发了这么一系列的组件，它只是在现有的开源组件的基础上，设计了一套统一的规范或者说是接口，使得这些组件可以接入 Spring Cloud 的体系，从而能够实现无缝的切换底层实现。就好比如服务中心，可以使用 Netflix 的 Eureka 同时也可以无缝切换成阿里巴巴开源的 Nacos 。

Dubbo 和 Spring Cloud 并不是水火不容的，在 2019 年 8 月份 Spring Cloud Alibaba 从 Apache 毕业成为顶级项目后， Dubbo 的生态已经和 Spring Cloud 的生态相互融合，使得微服务之间调用同时具备了 RESTful 和 Dubbo 调用的能力，做到对业务代码无入侵、无感知。在本书的第十三章，将会详细的讲解 Dubbo 与 Spring Cloud 的融合使用方式，介绍如何同时提供 RESTful 和 Dubbo 调用的能力。

 

1.4.3 Spring Cloud 与 gRPC

gPPC 是谷歌开源的一个高性能的、通用的RPC框架。和其他 RPC 一样，客户端应用程序可以直接调用远程服务的方法，就好像调用本地方法一样。它隐藏了底层的实现细节，包括序列化（XML、JSON、二进制）、数据传输（TCP、HTTP、UDP）、反序列化等，开发人员只需要关自业务本身，而不需要关注RPC的技术细节。

微服务架构的风格，是每个微服务运行在自己的进程中，并使用轻量级的通信机制，通常是HTTP RESTFUL API。这些服务是围绕业务能力来划分的、构建的，并通过完全自动化的机制来部署。这些服务可以用不同的语言来编写，以及不同的数据存储技术，以保证最低限度的集中式管理。但是在通常情况下，HTTP不会开启KeepAlive功能，即为短连接，每次请求都需要建立TCP连接，这使得其在耗时非常低效。对外提供RESTAPI是可以理解的，但内部服务之间进行调用若还是采用HTTP就会显得性能低下，Spring Cloud默认使用Feign进行内部服务调用，而Feign底层使用HTTP协议进行服务之间的调用。Spring Cloud官方没有提供RESTAPI之外的服务调用方案，现有的更高效的内部服务调用方案是GRPC。

 

1.4.4 Spring Cloud 与 Motan

Motan是一套基于java开发的RPC框架，由新浪微博开源。可靠性经过新浪微博生产环境验证。除了常规的点对点调用外，Motan还提供服务治理功能，包括服务节点的自动发现、摘除、高可用和负载均衡等。Motan具有良好的扩展性，主要模块都提供了多种不同的实现，例如支持多种注册中心，支持多种rpc协议等。支持通过spring配置方式集成，无需额外编写代码即可为服务提供分布式调用能力。支持集成consul、zookeeper等配置服务组件，提供集群环境的服务发现及治理能力。支持动态自定义负载均衡、跨机房流量调整等高级服务调度能力。基于高并发、高负载场景进行优化，保障生产环境下RPC服务高可用。从架构设计上来看，和Dubbo非常相似。但是市场占有率和知名度不及Dubbo，但是遗憾的是，Dubbo过于java,与其他语言的相容性一般，这时就显现出Motan的一大优点是，跨语言的Rpc框架，除了java外，还支持PHP、Go、Lua等相互之间调用。

 

来源：oschina

链接：https://my.oschina.net/u/4244602/blog/4272314