集群、分布式和微服务

一、架构演变

• 从单机结构到集群结构，你的代码基本无需要作任何修改，你要做的仅仅是多部署几台服务器，每台服务器上运行相同的代码就行了。
• 但是，当你要从集群结构演进到微服务结构的时候，之前的那套代码就需要发生较大的改动了。
• 所以对于新系统我们建议，系统设计之初就采用微服务架构，这样后期运维的成本更低。
• 但如果一套老系统需要升级成微服务结构的话，那就得对代码大动干戈了。所以，对于老系统而言，究竟是继续保持集群模式，还是升级成微服务架构，这需要你们的架构师深思熟虑、权衡投入产出比。

二、集群

　　程序单机处理达到瓶颈时，就将程序部署在多台服务器上，这样就构成了一个“集群”。集群中的每台服务器是这个集群的一个节点。每台机器都提供相同的服务，这样系统的处理能力就相同于提升了好几倍

  一）集群分为三种类型

　　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年提出，是对传统单体架构的一种进化。

        在单体架构中，所有功能模块紧密集成在一起，形成一个庞大的代码库，这导致开发效率降低、部署复杂度增加以及难以扩展等问题。

        相比之下，微服务架构则通过将系统分解为一系列小服务来应对这些挑战，每个服务专注于实现一种业务功能，并且可以独立部署、扩展和维护。

  二）微服务的核心特征

1. 服务组件化：每个微服务都是一个围绕业务能力构建的自治单元，负责一项具体的功能，如用户管理、订单处理等。这种设计促进了代码的模块化和重用。
2. 去中心化治理：微服务架构鼓励服务之间的去中心化管理和治理，即每个服务团队对自己的服务拥有完全的控制权，包括技术选型、部署策略等。
3. 接口标准化：虽然服务间是松耦合的，但为了保证它们能够高效协作，通常会定义一套通用的API协议或消息格式，如RESTful API、gRPC等。
4. 基础设施自动化：鉴于微服务数量众多，手动部署和运维变得不可行，因此需要依赖自动化工具和DevOps实践，如持续集成/持续部署（CI/CD）、容器编排（如Kubernetes）来提升效率。
5. 容错与弹性设计：微服务架构强调构建具有弹性和容错性的系统，这意味着每个服务需要设计为能独立失败，而不影响整个系统运行。通过服务间熔断、健康检查、自动重试等机制来实现这一点。

  三）实施微服务的挑战

1. 分布式系统的复杂性：随着服务数量的增加，跟踪、监控和调试的难度也会增大，需要采用分布式追踪、日志聚合等技术来管理。
2. 数据一致性：在分布式环境中维护数据一致性是一个挑战，通常需要采用事件驱动架构、Saga事务模式或最终一致性策略。
3. 服务划分：正确划分服务边界是关键，需要根据业务领域、团队结构、技术栈等多种因素综合考虑。
4. 安全性：每个服务都是潜在的攻击面，因此需要实施细粒度的安全控制，如API网关、OAuth2、JWT令牌等。

  四）成功实施微服务的关键实践

• 持续交付：确保快速、可靠地发布新功能和修复，减少发布周期。
• 自动化测试：全面覆盖单元测试、集成测试和端到端测试，保障服务质量和稳定性。
• 服务注册与发现：利用服务注册中心（如Eureka、Consul）来动态管理服务实例的位置信息，便于服务间的发现和通信。
• 配置管理：使用集中式配置管理（如Spring Cloud Config）来统一管理各个服务的配置，提高灵活性和一致性。
• 监控与日志：实施全面的监控体系，包括性能指标监控、日志收集分析、链路追踪等，确保系统健康可见。

五、简述集群、分布式和微服务的区别与关系

  一）集群

　　集群的意义在于利用多个服务器实现统一业务来提高运行效率

　　例如：一个任务需要消耗一台服务器一个小时，四个服务器一起运行运行，只需要一个小时

  二）分布式

　　分布式的意义在于把不同的业务分配给不同的服务器来完成，实现多服务器共同工作的效果，提高运行效率

　　例如：一个产品有A+B+C+D四个子业务，每个业务耗时一台服务器一个小时，一台服务器需要1*4=4个小时
　　使用分布式，不考虑各个服务器之间的通信时间等消耗，只需要1个小时

  三）微服务

　　微服务是一种架构风格

　　分布式和微服务很像，把一个系统的业务拆分成多个独立的服务，系统中的各个微服务的各个微服务可以独立部署，各个服务之间松耦合的

　　微服务的设计是为了不因为某个模块的bug影响现有的系统业务。

　　微服务与分布式的细微差别是：微服务的应用不一定是分散在多个服务器上，他可以是同一服务器。

　　严格来说：分布式是也是一种微服务，但是微服务不一定是分布式

  四）总结

• 集群：多个服务器部署相同的模块，干相同的事
• 分布式：多个服务器部署多个子模块，分别干不同的事
• 微服务：不一定是多个服务器，可能在一个服务器上，部署多个子模块分别干不同的事
• 好的设计应该是分布式和集群的结合，先分布式再集群
  • 具体实现就是业务拆分成多个子业务，然后针对每个子业务进行集群部署
  • 好处：每个子业务若出了问题，整个系统完全不会受影响