介绍
微服务是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。Spring Cloud 是一系列框架的有序集合，它利用 Spring Boot 的开发便利性简化了分布式服务系统的开发，比如服务发现、服务网关、服务路由、链路追踪等
微服务是一种架构风格，一个大型复杂软件应用根据业务划分为多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的（可以相互调用）。每个微服务仅关注于完成一件任务并很好的完成该任务，在所有的情况下，每个任务代表着一个小的业务能力。
微服务的特征：
1）微服务单元按照业务来划分
2）微服务通过HTTP来通讯，数据格式为json或者xml。
3）微服务的数据库相对独立
4）微服务的自动化部署。可使用jenkins、Docker、Kubernetes
5）服务集中管理。Eureka、Zookeeper、Consul、Nacos、Etcd（服务注册发现组件）
6）分布式架构（集群部署）。
7）熔断机制/防止雪崩。Hystrix
8）链路跟踪。Sleuth 、Skywalking
9）完整的安全机制。用户验证、权限验证、资源保护等
10）完整的实时日志。
问题1：分布式事务问题？setea 一般解决都是二阶段/三阶段提交，无论哪一种都有可能存在事务失败，导致数据不一致的情况。
一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果。所以他也就不知道本次事务到底应该commit还是 roolback。常规的解决办法就是引入一个“协调者”的组件来统一调度所有分布式节点的执行。
**两阶段提交主要保证了分布式事务的原子性：即所有结点要么全做要么全不做)。所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段)。**二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。
三阶段引入超时机制 (同时在协调者和参与者中都引入超时机制);在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的;也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit，而不会一直持有事务资源并处于阻塞状态。
问题2：拆分原则？DDD领域驱动设计 通过代码和数据分析合理的切分点。通过数据分析服务的划分边界和划分粒度。
Spring boot：spring boot是一个框架，一种全新的编程规范，他的产生简化了框架的使用，所谓简化是指简化了spring众多框架中所需的大量且繁琐的配置文件，所以springboot是一个服务于框架的框架，服务范围是简化配置文件！
Spring cloud：spring cloud基于spring boot提供了一整套服务的解决方案，包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件
Spring cloud利用spring boot的开发便利性巧妙的简化了分布式系统的基础设施开发，spring cloud为开发人员提供了快速构建分布式系统的一些工具，包扣配置管理、服务发现、断路器、路由、微代理、事件总线，他们都可以用spring boot的开发风格做到一键启动和部署！Spring Clould通讯方式是基于HttP Restful风格，Dubbo的通讯方式基于远程调用。
微服务的体现：
1、Eureka/nacos：服务注册中心，用于服务管理。
2、Ribbon：基于客户端的负载均衡组件。常与服务发现组件、网关、feign组合，在消费服务的时候做到负载均衡。
3、Hystrix：容错框架，能够防止服务的雪崩效应。
4、Feign：Web 服务客户端，能够简化 HTTP 接口的调用。 微服务直接的调用
5、Zuul/gateway---->Security(安全控制)：API 网关，提供路由转发、请求过滤等功能。可以做认证、监控、流量监控等。
Security：向服务单元提供了用户验证、权限认证。一般组合OAuth2.0+JWT一起使用。
6、Config：分布式配置管理。有客户端、服务端。服务端读取本地、服务端配置，客户端读取服务端配置，来达到同一管理。
7、Sleuth：链路跟踪。跟踪一个请求经过了多少服务。封装了Dapper、ZipKin、Kibana组件。
8、xxljob：远程调度任务
9、Stream：构建消息驱动的微服务应用程序的框架。
10、Bus：消息代理的集群消息总线。
服务配置
Zookeeper 是分布式应用程序协调服务, 用于维护配置信息、命名、提供分布式同步和提供组服务。客户端注册是服务自身要负责注册与注销的工作。**当服务启动后向注册中心注册自身，当服务下线时注销自己，期间还需要和注册中心保持心跳。**心跳不一定要客户端来做，也可以由注册中心负责（这个过程叫探活）。这种方式的缺点是注册工作与服务耦合在一起，不同语言都要实现一套注册逻辑。
Zookeeper数据模型的结构类似文件系统。集群是选举机制（第一次启动选举机制、非第一次启动选举机制/任意服务器故障），股适合安装奇数服务器，至少3台。
Eureka 提供服务注册服务, 各个节点启动后，会在 Eureka Server 中进行注册
Nacos 动态服务发现、服务配置、服务元数据及流量管理
Zookeeper 保证 CP，Eureka 、Nacos保证 AP：
C：数据一致性；
A：服务可用性；
P：服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同
时满足两个。
Zookeeper特性：
1）集群只能一个领导+多个跟随者
2）集群中只要半数以上节点存活，集群就才能正常服务
3）全局数据一致，每个server保存一份相同的数据副本，
4）同一个Client更新请求顺序执行
5）数据更行原子性
6）实时性。一定时间访问内，客户端读到最新数据
Eureka
1）服务注册。客户端要向服务端注册时，需提供自身的元数据（IP、端口等）
2）服务续约。每隔30秒发送一次心跳来进行服务续约。（缓冲）
3）获取服务注册列表。从服务器获取服务列表，并缓冲到本地
4）服务下线。客户端关闭时向服务端发送下线请求，服务做下线处理
5）服务剔除。客户端连续90秒如果没有向服务端进行续约就会被剔除。
Eureka的保护模式
当新的Server出现，从相邻peer节点读取所有服务实例，如果从相邻peer获取信息失败，会尝试从其他peer节点获取。
server拥有所有的服务实例后，会根据配置设置服务续约的阈值。在任何时间，如果接收到的服务续约低于该值配置的百分比（默认15分钟，百分比为85%），就开启自我保护模式，不在剔除注册服务的信息。
选择的原因：完全开源、而且跟其他组件很容易实现服务注册、负载均衡、熔断、路由等功能。
组件对比
Nacos与eureka的共同点
1）都支持服务注册和服务拉取
2）都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别
1）Nacos 支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
2）临时实例心跳不正常会被剔除，非临时实例则不会被剔除
3）Nacos 支持服务列表变更的消息推送模式，服务列表更新更及时
4）Nacos 集群默认采用 AP 方式，当集群中存在非临时实例时，采用 CP 模式； Eureka 采用 AP 方式
Hystrix 容错降级
熔断机制是应对雪崩效应的一种微服务链路保护机制。当某个微服务不可用或者响应时间太长时，会进行服务降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。
**在SpringCloud框架里熔断机制通过Hystrix实现，Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内调用20次，如果失败，就会启动熔断机制。**服务降级，一般是从整体负荷考虑。就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。这样做，虽然水平下降，但好歹可用，比直接挂掉强。
设计原则：
1）防止单个服务的故障耗尽整个服务的Servlet容器的线程资源
2）快速失败机制，如果某个服务出现了故障，则调用该服务的请求快速失败，而不是线程等待。
3）提供回退方案，在请求故障时，提供社会定好的回退方案。
4）使用熔断机制，防止故障扩散的服务。资源一直被占用，其他请求得不到资源，会导致服务故障更多。
5）提供熔断器的监控组件HystrixDashboard,可以实时监控熔断器的状态。
Hystrix的工作机制
当服务的某个API接口的失败次数在一定时间内小于设定的阈值（缺省是5秒内调用20次），熔断器处于关闭状态；如果失败次数大于阈值，就会判定API接口出现了故障，会打开熔断器。之后会执行设置的快速失败逻辑，不执行业务逻辑，请求线程就不会处于阻塞的状态。而处于打开状态的熔断器，在一段时间会处于半打开的状态，将一定的数量执行正常逻辑，其余的快速失败。若是执行业务逻辑成功，则熔断器关闭。
Hystrix 监控
每个使用Hystrix都有对应的监控页面，但是服务太多就不方便管理，可以使用Hystrix的另外一个组件Turbine，Turbine组件聚合多个Hystrix Dashbord组件的数据。
Ribbon（负载均衡）：
Ribbon是Netflix发布的负载均衡器，他有助于控制http和TCP客户端的行为，为ribbon配置服务提供者的地址列表后，ribbon就可基于某种负载均衡算法，自动的帮助服务消费者去请求。Ribbon默认为我们提供了很多的负载均衡算法，例如轮询、随机等，我们也可为ribbon实现自定义的负载均衡算法，在spring cloud中，当ribbon与eureka配合使用时，ribbon可自动从eurekaserver获取服务提供者的地址列表，并基于负载均衡算法，请求其中一个服务提供者的实例（为了服务的可靠性，一个微服务可能部署多个实例）。
RestTemplate是Spring Resource中一个访问第三方RESTful API接口的网络请求框架。可以说RestTemplate就是用来消费REST服务的。
负载均衡指的是将负载分摊到多个执行单元上，常见的负载均衡有两种方式：一种是独立进程单元，通过负载均衡，将请求转发到不同的执行单元上，例如：Nginx；另外一种是将负载均衡一代吗的形式封装到服务消费者的客户端的进程里，消费服务的客户端有服务提供的信息列表，就可以根据负载均衡测罗将请求分摊到多个服务提供者 例如：Ribbon。
Ribbon的负载均衡主要是通过LoadBalancerClient来实现的，而LoadBalancerClient的具体是交给了ILoadBalancer来处理，ILoadBalancer通过配置IRule策略、IPing 进行负载均衡。而RestTemplate加上@LoadBalancer就可以实现远程调用负载均衡。RestTemplate接口能实现，主要是添加了拦截器，只要是@LoadBalancer的就交给Ribbon的负载均衡器进行处理。
Fegin(接口调用):
微服务之间通过rest接口通讯，springcloud提供fegin框架来支持rest的调用，fegin使得不同进程的rest接口调用得以用优雅的方式进行，这种优雅表现的就像同一个进程调用一样（简化微服务的通信过程）。
**feign采用的是基于接口的注解 ，feign整合了ribbon，具有负载均衡的能力；整合了Hystrix，具有熔断的能力。**feign被设计成插拔式，可以注入其他组件一起使用，常和Ribbon实现负载均衡。
Fegin是个伪 Http客户端，Fegin不做任何的请求处理。通过处理注解生成定制的Request模版，从而简化http开发。Client组件是负责发送Request请求和接收响应的。
实现过程：
1）首先通过@EnableFeignClients注解开启FeignClient的功能，只有这个注解的存在，才会在程序启动的时候开启对@FeignClient注解的包的扫描。
2）根据Feign规则实现接口，并在接口上添加@FeignClient注解。
3）程序启动会把该注解下的类注入到IOC容器中，当接口调用时，生成RequestTemplate模版对象，再生成Request对象。
4）交由Client去处理，最后的被封装到LoadBalanceClient类，这个类可以结合Ribbon做到负载均衡（加负载均衡的注解@LoadBalancer）。
网关 Zuul/Gateway
网关的角色是作为一个 API 架构，用来保护、增强和控制对于 API 服务的访问。
API 网关是一个处于应用程序或服务（提供 REST API 接口服务）之前的系统，用来管理授权、访问控制和流量限制等，这样 REST API 接口服务就被 API 网关保护起来，对所有的调用者透明。 因此，隐藏在 API 网关后面的业务系统就可以专注于创建和管理服务，而不用去处理这些策略性的基础设施。
**服务网关内置了19中过滤器工厂，Gateway网关需要实现GatewayFilter和Ordered两个接口。服务网关分为网关过滤器和全局过滤器。**网关过滤器通过配置文件，作用到所有路由上。
常见的限流算法：计数器算法、漏桶算法、令牌桶算法。
Gateway
Spring Cloud Gateway基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流。底层使用了高性能的通信框架Netty,提供了异步支持，提供了抽象负载均衡，提供了抽象流控，并默认实现了RedisRateLimiter。
Zuul
**Zuul1.0采用的是异步阻塞模型。Zuul 2.x服务网关，基于Netty，也是非阻塞的，支持长连接。**Zuul用于构建边界服务，致力于动态路由、过滤、监控、弹性伸缩和安全。**另外zuul横向扩展能力非常好，可以通过使用不同Zuul来进行路由，按照前端的不同来。另外一种常见的是Nginx+Zuul模式。**暴露在外的是Nginx主从双热备进行keepalive，经过某种路由策略，将请求转发到Zuul集群上。
Zuul的特性：
1）可以和Ribbon、Eureka结合，可以实现智能路由和负载均衡。Zuul能够将请求流量按照某种策略分发到集群状态的多个服务实例。
2）网关将所有服务的API接口统一聚合，并统一向外暴露。
3）可以做用户身份认证和权限认证，防止非法请求操作API接口，对服务器起到保护作用。
4）网关可以实现监控功能，实时日志输出，并对请求进行记录。
5）网关可以实现流量监控，在高流量的情况下，对服务进行降级。
6）API接口从内部服务分离出来，方便做测试。
Zuul2x:
7）可以在网关层做权限判断
8）可以在网关层做缓冲
Zuul的工作原理
Zuul是通过Servlet来实现的，Zuul通过自定义的Servlet来对请求进行控制。Zuul的核心是一系列的过滤器，Zuul采用了动态读取、编译和运行这些过滤器，这些过滤器之间不能互相通讯，只能通过RequestContext对象来共享数据。
四个过滤器：
1）PRE过滤器：可以做安全认证 比如身份验证、参数验证。
2）ROUTING过滤器：将请求路由到具体的微服务实例。默认使用HTTP请求
3）POST 过滤器：用作收集统计信息、指标，以及将响应传到客户端。
4）ERROR过滤器：在其他过滤器发生错误时进行执行。
过滤器的类型：
type：决定了过滤器在请求的哪个阶段起作用，例如 pre post。
Execution Order:过滤器的执行次序，越小越先执行
Criteria:过滤器执行所需的条件。
Action：如果符合执行条件，则执行Action（即逻辑代码）。
一个请求的执行过程
进入到网关，先进入pre filter，进行一些列的验证、操作、判断。交给routing filter进行路由转发，转发到具体的服务实例进行逻辑处理；当处理完又post filter进行处理，该处理完将Respose返回给客户端。
Gateway 与Zuul 的区别
相同点：
1、底层都是servlet
2、两者均是web网关，处理的是http请求
不同点：
1、gateway功能更加强大，实现了负载均衡；zuul没有
2、gateway提供衣服支持，zuul仅支持同步（使用的是阻塞式的 API，不支持长连接**，比如 **websockets）
Config配置
在Spring Cloud中，有分布式配置中心组件spring cloud config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。在spring cloud config 组件中，分两个角色，一是config server，二是config client。
Config Server是一个可横向扩展、集中式的配置服务器，它用于集中管理应用程序各个环境下的配置，默认使用Git存储配置文件内容，也可以使用SVN存储，或者是本地文件存储。Config Client是Config Server的客户端，用于操作存储在Config Server中的配置内容。微服务在启动时会请求Config Server获取配置文件的内容，请求到后再启动容器。
Config Server支持从GIT仓库读取配置文件。配置变更后通过Bus去数据库刷新配置（/bus/refresh）。也可以将配置存储到mysql数据库。
Sleuth/Skywalking 服务链条
Spring Cloud Sleuth为Spring Cloud实现了分布式跟踪解决方案，兼容Zipkin、HTrace等其它基于日志的追踪系统，例如ELK。目前主流的链路追踪工具：Google的Dapper，阿里的鹰眼，大众点评的CAT，Twitter的Zipkin，LINE的pinpoint，国产的skywalking。
· Zipkin****：****Twitter开源的调用链分析工具，目前基于springcloud sleuth得到了广泛的使用，特点是轻量，使用部署简单。Zipkin是通过RabbiitMQ来传输链路数据的，并可以将数据存储到数据库，也可以存储到ES上面。
· Pinpoint：韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无代码侵入。
· Skywalking：国产的优秀APM组件，是一个基于字节码注入的调用链分析，对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统。特点是支持多种插件，UI功能较强，接入端无代码侵入。目前已加入Apache孵化器。
· CAT：大众点评开源的基于编码和配置的调用链分析，应用监控分析，日志采集，监控报警等一系列的监控平台工具。
Sleuth特性
探针的性能
主要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提高。 skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显。
collector的可扩展性
能够水平扩展以便支持大规模服务器集群。 zipkin支持多个实例订阅MQ，异步消费监控信息。skywalking支持单机和集群模式，使用gRPC通信。
全面的调用链路数据分析
提供代码级别的可见性以便轻松定位失败点和瓶颈。 zipkin的链路监控粒度到接口级别。skywalking 支持众多的中间件、框架、类库。pinpoint数据分析最完备，提供代码级别的可见性以便轻松定位失败点和瓶颈。
对于开发透明，容易开关
添加新功能而无需修改代码，容易启用或者禁用。 Zipkin它要求在需要时修改代码。skywalking和pinpoint基于字节码增强的方式，不需要修改代码，并且可以收集到字节码中的更多精确的信息 。
完整的调用链应用拓扑
自动检测应用拓扑，帮助你搞清楚应用的架构。 pinpoint界面显示的更加丰富，具体到调用的DB名，zipkin的拓扑局限于服务于服务之间 。
Skywalking是一个可观测性分析平台和应用性能管理系统，它也是基于OpenTracing规范、开源的AMP 系统。Skywalking提供分布式跟踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。支持 Java， .Net Core, PHP, NodeJS, Golang, LUA, c++代理。支持Istio +特使服务网格访问官方提供的控制台。
远程调度
XXL-JOB是一个分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。在众多XXL-Job平台的特征中，有如下几条需要关注的：
1、使用简单：支持通过Web页面对任务配置，降低操作任务的难度；
2、动态：支持动态修改任务状态、启动/停止任务，以及终止运行中任务，即时生效；
3、调度中心HA（中心式）：调度采用中心式设计，“调度中心”自研调度组件并支持集群部署，可保证调度中心HA；
4、执行器HA（分布式）：任务分布式执行，任务”执行器”支持集群部署，可保证任务执行HA；
5、注册中心: 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时，也支持手动录入执行器地址；
6、弹性扩容缩容：一旦有新执行器机器上线或者下线，下次调度时将会重新分配任务；
7、触发策略：提供丰富的任务触发策略，包括：Cron触发、固定间隔触发、固定延时触发、API（事件）触发、人工触发、父子任务触发；
Stream
Spring Cloud Stream 在 Spring Cloud 体系内用于构建高度可扩展的基于事件驱动的微服务，其目的是为了简化消息在 Spring Cloud 应用程序中的开发。
BUS
Spring Cloud Bus 使用轻量级的消息代理来连接微服务架构中的各个服务,可以将其用于广播状态更改(例如配置中心配置更改)或其他管理指令 通常会使用消息代理来构建一个主题,然后把微服务架构中的所有服务都连接到这个主题上去,当我们向该主题发送消息时,所有订阅该主题的服务都会收到消息并进行消费。 使用Spring Cloud Bus 可以方便地构建起这套机制,所以 Spring Cloud Bus 又被称为消息总线。
Spring Security
Spring Security是什么？
Spring Security 是Spring Resouurce社区的一个安全组件，可以在Controller、Service、DAO层等以加注解的方式来保护应用程序的安全。**提供了细粒度的权限控制，**可以精细到每个API接口、每个业务的方法、每个操作数据库的DAO层。Security提供的是应用层的安全解决方案，但是一个系统还需要考虑传输层、系统层的安全，例如：Http协议、服务器部署防火层、服务器集群隔离部署等。
**在安全方面，主要有两个领域，一个是认证、而是授权。**认证是认证主体的过程，通常是可以在应用程序中执行操作的用户、设备或者其他系统。授权是指决定是否允许已认证的主体执行某一操作。**Spring Security采用注解的方式控制权限，容易上手。**Spring Security支持很多种认证方式，自带和第三方的。
OAuth2.0
**OAuth2.0是一个标准的授权协议，允许不同的客户端通过认证和授权的方式来访问被其保护起来的资源。**主要包含3个角色：服务提供者、资源持有者、客户端。
大致流程如下（认证、授权）：
1）用户（资源持有者）打开客户端，客户端询问用户授权
2）用户同意授权
3）客户端向授权服务器申请授权。
4）授权服务器向客户端进行认证，也包括用户信息的认证，认证成功后授权给予令牌。
5）客户端获取令牌，携带令牌向资源服务器请求资源。
6）资源服务器确认令牌正确无误，向客户端释放资源。
**OAuth2.0分为两部分，分别是OAuth2 Provider和OAuth2 Client。**OAuth2 Provider负责公开被OAuth2保护起来的资源。OAuth2 Provider通过管理和验证OAuth2令牌来控制客户端是否有权限访问被其保护的资源。另外还为用户提供认证API接口。
**OAuth2 Provider角色分为资源服务和授权服务。可能一个授权服务对多个资源服务。**Spring OAuth2.0需配合Spring Security一起使用，所有请求经过控制器处理，并进过一些列的Spring Security过滤器。**Spring Security过滤器链中有2个节点用于获取验证和授权的。**如果资源服务和授权服务不在同一个服务中，则需要做额外的配置。
JWT
Spring Security OAuth2 保护了微服务系统，但是有个缺陷，每次请求都需要经过Uaa服务验证Token的合法性，并且需要查询该Token对应的用户的权限。针对此问题可以加入JWT的方式，Uaa服务只需要验证一次，返回JWT（用户的所有信息，包括用户权限）。
介绍
JWT是一种开放的标准，定义了一种紧凑且自包含的标准，该标准将各个主体的信息包装为JSON对象。主体信息是通过数字签名进行加密和验证的，常使用HMAC算法和RSA算法对JWT进行签名，安全性很高。
但是存在一个缺点，**权限变更之后需要重新登录获取新的Token。**之前的token如果没有过期的话，还是可以正常使用的。一种改进方式是登录成功之将token缓存到网关，如果权限发生变更，将网关的缓存Token删除，当请求经过网关，判断token在缓存中是否存在，不存在就提示重新登录。
JWT由3部分组成，Header（头）、Payload（有效负载）、Signature（签名）
使用场景：
1）认证：登录成功获取JWT，后续每个请求都携带JWT。
2）信息交换：JWT的在各方之间安全传输信息的一种方式。使用Header+Payload计算签名的时候还可以验证内容是否被篡改。
JWT认证过程
浏览器 ---------------》登录 ------------------》服务器------------》用密匙创建JWT -------------》返回JWT给浏览器 -------------》在header添加JWT---------------》检查JWT解密、获取用户信息-----------》给客户响应。
其他
seata分布式事务中间件
swagger 接口文档
nginx
Nginx是一个免费、开源、高性能、轻量级的 HTTP 和反向代理服务器，也是一个电子邮件（IMAP/POP3）代理服务器，其特点是占有内存少，并发能力强。Nginx 可以作为静态页面的 web 服务器，同时还支持 CGI 协议的动态语言，比如 perl、php 等，但是不支持 java。Java 程序一般都通过与 Tomcat 配合完成。
核心模块： HTTP 模块、EVENT 模块和 MAIL 模块
基础模块： HTTP Access 模块、HTTP FastCGI 模块、HTTP Proxy 模块和 HTTP Rewrite 模块
第三方模块： HTTP Upstream Request Hash 模块、Notice 模块和 HTTP Access Key 模块及用户自己开发的模块
为什么使用反向代理
- 保护和隐藏原始资源服务器
- 加密和SSL加速
- 通过缓存静态资源，加速Web请求
- 实现负载均衡
