在微服务之中，我们可以开展很多的研究，接下来在学习微服务之前了解一下必须的知识点。
一、集群技术
集群（cluster）技术是一种较新的技术，通过集群技术，可以在付出较低成本的情况下获得在性能、可靠性、灵活性方面的相对较高的收益，其任务调度则是集群系统中的核心技术。
1.1 系统结构
根据典型的集群体系结构，集群中涉及到的关键技术可以归属于四个层次：
（2）节点机及操作系统层高性能客户机、分层或基于微内核的操作系统等。
（3）集群系统管理层：资源管理、资源调度、负载平衡、并行IPO、安全等。
（4）应用层：并行程序开发环境、串行应用、并行应用等。
集群技术是以上四个层次的有机结合，所有的相关技术虽然解决的问题不同，但都有其不可或缺的重要性。
集群系统管理层是集群系统所特有的功能与技术的体现。在未来按需（On Demand）计算的时代，每个集群都应成为业务网格中的一个节点，所以自治性（自我保护、自我配置、自我优化、自我治疗）也将成为集群的一个重要特征。自治性的实现，各种应用的开发与运行，大部分直接依赖于集群的系统管理层。此外，系统管理层的完善程度，决定着集群系统的易用性、稳定性、可扩展性等诸多关键参数。正是集群管理系统将多台机器组织起来，使之可以被称为“集群”。
1.2 调度方法
1 进程迁移
进程迁移就是将一个进程从当前位置移动到指定的处理器上。它的基本思想是在进程执行过程中移动它，使得它在另一个计算机上继续存取它的所有资源并继续运行，而且不必知道运行进程或任何与其它相互作用的进程的知识就可以启动进程迁移操作，这意味着迁移是透明的。进程迁移是支持负载平衡和高容错性的一种非常有效的手段。对一系列的负载平衡策略的研究表明：进程迁移是实现负载平衡的基础，进程迁移在很多方面具有适用性。
二、SpringCloud
Spring Cloud是一系列框架的集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。
Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
三、微服务
(2条消息) 微服务介绍(史上最全)_胡安民-独行者的博客-CSDN博客_微服务
3.1 概念
维基上对其定义为：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。
微服务是分布式架构的一种，分布式架构其实就是要把服务做一个拆分，而springcloud只是解决了拆分过程中的服务治理问题。在单体架构中，我们把所有的服务都写在一起，随着业务的复杂代码的耦合度就会越来越高，不便于将来的升级维护。
所以往往需要拆分这些服务，微服务在拆分的时候，会根据业务功能模块把一个单体的应用拆分成许多个独立的项目，每个项目完成一部分的业务功能，然后独立开发和部署。这些独立的项目就成为一个微服务。进而构成一个服务集群。
举例：
一个商城系统就得提供相当多的服务， 比如订单服务，用户功能，商品服务，支付服务等等，这些模块如果使用单体架构来实现，那么耦合度会相当高，开发难度也会很大。如果使用微服务开发，把每一个服务都当成一个单体应用来开发，那么订单服务，用户服务，商品服务，支付服务等模块，每一个就成为一个微服务。由这些微服务构成整个的商城系统。这样明显是更加合理的。每个服务也可以根据业务的需要去进行集群部署。一方面降低了服务的耦合，一方面有利于服务的维护升级。
3.2 微服务的相关技术栈
1 注册中心：
一个业务往往就需要多个服务来共同完成，比如一个请求发送过来，先是调用了服务a，然后服务a调用服务b，服务b调用服务c；
然而，当业务越来越复杂的时候，这些服务之间的调用关系就错综复杂，所以这个时候需要一个注册中心，用来记录每一个服务的ip，端口，以及它能完成的功能，然后这些服务之间要互相调用的时候，不用去记录服务的ip，只要到注册中心找就可以了。
2 配置中心：
每个服务都有自己的配置文件，而一个上线的项目可能会有成百上千的服务，这些配置文件，我们不可能一个一个去修改，这个时候需要一个配置中心，它主要用来统一管理整个服务集群成千上百的配置，我们要变更某些配置，只要找到配置中心就可以了，它就会去找到对应的配置，实现配置的热更新。
3 网关：
所有的请求进来，并不能直接就去访问对应的服务，而是要通过一个网关服务，由它来路由到对应的服务。
4 分布式缓存：
数据库层，由于数据库即使是集群部署，也很难抗住高并发，往往还需要一个缓存集群，把数据库的数据搬到内存中以提高访问效率。请求先查询缓存，缓存未命中的时候再去查询数据库。
5 分布式搜索：
对于一些复杂的数据的搜索、统计、分析，我们还需要使用搜索集群。
6 消息队列：
在分布式架构中，还需要消息队列，因为一个业务往往会调用多个服务，但我们不能等到所有的服务都执行完成再返回响应数据，因为这样操作就类似串行执行，响应速度有所下降。这个时候可以使用消息队列，让服务发送消息通知其他服务去执行指定的任务，而自己则可以结束运行，提高响应速度。
7 分布式日志服务：
分布式日志服务：主要用来统计成百上千的服务的运行日志，方便系统出问题时的定位。
8 系统监控链路追踪：
系统监控链路追踪：可以实时监控整个服务集群的所有节点的运行状态。
3.3 单体架构和微服务的区别
架构的演变大致为：单一应用架构 ===> 垂直应用架构 ===> 分布式服务架构 ===> 流动计算架构微服务架构 ===> [未知]
3.3.1 单体架构
将业务的所有功能集中在一个项目中开发，打成一个包部署。架构简单，部署成本低，但是代码的耦合度高，所有的模块都耦合在一起。一个系统业务量很小的时候所有的代码都放在一个项目中就好了，然后这个项目部署在一台服务器上就好了。整个项目所有的服务都由这台服务器提供。这就是单机结构。
单体应用的优点在于：单一架构模式在项目初期很小的时候开发方便，测试方便，部署方便，运行良好。
他的缺点也很明显：应用随着时间的推进，加入的功能越来越多，最终会变得巨大，一个项目中很有可能数百万行的代码，互相之间繁琐的jar包。久而久之，开发效率低，代码维护困难。如果想整体应用采用新的技术，新的框架或者语言，那是不可能的。任意模块的漏洞或者错误都会影响这个应用，降低系统的可靠性。
3.3.2 分布式架构
根据业务功能对系统进行拆分，每个业务模块都作为独立的项目来开发，成为一个服务。降低服务之间的耦合度，有利于服务升级拓展。
由于整个系统运行需要使用到Tomcat和MySQL，单台服务器处理的能力有限,2G的内存需要分配给Tomcat和MySQL使用，随着业务越来越复杂，请求越来越多.。内存越来越不够用了，所以这时候我们就需要进行分布式的部署。
我们进行一个评论的请求，这个请求是需要依赖分布在两台不同的服务器的组件[Tomat和MySQL],才能完成的.。所以叫做分布式的系统。
分布式和单体项目最大的区别在于分布式的项目是分开部署的，比如说把数据库,MQ,ES,单独放在一台或者多台服务器上。
当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢？ 这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。
优点：抽取公共的功能为服务层，提高代码复用性。
缺点：系统间耦合度变高，调用关系错综复杂，难以维护。
3.3.3 集群
在上面的图解中其实是存在问题的，比如Tomcat存在单点故障问题，一旦Tomcat所在的服务器宕机不可用了，我们就无法提供服务了,所以针对单点故障问题，我们会使用集群来解决.那什么是集群模式呢
单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍（有几个节点就相当于提升了这么多倍）。
但问题是用户的请求究竟由哪个节点来处理呢？最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均。要实现这个功能，就需要在所有节点之前增加一个“调度者”的角色，用户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼了名字——负载均衡服务器(Nginx)。
3.3.4 微服务架构
微服务架构在某种程度上是面向服务的架构，它更加强调服务的"彻底拆分"。
优点：
服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展。
微服务之间采用RESTful等轻量级Http协议相互调用。
服务各自有自己单独的职责，服务之间松耦合，避免因一个模块的问题导致服务崩溃
缺点：
分布式系统开发的技术成本高（容错、分布式事务等）。
服务治理和服务监控关键。
多服务运维难度，随着服务的增加，运维的压力也在增大
优化之后：
3.4 微服务的特征
1.单一职责
微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发；
2.面向服务
微服务对外暴露业务接口；
3.自治
团队独立，技术独立，数据独立，部署独立；
4.隔离性强
服务调用做好隔离、容错、降级、避免出现级联问题。
3.5 服务拆分及远程调用
1 服务拆分的原则
-
不同微服务，不要重复开发相同的业务；
-
微服务数据独立，不要访问其他微服务的数据库；
-
微服务可以将自己的业务暴露为接口，供其他微服务调用。
2 服务的远程调用
(1条消息) 什么是微服务？_普通网友的博客-CSDN博客_微服务
3.6 微服务架构的常见概念
3.6.1 服务治理
服务治理就是进行服务的自动化管理，其核心是服务的注册与发现。
服务注册：服务实例将自身服务信息注册到注册中心。
服务发现：服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求他们提供服务。
服务剔除：服务注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到。
3.6.2 服务调用
在微服务架构中，通常存在多个服务之间的远程调用的需求，目前1主流的远程调用的技术有基于HTTP请求的RESTFul接口及基于TCP的RPC协议。
REST(Representational State Transfer)：这是一种HTTP调用的格式，更标准，更通用，无论哪种语言都支持http协议。
RPC（Remote Promote Call）：一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。
他们之间的区别于联系：
3.6.3 服务网关
随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信可能出现：
客户端需要调用不同的url地址，增加难度。
在一定的场景下，存在跨域请求的问题。
每个微服务都需要进行单独的身份认证。
为了解决这些问题，API网关顺势而生。
API网关直面意思是将所有API调用统一接入到API网关层，由网关层统一接入和输出。一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后，各个API服务提供团队可以专注于自己的的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。
3.6.4 服务容错
在微服务当中，一个请求经常会涉及到调用几个服务，如果其中某个服务不可用，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应。
我们没法预防雪崩效应的发生，只能尽可能去做好容错。服务容错的三个核心思想是：
不被外界环境影响。
不被上游请求压垮。
不被下游响应拖垮。
3.6.5 链路追踪
随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要对一次请求涉及的多个服务链路进行日志记录，性能监控即链路追踪。
四、RESTFul api
轻量级的通信机制互相沟通，通常是基于Http请求的RESTFul Api，通过RESTFul API，事件流和消息代理的组合相互通信；
REST(Representational State Transfer)：这是一种HTTP调用的格式，更标准，更通用，无论哪种语言都支持http协议。
五、Redis
六、算法
可以比较贪心算法、线性规划算法、遗传算法在任务调度中的性能