《Spring + Cloud微服务实战》读书笔记（一）————基础知识
1.微服务架构
微服务是系统架构中的一种设计风格。
将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于
HTTP的REST API进行通信协作。
每个小型服务维护自身的数据存储，业务开发，独立测试案例以及独立部署机制。
轻量级的通信协作基础，使得这些服务可以用不同语言编写。
2.微服务架构的九大特性
2.1服务组件化
组件，是一个可以独立更换和升级的单元，且不会影响到其他单元。
在微服务架构中，需要我们对服务进行组件化分解。服务，是一种进程外的组件。
每一个服务独立开发和部署，可以有效避免一个服务的修改引起整个系统的重新部署。
2.2按业务组织团队
由于每一个微服务都是针对特定业务的宽栈或全栈实现，既要负责数据的持久化存储，又要负责用户的接口定义等各种跨专业领域的职能。
因此，面对大型项目时，对于微服务团队的拆分更加建议按业务线的方式进行拆分。一方面可以有效减少服务内部修改所产生的内耗，另一方面，团队边界可以变得更为清晰。
2.3做“产品”的态度
在实施微服务架构的团队中，每个小团队都应该以做产品的方式，对其产品的整个生命周期负责。
开发团队通过了解服务在具体生产环境中的情况，可以增加对具体业务的理解。
对待每一个微服务，持续关注服务的运作情况，并不断分析以帮助用户来改善业务功能。
2.4智能端点与哑管道
在微服务中，由于服务不在一个进程中，组件间的通信模式发生了改变，若仅仅将原本在进程内的方法调用改为RPC方式的调用，会导致微服务之间产生烦琐的通信。
所以需要更粗粒度的通信协议，通常使用：
1、使用HTTP的RESTful API或轻量级的消息发送协议，实现信息传递与服务调用的触发。
2、通过在轻量级消息总线上传递消息，类似RabbitMQ等一些提供可靠异步交换的中间件。
2.5去中心化治理
在实施服务架构时，通常采用轻量级的契约定义接口，使得服务本身的具体技术平台不再那么敏感，这样整个微服务架构系统中的各个组件就能针对其不同的业务特点选择不同的技术平台。
不是每个问题都是钉子，不是每个解决方案都是锤子。
2.6去中心化管理数据
在实施微服务架构时，都希望每一个服务来管理其自有的数据库，这就是数据管理去中心化。
去中心化过程中，除了将原数据库中的存储内容拆分到新的同平台的其他数据库事例中（如将一个MySQL实例中的表，拆分到多个不同的MySQL实例中），也可以将一些具有特殊结构或业务特性的数据存储到一些其他技术的数据库实例中（MongoDB,Redis）。
数据管理的去中心化，可以让数据管理更加细致化，采用更合适的技术可以让数据存储好性能达到最优。
但，由于数据存储于不同数据库实例中后，数据的一致性成了有待解决的问题之一。
所以在微服务架构中能够，强调在各服务之间进行”无事务”的调用，而对于数据的一致性，只要求数据在最后的处理状态一致即可。
若在过程中发现错误，通过补偿机制进行处理，使得错误数据能够达到最终的一致性。
2.7基础设施自动化
在微服务架构中，务必从一开始就构建起”持续交付”平台来支撑整个实施过程，该平台需要两大内容：
1、自动化测试：
每次不输钱的强心剂，尽可能地获得对正在运行的软件的信心。
2、自动化部署：
解放烦琐枯燥的重复操作以及对多环节的配置管理。
2.8容错设计
在微服务架构中，由于服务都是运行在独立的进程中，所以存在部分服务出现故障，而其他服务正常运行的情况。
调用：
A -> B -> C -> D
如果D出现故障，调用链的上游所有服务都会等待下游的响应，造成连锁反应的蔓延，故障的蔓延
所以，在微服务架构中，快速检测出故障源并尽可能地自动恢复服务是必须被设计和考虑的。
通常，我们都希望在每个服务中实现监控和日志记录的组件，比如服务状态、断路状态，吞吐量，网络延迟等关键数据的仪表盘等。
2.9演进式设计
通过以上的几点特征，发现，要实施一个完美的微服务架构，需要考虑的设计与成本并不小。
所以，在很多情况下，架构师都会以演进的方式进行系统的架构。
在初期，以单体系统的方式来设计和实施：
1、系统体量初期并不会很大，构建和维护成本都不高
2、初期的核心业务在后期通常也不会发生巨大的改变
随着系统的发展或者业务的需要，架构师会将一些经常变动或是有一定时间效应的内容进行微服务处理，并逐渐将
原来在单体系统中多变的模块逐步拆分出来，而稳定不太变化的模块就形成一个核心微服务存在于整个架构中。
3.选择Spring Could的原因
这是一个解决未付架构实施的综合性解决框架，它整合了诸多被广泛实践和证明过的框架作为实施的基础部件，又在该体系基础上创建了一些非常优秀的边缘组件。
4.Spring Cloud 简介
Spring Cloud是一个基于Spring Boot实现的微服务架构开发工具。
它为微服务架构中涉及的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式回话和集群状态管理等操作提供了一种简单的开发方式。
Spring Cloud包含了多个子项目（针对分布式系统中设计的多个不同开源产品，还可能会新增），如下：
1、Spring Cloud Config:
配置管理工具，支持使用Git存储配置内容，可以使用它实现应用配置的外部化存储，并支持
客户端配置信息刷新、加密/解密配置内容等。
2、Spring Cloud Netflix:核心组件，对多个Netflix OSS开源套件进行整合
Eureka: 服务治理组件，包含服务注册中心、服务注册与发现机制的实现。
Hystrix: 容错管理组件，实现断路器模式，帮助服务依赖中出现的延迟和为故障提供强大的容错能力。
Ribbon:客户端负载均衡的服务调用组件。
Feign:基于Ribbon和Hystrix的声明式服务调用组件。
Zuul:网关组件，提供智能路由、访问过滤等功能。
Archaiux:外部化配置组件
3、Spring Cloud Bus
事件、消息总线，用于传播集群中的状态变化或事件，以触发后续的处理，比如用来冬天刷新配置等。
4、Spring Cloud Cluster
针对ZooKeeper、Redis、Hazelcast、Consul的选举算法和通用状态模式的实现。
5、Spring Cloud CloudFoundry
与Pivotal Cloud foundry 的整合支持。
6、Spring Cloud Consul
服务发下和配置管理工具
7、Spring Cloud Stream
通过Redis、Rabbit或者Kafka实现的消费微服务，可以通过简单的声明式模型来发送和接收消息。
8、Spring Cloud AWS
用于简化整合Amazon Web Service 的组件。
9、Spring Cloud Security
安全工具包，提供在Zuul代理中对OAuth2客户端请求的中继器。
10、Spring Cloud Sleuth
Spring Cloud应用的分布式跟踪实现，可以完美整合Zipkin
11、Spring Cloud ZooKeeper
基于ZooKeeper的服务发现与配置管理组件
12、Spring Cloud Starters
Spring Cloud 的基础组件，它基于Spring Boot风格项目的基础依赖模块
13、Spring Clod CLI
用于在Groovy中快速创建Spring Cloud应用的 Spring Boot CLI插件
5.备注
Hazelcast
Hazelcast是一个用Java编写的基于内存的数据网格管理平台（open source in-memory data grid）。
同时也是一个公司的名字。
公司网站：https://hazelcast.com
产品网站：https://hazelcast.org
Consul
一个服务管理软件。
支持多数据中心下，分布式高可用的，服务发现和配置共享。
consul支持健康检查，允许存储键值对。
一致性协议采用 Raft 算法,用来保证服务的高可用.
RabbitMQ
MQ是消费-生产者模型的一个典型的代表，一端往消息队列中不断写入消息，而另一端则可以读取或者订阅队列中的消息。MQ和JMS类似，但不同的是JMS是SUN JAVA消息中间件服务的一个标准和API定义，而MQ则是遵循了AMQP协议的具体实现和产品。
Kafka
Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。
有如下特性：
通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。
高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。
支持通过Kafka服务器和消费机集群来分区消息。
支持Hadoop并行数据加载。
Zuul
zuul 是netflix开源的一个API Gateway 服务器, 本质上是一个web servlet应用。
Zuul 在云平台上提供动态路由，监控，弹性，安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。
Zipkin
zipkin为分布式链路调用监控系统，聚合各业务系统调用延迟数据，达到链路调用监控跟踪
Groovy
Groovy是一种基于JVM（Java虚拟机）的敏捷开发语言，它结合了Python、Ruby和Smalltalk的许多强大的特性，Groovy 代码能够与 Java 代码很好地结合，也能用于扩展现有代码。由于其运行在 JVM 上的特性，Groovy 可以使用其他 Java 语言编写的库。