马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。
您需要 登录 才可以下载或查看，没有账号？立即注册
x
一、架构演变
- 从单机结构到集群结构，你的代码根本无需要作任何修改，你要做的仅仅是多部署几台服务器，每台服务器上运行相同的代码就行了。
- 但是，当你要从集群结构演进到微服务结构的时候，之前的那套代码就需要发生较大的改动了。
- 所以对于新体系我们建议，体系设计之初就采用微服务架构，这样后期运维的成本更低。
- 但假如一套老体系需要升级成微服务结构的话，那就得对代码大动干戈了。所以，对于老体系而言，毕竟是继续保持集群模式，还是升级成微服务架构，这需要你们的架构师深图远虑、权衡投入产出比。
二、集群
步调单机处理达到瓶颈时，就将步调部署在多台服务器上，这样就构成了一个“集群”。集群中的每台服务器是这个集群的一个节点。每台机器都提供相同的服务，这样体系的处理本领就相同于提拔了好几倍
一）集群分为三种类型
1、LB：Load Balancing：负载均衡，多个主机构成，每个主机只承担一部分的访问请求
2、HA：High Availiablity：高可用，避免单点故障SPOF（single point of failure）
- MTBF：mean time between failure 匀称无故障时间，正常时间
- MTTR：mean time to restoration（repair）匀称恢复前时间，故障时间
- A = MTBF / (MTBF+MTTR ) （0,1）: 99%,99.5%,99.9%,99.99%,99.999%
SLA：服务等级协议（全称：service level agreement） 是在肯定开销下为保障服务的性能和可用性，服务提供商与用户界说的一种两边认可的协定。这个开销是驱动提供服务质量的主要因素。在常规的领域中，总是设定所谓的三个9，四个9举行表示，当没有达到这种水平的时候，就会有一些列的惩罚步伐。而运维的目的就是达成这种服务水平。
停机时间又分为两种，一种是筹划内停机时间，一种是筹划外停机时间。而运维主要关注筹划外停机时间。
3、HPC：high-performance computing 高性能
三、分布式
一）分布式体系
1、分布式结构概述
分布式结构就是将一个完整的体系，按照业务功能，拆分成一个个独立的子体系，在分布式结构中，每个子体系就被称为“服务”。这些子体系可以或许独立运行在web容器中，它们之间通过RPC方式通信。
2、分布式常见应用
- 分布式应用：服务按照功能拆分，使用微服务
- 分布式静态资源：静态资源放在不同的存储集群上
- 分布式数据和存储：使用key-value缓存体系
- 分布式计算：对特殊业务使用分布式计算，好比Hadoop集群
二）留意事项
1、留意事项
分布式不肯定就是不同的组件，同一组件也可以，关键在于是否通过交换消息的方式举行协作；分布式体系也可以是一个集群
例如：zookeeper的节点都是对等的，但它自己构成了一个分布式体系。
2、举例说明
举个例子，假设需要开辟一个在线商城。按照微服务的头脑，我们需要按照功能模块拆分成多个独立的服务，如：用户服务、产品服务、订单服务、配景管理服务、数据分析服务等等。这一个个服务都是一个个独立的项目，可以独立运行。假如服务之间有依赖关系，那么通过RPC方式调用。
三）分布式的好处
- 体系之间的耦合度大大降低，可以独立开辟、独立部署、独立测试，体系与体系之间的界限非常明确，排错也变得相当容易，开辟效率大大提拔。
- 体系之间的耦合度降低，从而体系更易于扩展。我们可以针对性地扩展某些服务。假设这个商城要搞一次大促，下单量可能会大大提拔，因此我们可以针对性地提拔订单体系、产品体系的节点数量，而对于配景管理体系、数据分析体系而言，节点数量维持原有水平即可。
- 服务的复用性更高。好比，当我们将用户体系作为单独的服务后，该公司所有的产品都可以使用该体系作为用户体系，无需重复开辟。
四）分布式的实现
分布式的核心就一个字：拆。只要是将一个项目拆分成了多个模块，并将这些模块分开部署，那就算是分布式。（分布式拆了就行）
如何拆呢？有两种方式：水平拆分，垂直拆分（也称为“横向拆分”和“垂直拆分”）
1、水平拆分
根据“分层”的头脑举行拆分。例如，可以将一个项目根据“三层架构”拆分成 表示层（jsp+servlet）、业务逻辑层（service）和数据访问层（dao），然后再分开部署
2、垂直拆分
根据业务举行拆分。例如，可以根据业务逻辑，将“电商项目”拆分成“订单项目”、“用户项目”和“秒杀项目”。显然这三个拆分后的项目，仍然可以作为独立的项目使用。像这种拆分的方法，就成为垂直拆分。
四、微服务
微服务就黑白常微小的服务。微服务可以理解为非常细粒度的垂直拆分。
微服务架构是一种现代软件开辟方法，它将大型应用步调拆分成一组小型、独立的服务，每个服务运行在其独立的进程中，服务之间通过轻量级通信机制（通常是HTTP REST API或RPC）相互通信。这种方法夸大松耦合、高内聚的设计原则，以支持敏捷开辟、持续交付和体系的可伸缩性。
一）微服务的起源与理念
微服务架构的概念最早由马丁·福勒（Martin Fowler）等人在2014年提出，是对传统单体架构的一种进化。
在单体架构中，所有功能模块紧密集成在一起，形成一个巨大的代码库，这导致开辟效率降低、部署复杂度增加以及难以扩展等问题。
相比之下，微服务架构则通过将体系分解为一系列小服务来应对这些挑战，每个服务专注于实现一种业务功能，并且可以独立部署、扩展和维护。
二）微服务的核心特性
- 服务组件化：每个微服务都是一个围绕业务本领构建的自治单元，负责一项详细的功能，如用户管理、订单处理等。这种设计促进了代码的模块化和重用。
- 去中央化治理：微服务架构鼓励服务之间的去中央化管理和治理，即每个服务团队对自己的服务拥有完全的控制权，包括技术选型、部署策略等。
- 接口标准化：固然服务间是松耦合的，但为了包管它们可以或许高效协作，通常会界说一套通用的API协议或消息格式，如RESTful API、gRPC等。
- 底子设施自动化：鉴于微服务数量众多，手动部署和运维变得不可行，因此需要依赖自动化工具和DevOps实践，如持续集成/持续部署（CI/CD）、容器编排（如Kubernetes）来提拔效率。
- 容错与弹性设计：微服务架构夸大构建具有弹性和容错性的体系，这意味着每个服务需要设计为能独立失败，而不影响整个体系运行。通过服务间熔断、健康检查、自动重试等机制来实现这一点。
三）实行微服务的挑战
- 分布式体系的复杂性：随着服务数量的增加，跟踪、监控和调试的难度也会增大，需要采用分布式追踪、日志聚合等技术来管理。
- 数据同等性：在分布式环境中维护数据同等性是一个挑战，通常需要采用事件驱动架构、Saga事件模式或最终同等性策略。
- 服务划分：精确划分服务界限是关键，需要根据业务领域、团队结构、技术栈等多种因素综合考虑。
- 安全性：每个服务都是潜在的攻击面，因此需要实行细粒度的安全控制，如API网关、OAuth2、JWT令牌等。
四）乐成实行微服务的关键实践
- 持续交付：确保快速、可靠地发布新功能和修复，减少发布周期。
- 自动化测试：全面覆盖单元测试、集成测试和端到端测试，保障服务质量和稳固性。
- 服务注册与发现：利用服务注册中央（如Eureka、Consul）来动态管理服务实例的位置信息，便于服务间的发现和通信。
- 配置管理：使用会合式配置管理（如Spring Cloud Config）来统一管理各个服务的配置，提高灵活性和同等性。
- 监控与日志：实行全面的监控体系，包括性能指标监控、日志网络分析、链路追踪等，确保体系健康可见。
五、简述集群、分布式和微服务的区别与关系
一）集群
集群的意义在于利用多个服务器实现统一业务来提高运行效率
例如：一个任务需要消耗一台服务器一个小时，四个服务器一起运行运行，只需要一个小时
二）分布式
分布式的意义在于把不同的业务分配给不同的服务器来完成，实现多服务器共同工作的效果，提高运行效率
例如：一个产品有A+B+C+D四个子业务，每个业务耗时一台服务器一个小时，一台服务器需要1*4=4个小时
使用分布式，不考虑各个服务器之间的通信时间等消耗，只需要1个小时
三）微服务
微服务是一种架构风格
分布式和微服务很像，把一个体系的业务拆分成多个独立的服务，体系中的各个微服务的各个微服务可以独立部署，各个服务之间松耦合的
微服务的设计是为了不因为某个模块的bug影响现有的体系业务。
微服务与分布式的渺小差别是：微服务的应用不肯定是分散在多个服务器上，他可以是同一服务器。
严格来说：分布式是也是一种微服务，但是微服务不肯定是分布式
四）总结
- 集群：多个服务器部署相同的模块，干相同的事
- 分布式：多个服务器部署多个子模块，分别干不同的事
- 微服务：不肯定是多个服务器，可能在一个服务器上，部署多个子模块分别干不同的事
- 好的设计应该是分布式和集群的团结，先分布式再集群
- 详细实现就是业务拆分成多个子业务，然后针对每个子业务举行集群部署
- 好处：每个子业务若出了问题，整个体系完全不会受影响
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
