SpringCloud入门

分布式

什么是分布式架构

分布式系统（distributed system） 是建立在网络之上的软件系统。

内聚性：是指每一个数据库分布节点高度自治，有本地的数据库管理系统。

透明性：是指每一个数据库分布节点对用户的应用来说都是透明的，看不出是本地还是远程。

在分布式数据系统中，用户感觉不数据是分布的，即用户不须知道关系是否分割，有无副本，数据存在于那个站点以及事物在哪个站点上执行。

简单来说：在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。

比如说原来我们有一个系统，有100万行代码。现在拆分成20个小系统，每个小系统仅剩5万行代码。

原本代码之间都是直接基于Spring框架走JVM内存调用，现在拆分后，将20个小系统部署在不同的机器上，然后基于分布式服务框架（比如dubbo）搞一个rpc调用，接口与接口之间通过网络通信进行请求和响应。

分布式系统大概可以分成两类。

1.底层的分布式系统

比如hadoop hdfs（分布式存储系统）、spark（分布式计算系统）、storm（分布式流计算系统）、elasticsearch（分布式搜索系统）、kafka（分布式发布订阅消息系统）等。

2、分布式业务系统

分布式业务系统将原来用java开发的一大块系统，给拆分成多个子系统，多个子系统之间互相调用，形成一个大系统的整体。

假设原来做了一个OA系统，里面包含了权限模块、员工模块、请假模块、财务模块等，一个工程，里面包含了一堆模块，模块与模块间会相互调用，1台机器部署。

现在你将这个系统拆分为，权限系统、请假系统、员工系统、财务系统，4个系统，4个工程，分别在4台机器上部署。

然后用户一个请求过来，要完成这个请求，员工系统去调用权限系统，调用请假系统，调用财务系统，4个系统分别完成了一部分事情。

最后4个系统都干完后，才认为这个请求已经完成，这就是所谓的分布式系统。

分布式架构的意义

造成的问题：

首先是项目工程无节制的变得臃肿庞大，今天增加一个业务，明天扩展一个模块，系统复杂度增加，大几十万行代码，几十个开发人员，service层，dao层代码大量被copy使用，经常有各种代码合并冲突要处理，非常耗时间。

每次发布都是几十万行代码的系统一起发布，几十万行代码的上线每次要做很多检查，需要处理很多异常问题，每个人都高度紧张，

而且我现在有个新业务，打算把相关依赖升级一下，比如升级到最新的spring版本，还不行，因为可能会导致别人的代码报错，不敢随便改技术。并且一个web工程每次启动都需要好几分钟时间，本地IDE里面调试一次代码都很痛苦。

其次随着用户访问流量的增加，系统负载压力加大，变得不堪重负，通过增加实例数，增加硬件扩容能够带来的效果已经微乎其微，故障频发，效率低下。系统质量也越来越难以保证，测试周期也变得越来越长，无法满足公司业务的发展需要。

总的来说，问题主要体现在以下几个方面：

1、应用代码耦合严重，功能难以扩展;

2、新需求开发交付周期延长，测试工作量大；

3、新加入团队的成员需要很长时间才能熟悉系统；

4、升级维护也很困难（改动任何一点地方都需要升级整个系统）

5、系统性能提升艰难，可用性低，不稳定

系统拆分后带来的好处：

百万行代码拆分成20个服务子系统，平均每个服务也就5万行代码，每个服务部署到单独的机器上，20个工程就用20个git仓库代码，20个开发人员，每个人维护自己那个服务就可以。

1、自己维护自己的代码，再也不需要考虑代码冲突；

2、每次只需要测试自己的代码就好了；

3、每次修改后只需要发布自己的服务就可以；

4、技术上可以随心所欲的升级，保持接口定义不变，输入输出不变就好；

三、系统如何拆分 一般来说要将系统进行拆分，首先要对系统整体比较熟悉。可以采用多轮拆分的思路，第一次拆分就是将以前各模块粗粒度的拆分开来。

比如一个电商系统就可以拆分成订单系统、商品系统、店铺系统、会员系统、促销系统、支付系统等。

后面可能每个系统又变的复杂，比如说订单系统又可以拆分成购物车系统，库存系统，价格系统等。

微服务

什么是微服务？

微服务架构（也可简称为微服务）是一种依赖于一系列可独立部署服务的架构方法。这些服务有自己的业务逻辑和数据库，并负责实现特定的目标。更新、测试、部署和扩展都在每一项服务中进行。微服务可将特定于领域的主要业务问题分解为单独的独立代码库。微服务不会降低复杂性，但它们可将任务划分成彼此独立运行且对整体有益的较小流程，从而使任何复杂情况都变得一目了然且更易管理。

微服务的优点

敏捷 — 提倡通过小型团队进行敏捷开发，频繁地进行部署。

灵活扩展 — 如果某一微服务达到负载容限，可将该服务的新实例快速部署到相关集群，以帮助缓解压力。我们现在采用多租户和无状态结构，客户分散在多个实例上，而且也能支持规模大得多的实例。

持续部署 — 我们现在拥有频繁且更快的发布周期。原先是每周推出一次更新，现在则可做到每天大约两三次。

高可维护性和可测试性 — 团队可以试验新的功能，并在出现状况时回滚。这样，代码更新变得更加轻松，新功能的面市时间也得以加快。此外，还可以轻松隔离和修复各项服务中的错误和漏洞。

独立部署 — 由于微服务是单独的单元，因此能够快速、轻松地独立部署各个功能。

技术灵活 — 微服务架构允许团队自由选择所需的工具。

高度可靠 — 您可以为特定服务部署更改，而不必担心要关闭整个应用。

微服务的缺点

开发蔓延 — 与单体式架构相比，微服务会导致复杂性上升，因为多个团队会在更多地方创建更多服务。开发蔓延若管理不当，则会导致开发速度减慢和运营绩效降低。

基础架构成本呈指数级增长 — 每项新的微服务都有自己的成本，例如在测试套件、部署手册、托管基础架构和监控工具等方面。

组织开销增多 — 团队需要额外的通信和协作来协调更新和交互。

调试挑战 — 每个微服务都有自己的一组日志，从而使调试变得更加复杂。此外，单个业务流程可能会在多个计算机上运行，从而进一步加大调试复杂度。

欠缺标准化 — 若无一个通用平台，语言、日志记录标准和监控手段便可能会激增。

缺少明确责任 — 当推出的服务增多后，运行这些服务的团队数量也会增加。随着时间推移，便难以清晰掌握团队有哪些服务可供使用，以及与谁联系来获得支持。

SpringCloud

我觉着SpringCloud就是一个分布式微服务架构的一站式解决方案，它提供了很多组件用来解决了分布式架构所带来的一些问题。 Eureka[优瑞卡]、Ribbon[瑞本]、Feign[菲恩]、Hystrix[黑丝锤科丝]，Zuul[入欧]这么几个组件。其中 Eureka在整个微服务架构中充当注册中心的角色，服务提供者将自身信息注册到Eureka Server[涩沃]中，然后服务消费者就可以从Eureka Server中获取注册的服务提供者的信息，然后就可以向服务提供者发起调用了。 Ribbon实现了客户端的负载均衡，它提供了轮询、轮询权重、随机等一些常用的负载均衡策略。 Feign我理解的就是简化服务之间的调用，让我们调用远程接口就像在调用本地方法一样。 Hystrix的主要功能就是服务熔断、降级和资源隔离，用来保护我们的调用链路，避免发生服务雪崩问题。 Zuul在整个微服务架构中充当服务网关的角色，提供请求转发和过滤的功能，可以在服务网关中实现统一身份验证、统一跨域请求处理等功能。

CAP原则

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错（Partition-tolerance）。在一个分布式系统中三个要素不可同时具有，只能选择其中两个。

一致性（Consistency）

在分布式系统中，所有节点在同一时刻的数据都是一致的。

可用性（Availability）

在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。即每个请求不管成功与否都能得到响应。

分区容错（Partition-tolerance）

保证系统中任意信息的丢失都不会影响系统的运行。

一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。

AP

保持可用性和分区容错。如果选择分区容错性和可用性，当节点损坏时，遇到分区事件，受影响的服务不需要等待数据一致，就可以对外提供服务，保证了可用性就必须放弃一致性。

CP

保证一致性和分区容错。如果选择分区容错性和一致性，为保证一致性，各个节点之间的数据必须保持一致，当出现分区时，会导致同步时间无限延长，在同步的这段时间就无法对外提供服务，就无法保证可用性。

CA

保持一致性的同时保证可用性，这在分布式系统中是不存在的，因为分区问题总是会出现在分布式系统中。出现分区就必然会产生一致性问题和可用性问题，一致性和可用性两者只能选其一。

nacos和eureka的区别

服务注册与发现是云原生微服务架构中的基本组成部分。服务发现旨在让各个组件可以自动化地发现和使用彼此，从而使微服务架构更加灵活和可扩展。Nacos和Eureka都是可用于服务注册与发现的开源框架，以下是它们之间的一些区别：

主要区别：

接口方式:

Nacos与Eureka都对外暴露了Rest风格的API接口，用来实现服务注册、发现等功能

实例类型:

Nacos的实例有永久和临时实例之分;而Eureka只支持临时实例

健康检测:

Nacos对临时实例采用心跳模式检测，对永久实例采用主动请求来检测:Eureka只支持心跳模式

服务发现:

Nacos支持定时拉取和订阅推送两种模式;Eureka只支持定时拉取模式

其他区别

语言支持

Eureka是Netflix开发的，主要用于Java语言的服务治理。虽然Eureka也支持其他语言，但具体实现需要一些额外的工作量，因此它的语言支持范围相对较窄。

Nacos是由阿里巴巴开发的，支持多种主流编程语言（包括Java、Go、Python等），并提供了一系列的SDK和API，以方便各种语言的客户端进行接入。

功能特性

Eureka最初是专为服务注册与发现而开发的，因此它主要支持服务注册和服务发现一类的功能。它通过心跳机制来保持实例在线和更新实例状态，通过客户端请求来快速地进行服务发现。

Nacos则不仅仅在服务发现方面进行了深入的探索，还提供了配置管理、DNS服务、流量管理等一系列的功能。Nacos也支持动态配置管理、弹性伸缩、测试验证等特性，全面满足了微服务体系中各种类型的需求。

高可用性

Eureka需要依赖第三方组件（如Zookeeper）才能实现分布式，从而保证高可用性。而Nacos可以在本身作为分布式部署的同时，提供更加完备和丰富的可用性方案。例如，Nacos通过多副本机制和故障转移方式来保证服务的高可靠性。

运维管理

Eureka的维护和管理都是通过REST API实现的。对于初学者而言，需要一定的技术学习和操作经验。而Nacos提供了更加友好和便捷（包括命令行以及可视化界面）的管理功能，让企业和运维人员可以更加容易地完成服务的管理和维护。

生态圈支持

在生态圈的支持方面，两者都有相应的应用场景和使用者。由于Eureka诞生较早，因此它在Netflix内部生成了一系列商业项目，比如Zuul、Hystrix等。Nacos则在阿里巴巴内部得到了广泛的使用，同时也正在不断地推向开源社区并进行开源应用和解决方案的培育。