7.30 观《Spring微服务实战》输出笔记20201231

  1.  
序号
书中主要内容
解决的问题和疑问点和收获
0
序言：看书想解决的问题点：前言
  1. Spring Framework和Spring的关系， Spring Boot，Spring Clould？
    1. Spring Framework像是Spring树根，让JAVA在Spring中屹立不倒的原因，他的目标是帮助开发人员开发出更好的的系统
    2. Spring Boot像树干，简化Spring的初始开发搭建以及开发过程，在快速开发领域蓬勃发展。
    3. Springcould犹如Spring这颗参天大树在微服务的开发领域结出的果实
  2. 为什么用微服务、技术选型的角度看
    1. Spring Cloud是一系列框架的有序集合。Spring Cloud提供一整套微服务实施方案，它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。
    2. 微服务的简单可以成为架构的改变者，微服务的架构重点是使用简单协议（HTTP和JSON）进行通信的小型服务。开发可以使用任何编程语言编写微服务。
    3. Spring Clould框架为许多微服务开发人员将会遇到的常见开发和运维问题提供开箱即用的解决方案
  3. 微服务的缺点
    1. 构建单个微服务简单，但实施和扩展却很难。
  4. 传统淘汰的架构演进成微服务
    1. 技术公司基于XML模式构建面向服务的架构（SOA，服务总线联通所有系统）？那沉重？现在那些企业还在用
    2. 基于Web的应用单体架构
      1. 单体应用程序需要重新部署，重新测试和构建
eagleEye:鹰眼
Docker： 物件， 码头工人
Amazon:亚马逊云环境
Framework：框架，结构
1
第一章：欢迎迈入云的世界，Spring
    1. 什么是微服务，2014有初步的思想？（CRM系统的典例，把项目分解成完全彼此独立的微服务，每个开发团队可以独立开发和部署）
      1. 是小的，松耦合的分布式系统
      2. 分解和分离应用程序的功能，使他们彼此独立构建，部署和测试
      3. 微服务的特征
        1. 应用程序逻辑分解为具有明确定义职责范围的颗粒度组件，这些组件互相协调提供解决方案。
        2. 职责范围和细粒度组价，每个组件有小弟职责领域，并且完全独立部署，彼此独立构建，部署和测试
        3. 微服务通信基于基本原则，一般采用HTTP或者JSON轻量级通信协议
        4. 微服务利用其小，独立和分布式的性质，让组织拥有明确责任领域的小型开发团队。
    2. Spring和微服务的关系
      1. Spring目前是标准开发框架，核心是依赖注入（管理类或者JAVABean的依赖关系），允许用户通过约定（注解）将应用程序对象之间关系外部化，以便于轻松管理大型JAVA项目。Spring的轻量级取代了J2EE技术栈。
      2. Spring团队发现正在从应用程序的展现，业务和数据访问逻辑打包从但他应用程序迁移，转向高度分布式模型，服务可被构建成轻松部署到云端的小型分布式服务。spring启动的2个项目就是SpringBoot和SpringCould。
      3. Spring Boot剥离SPring许多企业特性，提供一个基于JAVA、面向REST的微服务框架。只需要一些简单的注解，快速构建打包部署REST的微服务，不需要外部容器。
        1. REST的核心，使用HTTP动词（get，post，pul，delete）代表接口的核心操作，通常使用JSON传输数据
        2. 测试过程可基于POSTMAN调用微服务接口
    3. 使用Spring Boot构建微服务
      1. SpringBoot抽象出了微服务任务(路由到业务逻辑，从URL解析HTTP参数、JSON与对象的相互映射)，让开发人员专注于逻辑，REST端点
      2. 测试过程可基于POSTMAN调用微服务HTTP JSON REST接口
      3. 主要步骤
        1. 客户端发送HTTP的GET请求到微服务
        2. 路由映射：SpringBoot解析HTTP请求，根据URL和HTTP谓词映射相应的RestControll方法
        3. 参数解析：识别路由后解析URL参数和传输参数映射到执行该工作的方法
        4. JSON到JAVA对象映射：对于HTTP的put和post请求，在HTTP主体中传递的JSON被映射到JAVA类
        5. 业务逻辑执行：映射完所有数据，SpringBoot执行业务逻辑。
        6. JAVA到JSON对象返回：执行完业务逻辑，SpringBoot将对象转换为JSON
        7. 客户端以JSON接收来自服务的响应，调用成功和失败以状态码返回。
      4. 为什么依赖Docker容器，如果自搭建的话需要那些操作？
      5. 疑问：销售易项目上的注解譬如@path，@XsyApi都是怎么走的注解？
      6. 创建代码，然后使用MVN和JAVA构建服务。
        1. MVN springBoot：run，使用SpringBoot插件，使用嵌入的Tomcat启动服务器（可以使用Groovy编程，Gradle构建服务）
        2. 可以使用PostMan调用对应的rest接口
    4. 为什么要改变构建应用的方式使用微服务
      1. 项目的拐点，客户的痛点，使用单体结构的弊端
        1. 复杂性上升
        2. 客户期待更快的交付
        3. 性能和可伸缩性
        4. 客户期望应用程序可用
      2. 开发人员需构建高可伸缩性和高度冗余的应用程序，把他们分解小互相独立构建和部署的小型服务。
        1. 灵活性，解耦的服务重新组合和安排，可以实现快速交付
        2. 有弹性，单一服务故障不影响整个项目
        3. 可伸缩，解耦的服务可以轻松跨多个服务器水平分布。
        4. 总结就是：小型的、简单的、解耦的服务=可伸缩、有弹性和灵活
        5. 微服务的重点是构建有限职责的小型服务，并使用基于HTTP的接口通信。
    5. 云到底是什么
      1. 云计算的三种基本模式
        1. 基础设施即服务（Infrastructure as a Service ,Iaas）商店购买食物
          1. 云供应商提供基础设施，你需要选择技术并构建最终的解决方案
        2. 平台即服务（Platform as a Service，Paas）点外卖
          1. 你仍然需要负责烹饪食物，同时依靠供应商来负责和膳食制作相关核心人物
          2. 你提供盘子和家具，餐厅老板提供烤箱
        3. 软件即服务（Software as a Service，Saas）去餐厅吃饭
          1. 你是供应商提供的被动消费者，无法对技术选择，没有责任维护基础设施
        4. 新兴的云平台
          1. 函数即服务（Functions as a Service，FaaS）
          2. 容器即服务（Container as a Service，Caas）
        5. 每个模型的关键都是控制项
          1. 由谁维护基础设施，以及构建应用程序的技术选择
            1. ,Iaas云供应商提供基础设施，你需要选择技术并构建最终的解决方案
            2. Saas你是供应商所提供的的被动消费者，无法对技术进行选择，同时也没有任何责任来维护应用程序的基础设施。
    6. 为什么是云和微服务
      1. 将服务器部署到某个环境里
        1. 物理服务器：虽然可以构建和部署微服务到物理机器，但过于局限，不能快速的提高物理服务器的容量，并且在多个物理服务器之间水平伸缩微服务成本会很高。
        2. 虚拟机镜像：能够快速启动或者关闭微服务实例，响应可伸缩和服务故障，虚拟机是主要云供应商的心脏和灵魂。微服务可打包虚拟机镜像中，开发人员可以在Iaas私有或者公有云中快速部署和启动微服务实例。
        3. 虚拟容器：是在虚拟机镜像上部署微服务的自然延伸，将Docker容器（或者等效容器）部署到云端。虚拟容器在虚拟机内运行。使用虚拟容器，可以将单个虚拟机隔离成共享相同虚拟机镜像的一系列独立进程
      2. 基于云的微服务优势
        1. 以弹性的概念为中心，开发商允许几分钟内快速启动新的虚拟机和容器
        2. 使用Docker容器将所有的微服务和所有微服务和相应的服务基础设施部署到基于Iaas云供应商
          1. 简化基础设施管理：有效控制服务，开发人员通过简单的API启动和停止新服务
          2. 大规模的水平可伸缩性：快速简便的启动服务的一个或者多个实例
          3. 通过地理分布实现高亢余：拥有多个数据中心。
        3. 使用Docker打包微服务，将这些容器部署到亚马逊平台。第十章详细介绍
    7. 微服务不仅仅是编写代码（全文的概括）
      1. 构建单个微服务的概念很容易理解，但运行和支持健壮性的云上微服务不只涉及编写代码，
      2. 需考虑的要点
        1. 大小适当：服务的单一职责
        2. 位置透明：多个服务的快速启动
        3. 有弹性：快速失败，绕过失败的服务
        4. 可重复：相同的配置和代码库
        5. 可伸缩：如果使用异步方式最小化服务的直接依赖关系
      3. 基于模式的方法解决上述问题，不同技术实现来使用通用设计，基于SpringBoot和Spring Cloud实现所使用的模式。
        1. 核心微服务开发模式:构建微服务的基础问题
          2. 服务粒度：怎样适中？不过大和过于小（复杂）
          3. 通信协议：JSON（对象表示法）？XML（可扩展标记语言）
          4. 接口设计：实际的服务接口，便于开发服务调用，URL设计，版本化服务——》第2章详细介绍
          5. 服务的配置管理：管理微服务，服务的配置文件；第3章详细介绍
          6. 服务之间的事件处理。第八章
        2. 微服务的路由模式
          1. 基于云的应用程序，可能运行成千上百个微服务实例，抽象服务的物理IP地址，并为服务调用提供单个入口，以便为所有服务调用持续强制的执行安全和内容策略，如何将客户的请求发送到服务的特定实例
            1. 服务发现，第四章详细介绍：如何使微服务被发现
            2. 服务路由，第六章详细介绍：为所有服务提供单个入口点，将安全策略和路由规则统一应用
        3. 微服务的弹性模式
          1. 微服务是高度分布式的，所以必须防止单个服务中问题级联暴露给消费者。
            1. 客户端负载均衡
            2. 断路器模式
            3. 后备模式
            4. 舱壁模式
        4. 微服务的安全模式
          1. 验证
          2. 授权      
          3. 凭据管理和传播
        5. 微服务日志记录和跟踪模式
          1. 日志关联
          2. 日志聚合
          3. 微服务跟踪
        6. 微服务的构建和部署模式
          1. 微服务的每个实例都和其它相同
          2. 构建和部署管道
          3. 基础设施及代码
    8. 使用Spring Cloud构建微服务
      1. Spring Cloud将Pivotal、HashiCorp和Netfils等开源公司的工作封装在一起。 
        1. 简化将这些项目设置和配置Spring应用程序中的工作，以便开发人员专注于编写代码，不会沦陷于配置构建和部署微服务应用程序的所有基础设施中。
      2. Spring Boot是微服务使用的核心技术，
        1. 简化构建基于REST的微服务核心任务，大大简化微服务开发。还极大简化将HTTP类型动词（GET、PUT、POST、DELETE）的、映射到URL、JSON协议序列化和JAVA对象相互转化，将JAVA处理结果映射成HTTP错误码。
      3. Spring Cloud Config
        1. Spring Cloud Config通过集中式服务处理应用程序配置数据的管理，配置数据和部署微服务分离，无论启动多少微服务实例，这些实例有相同的配置。Spring Cloud Config有自己的属性管理存储库，也可以和开源项目集成。
          1. 与GIT集成：GIT是一个开源的版本控制系统。
          2. 与Consul集成：Consul开发是一种开源的服务发现工具，它允许服务实例向自己注册。
          3. 与Eureka集成：Eureka是一个开源的Netfix项目，和Consul类似提供服务发现的功能。Eureka同样有一个被Spring Cloud Config使用的键值数据库。
      4. Spring Cloud 的服务发现
        1. 通过服务发现，开发人员可以从客户端消费的服务抽取部署微服务的物理位置，服务消费者通过逻辑名称而不是物理位置来调用服务器的业务逻辑。
        2. 服务发现也处理服务实例的注册好注销（在服务实例启动和关闭时）
        3. 可以使用Consul和Eureka作为服务发现的引擎
      5. Spring Cloud 与Netflix Hystrix 和 Netflix  Ribbon
        1. Spring Cloud与Netflix的开源项目逬行了大量整合。对于微服务客户端弹性模式 Spring Cloud，封装了Netflix Hystrix和Netflix Ribbon项目，开发人员可以轻松地在微服务中使用它们。
        2.  使用NetflixHystrix开发可以快速实现服务客户端弹性模式,如断路器模式和舱壁模式。
        3.    虽然Netflix Ribbon项目简化了与诸如Eureka这样的服务_代理的集成，但它也为服劳消赛者提供了客户端对调用的负载均衡。即使在服务代理暂时不可用时，客户端也可以继续进行服务调用。
      6. Spring Cloud 与Netflix Zuul
        1. 提供路由服务，Zuul是代理服务请求的服务网关，对所有微服务的调用都有一个前门，通过集中的服务调用，开发人员可以强制执行标准服务策略，如安全授权验证，内容过滤和路由规则。
      7. Spring Cloud Stream
        1. 是一种可以让开发人员轻松的将轻量级消息处理集成到微服务的支持技术。开发人员能够构建智能的微服务。他可以使用应用程序出现的异步事件。可以快速将微服务与消息代理进行整合，如RabbitMQ，Kafka
      8. Spring Cloud Sleuth
        1. 跟踪号码
      9. Spring Cloud Security
        1. 验证和授权框架，控制那些人访问
      10. 代码供应
总结解决的问题或者知识点
 
  1. 什么是微服务？（答案左边）
  2. 公司使用微服务的原因（微服务的优点）
    1. 灵活性，解耦的服务重新组合和安排，可以实现快速交付
    2. 有弹性，单一服务故障不影响整个项目
    3. 可伸缩，解耦的服务可以轻松跨多个服务器水平分布。
    4. 总结就是：小型的、简单的、解耦的服务=可伸缩、有弹性和灵活
    5. 微服务的重点是构建有限职责的小型服务，并使用基于HTTP的接口通信。
  3. 为什么构建应用程序，基于云的应用程序重要方法。
    1. 以弹性的概念为中心，开发商允许几分钟内快速启动新的虚拟机和容器
    2. 使用Docker容器将所有的微服务和所有微服务和相应的服务基础设施部署到基于Iaas云供应商
      1. 简化基础设施管理：有效控制服务，开发人员通过简单的API启动和停止新服务
      2. 大规模的水平可伸缩性：快速简便的启动服务的一个或者多个实例
      3. 通过地理分布实现高亢余：拥有多个数据中心。
    3. 使用Docker打包微服务，将这些容器部署到亚马逊平台。
  4. 构建微服务有哪些需要注意的点（运行和支持健壮性的云上微服务不只涉及编写代码）
    1. 需考虑的问题
      1. 大小适当：服务的单一职责
      2. 位置透明：多个服务的快速启动
      3. 有弹性：快速失败，绕过失败的服务
      4. 可重复：相同的配置和代码库
      5. 可伸缩：如果使用异步方式最小化服务的直接依赖关系
    2. 用什么技术解决
      1. 微服务的路由模式
        1. 服务发现，第四章详细介绍
        2. 服务路由，第六章详细介绍
      2. 微服务的弹性模式
        1. 微服务是高度分布式的，所以必须防止单个服务中问题级联暴露给消费者。
        2. 客户端负载均衡
        3. 断路器模式
        4. 后备模式
        5. 舱壁模式
      3. 微服务的安全模式
        1. 验证
        2. 授权      
        3. 凭据管理和传播
      4. 微服务日志记录和跟踪模式
        1. 日志关联
        2. 日志聚合
        3. 微服务跟踪
      5. 微服务的构建和部署模式
        1. 微服务的每个实例都和其它相同
        2. 构建和部署管道
        3. 基础设施及代码
  5. 使用Spring Cloud构建微服务（答案如左边）
    1. Spring Cloud将Pivotal、HashiCorp和Netfils等开源公司的工作封装在一起。 
      1. 简化将这些项目设置和配置Spring应用程序中的工作，以便开发人员专注于编写代码，不会沦陷于配置构建和部署微服务应用程序的所有基础设施中。
    2. Spring Boot是微服务使用的核心技术，
      1. 简化构建基于REST的微服务核心任务，大大简化微服务开发。还极大简化将HTTP类型动词（GET、PUT、POST、DELETE）的、映射到URL、JSON协议序列化和JAVA对象相互转化，将JAVA处理结果映射成HTTP错误码。
  6. 微服务基于SpringBoot和Spring Cloud实现。（答案左边第7，8点）
  7. 总结
    1. 微服务是小的功能部件，负责单一和特定的范围领域
    2. 微服务目前没有行业标准，与其它早期WEB协议不同，微服务采用原则导向的方法，与REST和JSON的概念 一致
    3. 编写微服务很容易，但要是用于项目需深谋远虑，主要的几类微服务开发模式，包括核心开发模式，路由模式，客户端弹性模式，安全模式，日志记录和跟踪模式以及构建和部署模式
    4. 微服务与语言无关，但Spring Boot和Spring cloud非常有助于构建微服务
    5. Spring Boot用于简化REST的JSON微服务的构建，其目标让用户只需要少量注解就能快速构建微服务。
    6. Spring Cloud是NEtflix和HashiCorp公司开源项目的集合，他们用Spring注解进行包装，简化服务的设置和配置。
2
第二章：使用spring Boot 构建微服务
  1. 架构师的故事：设计微服务架构
    1. 分解业务问题:业务事务俩个不同部分如何交互成为微服务的服务接口
      1. 描述业务问题，反复使用的名词是核心的业务领域，可创建微服务。如合同，许可证，资产。
      2. 注意动词，注意交互关系，代表问题的自然轮廓
      3. 寻找数据内聚
    2. 建立服务粒度
      1. 正确服务粒度的解决方案
        1. 开始让服务涉及范围广一点，然后再将其重构更小的服务
        2. 重点关注服务如何交互，有助于建立问题域的粗粒度接口
        3. 随着对问题域的理解增长，服务的职责随着时间而改变。
      2. 错误微服务的特征
        1. 服务粒度问题
          1. 服务承担过多的职责
          2. 跨大量表管理数据
          3. 测试用例太多
        2. 过于细粒度
          1. 问题域的一部分微服务不断繁殖
          2. 微服务彼此相互依赖
          3. 微服务成为简单的CRUD集合
      3. 演化思维的过程来开发一个微服务架构
      4. 采取务实的方法进行交付
    3. 互相交流：定义服务接口
      1. 服务接口应该是直观的，思考服务接口设计
        1. 拥抱REST理念
        2. 使用URL传达意图
        3. 请求和响应使用的JSON
        4. 使用HTTP状态码传达结果
  2. 微服务不适用于什么项目
    1. 构建分布式系统的复杂性
      1. 微服务的分布式和颗粒度小从而引入复杂性，微服务架构需要成熟的运维，组织愿意投入高分布式应用程序获得成功所需的自动化和运维工作（监控，伸缩）
    2. 服务器散乱
      1. 一个服务器部署一个实例，最终可能需要50-100台服务器或容器（通常是虚拟容器）,这些服务器必须单独搭建和维护，管理和维护监控这些服务器操作复杂度也是巨大的
    3. 应用程序类型
      1. 微服务面向可复用性，并且对构建高度弹性和可伸缩性大型应用程序非常有用，大用户群，搭建分布式系统。
    4. 数据事务和一致性
      1. 微服务间执行事务没有标准，如果需要事务管理，需要自己构建逻辑。第七章：微服务可使用消息进行通信
  3. 开发人员的故事：用Spring boot 和JAVA构建微服务（怎样搭建详细如书中37页）
    1. 骨架项目开始
      1. 冲许可证服务创建一个骨架项目
    2. 编写引导类
    3. 微服务的入口：spring Boot的控制器
  4. DevOps(开发运维或运营)工程师的故事:构建运行时的严谨性 
    1. 对于DevOps工程师来说，微服务的设计关乎投入生产后如何管理服务。编写代码很简单，保持代码运行是困难的，四个原则
      1. 微服务应该是独立的可独立部署的
      2. 微服务应该是可配置的
      3. 微服务实例需要对客户端是透明的，客户端不应该知道服务的确切位置。
      4. 微服务应该传达它的健康状态，它是云架构的关键部分。
    2. 4个原则映射运维的4个生命周期
      2. 服务装配，如何快速打包和部署微服务多个实例，保证可重复性和一致性。
        1. 可以使用Maven和SpringBoot构建一个可执行的JAVA的Jar文件，该文件具有嵌入式的Tomcat再其中，
        2. 命令：mvn clean package && java -Cjar target/jar包名 
      3. 服务引导，配置代码和运行代码如何分开，任何环境快速启动和部署微服务实例，无需对配置微服务进行干预。
        1. 需要使用应用程序的运行时行为可配置。
          1. 通常涉及从应用程序部署的属性文件读取配置数据，
          2. 从数据存储区读取数据
        2. 微服务通常会遇到相同类型的配置需求，运行成千上百的微服务实例，由于存在大量地理分散的服务，重新部署服务获取新的配置难以实施。
        3. 将数据存储在服务器外部的数据存储解决这个问题，
        4. 云上微服务配置的挑战
          1. 配置数据结构简单，通常读取频繁不经常写入，这种情况，使用关系数据库，过于大材小用。关系型数据库主要是管理一组简单键值对数据的更复杂关系数据。
          2. 数据定期访问很少更改，数据必须具有低延迟的可读性
          3. 数据存储必须有高可用性，靠近读取数据的服务。第三章详细介绍使用键值对数据存储工具
      4. 服务注册和发现，客户端如何跟微服务通信，部署一个新的微服务实例，如何让其他应用程序客户端发现
      5. 服务监控，微服务环境中，由于高可用需求，同一服务运行多个实例非常常见，监控微服务实例，确保绕过微服务的其它屏障，状况不佳的服务需要被拆卸。
  5. 三者视角综合起来
    1. 云中的微服务卡你来简单，但要成功需要架构师，开发人员，和DEVOPS的综合视角
      1. 架构师专注于业务问题的轮廓
      2. 软件工程师专注于构建分层服务，每一层有离散职责，避免代码中构建框架，尝试每个微服务完全独立
      3. DevOps，尽早的建立服务的生命周期,不仅仅关注如何自动化服务的构建和部署，关注服务的健康状态，出问题快速反应
解决的问题或者知识点
  1. 了解微服务的架构
  2. 什么时候不应该使用微服务，微服务不适用于什么项目（答案左边第二大点）
  3. 怎样使用Spring Boot搭建微服务？
  4. 传统开发和微服务开发的区别
    1. 传统项目的劣势（微服务能解决的问题）？
      1. 传统开发项目崩溃，瀑布开发方法，着重项目开始的的界定，所有需求和设计。
      2. 现实情况大部分软件开发都属于一个演化过程，弄明白手头工作前，需要经历和客户沟通，像客户学习和客户交互数次迭代。
    2. 传统开发：瀑布开发方法，坚持开始时界定所有的应用和需求设计
      1. 紧耦合:
      2. 有漏洞的
      3. 单体的
    3. 实际情况: 软件开发并不是一个线性过程，而是一个演化迭代过程，微服务有哪些关键特征
      1. 有约束的，遵循UNIX的理念，应用程序是有序的集合，有限单一职责，每个服务做一件事，并做好一件事
      2. 松耦合的，基于微服务的应用程序使小型服务的集合
      3. 抽象的，微服务拥有自己的数据库和数据源。
      4. 独立的，每个服务可以独立其它程序进行编译和部署
    4. 为什么微服务基于云开发很重要
      1. 拥有庞大和多样化的用户群
      2. 极高的运行时间要求
      3. 不均匀的需求容量
  5. 微服务成功项目需要通过架构师，开发人员，和DEVOPS的综合视角
    1. 架构师角度，微服务是小型的，独立的和分布式的。微服务具有狭窄的边界，并管理一组数据。
    2. 开发人员角度，微服务通常使用REST风格构建，JSON作为服务发送和接收的净荷。
      1. SpringBoot是微服务的理想框架，它允许人员简单注解就能构建基于REST的json服务.
      2. 可以使用Maven和SpringBoot构建一个可执行的JAVA的Jar文件，该文件具有嵌入式的Tomcat服务器承载该服务。
      3. SpringBoot框架附带的SpringActuatoe会公开有关服务健康状况的信息和服务运行的信息
    3. DevOps角度，微服务打包部署和监控都至关重要。
3
第三章：使用Spring cloud配置服务器控制服务
  1. 配置文件的问题
    1. 将应用程序配置数据避免直接写入代码，对配置更改时都必须重新编译和部署。
      1. 解决方式：配置信息和代码分离，但会引入程序的复杂性。就会存在另一个需要和应用程序一起管理和部署的制品。
      2. 许多开发转向低层级的属性文件(YAML,JSON,XML)来存储配置信息，存在服务器，包含数据库连接和驱动信息，适用于少量应用程序。
    2. 配置管理是一件重要的事情。基于云的微服务开发强调几点
      1. 应用程序的配置和正在部署的实际代码完全分离
      2. 构建一个服务器，应用程序以及一个不可变的镜像，它们在各环境提升永远不会发生变化。
      3. 在服务器启动通过环境变量注入应用程序配置信息，或在微服务启动时通过集中式存储库读取应用程序配置信息。
  2. 解决的问题或者知识点
    1. 将服务配置和代码分开
    2. 配置Spring cloud的配置服务器
    3. 集成Spring Boot的微服务
    4. 加密敏感属性
  3. 管理配置（和复杂性）
    1. 应用程序配置的4个原则
      1. 分离：应用程序的配置和正在部署的实际代码完全分离
      2. 抽象：应用程序的配置数据功能抽象到一个服务接口，使用基于REST的JSON服务检索配置数据。
      3. 集中：最小化用于保存配置信息的不同存储库数量至关重要，应用程序配置集中在尽可能少的数据库中。
      4. 稳定：保证其高可用和冗余、
    2. 实施选择
      1. 实施配置管理技术方案优先选择Spring Clould config、Eureka、Consul
        1. Spring Clould config易于搭建和使用
        2. Spring Clould config与SpringBoot紧密集成，可以使用简单易用的注解读取应用程序的配置文件
        3. 提供多个后端用于存储配置数据。已经使用Eureka、Consul等工具，可以直接将他们插入Spring Config的配置服务器中
        4. 可直接和GIT源控制平台集成
  4. 构建配置Spring cloud的配置服务器（基于文件系统和使用Git存储库）
    1. 建立在Spring Boot之上配置服务器是基于REST的应用程序，它不是独立的服务器，可以嵌入现有的SpringBoot应用程序中，也可以嵌入它的服务器中启动新的Springboot项目
      1. 步骤
        1. /confsvr/pom.xml首先创建一个名为Confsvr的项目目录，创建新的maven文件，用于拉取启动Spring could配置服务器所需的Jar文件。
          1. 首先声明SpringBoot的版本
          2. 使用Spring could config的父物料清单（BOM），大量独立项目的集合,包含云项目中使用的所有第三方库和依赖项以及构成该版本的各个项目版本号。
            1. Spring-could-starter-config，所有Spring could依赖项
            2. Spring-could-config-server，它包含Spring-could-config-server的核心库。
        2. /confsvr/src/main/resources/application.yml,核心配置服务器正常运行。告诉Spring could侦听那些端口以及找到提供数据配置的后端。
        3. /confsvr/src/main/resources/config/licensingservice/licensingservice-dev.yml运行作为服务器公开Spring Cloud的配置文件，对应环境不同名
          1. 许可证服务直接使用示例属性
          2. 用于存储许可证服务数据的Postgres数据库配置
    2. 创建Spring Cloud Config引导类,构建
      1. 引导类/confsvr/src/main/java/com/thoughtmechanix/confsvr/ConfigServerApplication
        1. 服务启动入口点Java main方法
        2. 以及一组告诉启动服务将要启动那种类型的SpringCloud行为的Spring Cloud注解
      2. Spring Boot涉及的注解和作用？完善pringBoot注解。
        1. @SpringBootApplication 标记Spring could config是SpringBoot的应用程序
        2. @EnableConfigServer 使服务成为Spring Cloud Config服务
        3. main方法启动服务并启动Spring容器
      3. 使用带有文件系统的SPring Cloud 配置服务器
        1. 配置服务器在//confsvr/src/main/resources/application.yml,里
          1. 配置监听端口
          2. 用于存储配置的后端存储库，native
          3. 配置文件存储路径
        2. 运行Springboot项目：SpringBoot：run
          1. 访问许可证链接：http:/localhost:8080/licensingservcice/default
  5. 将Spring Cloud config和Spring Boot结合，待完善
    1. 建立许可证服务队Spring Cloud Config服务器的依赖
    2. 配置许可证服务以使用Spring Cloud Config
    3. 使用Spring Cloud配置服务器连接数据源
    4. 使用@value注解直接读取属性
    5. 使用Spring Cloud配置服务器和GIT
    6. 使用Spring Cloud配置服务器刷新属性
  6. 保护敏感配置信息
    1. 下载并安装加密所需的Oracle JCE jar
    2. 创建加密秘钥
    3. 加密和解密属性
    4. 配置微服务在客户端使用加密
  7. 最后的延伸
  1. 怎么将服务配置和代码分开？
    1. 把配置文件存在服务器上
    2.  
  2. 构建配置Spring cloud的配置服务器（基于文件系统和使用Git存储库）答案左边第四大点
  3. 集成Spring Boot的微服务
  4. 保护敏感配置信息
  5. 总结
    1. Spring Cloud配置服务器允许使用环境特定值创建应用程序属性
    2. Spring使用Spring profile来启动服务，以确定要从Spring Cloud Config服务减速那些环境属性
    3. Spring Cloud配置服务可以使用基于文件或基于Git的应用程序配置存储库来存储应用程序属性
    4. Spring Cloud配置服务允许使用对称加密和非对称加密对敏感属性文件进行加密
4
第四章：服务发现
  1. 本章引论
    1. 服务发现是什么：分布式架构需要找到机器的物理位置，
    2. 服务发现
      1. 简单的：通过属性文件包含应用程序的所有远程使用的地址
      2. 复杂的：像通用描述、发现和集成服务（UUDI）存储库一样正式和复杂
    3. 服务发现对基于云的应用程序至关重要
      1. 首先，它可以快速对环境中运行的服务实例数量进行水平伸缩，可以在服务池里添加或者移除服务实例
        1. 通过添加更多的服务器（水平伸缩）来扩大项目
        2. 服务发现有利于抽象这些服务部署，远离服务消费者
      2. 其次，它有助于提高应用程序的弹性
        1. 微服务实例变得不健康或者不可用时，服务的发现引擎将可用列表移除改服务，服务发现引擎在路由服务绕过不可用服务，使不可用服务造成最小伤害。
  2. 我们的服务在哪
    1. 应用程序调用分布在多个服务器上的资源时，需要定位这些资源的物理位置，实现方式有DNS和服务发现两种：
      1. 非云的世界：服务解析由DNS域名服务和网络负载均衡器解决，大体实现
        1. 应用程序使用通用的DNS和特定于服务路径调用服务
        2. 负载均衡器查找托管服务的服务地址（辅助负载均衡器检查主负载均衡，必要时接管服务）
        3. 服务部署到应用程序中，应用程序容器运行在持久服务器上
        4. DNS域名服务和网络负载均衡器解决优点：
          1. 适用于企业数据中心内部运行的应用程序，以及一组静态服务器上运行的少量服务情况
          2. 可以在集中化SSL终端和管理服务端口安全性发挥作用
        5. DNS域名服务和网络负载均衡器解决缺点
          1. 单点故障，负载均衡可实现高可用，但是整个基础设施的单点故障
          2. 有限的水平可伸缩性
          3. 静态管理
          4. 复杂
      2. 基于云的应用程序实现一个健壮的服务发现机制
  3. 云中的服务发现
    1. 基于云的应用程序实现一个健壮的服务发现机制的优点
      1. 高可用：可实现热部署
      2. 点对点：服务实例的传播
      3. 负载均衡：客户端本地缓存
      4. 弹性：服务器移除和添加不影响客户端使用
      5. 容错：30s心跳可监控
    2. 服务发现的架构
      1. 简单实现服务架构
        1. 客户端应用程序从服务发现代理获取服务IP地址，通过逻辑名称从服务发现代理找服务位置
        2. 一个服务上线时，这个服务会向服务发现代理注册他的IP地址
        3. 服务发现节点共享服务实例的健康信息
        4. 服务向服务发现代理发送心跳包，如果服务死亡，将被移除
      2. 更健壮的负载均衡
        1. 当服务客户端需要调用服务时，它将检查本地缓存的服务IP，服务实例之间的负载均衡会发生该服务上
        2. 客户端在缓存中找到一个服务IP，那么客户端将使用它，否则客户端将服务发现
        3. 客户端缓存将定期使用服务发现刷新
  4. 构建Spring Eureka注册服务
    1. 通过Spring Cloud和Netflix的Eureka实现服务发现引擎，使用ribbon库实现客户端的负载均衡实战项目
      1. 当服务实例启动时，许可证，组织服务（实现点对点传播）将使用Eureka注册他们IP
      2. 当许可证服务调用组织服务时，它将使用RIbbon查看组织服务IP是否存在本地缓存(实现负载均衡)
      3. Ribbon将定期刷新它的IP地址缓存
    2. 代码构建
      1. SPringboot实现Eureka
        1. pom的maven依赖
          1. Spring-could-starter-eureka-server；包含eureka库包括ribbon
        2. 创建application.yml文件
          1. Eureka监听的端口：server.port
          2. 本身也是启动项，告知要不要自己启动：eureka.client.registerWithEureka:
          3. 本地是否加载注册表信息：fetchRegistry
          4. 等待多久注册服务：waitTimeInMsWhenSyncEmpty：
          5. 服务注册需要30s才能显示在Eureka中
        3. 标注引导类EurekaServerApplication.java
          1. EnableEurekaServer，在Spring中启动Eureka服务器
  5. 通过Spring Eureka注册服务（书90页）
    1. pom的maven依赖
      1. 引入eureka库：Spring-could-starter-eureka
    2. application.yml额外配置
      1. 注册服务的逻辑名称
      2. 注册服务器的IP、
      3. 向Eureka注册服务
      4. 拉取注册表副本
      5. Eureka的服务位置
  6. 使用服务发现查找服务
    1. 3种不同的Spring、Netflix客户端库，许可证服务通过Eureka查找组织服务的位置，
      1. Spring DiscoveryClient
      2. 启用RestTemplate的SPring DiscoveryClient
      3. Netflix Fegin客户端
服务发现可以通过zk实现
有什么区别和优缺点的对比
 
  1. 服务发现抽象服务的物理位置
  2. Eureka服务发现引擎可以不影响客户端情况，向环境添加或者移除服务实例
  3. 服务调用客户端缓存的物理位置，客户端负载均衡提供了弹性
  4. Eureka是Netfilx项目，在Spring Cloud很容易对Eureka进行建立和配置
  5. 本章在Spring cloud、Netflix Eureka 和 Netflix Ribbon中使用了3种不同机制调用服务
    1. 使用Spring Cloud服务DiscoveryClient
    2. 使用Spring Cloud服务和支持Ribbon的RestTemplate
    3. 使用Spring Cloud服务和Netflix的Fegin客户端
 
5
第五章：使用微服务和Netflix Hystrix的客户端弹性模式
  1. 预防服务崩溃应该做哪些准备？
    1. 不应只考虑基础设施和关键服务彻底发生故障
    2. 检测到服务性能不佳绕过非常困难的原因
      1. 服务降级可以间接问题开始，并形成不可逆的势头
      2. 对远程服务调用通常是同步的，不会缩短长时间运行的调用
      3. 应用程序经常被设计为处理远程资源的彻底故障，而不是部分降级，不会快速失败的策略
    3. 基于云和微服务的应用程序特别容易受到中断影响，由于应用程序由大量分布式服务组成
  2. 什么是客户弹性模式，分为几种
    1. 重点作用是，当远程服务发生错误或者表现不佳时保护远程资源的客户端免于崩溃
      1. 目标让客户端快速失败，不消耗数据库和线程池的资源，防止向客户端消费上游传播
    2. 四种弹性模式，分别是
      1. 客户端负载均衡：服务客户端缓存在服务发现期间检索到微服务的 
        1. 客户端负载均衡位于服务客户端和服务消费之间，负载均衡器可以检测服务实例是否抛出错误或表现不佳
        2. 这是Netflix的Ribbon库提供开箱即用的功能
      2. 断路器模式:断路器模式确保服务客户端不会重复调用失败的服务
        1. 电路断路器的保险丝，远程调用时间长，会中断调用
        2. 失败次数足够多，会采取快速失败，防止继续失败
        3. 断路器模式为远程调用提供关键能力
          1. 快速失败：远程服务处于降级时，应用程序会快速失败，大多数中断最好服务部分服务关闭，而不是完全关闭
          2. 优雅的失败：后备模式重其它地方检索数据
          3. 无缝的恢复：定期检查服务是否上线，重新允许资源访问。
      3. 后备模式：当调用失败时，后备模式询问是否可执行的替代方案
        1. 远程调用失败，服务消费将执行替代代码路径，尝试通过其他方式执行操作。
        2. 例如大数据分析推荐商品，如果个人个性推荐调用失败，给返回一个通用推荐
      4. 舱壁模式：隔离服务客户端上不同的服务调用，确保表现不佳的服务不会耗尽客户端的所有资源
        1. 舰船隔离和防水隔间，把远程资源调用分到线程池，线程池充当船舱臂，
        2. 如果一个服务响应过慢，那么这种服务调用的饱和并停止处理
  3. 为什么客户端弹性模式很重要？
    1. 解决什么问题
      1. 当某个服务表现不佳时，调用的断路器会跳闸，并且快速失败，不会消耗一个完整的线程
      2. 对于调用服务不佳的头调用服务，只有调用不佳的那个服务联系有影响，服务头其它服务可以正常调用
      3. 断路器在应用程序和远程服务间当中间人。可以防止系统崩溃。
  4. 进入Hystrix
    1. 构建断路器模式，后备模式，船舱壁模式及哦需要对线程和线程池管理有深入的理解，正确的使用很难
    2. 开发可使用Spring Cloud的Netflix的Hystrix库代替复杂的线程池管理
  5. 搭建许可服务使用微服务和Hystrix(书107页)
    1. pom导入Hystrix的maven依赖
      1. 第一个dependency拉取hystrix（spring-cloud-starter-hystrix）依赖
      2. 第二个dependency拉取核心依赖（hystrix-javanica）
      3. 使用EnableCircuitBreaker注解标注服务的引导类,对许可证服务，将注解加到Application.java里
  6. 使用Hystrix实现断路器
    1. 使用Hystrix断路器包装远程资源
      1. Spring Cloud 和Hystrix使用@HystrixCommand注解将标记为断路器，
        1. 动态生成一个代理，代理包装方法，通过专门处理远程调用的线程池来管理对该方法的所有调用
      2. 包装LicenseService类中的getLicensesByorg（）方法
        1. 调用超过一定时间会中断方法的调用，中断对服务和数据库的调用
        2. 定制超时时间，慢的调用它隔离到单独的线程池当中
  7. 实现后备处理模式
    1. fallbackMethod属性定义类中一个方法，如果来自Hystrix调用失败，就会调用该方法
    2. 定义一个待执行的后备方法，在hystrixCommand在同一类中
  8. 实现舱壁模式
    1. 实现舱壁模式区别
      1. 不使用舱壁模式，默认使用同一批线程执行调用，大量请求时，一个线程可能会导致JAVA容器的所有线程刷爆并等待处理，堵塞新请求，导致JAVA容器崩溃
      2. 舱壁模式将远程资源调用隔离在它们自己的线程池里，以便可以控制表现不佳的服务，不会使容器崩溃
    2. hystrix使用线程池委派所有对远程服务的请求
      1. 共享一个线程池处理，有10个线程处理远程调用服务，默认多种资源类型共享，可以调用服务和数据库。
      2. 实现隔离的线程池（书117页）
        1. 为getLicensesByOrg建立个单独的线程池
        2. 设置线程池的线程数，线程池通过配置实现
        3. 设置单个线程繁忙时可排队请求的队列大小
  9. 基础进阶，微调Hystrix
    1. 断路器的常规判断
      1. 问题开始：第一个判断是否达到最少调用次数，
      2. 第二个判断：是否达到错误的阀值，是的话跳闸,调用时间10S
      3. 然后不断检测远程调用的问题是否存在，来来恢复程序
    2. 5个属性定制断路器行为
      1. 10S内连续的调用量
      2. 百分比占用
      3. 控制休眠时间
      4. 调用监控服务调用问题的窗口大小
      5. 收集统计信息个数
    3. 常用配置的搭配（书121页）
  10. 线程上下文和Hystrix
    1. 俩种隔离策略：默认THREAD线程和SEMAPHORE信号量
      1. THREAD线程：保护每个hystrix命令在单独的线程池运行，该线程不与父线程共享上下文，可控制中断线程
      2. SEMAPHORE信号量：不启动新线程，调用超时中断父线程，导致异常不被捕获。不建议使用
      3.  
    2. 总结
解决的问题
  1. 怎样实现断路器、后备、舱壁模式
  2. 使用断路器模式来保护微服务客户端资源
  3. 远程调用失败时使用Hystrix
  4. 实施Hystrix的舱壁模式隔离远程调用
  5. 定制Hystrix的并发策略
  6. 为什么分布式系统遇到故障使用弹性模式？
  7. 定制超时时间，慢的调用它隔离到单独的线程池当中，销售易项目怎样隔离，拉入黑名单
6
第六章:使用 SpringCloud和 Zuul进行路由服务
  1. 本章内容
    1. 什么是服务网关（中央策略执行点PEP）
      1. 可以通过客户端直接调用各个服务。
      2. 也可以通过Eurker服务发现引擎调用，服务网关充当服务客户端和被调用服务的中介。
        1. 服务网关可以像指挥者将调用接口引导到目标实例和目标微服务。
        2. 服务网关位于服务客户端和相应服务实例之间
      3. 常使用的实现横切关注点
        1. 静态路由
        2. 动态路由
        3. 验证和授权
        4. 度量数据手机和日志记录
      4. 服务网关的潜在危险
        1. 集中式的负载均衡容易单点故障和服务瓶颈
        2. 构建服务网关时，牢记
          1. 在单独服务组面前，负载均衡器仍然有效，将负载均衡器放在多个服务网关实例前面是个恰当的设计，它确保服务网关可伸缩
          2. 确保服务网关编写的代码是无状态的。不在内存中存任何信息，导致限制网关可伸缩性，导致所有服务网关实例被复制
          3. 确保服务网关代码是轻量的
    2. Spring cloud 和 Netflix的Zuul简介
      1. Zuul是服务网关，非常容易通过Spring Cloud注解创建和使用，核心功能如下
        1. 将应用程序的所有服务路由映射到一个URL
        2. 构建可以对通过网关的请求践行检查和操作的过滤器
      2. 开始使用zuul，需完成
        1. 建立一个Zuul的Spring Boot项目，并配置适当的Maven依赖
          1. 只需要配置Dependency加Spring-cloud-starter-zuul依赖
        2. 使用Spring Cloud注解修改Spring Boot 项目，声明为Zuul服务
          1. 加注解@EnableZuulProxy，使服务成为Zuul服务器
        3. 配置Zuul以便Eureka进行通信（可选完成）
          1. 修改Zuul的application.yml 指向Eureka服务器
    3. 在Zuul中配置路由
      1. Zuul的核心是一个反向代理服务器，反向代理是一个中间件服务器，负责捕获客户端请求，然后代表客户端调用远程资源。
      2. Zuul从客户端接收微服务调用并转发给下游服务，Zuul必须知道如何将调用映射到下游。主要的实现机制
        1. 通过服务发现自动映射路由
          1. 没有配置自动映射
          2. Zuul将使用organizationservice应用程序名称将请求映射到组织的服务实例。
            1. 服务名称organizationservice充当服务网关查找服务物理位置的键
            2. 路径的其余部分将要调用实际的URL端点
        2. 使用服务发现手动映射路由
          1. 更细粒度的的明确定义的路由映射，不仅单纯依赖服务的Eureka服务ID创建的自动路由
          2. 在Zuul的application.yml 手动定义路由映射
        3. 使用静态URL手动映射路由
          1. Zuul可以用来管理那些不受Eureka管理的服务
    4. Zuul真正的威力：三种类型过滤器
      1. 构建一个前置过滤器
      2. 构建一个后续过滤器
      3. 构建动态路由过滤器
    5. 构建一个前置过滤器
    6. 构建一个后续过滤器
    7. 构建动态路由过滤器
    8. 总结
      1.  
解决什么问题
  1. 结合微服务使用服务网关
  2. 使用Zuul实现路由和网关
  3. 使用 SpringCloud和 Zuul进行路由服务
    1. 在微服务的分布式架构中，需要确保多个服务调用的关键服务正常运行，安全，日志记录和用户追踪。
      1. 使用框架和公共库在单个服务构建常出现的问题
        1. 在构建每个服务中很难实现这些功能，忘记实现日志记录和追踪
        2. 正确的实现是一个挑战
        3. 在所有服务中创建一个顽固的依赖
      2. 需要将这些横切关注点抽象出成一个独立且作为应用程序所有微服务调用的过滤器和路由服务，这些横切关注点被称为服务网关。
7
第七章：保护微服务
  1. OAuth2简介
    1. OAuth2是什么？
      1. 是一个基于令牌的安全框架和授权框架，实现验证和授权控制保护基于Spring的服务，允许用户使用第三方验证服务验证
      2. 安全性分解四部分，对用户进行验证
        1. 受保护的资源，受保护资源的微服务
        2. 资源所有者，
        3. 应用程序
        4. OAuth2验证服务器
      3. 使用授权不同的验证方案，4种类型授权
        1. 密码
        2. 客户端凭据
        3. 授权码
        4. 隐式
  2. 从小事做起，使用SPring和OAuth2保护单个端点
    1. 建立EagleEyeOAuth2验证服务
    2. 使用Oauth服务注册客户端应用程序
    3. 配置EagleEye用户
    4. 验证用户
  3. 使用OAuth2保护组织服务
    1. 将Spring Security和OAuth2 jar加入各个服务
    2. 配置服务以指向OAuth2验证服务
    3. 定义谁可以访问
    4. 传播OAuth2访问令牌
  4. JSON WebToken（JWT）与OAuth2
    1. JSON WebToken（JWT）提供标准结构，JWT有以下特点
      1. 小巧：
      2. 密码改名
      3. 自包含
      4. 可扩展
    2. 修改验证服务以颁发JWT令牌
    3. 在微服务中使用JWT
    4. 扩展JWT令牌
    5. 从JWT解析自定义字段
  5. 关于微服务安全
    1. 构建生产级别微服务时，围绕以下实践构建微服务安全
      1. 对所有服务通信使用HTTPS安全套接字层
      2. 所有服务调用都应通过API网关
      3. 将服务划分公共的API和永久API
      4. 通过封锁不需要网络端口来限制微服务的攻击面
 
8
第八章：使用Spring Cloud Stream的事件驱动架构
  1. 为什么使用消息传递，EDA和微服务
    1. 我们与世界交互不是线性的，同步的，而是驱动的，不断的发送和接收信息，事件驱动架构
      1. 实现许可证快速查找组织服务信息，用缓存解决三个核心要求
        1. 缓存数据要在许可证所有实例保持一致
        2. 不能将组织数据缓存在托管许可证服务的容器和内存中
        3. 更新和删除一个组织时，开发人员希望许可服务能识别组织服务的变化
    2. 解决的俩种方式
      1. 使用同步请求响应方式传达转台变化：通过他们REST接口通信
        1. 实现的问题
          1. 服务之间紧密耦合：许可证服务始终依赖组织服务检索数据
          2. 服务之间的脆弱性：许可证服务缓慢，组织服务也会受影响
          3. 修改组织以增加新的消费者方面是不灵活的：
            1. 其它服务对组织服务发生改变，需更改代码部署
            2. 网状依赖关系会成为故障点
      2. 组织服务发出异步事件，该事件将通报组织服务数据发生改变
        1. 在消息传递之间加一个间接层，许可证和组织间加个消息队列中介
          1. 组织服务用于组织数据内状态更改发布消息到队列中
          2. 许可证服务监视队列中由组织服务发布所有消息，并可根据需要使Redis缓存数据清除
        2. 优点
          1. 松耦合：
            1. 最小化依赖关系，涉及传达状态更改时，俩个服务不知道彼此，许可证服务只知道得到一个消息
          2. 耐久性
            1. 即使服务消费已经关闭了，也可发送信息
            2. 许可证服务不可用，组织服务也可继续发布消息
            3. 缓存结合在一起，组织服务关闭，许可证可优雅剪辑，至少有部分数据在缓存里
          3. 可伸缩性
            1. 消息发送者不必等待消息响应，可继续工作
            2. 受到CPU的限制，微服务没这样限制，增加托管消息服务机器数量扩大
          4. 灵活性
            1. 可随意添加消费者，不影响原始消费服务，，消息发送者不知谁消费它
            2. 可添加新功能，新的代码监听正在发布的事件
        3. 缺点：可能复杂，需要开发人员注意下面事项
          1. 消息处理语义：客户消息失败，怎么处理与该客户有关的未来消息
          2. 消息可见性：关联ID是在用户事务开始生成的唯一编号，并与每个服务调用一起传递，它还应该在每条消息被发布和消费时被传递
          3. 消息编排 :基于消息传递的应用程序很难按照应用程序的执行顺序进行业务逻辑推理，涉及多服务时，用户事务可以不同时间不按顺序执行
  2. SPring Cloud Stream简介
    1. 是一个注解驱动的框架，允许开发人员在Spring应用程序中轻松的构建消息发布者和消费者
    2. 还允许开发人员抽象出正在使用的消息传递平台的实现细节
    3. 可以使用多个消息平台（kafka或者RabbitMQ），平台的具体实现细节被排除在应用程序代码之外
    4. Spring Cloud Stream架构
      1. 随着Spring Cloud消息的发布和消费，4个组件涉及发布消息和消费消息
        1. 发射器：发布消息，发射器是一个Spring注解的接口，它接收JAVA对象，序列化并将消息发布到通道
        2. 通道：是队列的抽象，消息生产发布消息，活消费者消费消息后保留该消息，
          1. 通道名称始终和目标队列名称相关联，开发人员可直接更改应用程序配置
        3. 绑定器：与特定消息对话的Spring代码，绑定器允许开发人员处理消息，不必依赖特定的平台和API发布和消费信息
        4. 接收器：通过接收器从队列接收消息，反序列POJO，从这里可以按照业务逻辑处理。
  3. 编写简单的消息生产者和消费者
    1. 在组织服务中编写消息生产者
      1. Maven添加Spring Cloud Stream库，另一个包含Spring Cloud Steam Kafka库
      2. 用@EnableBindind注解标记组织服务的引导类
      3. 组织数据变化，发送到kafka队列
    2. 在许可证服务中编写消息消费者
      1. 监听执行相应的方法
      2. 用@EnableBindind注解监听组织服务的消息
      3. 用@StreamListener注解，从input通道接收消息，就会执行LoggerSink方法
      4. 在许可证服务的配置文件application能找到队列配置
    3. 在实际操作中查看消息服务
  4. Spring Cloud Stream用例：分布式缓存
    1. 使用Redis缓存查找，具体思想书217页
      1. 配置许可证服务包含Spring Data Redis的依赖
        1. redis,jedis和common-pools2的依赖包
      2. 构造一个到Redis服务器的数据库连接
        1. Spring使用开源项目Jedis和Redis服务器进行通信
      3. 定义SpringDataRedis存储库
        1. 存储定义俩个文件
      4. 使用Redis和许可证服务来存储和读取组织数据
        1. 完成对Redis执行操作的代码之后，可以修改许可证服务
    2. 定义自定义通道
    3. 将其全部汇集在一起，收到消息时清理缓存
 
9
第九章：使用SpringCloudSleuth和ZipKin进行分布式跟踪
    1. 微服务架构是一种强大的设计范式，
      1. 将复杂的单体软件系统费解为更小，更易于管理。
      2. 管理范式可以独立构建和部署。
    2. 微服务的弊端
      1. 灵活性付出代价，复杂性
      2. 微服务本质是分布式，调试出现的问题让人抓狂
      3. 分布式的特性意味着多个服务，物理机器和不同数据存储跟踪一个事务或者多个事务，然后拼凑出发生什么
    3. 分布式调试的几个技术
      1. Spring Cliud Sleuth于关联ID：使用关联ID将跨多个服务的事务链接在一起
      2. papertrail：将来自多个服务的日志数据聚合为一个可搜索源
      3. Zipkin：可视化跨多个服务的用户事务流，并理解事务每个部分特征
  1. Spring Cliud Sleuth于关联ID
    1. 通过添加sleuth到Spring微服务中，开发人员可以
      1. 透明地创建，并注入一个关联ID到服务调用中，如果关联ID不存在
      2. 管理关联ID到出站服务调用的传播，以便将事务关联ID自动添加出站调用中
      3. 将关联信息添加到MDC日志记录，以便生成关联ID由SpringBoot默认SL4J和Logback实现自动记录
      4. （可选）将服务调用中的跟踪信息发布到Zipkin分布式跟踪平台
      5. 总结：有了sleuth，使用Spring boot实现日志记录，关联ID自动添加到微服务的日志语句中。
    2. 将Spring Cliud Sleuth添加到许可证服务和组织服务中
      1. 需要在俩个服务使用sleuth，需要先添加pom依赖，拉取Spring Cloud Sleuth 需要的核心库，完成以下功能
        1. 检查每个传入的HTTP服务，确定调用中是否存在Spring Cloud Sleuth跟踪信息，存在捕获传递到微服务的跟踪信息，并进行日志和处理
        2. 添加到Spring MDC，以便微服务创建的每个日志语句都添加到日志中
        3. 将跟踪信息注入服务发出的每个出站HTTP调用以及Spring消息传递通道消息中
    3. 剖析Spring Cliud Sleuth跟踪：向日志添加4条信息
      1. 服务的应用程序名称
      2. 跟踪ID：事务的ID
      3. 跨度ID：整个事务中某一部分，唯一ID
      4. 是否将跟踪数据发送到ZipKin
  2. 日志聚合与Spring Cliud Sleuth:
      1. 大型微服务中，日志记录数据是调试问题的关键工具，但因为基于微服务的应用程序功能被分解小型的细粒度的服务
        1. 产生的问题
          1. 登录多个服务器看日志很费时
          2. 编写查日志的脚本
          3. 延长停止服务的进程恢复
        2. 解决方式，所有日志实时流到一个聚合点
          1. 很多开源和商业残品帮助我们实现聚合的日志记录框架
    1. papertrail：将来自多个服务的日志数据聚合为一个可搜索源实战
    2. 创建Papertrail庄户并配置Syslog连接器
    3. 将Docker输出重定向到
    4. 在Papertrail中所说Spring Cloud Sleuth的跟踪ID
    5. 使用Zuul将关联的ID添加到HTTP响应
  3. 使用OPenZipKin进行分布式跟踪
    1. 添加Spring Cloud Sleuth和Zipkin依赖
    2. 配置服务指向Zipkin
    3. 安装和配置Zipkin服务器
    4. 设置跟踪级别
    5. 使用Zipkin跟踪事务
    6. 可视化更复杂的事务
    7. 捕获消息传递跟踪
    8. 添加自定义跨度
  4. 小结
    1. Spring Cloud Sleuth可以无缝地将跟踪信息（关联ID）添加到微服务调用中
    2. 关联ID用于多个服务之间链接日志条目，可以使用关联ID查看单个事务中设计的所有服务的事务行为
    3. 关联ID和聚合日志平台使用，便于多个来源获取日志，搜索查询他们的内容
    4. 但基于云服务，对日志进行管理，
    5. 将Docker容器日志聚合平台集成，
    6. 虽然统一日志记录平台很重要，通过微服务可视化跟踪事务的能力
    7. Zipkin可以让开发人员在对服务之间存在的依赖关系
    8. Sleuth和Zipkin集成，让开发人员图形方式查看事务流程，并了解用户事务设计微服务的特性
    9. Sletuth自动捕获HTTP调用以及入站和出站消息跟踪数据
    10. Sleuth将每个服务调用映射一个跨度概念，Zipkin查看一个跨度的性能
    11. Sleuth和Zipkin允许开发人员自定义调度，了解基于非Spring的资源和性能（Postgres或Redis等数据库服务器）
 
10
第十章：部署微服务
    1. 如何构建微服务
      1. 微服务可以是快速构建、修改和部署到独立生产环境中的小型代码单元，有以下特征
        1. 自动的，构建和部署过程不应该人为干预
        2. 可重复的，用来构建和部署软件的过程应该是可重复的
        3. 完整的，应该是一个完整的虚拟机或容器镜像Docker
        4. 不可变的，包含服务的机器镜像一旦构建
      2. 运维人员让构建过程通用化，使用非Spring工具构建和部署管道
        1. 将一直使用的Maven构建脚本集成到名为Travis CI的持续集成、部署云工具中
        2. 为每个服务构建不可变的Docker镜像，镜像推送到集中式存储库中
        3. 使用亚马逊的EC2容器服务，将整套微服务部署到亚马逊上
        4. 运行平台，看服务是否正常
  1. EagleEye：在云中简历核心基础设施
    1. 实现思路
      1. 所有的EagleEye服务（除了数据库和Redis集群）都将部署为Docker容器，这些Docker容器在单点ECS集群内部运行。
      2. 在亚马逊使用亚马逊的RDS和亚马逊的ElastiCache服务
      3. 所有的流量通过Zuul API网关
      4. 仍将需要使用Spring的OAuth2服务器来保护
      5. 所有的服务器，包括kafka服务器，外界都无法通过公开的Docker端口进行访问
    2. 使用亚马逊的RDS创建PostgreSQL数据库
      1. 创建和配置AWS账户
        1. 在AWS创建 PostgreSQL数据库
        2. 在AWS创建Redis集群
          1. 使用亚马逊的ElastiCache服务，ElastiCache允许开发人员使用Redis或Memcached构建数据缓存
          2. 创建ESC缓存，以供应用于托管Docker容器的Amazon机器
    3. 超越基础设施：部署EagleEye
      1. 安装ESC命令的客户端，部署Docker容器
      2. 通过SSH命令进入ESC集群查看docker日志
    4. 构建和部署管道的架构（）
      1. 基于用于实现持续集成的通用架构部署模式架构CI
        1. 开发人员提交服务代码到源代码存储库
        2. 构建/部署引擎牵出代码并运行构建脚本
        3. 引擎编译代码，运行测试，创建一个可执行的软件制品
        4. 创建安装了服务及其运行时引擎的虚拟机镜像
        5. 针对机器镜像才能提升新环境
        6. 机器镜像提升到下一个环境钱，必须对该环境运行平台测试
  2. 构建和部署管道实战
    1. Github
    2. Travis CI
    3. Maven/Spotify Docker插件
    4. Docker
    5. Docker Hub
    6. pytuhon
    7. Amazon的EC2容器服务（ECS）
  3. 开始构建和部署管道：GITHub和Travis CI
  4. 使用服务能在Travis CI构建
  5.  
 
 
  1. 微服务的说明
    1. 微服务的由来
      1.   微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。
    2. 微服务是什么
      1. 是小的，松耦合的分布式系统，区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。
      2. 分解和分离应用程序的功能，使他们彼此独立构建，部署和测试
      3. 微服务的特征
        1. 应用程序逻辑分解为具有明确定义职责范围的颗粒度组件，这些组件互相协调提供解决方案。
        2. 职责范围和细粒度组价，每个组件有小弟职责领域，并且完全独立部署，彼此独立构建，部署和测试
        3. 微服务通信基于基本原则，一般采用HTTP或者JSON轻量级通信协议
        4. 微服务利用其小，独立和分布式的性质，让组织拥有明确责任领域的小型开发团队。
      4. spring cloud 为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等。
    3. 微服务的优点
      1. 灵活性，解耦的服务重新组合和安排，可以实现快速交付
      2. 有弹性，单一服务故障不影响整个项目
      3. 可伸缩，解耦的服务可以轻松跨多个服务器水平分布。
      4. 总结就是：小型的、简单的、解耦的服务=可伸缩、有弹性和灵活
      5. 微服务的重点是构建有限职责的小型服务，并使用基于HTTP的接口通信。
    4. 微服务的缺点
      1. 灵活性付出代价，复杂性，运维要求较高
      2. 微服务本质是分布式，调试出现的问题让人抓狂，分布式的复杂性
      3. 分布式的特性意味着多个服务，物理机器和不同数据存储跟踪一个事务或者多个事务，然后拼凑出发生什么
    5. 单体架构的演变
      1. 单体结构的问题
        1. 复杂性上升
        2. 客户期待更快的交付
        3. 性能和可伸缩性
        4. 客户期望应用程序可用
        5. 阻碍技术创新
    6. 目前微服务的开发框架，最常用的有以下四个：
      1. Spring Cloud：http://projects.spring.io/spring-cloud（现在非常流行的微服务架构）
      2. Dubbo：http：//dubbo.io
      3. Dropwizard：http://www.dropwizard.io （关注单个微服务的开发）
      4. Consul、etcd&etc.（微服务的模块）
    7. 基于云微服务的优点
      1. 为什么是云和微服务
        1. 将服务器部署到某个环境里
          1. 物理服务器：虽然可以构建和部署微服务到物理机器，但过于局限，不能快速的提高物理服务器的容量，并且在多个物理服务器之间水平伸缩微服务成本会很高。
          2. 虚拟机镜像：能够快速启动或者关闭微服务实例，响应可伸缩和服务故障，虚拟机是主要云供应商的心脏和灵魂。微服务可打包虚拟机镜像中，开发人员可以在Iaas私有或者公有云中快速部署和启动微服务实例。
          3. 虚拟容器：是在虚拟机镜像上部署微服务的自然延伸，将Docker容器（或者等效容器）部署到云端。虚拟容器在虚拟机内运行。使用虚拟容器，可以将单个虚拟机隔离成共享相同虚拟机镜像的一系列独立进程
      2. 基于云的微服务优势
        1. 以弹性的概念为中心，开发商允许几分钟内快速启动新的虚拟机和容器
        2. 使用Docker容器将所有的微服务和所有微服务和相应的服务基础设施部署到基于Iaas云供应商
          1. 简化基础设施管理：有效控制服务，开发人员通过简单的API启动和停止新服务
          2. 大规模的水平可伸缩性：快速简便的启动服务的一个或者多个实例
          3. 通过地理分布实现高亢余：拥有多个数据中心。
        3. 使用Docker打包微服务，将这些容器部署到亚马逊平台。第十章详细介绍
    8. 微服务适用于什么项目
      1.    微服务可以按照业务功能本身的独立性来划分，如果系统提供的业务是非常底层的，如：操作系统内核、存储系统、网络系统、数据库系统等等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部署和运行，也就不适合做成微服务了。
      2. 小：微服务体积小，2 pizza 团队。
      3. 独：能够独立的部署和运行。
      4. 轻：使用轻量级的通信机制和架构。
      5. 松：为服务之间是松耦合的。
    9. 微服务不适用于什么项目
      1. 构建分布式系统的复杂性
        1. 微服务的分布式和颗粒度小从而引入复杂性，微服务架构需要成熟的运维，组织愿意投入高分布式应用程序获得成功所需的自动化和运维工作（监控，伸缩）
      2. 服务器散乱
        1. 一个服务器部署一个实例，最终可能需要50-100台服务器或容器（通常是虚拟容器）,这些服务器必须单独搭建和维护，管理和维护监控这些服务器操作复杂度也是巨大的
      3. 应用程序类型
        1. 微服务面向可复用性，并且对构建高度弹性和可伸缩性大型应用程序非常有用，大用户群，搭建分布式系统。
      4. 数据事务和一致性
        1. 微服务间执行事务没有标准，如果需要事务管理，需要自己构建逻辑。第七章：微服务可使用消息进行通信
    10. 微服务中使用到的注解
      1.  
  2. 微服务的构建
    1. 如何使用spring Boot 构建微服务，云中的微服务卡构建简单，但要成功需要架构师，开发人员，和DEVOPS的综合视角
      1. 架构师专注于业务问题的轮廓
      2. 软件工程师专注于构建分层服务，每一层有离散职责，避免代码中构建框架，尝试每个微服务完全独立
      3. DevOps，尽早的建立服务的生命周期,不仅仅关注如何自动化服务的构建和部署，关注服务的健康状态，出问题快速反应
      4. 构建单个微服务的概念很容易理解，但运行和支持健壮性的云上微服务不只涉及编写代码，
        1. 大小适当：服务的单一职责
        2. 位置透明：多个服务的快速启动
        3. 有弹性：快速失败，绕过失败的服务
        4. 可重复：相同的配置和代码库
        5. 可伸缩：如果使用异步方式最小化服务的直接依赖关系
    3. 开发模式
      1. Spring Cloud Config配置服务器控制
        1. 实施配置管理技术方案优先选择Spring Clould config、Eureka、Consul
          1. Spring Clould config易于搭建和使用
          2. Spring Clould config与SpringBoot紧密集成，可以使用简单易用的注解读取应用程序的配置文件
          3. 提供多个后端用于存储配置数据。已经使用Eureka、Consul等工具，可以直接将他们插入Spring Config的配置服务器中
          4. 可直接和GIT源控制平台集成
      2. 构建Spring Cloud配置服务器
        1. 将Spring Cloud config和Spring Boot结合，
          1. 建立许可证服务队Spring Cloud Config服务器的依赖
          2. 配置许可证服务以使用Spring Cloud Config
          3. 使用Spring Cloud配置服务器连接数据源
          4. 使用@value注解直接读取属性
          5. 使用Spring Cloud配置服务器和GIT
          6. 使用Spring Cloud配置服务器刷新属性
      3. 使用Spring Cloud Stream的事件驱动架构:第八章
        1. SPring Cloud Stream简介
          1. 是一个注解驱动的框架，允许开发人员在Spring应用程序中轻松的构建消息发布者和消费者
          2. 还允许开发人员抽象出正在使用的消息传递平台的实现细节
          3. 可以使用多个消息平台（kafka或者RabbitMQ），平台的具体实现细节被排除在应用程序代码之外
          4. Spring Cloud Stream架构
            1. 随着Spring Cloud消息的发布和消费，4个组件涉及发布消息和消费消息
              1. 发射器：发布消息，发射器是一个Spring注解的接口，它接收JAVA对象，序列化并将消息发布到通道
              2. 通道：是队列的抽象，消息生产发布消息，活消费者消费消息后保留该消息，
                1. 通道名称始终和目标队列名称相关联，开发人员可直接更改应用程序配置
              3. 绑定器：与特定消息对话的Spring代码，绑定器允许开发人员处理消息，不必依赖特定的平台和API发布和消费信息
              4. 接收器：通过接收器从队列接收消息，反序列POJO，从这里可以按照业务逻辑处理。
        2. 编写简单的消息生产者和消费者
          1. 在组织服务中编写消息生产者
            1. Maven添加Spring Cloud Stream库，另一个包含Spring Cloud Steam Kafka库
            2. 用@EnableBindind注解标记组织服务的引导类
            3. 组织数据变化，发送到kafka队列
          2. 在许可证服务中编写消息消费者
            1. 监听执行相应的方法
            2. 用@EnableBindind注解监听组织服务的消息
            3. 用@StreamListener注解，从input通道接收消息，就会执行LoggerSink方法
            4. 在许可证服务的配置文件application能找到队列配置
    4. 微服务的路由模式
      1. 服务发现，第四章详细介绍
        1. 服务发现对基于云的应用程序至关重要
          1. 首先，它可以快速对环境中运行的服务实例数量进行水平伸缩，可以在服务池里添加或者移除服务实例
            1. 通过添加更多的服务器（水平伸缩）来扩大项目
            2. 服务发现有利于抽象这些服务部署，远离服务消费者
          2. 其次，它有助于提高应用程序的弹性
            1. 微服务实例变得不健康或者不可用时，服务的发现引擎将可用列表移除改服务，服务发现引擎在路由服务绕过不可用服务，使不可用服务造成最小伤害。
        2. 构建Spring Eureka注册服务
          1. 通过Spring Cloud和Netflix的Eureka实现服务发现引擎，使用ribbon库实现客户端的负载均衡实战项目
            1. 当服务实例启动时，许可证，组织服务（实现点对点传播）将使用Eureka注册他们IP
            2. 当许可证服务调用组织服务时，它将使用RIbbon查看组织服务IP是否存在本地缓存(实现负载均衡)
            3. Ribbon将定期刷新它的IP地址缓存
      2. 服务路由，第六章:使用 SpringCloud和 Zuul进行路由服务
        1. Spring cloud 和 Netflix的Zuul简介
          1. Zuul是服务网关，非常容易通过Spring Cloud注解创建和使用，核心功能如下
            1. 将应用程序的所有服务路由映射到一个URL
            2. 构建可以对通过网关的请求践行检查和操作的过滤器
          2. 开始使用zuul，需完成
            1. 建立一个Zuul的Spring Boot项目，并配置适当的Maven依赖
              1. 只需要配置Dependency加Spring-cloud-starter-zuul依赖
            2. 使用Spring Cloud注解修改Spring Boot 项目，声明为Zuul服务
              1. 加注解@EnableZuulProxy，使服务成为Zuul服务器
            3. 配置Zuul以便Eureka进行通信（可选完成）
              1. 修改Zuul的application.yml 指向Eureka服务器
        2. 在Zuul中配置路由
          1. Zuul的核心是一个反向代理服务器，反向代理是一个中间件服务器，负责捕获客户端请求，然后代表客户端调用远程资源。
          2. Zuul从客户端接收微服务调用并转发给下游服务，Zuul必须知道如何将调用映射到下游。主要的实现机制
            1. 通过服务发现自动映射路由
              1. 没有配置自动映射
              2. Zuul将使用organizationservice应用程序名称将请求映射到组织的服务实例。
                1. 服务名称organizationservice充当服务网关查找服务物理位置的键
                2. 路径的其余部分将要调用实际的URL端点
            2. 使用服务发现手动映射路由
              1. 更细粒度的的明确定义的路由映射，不仅单纯依赖服务的Eureka服务ID创建的自动路由
              2. 在Zuul的application.yml 手动定义路由映射
            3. 使用静态URL手动映射路由
              1. Zuul可以用来管理那些不受Eureka管理的服务
        3. Zuul真正的威力：三种类型过滤器
          1. 构建一个前置过滤器
          2. 构建一个后续过滤器
          3. 构建动态路由过滤器
    5. 微服务的弹性模式
      1. 微服务是高度分布式的，所以必须防止单个服务中问题级联暴露给消费者。
      2. 四种弹性模式，分别是
        1. 客户端负载均衡：服务客户端缓存在服务发现期间检索到微服务的 
          1. 客户端负载均衡位于服务客户端和服务消费之间，负载均衡器可以检测服务实例是否抛出错误或表现不佳
          2. 这是Netflix的Ribbon库提供开箱即用的功能
        2. 断路器模式:断路器模式确保服务客户端不会重复调用失败的服务
          1. 电路断路器的保险丝，远程调用时间长，会中断调用
          2. 失败次数足够多，会采取快速失败，防止继续失败
          3. 断路器模式为远程调用提供关键能力
            1. 快速失败：远程服务处于降级时，应用程序会快速失败，大多数中断最好服务部分服务关闭，而不是完全关闭
            2. 优雅的失败：后备模式重其它地方检索数据
            3. 无缝的恢复：定期检查服务是否上线，重新允许资源访问。
        3. 后备模式：当调用失败时，后备模式询问是否可执行的替代方案
          1. 远程调用失败，服务消费将执行替代代码路径，尝试通过其他方式执行操作。
          2. 例如大数据分析推荐商品，如果个人个性推荐调用失败，给返回一个通用推荐
        4. 舱壁模式：隔离服务客户端上不同的服务调用，确保表现不佳的服务不会耗尽客户端的所有资源
          1. 舰船隔离和防水隔间，把远程资源调用分到线程池，线程池充当船舱臂，
          2. 如果一个服务响应过慢，那么这种服务调用的饱和并停止处理
    6. 微服务的安全模式
      1. 验证
      2. 授权      
      3. 凭据管理和传播
    7. 微服务日志记录和跟踪模式
      1. 日志关联
      2. 日志聚合
      3. 微服务跟踪
    8. 微服务的构建和部署模式
      1. 微服务的每个实例都和其它相同
      2. 构建和部署管道
      3. 基础设施及代码
posted @ 2021-03-08 15:11  Smileing  阅读(80)  评论(0)  编辑  收藏  举报