Spring Cloud(一)：微服务与 Spring Cloud 概述

前言：公司的一个数据聚合项目，开始使用 Spring Cloud来搭建微服务框架，项目有好几十个数据源，每个数据源就是一个微服务。
在应用中有碰到各种问题，概念方面和技术方面都有，需要多层次多角度来理解，所以开辟Spring Cloud系列文章记录个人学习中得失。

Spring Cloud 是个新的知识领域，为应用而学习，将学习到的在实际项目中实践。Spring Cloud 可集成一系列组件, 为中小型互联网企业提供了一站式的微服务架构解决方案。

Spring Cloud 官网，Spring Cloud GitHub，可以在GitHub上搜Spring Cloud相关资源。

微服务是一种架构风格, Spring Cloud 的一系列组件框架为实现微服务架构提供了解决方案。

微服务概念

要深入理解微服务概念最好阅读下原始论文：James Lewis/Martin Fowler：Microservices -a definition of this new architectural term（微服务 -这个新架构述语的定义）。

微服务强调功能趋向单一，将不同功能模块拆分成多个不同的服务，服务单元小型化和微型化。在思想和理念上，微服务倾向于将功能进行拆份，将服务粒度做小，可以独立承担对外服务的职责，以这个思路来开发和交付的软件服务实体叫做微服务。

微服务的显著特征是独立，职责单一。从开发到交付整条键路上都是独立进行，这有助于多服务并行开发、各自快速迭代，可以保持开发阶段的独立性，保证微服务的研发可以高效进行。微服务失败只影响自己或少量的其它服务，不会波及整个服务体系。可以是多种语言开发的微服务，提高了整个服务体系的互通性和扩展性。

微服务特点：

1. 服务是一组小型的服务，有自己的生命周期
2. 在自己的进程中运行
3. 轻量级通信，通常是 HTTP API 方式
4. 围绕业务能力构建的
5. 可以通过全自动部署机制独立部署
6. 可以使用不同的编程语言编写
7. 可以使用不同的数据存储技术

微服务架构中，服务之间的调用方式主要有两种：

1. 使用HTTP的Restful API或轻量级的消息发送协议，实现信息传递服务调用的触发。
2. 通过在轻量级消息总级上传递消息，类似 RabbitMQ 等一类提供可靠异步交换的中间件(一般指消息中间件)。

微服务的特性

引用：James Lewis/Martin Fowler：Microservices -a definition of this new architectural term（微服务 -这个新架构述语的定义）

并非所有微服务架构都具有所有特征，但确实希望大多数微服务架构表现出大多数特征。

1. 通过服务实现组件化（Componentization via Services）

   组件是可独立更换和升级的软件单元。

   微服务架构将使用库(lib)，但他们将自己的软件组件化的主要方式是分解成服务。

   我们将库定义为链接到程序中并使用内存内函数调用调用的组件，而服务则是进程外组件，它们通过web服务请求或远程过程调用等机制进行通信。

   使用服务作为组件（而不是库）的一个主要原因是服务是可独立部署的。

   一个好的微服务架构的目标是通过服务契约中的内聚服务边界和演化机制来最小更新和重新部署。

   使用服务作为组件的另一个结果是更明确的组件接口。

2. 围绕业务能力进行组织（Organized around Business Capabilities）

   两层意思：服务组件是围绕业务能力进行组织的，团队组织结构也是围绕业务能力组织的，可理解为系统设计的结构反映期团队的组织结构。

   服务组件需要更明确的分离，这使得团队边界更加清晰。

3. 开发产品而不是完成项目（Products not Projects）

   大多数系统开发都使用项目模型：其目的是交付一些软件，完成后，移交给维护团，并解散了构建它的项目团队。

   微服务支持者倾向于避免这种模式，而是更喜欢团队应该在其整个生命周期内拥有产品的概念。一个共同的灵感来自亚马逊的 你构建，你运行 的概念，开发团队对生产中的软件承担全部责任。这使开发人员能够日常接触他们的软件在生产中的行为，并增加与用户的联系，因为他们必须承担至少一部分的技术支持的负担。

   产品心态与业务能力的联系紧密结合。与其将软件视为一组要完成的功能，不如将其视为一种持续的关系，问题在于软件如何帮助用户增强业务能力。

   没有理由不能在单体应用程序中采用同样的方法，但服务的粒度较小，可以更容易地在服务开发人员和用户之间创建个人关系。

4. 智能端点和无声管道（Smart endpoints and dumb pipes）

   微服务不是在一个进程里运行，服务之间通信需要简单高效。

   微服务构建的应用程序旨在尽可能地解耦和内聚——它们拥有自己的领域逻辑，并且更像是经典 Unix 意义上的过滤器——接收请求，适当地应用逻辑并产生响应。

   最常用的两种协议：带有资源的 HTTP 请求-响应 API 和 轻量级消息传递。

5. 去中心化治理（Decentralized Governance）

   打破在单一技术平台上标准化的趋势。经验表明，这种方式是有限的。

   微服务倾向于使用合适的工具完成工作，构建微服务的团队也更喜欢采用不同的标准方案。微服务为这种灵活的选择提供了可能。

   每个服务技术方案可自由选择，可以使用不同的编程语言，使用不同的数据存储。

6. 去中心化数据管理（Decentralized Data Management）

   微服务更喜欢让每个服务管理自己的数据库，可以是相同数据库技术的不同实例，也可以是完全不同的数据库系统。

   微服务架构强调服务之间的无事务协调，明确认识到一致性可能只是最终的一致性，问题通过补偿操作来处理。

7. 基础设施自动化（Infrastructure Automation）

   构建软件广泛使用基础设施自动化技术管理微服务。持续集成，持续交付，自动化测试，自动部署。

8. 容错设计

   使用服务作用为组件，设计时需要考虑服务容错。由于服务提供者不可用，任务服务调用都可能失败，消费者必须尽可能优雅对此做出响应。相比单体应用，这是一个缺点。微服务架构引入了额外的复杂性来处理它。微服务团队需要不断思考服务故障如何影响用户体验。

   服务随时可能出现故障，因此能够快速检测故障并在可能的情况下自动恢复服务非常重要。

   微服务应用非常重视应用的实时监控，检查架构元素（数据库每秒收到多少请求）和业务相关指标（例如每分钟收到多少订单）。 语义监控可以为错误提供预警系统，从而触发开发团队跟进和调查。

   监控对于微服务架构尤为重要控，对于快速发现不良紧急行为至关重要，因此可以对其进行修复。

   微服务团队希望看到每个单独服务的复杂监控和日志记录设置，例如显示启动/关闭状态的仪表板以及各种运营和业务相关指标。 有关断路器状态、当前吞吐量和延迟的详细信息。

9. 演进式设计（Evolutionary Design）

   服务拆分不会减慢应用的更改速度，可以对软件进行频繁、快速且可控的变更。

   将组件放入服务中为更精细的发布计划增加了机会。使用微服务，只需要重新部署修改的服务，但必须考虑向后兼容问题，避免破坏其消费者。

微服务新挑战

1. 运维新挑战
   需要维护的应用(微服务)大量增加，管理和维护这些微服务并不是件容易的事，运维过程需要更多的自动化。
2. 接口的一致性
   虽然拆分了服务，但业务逻辑上的依赖并不消除，只是从单体应用中的代码依赖变为了服务之间的通信依赖,对接口的修改需要协调交互方同步修改，以保证接口的正确调用，需要更完善的接口和版本管理。
3. 分布式的复杂性
   拆分后的服务独立部署，服务之间需要通过通信来进行协作，分布式环境的问题是分布式微服务系统设计需要考虑的因素，如网络延迟、分布式事务、异步消息等。
4. 数据管理去中心化
   数据管理去中心化对存在数据一致性问题，分布式事务的实现难度较大，所以在微服务架构中，我们更强调在各服务之间进行无事务的调用，而对于数据一致性，只要求数据在最后的处理状态是一致的即可；若在过程中发现错误，通过补偿机制来进行处理，使的数据能够达到最终一致性。

Spring Cloud

Spring Cloud 是一个基于 Spring Boot 实现的微服务架构开发工具，是解决微服务架构实施的综合性框架，整合了诸多已被广泛实践和证明过的框架作为实施的基础部件，在此基础上还创建了一些非常优秀的边缘组件，被喻为全家桶。

Spring Cloud 为我们提供了配置管理、服务发现、断路器、代理服务等在做分布式方案时非常有用的组件，可以满足一系列的微服务架构的要求。基于 Spring Cloud 开发的应用非常适合在 Docker 或者其他专业 PaaS 部署。

Spring Cloud 包含了多个子项目，其中涉及多个不同开源产品，还可能新增部件：

1. Eureka：服务注册中心，于用服务管理。
2. Zuul：API 网关, 提供路由转发，请求过滤等功能。
3. Ribbon：基于客户端的负载均衡组件。
4. Hystrix：容断器组件，防止服务的雪崩效应。
5. Feign：Web 服务客户端，简化 Http 接口调用。
6. Config：为分布式系统中的外部化配置提供服务器和客户端支持。
   配置管理工具，支持应用配置的外部化存储, 默认实现使用 Git，支持客户端配置刷新，加密/解密配置内容。
7. Netflix：为 Spring Boot应用提供 Netflix OSS 集成，是核心组件。
   Netflix 组件包含服务治理(Eureka)，断路器(Hystrix)，网关组件(Zuul)、负载均衡(Ribbon)。
8. Bus：事件、消息总线，用于广播集群中的状态变化或事件(如：配置更新),目前唯一的实现是使用 AMQP 代理作来传输消息。
9. Cluster：针对 Zookeeper，Redis，Hazelcast，Consul 的领导选举算法和通用状态模式的抽象和实现。
10. Foundry：将您的应用程序与Pivotal Cloud Foundry集成。 提供服务发现实现，还可以轻松实现受SSO和OAuth2保护的资源。
11. Sleuth：为Spring Cloud实施分布式跟踪解决方案，大量借用Dapper，Zipkin和HTrace。
    对于大多数用户来说，检测应该是隐形的，并且所有与外部系统的交互都应该自动进行检测。 您可以简单地在日志中捕获数据，也可以将数据发送到远程收集器服务。
    其它组件及说明可参阅官网及其文档,同时在官网首页上可以看到 Spring Cloud 当前版本支持的组件版本号。

特别注意：此 Spring Cloud 系列文章，基于 JDK8 和 Spring Boot 2.x 版本，Spring Cloud 版本是 Greenwich.RELEASE。因 Spring Boot 和 Spring Cloud 非常活跃，更新较快，版本之间会存在配置方面的差异，若升级版本可能存在兼容性问题，更多可参考官方文档。

Spring Boot

Spring Boot 为构建微服务提供了基础框架，在使用 Spring Cloud 之前最好先了解 Spring Boot的基本使用。可参考Spring Boot 2实践系列系列文章。

相关参考

1. Microservices - a definition of this new architectural term
2. SOA vs. Microservices: What’s the Difference?
3. Spring Cloud在国内中小型公司能用起来吗？
4. 中小型互联网公司微服务实践-经验和教训