Spring Cloud理论

单体应用

1.特点

• 传统的单个应用程序
• 采用分层、分包的方式实现代码解耦和管理
• 整个应用在一个web项目中，使用一个JVM

2.缺点

• 随着项目增大，导致代码量增大，造成编译、打包耗时，影响效率
• 随着业务增加，不同业务重建新项目，不同项目的功能模块可能会出现重复建设的情况，造成浪费

分步式应用

1.分步式系统

• 分步式系统是若干独立计算机的集合，这些计算机对用户来说就像单个相关系统
  

2.WebService分步式

• 三大原理

1.XML：封装数据(WebService采用HTTP协议在C与S间传输数据)
2.SOAP：WebService通过HTTP发送请求和接受结果时，采用XML格式封装，并增加特定HTTP头头信息，特定HTTP消息头和XML内容格式就是SOAP协议规定的
	请求头+请求实体xml
3.WSDL：基于XML(机器可读)说明WebService有哪些服务可以对外调用
	服务定义语言

• 交互过程

WebService遵循SOAP协议通过XML封装数据，然后由Http协议来传输数据

• 缺点

传输数据冗余
每个服务在单独服务器上

3.SOA 思想

• 面向服务的架构思想
• 降低分步式应用之间的耦合
• SOA只是架构设计模式，SOAP、REST、RPC是根据SOA构建的规范

SOAP：http+xml(webservice)
REST：http+json(springcloud)
RPC：socket(dubbo)

云

• 微服务与云息息相关，此处先介绍云

什么是云？

• 基础设施即服务Infrastructure as a Service(IaaS)
• 平台即服务Platform as a Service(PaaS)
• 软件即服务Software as a Service(SaaS)
• 函数即服务Function as a Service(FaaS)
• 容器即服务Container as a Service(CaaS)
  

2.为什么是云和微服务?

• 微服务架构核心概念之一就是每个服务都被打包和部署为离散的独立程序
• 服务实例迅速启动
• 服务的每一个实例都是完全相同的
• 服务将部署到以下某个环境之中

1.物理机: 开发人员不能快速提高物理机的容量，并且在多个物理服务器之间水平伸缩微服务的成本很高
2.虚拟机镜像: 微服务优点之一就是能快速启动和关闭微服务实例，以响应可伸缩性和服务故障事件.微服务可以打包在虚拟机镜像中，开发人员可以在IaaS私有或公有云中快速部署和启动服务的多个实例
3.虚拟容器: 虚拟容器是虚拟机镜像上部署微服务的自然延伸，使用虚拟容器(如docker)可以将单个虚拟机隔离成共享相同虚拟机镜像的一系列独立进程

• 基于云的微服务以弹性的概念为中心

需要时，在云上几分钟之内快速布置启动新的虚拟机和容器
如服务需求下降，可以关闭虚拟服务器

微服务

1.概述

• SOA思想的实现
• 开发要点

位置透明(知道服务大体位置，自动感知)，大小适当(根据请求力度拆分)、有弹性、可重复、可伸缩

2.核心微服务开发模式

• 服务粒度

正确划分微服务大小，确定微服务职责，可快速更改应用同时降低整个应用的中断总体风险

• 通信协议

开发人员如何与服务进行通信?
采用什么协议与服务传输数据?

• 接口设计

如何设计微服务的接口,便于开发人员进行服务调用?
如何构建服务URL来传达服务意图?
如何版本化服务?
精心设计的微服务接口使服务更直观

• 服务的配置管理

如何管理服务的配置，以便在不同的云环境迁移时，不必更改核心应用程序代码或配置

• 服务之间的事件处理

使用事件解耦微服务，以便最小化服务之间的硬编码依赖关系，并提高应用程序的弹性

3.微服务路由模式

• 保证客户端应用程序发现服务的位置并路由到服务
  
• 服务注册与发现

如何使微服务容易被发现，并且服务的位置不硬编码到应用程序中还可以找到他，如何快速删除表现不佳的微服务实例

• 服务路由

为所有服务提供单点入口，以便将安全策略和路由规则统一应用于微服务应用程序中的多个服务实例

4.微服务客户端弹性模式

• 微服务架构是高度分布式的，如何防止单个服务（或服务实例）中的问题级联暴露给服务的消费者
  
• 四种客户端弹性模式

1.客户端负载均衡：在客户端上缓存服务实例的位置，以便对微服务的多个实例的调用负载均衡到该微服务的所有健康实例（Ribbon)
2.断路器模式：阻止客户继续调用出现故障的或遭遇性能问题的服务（Hystrix）
3.后备模式：当服务调用失败提供插件机制，允许客户端尝试通过调用微服务之外的其他方法来执行工作（Hystrix fallback）
4.舱壁模式：微服务应用程序使用多个分布式资源来执行工作，如何区分这些调用，以便表现不佳的服务调用不会对应用程序的其他部分产生负面影响（Docker）

5.微服务安全模式

• 验证

确定服务的客户端就是它们声称的那个主体

• 授权

确定调用微服务的客户单是否允许执行它们正在进行的操作

• 凭证管理和传播

避免客户端每次都要提供凭证信息才能访问事务中涉及的服务调用。使用基于令牌的安全标准来获取可以从一个服务调用传递到另一个服务调用令牌，以验证和授权用户，这里设计的标准包括 OAuth2和JSON Web Token（JWT）

• 使用基于令牌的安全方案，可以实现服务验证和授权，而无需传递客户端凭证
  

6.微服务日志记录和跟踪模式

• 微服务架构的优点：单体应用被分解成可以彼此独立部署的小的功能部件
• 微服务架构的缺点：调试和跟踪应用程序和服务中发生的事情要困难地多
• 日志关联

一个用户事务会调用多个服务，需要将这些服务所生成的日志关联到一起
关联ID是唯一的标识符，在事务中调用所有服务都会携带他，通过它能够将每个服务生成的日志条目联系起来

• 日志聚合

将微服务（及其各个实例）生成的所有日志合并到一个可查询的数据库中及如何使用关联ID来协助搜索聚合日志

• 微服务跟踪

在涉及的所有服务中可视化客户端事务的流程，并了解事务所涉及的服务的性能特征

7.微服务构建和布署模式

• 微服务架构的核心原则之一：微服务的每个实例都应该和其他所有实例相同
• “配置漂移”（某些文件在部署到服务器之后发生了一些变化）是不允许出现的
  
• 在构建过程中构建和编译微服务并准备进行微服务的虚拟微服务镜像
• 部署微服务时，服务器运行所需的整个机器镜像都会进行部署

1.构建和部署管道
	创建一个可重复的构建和部署过程，只需一键即可构建和部署到组织中的任何环境
2.基础设施即代码
	将服务的基础设施作为可在源代码管理下执行和管理的代码去对待
3.不可变服务器
	一旦创建了微服务镜像，如何确保它在部署之后永远不会改变
4.凤凰服务器（Phoenix Server）
	服务运行的时间越长，就越容易发生配置漂移。如何确保运行微服务的服务器定期被拆卸，并重新创建一个不可变的镜像

8.spring cloud中实现以上模式的技术栈