第一章 基础知识
什么是微服务架构
“微服务”一词源于Martin Flower的名为Microservices的博文，可以在他的官方博客上找到：http://martinfowler.com/articles/microservices.html
简单地说，微服务是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行通信协作。被拆分成的每一额小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言来编写。
与单体系统的区别
传统的企业系统架构
- 复杂的业务需求通常使用对象或业务类型来构建一个单体项目；
- 需求分为三个主要部分：数据库、服务端处理、前端展现；
- 业务逻辑在一个应用中；
- 需求的扩大使得单体应用变臃肿；
- 部署在一个进程内，一处修改，会影响其他功能的运行；
- 系统容量难以准确评估
微服务架构
- 不同功能模块拆分成多个不同的服务，这些服务都能独立部署和扩展；
- 每个服务都运行在自己的进程内，每个服务的更新不会影响其他服务的运行；
- 独立部署，可以准确地评估每个服务的性能容量。
如何实施微服务
在实施微服务之前，我们必须要知道，微服务虽然有非常多吸引人的优点，但是也因为服务的拆分引发了诸多原本在单体应用中没有的问题。
运维的新挑战
在微服务架构中，运维人员需要维护的进程数量会大大增加。有条不紊地将这些进程编排和组织起来不是一件容易的事，传统的运维人员往往很难适应这样的改变。
接口的一致性
虽然我们拆分了服务，但是业务逻辑上的依赖并不会消除，只是从单体应用中的代码依赖变为了服务间的通信依赖。而当我们对原有接口进行了一些修改，那么交互方也需要协调这样的改变来进行发布，以保证接口的正确调用。我们需要更完善的接口和版本管理，或是严格地遵循开闭原则。
分布式的复杂性
由于拆分后的各个微服务都是独立部署并运行在各自的进程内，它们只能通过通信进行协作，所以分布式环境的问题都将是微服务架构系统设计时需要考虑的重要因素，比如网络延迟、分布式事务、异步消息等。
微服务架构的九大特性
服务组件化
组件，是一个可以独立更换和升级的单元。就像PC中的CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。
按服务组织团队
在实施微服务架构时，需要采用不同的团队分割方法。由于每一个微服务都是针对特定业务的宽栈或是全栈实现，既要负责数据的持久化存储，又要负责用户的接口定义等各种跨专业领域的职能。因此，面对大型项目的时候，对于微服务团队的拆分更加建议按业务线的方式进行拆分，一方面可以有效减少服务内部修改所产生的内耗；另一方面，团队边界可以变得更为清晰。
做“产品”的态度
在实施微服务架构的团队中，每个小团队都应该以做产品的方式，对其产品的整个生命周期负责。而不是以项目的模式，以完成开发与交付并将成果交接给维护者为最终目标。
智能端点与哑管道
在单体应用中，组件间直接通过函数调用的方式进行交互协作。而在微服务架构中，由于服务不在一个进程中，组件间的通信模式发生了改变，若仅仅将原本在进程内的方法调用改成RPC方式的调用，会导致微服务之间产生繁琐的通信，使得系统表现更为糟糕，所以我们需要更粗粒度的通信协议。
在微服务架构中，通常会使用以下两种服务调用方式：
- 第一种：使用HTTP的RESTful API 或轻量级的消息发送协议，实现信息传递与服务调用的触发；
- 第二种：通过在轻量级消息总线上传递消息，类似RabbitMQ等一些提供可靠异步交换的中间件。
在极度强调性能的情况下，可能会使用二进制的消息发送协议，例如protobuf。即使这样，这些系统仍然会呈现出“智能端点和哑管道”的特点，这是为了在易读性与高效性之间取得平衡。当然大多数Web应用或企业系统并不需要在这两者间做出选择，能够获得易读性已经是一个极大的胜利了。
去中心化治理
在实施微服务架构时，通过采用轻量级的契约定义接口，使得我们对于服务本身的具体技术平台不再那么敏感，这样整个微服务架构系统中的各个组件就能针对其不同的业务特点选择不同的技术平台，终于不会出现杀鸡用牛刀或是傻妞用指甲剪的尴尬处境了。
“不是每一个问题都是钉子，不是每一个解决方案都是锤子。”
去中心化管理数据
-
数据管理的去中心化：每一个微服务管理自有的数据库。
- 将原数据库中的存储内容拆分到新的同平台的其他数据库实例中，如把原本存储在MySQL中的表拆分后，存储到多个不同的MySQL实例中。
- 将具有特殊结构或业务特性的数据存储到其他技术的数据库实例中，如吧日志信息存储到MongoDB中或把用户登录信息存储到Redis中。
-
缺点：
- 数据一致性问题；
- 分布式事务实现难度大；
-
解决方法：
- 要求数据最后的处理状态一致即可；
- 各服务之间进行“无事务”的调用；
- 过程中发现错，通过补偿机制进行处理，使得错误数据达到最终的一致性。
基础设施自动化
微服务架构中，务必一开始就构建“持续交付”平台来支撑整个实施过程，因此需要下面两大内容：
- 自动化测试：每次部署前的强心剂，尽可能地获得对正在运行的软件的信心。
- 自动化部署：解放繁琐枯燥的重复操作以及对多环境的配置管理。
容错设计
- 单体应用：一挂全挂；
- 微服务架构：部分故障，其他正常运行；
在微服务架构中，会出现故障的蔓延，因此快速检测出故障源并尽可能地自动恢复服务是必须设计和考虑的。通常，我们都希望在每个服务中实现监控和日志记录的组件，比如服务状态、断路器、吞吐量、网络延迟等关键数据的仪表盘等。
演进式设计
在很多情况下，架构师都会以演进的方式进行系统的构建。在初期，以单体系统的方式来设计和实施，一方面系统体量初期并不会很大，构建和维护成本都不高。另一方面，初期的核心业务在后期通常也不会发生巨大的改变。随着系统的发展或者业务的需要，架构师会将一些经常变动或是有一定时间效应的内容进行微服务处理，并逐渐将原来在单体系统中多变的模块逐步拆分出来，而稳定不太变化的模块就形成一个核心微服务存在于整个架构中。
为什么选择Spring Cloud
Spring Cloud的出现，可以说是对微服务架构的巨大支持和强有力的技术后盾。它是一个解决微服务架构是的综合性解决框架，它整合了诸多被广泛实践和证明过的框架作为实施的基础部件，又在该体系基础上创建了一些非常优秀的边缘组件。
Spring Cloud简介
Spring Cloud 是一个基于Spring Boot 实现的微服务架构开发工具。它为微服务架构中涉及的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。
Spring Cloud 包含了多个子项目（针对分布式系统中涉及的多个不同开源产品，还可能会新增），如下所述：
- Spring Cloud Config:配置管理工具，支持使用Git存储配置内容，可以使用它实现应用配置的外部化存储，并支持客户端配置信息刷新、加密/解密配置内容等。
- Spring Cloud Netflix：核心组件，对多个Netflix OSS 开源套件进行整合。
- Eureka：服务治理组件，包含注册中心、服务注册与发现机制的实现。
- Hystrix：容错管理组件，实现断路器模式，帮助服务依赖中出现的延迟和为故障提供强大的容错能力。
- Ribbon：客户端负载均衡的服务调用组件。
- Feign：基于Ribbon和Hystrix的声明式服务调用组件。
- Zuul：网关组件，提供智能路由、访问过滤等功能。
- Archaius：外部化配置组件。
- Spring Cloud Bus：事件、消息总线，用于传播集群中的状态变化或事件，以触发后续的处理，比如用来动态刷新配置等。
- Spring Cloud Cluster：针对ZooKeeper、Redis、Hazelcast、Consul的选举算法和通用状态模式的实现。
- Spring Cloud Cloudfoundry：与Pivotal Cloudfoundry的整合支持。
- Spring Cloud Consul：服务发现与配置管理工具。
- Spring Cloud Stream：通过Redis、Rabbit或者Kafka实现的消费微服务，可以通过简单的声明式模型来发送和接收消息。
- Spring Cloud AWS：用于简化整合Amazon Web Service的组件。
- Spring Cloud Security：安全工具包，提供在Zuul代理中对OAuth2客户端请求的中继器。
- Spring Cloud Sleuth：Spring Cloud英勇的分布式跟踪实现，可以完美整合Zipkin。
- Spring Cloud ZooKeeper：基于ZooKeeper的服务发现与配置管理组件。
- Spring Cloud Starters：Spring Cloud的基础组件，它是基于Spring Boot风格项目的基础依赖模块。
- Spring Cloud CLI：用于在Groovy中快速创建Spring Cloud应用的Spring Boot CLI插件。
- …
版本说明
由于Spring Cloud 不像Spring社区其他一些项目那样相对独立，它是一个拥有诸多子项目的大型综合项目，可以说是对微服务架构解决方案的综合套件组合，其包含的各个子项目也都独立进行着内容更新与迭代，各自都维护者自己的发布版本号。因此每一个Spring Cloud的版本都会包含多个不同的版本的子项目，为了管理每个版本的子项目清单，避免Spring Cloud的版本号与其子项目的版本号相混淆，没有采用版本号的方式，而是通过命名的方式。这些版本的名字采用了伦敦地铁站的名字，根据字母表的顺序来对应版本时间顺序。