文章目录
前言
在学习SpringCloud的过程中，对SpringCloud的知识进行记录。
一、微服务
1.什么是微服务？
谈到SpringCLoud的话，就避免不了谈及微服务。什么是微服务？简而言之，微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。
在我们软件开发里，所谓的微服务，是以缩短交付周期为核心，基于DevOps的演进式架构。
2.微服务与DevOps
我们面向用户的移动应用、WEB应用包括一些物联网应用，通过接入服务层来调用访问，所谓的服务入口就是我们的API网关，而通过API网关又有一些安全策略和访问的认证。API网关帮助我们做服务的路由，在服务的整个注册中心中进行服务发现；不同的业务模块把服务注册到服务注册中心，再由服务的路由来调用。服务与服务之间的通信，还有通过消息中心。基于微服务的开发过程中，有自动化测试、自动化构建、自动化部署以及自动化平台的服务。在此基础上又形成IT运营的服务，比如说写作、技术看板、业务看板；遥测服务：监控与通知、日志优化。在没有微服务的是有也有DevOps想把运维这方面做得简单便捷，有了微服务后，可以更好的与DevOps结合。
3.微服务实施的问题
微服务的实施，必然将原先的应用拆分成数十个，那么对于拆分后的微服务进行编译、打包、部署的工作量必然是原来的数倍。
微服务的实施，会涉及多个微服务之间的写作，那么对微服务的功能进行测试就变得更加复杂。
微服务的实施，多个微服务可能采用不同框架，所依赖的基础环境就会更加复杂。
微服务的实施，会涉及多个团队的开发，那么微服务需求的管理任务就会变得更加艰巨。
微服务的实施，会频繁的进行应用更新，那么代码编译、版本控制、质量管理将无法保障。
综上所述，微服务的实施会带来一系列的问题，所以我们必须要采用成熟且先进的工具来帮助我们进行管理。因此，DevOps是微服务实施的充分必要条件；微服务是DevOps实施的充分但不必要条件。
4.微服务的基本特点
- 独立部署，灵活扩展
传统的单体架构是以整个系统为单位进行部署，而微服务是以每一个独立组件（例如用户服务、商品服务）为单位进行部署。
什么意思呢？比如根据每个服务器的吞吐量不同，支付服务需要部署20台机器，用户服务需要部署30台机器，而商品服务只需要部署10台机器。这种灵活部署只有微服务架构才能实现。而近几年流行的Docker，为微服务架构提供了有效的容器。 - 资源的有效隔离
微服务设计的原则之一，就是每一个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的结构来完成。这样有效避免了服务之间竞争数据库和缓存所带来的问题。
同时，由于每一个微服务实例在Docker容器上运行，实现了服务器资源（内存、cpu资源等）的有效隔离。 - 团队组织架构的调整
微服务设计的思想也改变了原有的企业研发团队组织架构。传统的研发团队是水平架构，前端有前端的团队，后端有后端的团队，DBA有DBA的团队，测试有测试的团队。
事实上传统应用设计架构的分层结构正反应了不同角色的沟通结构。所以若要按微服务的方式来构建应用，也需要对应调整团队的组织架构。每个服务背后的小团队的组织是跨功能的，包含实现业务所需的全面的技能。
5.主流微服务框架
- Spring Cloud
用户数量、开发数量较多 - DUBBO
阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成 - Service Comb
华为内部探索设计并商用，后进入Apache孵化器，并在Apache 软件基金会毕业成为顶级项目 - NACOS
基于Spring Cloud的基础上做了更高层次的封装
二、Spring Cloud
1.Spring Cloud基础介绍
Spring Cloud为开发人员提供了工具，以快速构建分布式系统中的某些常见模式（例如，配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁，领导选举，分布式会话，群集状态）。分布式系统的协调导致了样板式样，并且使用Spring Cloud开发人员可以快速站起来实现这些样板的服务和应用程序。它们可以在任何分布式环境中正常工作，包括开发人员自己的笔记本电脑，裸机数据中心以及Cloud Foundry等托管平台。
2.Spring Cloud特征
Spring Cloud专注于为典型的用例和可扩展性机制（包括其他用例）提供良好的开箱即用体验。
- 分布式/版本化配置
其实就是市面上的全局配置中心，用来统一管理分布式的系统外部化配置。 - 服务注册和发现
在一个微服务应用中，服务实例在运行时的配置也会动态变化，包括他们的网络地址。为了满足客户端向服务发送请求的需要，必须要实现服务发现机制。
服务发现的关键部分是服务注册表。服务注册表是一个可用的服务实例的数据库。服务注册表提供了一个管理API和一个查询API。服务实例的注册和注销通过管理API实现，查询API用来寻找可用的服务实例。 - 路由
Spring在因Netflix开源流产事件后，在不断的更换Netflix相关的组件，比如：Eureka、Zuul、Feign、Ribbon等，Zuul的替代产品就是SpringCloud Gateway，这是Spring团队研发的网关组件，可以实现限流、安全认证、支持长连接等新特性。 - 服务到服务的呼叫
SpringCloud中为了解决服务与服务调用的问题，提供了两种方式。RestTemplate和Feign。虽然这两种调用的方式不同，但在底层还是和HttpClient一样，采用http的方式进行调用的，对HttpClient进行的封装。 - 负载均衡
将负载(工作任务)进行平衡、分摊到多个操作单元上进行运行,例如FTP服务器、Web服务器、企业核心应用服务器和其它主要任务服务器等,从而协同完成工作任务。负载均衡构建在原有网络结构之上,它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性。 - 断路器
为了保证微服务高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。为了解决这个问题，业界提出了断路器模型。
Netflix开源了Hystrix组件，实现了断路器模式，SpringCloud对这一组件进行了整合。 在微服务架构中，一个请求需要调用多个服务是非常常见的，较底层的服务如果出现故障，会导致连锁故障。当对特定的服务的调用的不可用达到一个阀值（Hystric 是5秒20次） 断路器将会被打开。断路打开后，可用避免连锁故障，fallback方法可以直接返回一个固定值。 - 全局锁
Spring Cloud 的分布式架构，那么也带来了线程安全问题，在高并发的情况下如果不加锁就会有问题，而传统的加锁方式只针对单一架构，对于分布式架构是不适合的，这时就需要用到分布式锁。 - 领导选举和集群状态
在一个ZooKeeper集群中，只能存在一个Leader，这个Leader是集群中事务请求唯一的调度者和处理者，所谓事务请求是指会改变集群状态的请求；Leader根据事务ID可以保证事务处理的顺序性。 - 分布式消息传递
消息总线是一种通信工具，可以在机器之间互相传输消息、文件等，他扮演着一种消息路由的角色，拥有一套完备的路由机制来决定消息传输方向。发送端只需要向消息总线发出消息，而不用管消息被如何转发。
3.Spring Cloud技术图谱
3.Spring Cloud服务治理
服务治理是微服务架构中核心模块，它主要用来实现各个微服务实例的自动化注册、发现、续约和销毁。
Spring Cloud Eureka是Spring Cloud Netflix微服务套件中的一部分，它基于Netflix Eureka做了二次封装。主要负责完成微服务架构中的服务治理功能。
- Eureka服务器
服务消费者和提供者都要在该服务器上注册，只有在这个服务器上注册的才可以相互进行数据交流 - 服务消费者
调用方，例如查看订单下的所有商品，现在订单系统是一个服务器，商品系统是一个服务器；我只能拿到订单号，找到订单下的商品id，得到商品信息，只有拿着这些商品id去商品服务商找商品 - 服务提供者
被调用方，提供商品服务，为订单系统调用提供数据
4.Spring Cloud Eureka
Eureka是Netflix开源的服务发现组件，本身是一个基于REST的服务。它包含Server和Client两部分。Spring Cloud将它集成在子项目Spring Cloud Netflix中，从而实现微服务的注册与发现。
总结
本文简单总结了微服务以及SpringCloud中的架构，具体的知识还有很多要学习。