分布式、微服务、集群

最新推荐文章于 2023-10-28 18:07:27 发布

JarvanBest

最新推荐文章于 2023-10-28 18:07:27 发布

阅读量69

点赞数

文章标签： Java

本文链接：https://blog.csdn.net/Jarvanxy/article/details/132236906

版权

集群

描述

集群是指将多台服务器集中在一起，每台服务器都实现相同的业务，做相同的事情。

优势

每台服务器并不是缺一不可，存在的作用主要是缓解并发压力和单点故障转移问题。我们可以利用一些廉价的符合工业标准的硬件构造高扩展、高性能、低成本、高可用的系统。

特性

伸缩性-Scalability
- 一组服务器组在一起，像单个服务器一样分担处理一个繁重的任务，我们只需要将新的服务器加入集群中即可；
高可用性-High availability
- 集群的出现就是为了使集群的整体服务尽可能可用，以便考虑计算硬件和软件的易错性，避免单点失效发生；
负载均衡-Load balancing
- 均衡的应用程序处理负载或网络流量负载，使负载可以在计算机集群中尽可能平均地分摊处理。
高性能-High Performance
- 并行计算（或称平行计算）是相对于串行计算来说的，并行计算能力的目的是用来提高计算速度。

缺点

当应用出现故障需要重新修复运转时，其他服务器会接管该应用的数据区，而这个接管过程却需要消耗一些时间，应用越大，接管时间越长，会造成一定的延误。

一句话总结

复制部署，能力一致，目的是实现：伸缩性、高可用、负载均衡和高性能；

分布式

描述

分布式服务是指将多台服务器集中在一起，服务是分散部署在不同的机器上的。

每台服务器都实现总体中的不同业务，做不同的事情。一个服务可能负责几个功能，是一种面向 SOA 的架构。各分开部署的部分彼此通过各种通讯协议交互信息，并且每台服务器都缺一不可，如果某台服务器故障，则部分功能缺失，或导致整体无法运行。

优点

1、增大系统容量。我们的业务量越来越大，而要能应对越来越大的业务量，一台机器的性能已经无法满足了，我们需要多台机器才能应对大规模的应用场景。所以，我们需要垂直或是水平拆分业务系统，让其变成一个分布式的架构
2、加强系统可用。我们的业务越来越关键，需要提高整个系统架构的可用性，这就意味着架构中不能存在单点故障。这样，整个系统不会因为一台机器出故障而导致整体不可用。所以，需要通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用性。
3、因为模块化，所以系统模块重用度更高
4、因为软件服务模块被拆分，开发和发布速度可以并行而变得更快
5、系统扩展性更高、团队协作流程也会得到改善

特性

分布式存在的主要作用是大幅度的提高效率，缓解服务器的访问和存储压力。区别分布式的方式是一个业务分拆多个子业务，部署在不同的服务器上。

缺点

1、架构设计变得复杂（尤其是其中的分布式事务）
2、部署单个服务会比较快，但是如果一次部署需要多个服务，部署会变得复杂
3、系统的吞吐量会变大，但是响应时间会变长
4、运维复杂度会因为服务变多而变得很复杂
5、架构复杂导致学习曲线变大
6、测试和查错的复杂度增大
7、技术可以很多样，这会带来维护和运维的复杂度
8、管理分布式系统中的服务和调度变得困难和复杂

一句话总结

分散部署，是一种面向 SOA 的架构，服务分散部署在不同的机器上，实现不同业务，做不同的事情。

微服务

描述

微服务就是很小的服务，小到一个服务只对应一个单一的功能。每个微服务仅关注于完成一件任务并很好地完成该任务，这个服务可以单独部署运行。各个微服务之间是松耦合的，服务之间可以通过 RPC 来相互交互。每个微服务都是由独立的小团队开发、测试、部署，上线，负责它的整个生命周期。

优点

微服务是松藕合的，无论是在开发阶段或部署阶段都是独立的。
开发简单、开发效率提高，一个服务可能就是专一的只干一件事, 能够被小团队单独开发，这个小团队可以是 2 到 5 人的开发人员组成。
每个微服务都很小，足够内聚，足够小，代码容易理解。团队能够更关注自己的工作成果, 聚焦指定的业务功能或业务需求。
能够快速响应, 局部修改容易, 一个服务出现问题不会影响整个应用。
易于和第三方应用系统集成, 支持使用不同的语言开发, 允许你利用融合最新技术。

特性

组件化
- 服务粒度要小，而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情。
松耦合
- 每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。
- 技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。相对单体架构，微服务架构是更面向业务创新的一种架构模式。
自治\去中心化
- 团队对服务的整个生命周期负责，工作在独立的上下文中，自己决策自己治理，而不需要统一的指挥中心。

缺点

1、团队沟通的过载：微服务架构降低了团队管理的难度，但是确不能降低团队沟通的需求。研发人员需要确保一个服务中的更新不会破坏其它功能。我们在单体应用中也会发现类似问题，但是微服务架构的应用这个问题会更加明显
2、正式文档的过载：每一个独立的运行部件需要持续维护其规格和接口文档，这些文档是其它团队使用这些部件的必要条件。
3、不一致性的应用：我们可以为每一个组件选择不同的技术栈。这导致了不一致的应用设计和架构，而这会在更长期的运维期间增加系统维护成本。
4、DevOps的复杂度：我们需要拥有一支成熟的DevOps团队去处理微服务架构的应用的复杂性。由于多个应用存在多个活动部件，这种复杂度需要有高水平的经验。
5、增加了资源使用：运行这些微服务架构的应用的初始投资会比较大，因为所有微服务应都需要拥有他们自己的运行容器，这也需要更多的CPU和内存。另外采用了中间件也会带啦一个比较大的基座投资。
6、增加了网络通信开销：分布式系统的产生的网络开销比单机应用多很多，不能简单把内部调用简单改为分布式调用，吃亏很大。微服务架构下，独立运行的组件都需要通过网络进行互相通信。这中系统需要有更加可靠和快速的网络连接。
7、网络安全：通过网络进行通信的系统更容易产生安全缺陷。
8、测试：测试微服务架构的应用绝对比单体应用难很多，深有体会，集成测试过程是一场噩梦。
9、产品监控：监控微服务架构应用的成本会更高，很难获得合适的工具，自研的成本也很高。