1. 微服务架构

1.1 互联网应用架构的演变

• 单体应用架构　　

　　　　所有的功能放在一个工程中进行编码、编译、打包，并且部署在一个Tomcat容器中，简单实用

　　　　优点：高效开发，架构简单（使用MVC架构，借助IDEA开发调试即可），便于测试和部署（打包成单?可执?的jar或者打成war包放到容器内启动）

　　　　缺点： 可靠性差，某个应用Bug，例如死循环、内存溢出等， 可能会导致整个应用的崩溃；复杂型高，项目耦合性高，扩展能力受限

　　　　业务量上涨之后，单体应用架构进一步丰富变化，比如应用集群部署、使用Nginx进行负载均衡、增加缓存服务器、增加文件服务器、数据库集群并做读写分离等，通过以上措施增强应对高并发的能力、应
对一定的复杂业务场景，但依然属于单体应用架构。

• 垂直应用架构

　　　　对项目进行模块的垂直划分，基于业务特性实现业务之间互不影响，减少组件之间的依赖

　　　　优点：系统拆分实现了流量分担，解决了并发问题，可以针对不同模块进行优化和功能扩展，方便水平扩展，负载均衡，容错率提高，系统间相互独立

　　　　缺点：

• • 服务之间相互调用使得如果某个服务端口或IP地址改变，系统需要手动更改；
  • 搭建集群后实现负载均衡比较负载，如内?负载，在迁移机器时会影响调??的路由，导致线上故障；
  • 服务之间调用方式不统一，基于 httpclient 、 webservice 的接?协议不统?；
  • 服务监控不到位，除了依靠端?、进程的监控，调?的成功率、失败率、总耗时等等这些监控指标是没有的
   

• SOA应用架构

 　　　　为解决接口协议不同意、服务无法监控、服务的负载均衡，引入了阿里巴巴的Dubbo高性能轻量级的java远程调用框架，与spring无缝集成，提供了三大核心功能：面向接口的远程方法调用，智能容错和负载均衡以及服务自动注册和发现

　　　　SOA (Service-Oriented Architecture)，即面向服务的架构。根据实际业务，把系统拆分成合适的、独立部署的模块，模块之间相互独立（通过Webservice/Dubbo等技术进行通信）。

　　　　优点：分布式、松耦合、扩展灵活可重用

　　　　缺点：服务抽取粒度大、服务调用方和提供方耦合度较高

• 微服务应用架构

　　　　微服务架构拆分粒度更小、服务更独立。把应用拆分成为一个个微小的服务，不同的服务可以使用不同的开发语言和存储，服务之间往往通过Restful等轻量级通信。

　　　　微服务架构关键在于微小、独立、轻量级通信。微服务是在 SOA 上做的升华粒度更加细致，微服务架构强调的?个重点是业务需要彻底的组件化和服务化

1.2 微服务架构体现的思想及优缺点

• 优点
  • 服务拆分粒度小，彻底的组件化和服务化使得开发耦合度低，可以独立部署扩展，灵活性强，省级改造影响范围小
    
  • 微服务小，便于特定业务功能的聚焦，解耦，开发，重用和模块的组装
  • 微服务相对独立，不同的微服务可以使用不同的语言开发，松耦合
  • 微服务架构下便于引进新技术
• 缺点
  • 分布式复杂难以管理
  • 分布式链路追踪难等

1.3 微服务架构中的核心概念

• 服务注册与服务发现
  • 服务注册：服务提供者将所提供的服务信息（服务器IP和端口、服务访问协议等）注册/登记到注册中心
  • 服务发现：服务消费者能够从注册中心获取到较为实时的服务列表，然后根究一定的策略选择一个服务访问
    
    
• 负载均衡：将请求压力分配到多个服务器（应用服务器、数据库服务器等），以此来提高服务的性能、可靠性

• 熔断：短路保护，如果下游服务器因访问过大而响应变慢或失败，上游服务为了保护系统整体可用性，可暂时切断对下游服务的调用，牺牲局部保障整体

• 链路追踪：对一次请求涉及的很多个服务链路进行日志记录和性能监控 

   

• API 网关
  • 微服务架构下，不同的微服务往往会有不同的访问地址，客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信可能出现：
    • 客户端需要调用不同的url地址，增加了维护调用难度
    • 在一定的场景下，也存在跨域请求的问题（前后端分离就会碰到跨域问题，原本我们在后端采用Cors就能解决，现在利用网关，那么就放在网关这层做好了）
    • 每个微服务都需要进行单独的身份认证
  • API网关就可以较好的统一处理上述问题，API请求调用统一接入API网关层，由网关转发请求。API网关更专注在安全、路由、流量等问题的处理上（微服务团队专注于处理业务逻辑即可）
    • 统一接入（路由）
    • 安全防护（统一鉴权，负责网关访问身份认证验证，与“访问认证中心”通信，实际认证业务逻辑交移“访问认证中心”处理）
    • 黑白名单（实现通过IP地址控制禁止访问网关功能，控制访问）
    • 协议适配（实现通信协议校验、适配转换的功能）
    • 流量管控（限流）
    • 长短链接支持
    • 容错能力（负载均衡）
      

2. SpringCloud简述

2.1 SpringCloud简述

 　　Spring Cloud是一系列框架的有序集合，利用SpringBoot的开发便利性简化了分布式系统基础设施的开发，如服务发现与注册、配置中心、消息总线、负载均衡、熔断器、数据监控等。

• Spring Cloud其实是一套规范，是一套用于构建微服务架构的规范，而不是一个可以拿来即用的框架（所谓规范就是应该有哪些功能组件，然后组件之间怎么配合，共同完成什么事情）。
• 在这个规范之下第三方的Netflix公司开发了一些组件、Spring官方开发了一些框架/组件，包括第三方的阿里巴巴开发了一套框架/组件集合Spring Cloud Alibaba，这些才是Spring Cloud规范的实现。
• Spring Cloud 规范及实现意图要解决的问题其实就是微服务架构实施过程中存在的一些问题，如微服务架构中的服务注册发现问题、网络问题（比如熔断场景）、统一认证安全授权问题、负载均衡问题、链路追踪等问题
  • Distributed/versioned configuration （分布式/版本化配置）
  • Service registration and discovery （服务注册和发现）
  • Routing （智能路由）Service-to-service calls （服务调用）
  • Load balancing （负载均衡）Circuit Breakers （熔断器）
  • Global locks （全局锁）
  • Leadership election and cluster state （ 选举与集群状态管理）
  • Distributed messaging （分布式消息传递平台）
• Spring Cloud 只是利用了Spring Boot 的特点，让我们能够快速的实现微服务组件开发，否则不使用Spring Boot的话，我们在使用Spring Cloud时，每一个组件的相关Jar包都需要我们自己导入配置以及需要开发人员考虑兼容性等各种情况。所以Spring Boot是我们快速把Spring Cloud微服务技术应用起来的一种方式
  

2.2 SpringCloud核心组件

 Spring Cloud 是一个微服务相关规范，意图为搭建微服务架构提供一站式服务，采用组件（框架化）机制定义一系列组件，各类组件针对性的处理微服务中的特定问题，共同构成微服务技术栈。

• 按发展可以分为第一代Spring Cloud组件和第二代SpringCloud组件

• SpringCloud中的各组件协调工作，注册中心负责服务的注册与发现，API网关负责转发所有外来的请求，断路器负责监控服务之间的调用情况，连续多次失败进行熔断保护，配置中心提供统一的配置信息管理服务，实时通知各个服务获取最新配置信息

2.3 SpringCloud 与Dubbo的对比

• Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，基于RPC调用，工作在传输层，TCP协议
• 对于目前使用率较高的Spring Cloud Netflix来说，它是基于HTTP的，所以效率上没有Dubbo高
• Dubbo体系的组件不全，不能够提供一站式解决方案，比如服务注册与发现需要借助于Zookeeper等实现，而SpringCloud Netflix则是真正的提供了一站式服务化解决方案，且有Spring大家族背景。

微服务架构与SpringCloud简述