1、架构-服务架构演进史

架构演进史

1. 原始分布式时代

这个阶段发生在20世纪70年代末到80年代初，当时的计算机科学从以大型机为主转向以微型机为主。在这个时期，由于单台计算机的处理能力有限，计算机科学家开始尝试使用多台计算机共同协作来支撑更大的软件系统。这些早期的分布式尝试，包括惠普的网络运算架构、卡内基·梅隆大学的AFS（Andrew File System）等，都是对分布式计算的初步探索。

2. 单体系统时代

随着摩尔定律的实现和微型计算机性能的飞速提升，单体架构开始成为主流。在这个时代，大型信息系统常常是由单台或少数几台计算机支撑的，采用单体架构。单体架构简单易于开发和维护，但当应用规模扩大时，其缺陷也逐渐显现，尤其是在系统扩展性和灵活性方面。

3. SOA时代

服务导向架构（SOA）提供了一种新的设计和实现大型企业系统的方法，通过将应用划分为松耦合的服务，每个服务执行特定的业务功能。SOA架构使得系统更加灵活，易于扩展和维护，但实现和管理复杂度较高。

4. 微服务时代

微服务架构是SOA的进一步发展，它推崇将应用拆分成更细粒度的服务。每个微服务独立运行在自己的进程中，独立部署，通过轻量级通信机制互相协作。微服务架构提高了系统的可扩展性和可靠性，使得各个组件可以独立更新，降低了系统整体的风险。

5. 后微服务时代

在微服务架构成熟之后，业界开始探索更加灵活的架构风格，如无服务器架构。这种架构进一步简化了开发和运维的复杂度，开发者无需关心服务器和运行时环境，只需要专注于业务逻辑的编写。

6.无服务时代

无服务架构（Serverless）是指应用的业务逻辑运行在由第三方管理的运行时环境中，完全抽象化了服务器的概念。这种架构使得开发者可以更加专注于代码的编写和业务逻辑的实现，而无需关心底层的硬件和系统运维问题。

对比学习与思考

1、soa和微服务区别

SOA:

服务导向架构（SOA，Service-Oriented Architecture）是一种软件设计风格，它允许服务间通过网络接口相互作用和通信。SOA的主要目标是提高业务灵活性和可重用性，通过将复杂的应用程序分解为独立的、功能性的模块------通常称为"服务"------来实现。这些服务通常通过网络协议相互作用，例如HTTP，实现松散耦合。

SOA的核心思想

1. 松散耦合：服务之间的依赖最小化，各个服务之间保持相对独立，使得每个服务可以独立开发、测试、部署和更新。
2. 服务重用：在SOA架构中，服务是通用的，可以被多个不同的业务流程或业务功能复用。
3. 抽象：服务隐藏了其后台的逻辑过程，只通过暴露的接口进行通信，这样用户不需要了解服务内部的实现细节。
4. 可组合性：由于服务是独立的，它们可以按照需要组合，支持快速的业务变化和新服务的创建。
5. 自治：每个服务管理其自身的逻辑和数据，确保服务的封装性和独立性。
6. 可发现的：服务可以被描述、发布、发现，并通过网络调用，通常配合使用服务目录来实现。

具体的架构模式

SOA不是指具体的技术实现，而是一种设计原则和架构方法。它可以通过不同的技术和模式实现，包括但不限于以下几种：

1. 基于消息的SOA：

   • 在这种模式下，服务通过消息传递系统交换数据，如使用消息队列（MQ）。
   • 消息可以是同步的或异步的，支持服务之间的松散耦合和可靠通信。

2. 基于事件的SOA：

   • 服务之间通过事件来进行交互，一个服务的输出事件可以触发另一个服务的处理逻辑。
   • 这种模式强调了响应性和非阻塞行为，适用于需要高响应性的系统。

3. 基于Web服务的SOA：

   • 使用Web服务标准（如SOAP和WSDL）来定义、发现和实现服务。
   • Web服务提供了一种跨平台和跨语言的方式来实现服务，可以通过HTTP进行交互。

4. 微服务架构：

   • 虽然微服务架构可以被视为SOA的一种现代化、更细粒度的实现，但它强调独立部署、技术多样性和微服务间的轻量级通信（通常是REST）。
   • 每个微服务都是围绕特定业务功能构建的，并且拥有独立的数据管理。

5. RESTful SOA：

   • 利用REST原则实现的SOA，使用简单的HTTP作为通信协议。
   • RESTful服务通常使用标准的HTTP方法（GET, POST, PUT, DELETE）来实现CRUD操作。

微服务

微服务架构（Microservices Architecture）是一种将单一应用程序划分成一组小的、自治的服务的架构风格。每个服务都围绕特定的业务功能构建，并且可以独立部署、独立扩展和独立开发。微服务与传统的单体应用相比，提供了更高的灵活性和可维护性，特别适合云计算环境。

微服务的核心特点

1. 服务自治：每个微服务都是自包含的，负责处理其定义的业务功能。它们通过定义良好的API与其他服务通信，从而减少服务间的直接依赖关系。

2. 分布式开发：微服务架构支持分布式的开发团队。不同的团队可以独立地开发、测试、部署和扩展他们的服务。

3. 去中心化数据管理：每个微服务管理其自己的数据库，这种数据的去中心化有助于服务的自治性，但也带来了数据一致性的挑战。

4. 容错性：微服务架构通过服务的隔离性增加了系统的整体容错性。单个服务的失败不应影响系统的其余部分。

5. 技术多样性：在微服务架构中，各个服务可以使用最适合其业务需求的语言和技术栈独立开发。

6. 可维护性和可测试性：较小的服务更容易理解、开发和测试。

7. 可扩展性：微服务可以根据需求独立地扩展。服务的使用率高的部分可以单独扩展，而不必扩展整个应用。

8. 持续交付和部署：微服务支持快速的、持续的软件交付和部署。新功能可以快速部署到生产环境中，而不会影响到其他服务的运行。

微服务架构模式

1. API网关：API网关是微服务架构中的一个核心模式，它处理所有客户端请求，向客户端提供API聚合服务，并将请求路由到后端的各个微服务。

2. 服务发现：在微服务架构中，服务可能会动态更改其位置。服务发现机制允许服务查询一个中心注册表，以找出其他服务的网络位置。

3. 断路器模式：断路器模式防止一个服务的故障连锁影响其他服务。如果服务检测到多次失败，断路器会打开，所有对该服务的调用会自动失败，而不会执行实际的调用。

4. 外部配置管理：微服务可以从外部源动态加载配置信息。这使得服务可以在不重新部署的情况下适应环境变化。

5. 日志和跟踪：由于系统中存在大量服务，因此集中式日志记录和跟踪请求跨服务流转变得非常重要。

微服务架构的采用在许多技术公司中已成为标准实践，特别是对于那些需要快速迭代、支持多种技术栈，并且要求高可用性和可扩展性的组织。然而，微服务也带来了管理复杂性、服务间通信的开销和一致性维护的挑战，因此在采用之前需要仔细权衡其优势和缺点。

区别：

SOA（服务导向架构）和微服务都是服务基础的架构风格，都旨在通过将大型复杂的应用分解为可以独立开发、部署和维护的小型服务来提高软件的可管理性和可伸缩性。虽然它们有着类似的基本理念，但在实施方式、设计理念和技术重点上存在一些关键的区别：

1. 设计粒度

• SOA：通常面向企业级的服务，服务粒度相对较大，更侧重于整个业务流程的服务化。
• 微服务：强调更细粒度的服务划分，每个服务通常围绕单一业务功能构建，服务之间保持高度的自治和松散耦合。

2. 数据管理

• SOA：服务之间可能共享数据模型和数据库，更多地使用集中式的数据管理策略。
• 微服务：每个微服务管理自己的数据库，采用去中心化的数据管理，服务间不共享数据库，从而增强服务的独立性。

3. 技术异质性

• SOA：尽管SOA支持多种技术平台，但企业实践中常常因为整合需求而倾向于选择统一的技术栈和通信协议（如使用SOAP）。
• 微服务：鼓励技术多样性，不同的微服务可以使用不同的编程语言和数据存储技术，只需保持API接口的一致性即可。

4. 部署

• SOA：SOA的服务通常部署为一组较大的单元，每个服务可能包含多个较小的功能。
• 微服务：每个服务都是独立部署的，每个服务的更新和扩展不会影响到其他服务。

5. 通信方式

• SOA：倾向于使用企业服务总线（ESB）来进行服务间的复杂消息传递和转换。
• 微服务：推荐使用轻量级的HTTP/REST或者轻量级消息传递系统，如RabbitMQ或Kafka，避免使用重量级的ESB。

6. 业务重点

• SOA：重点在于可重用性，服务被设计为多个业务流程和不同应用之间的共享资源。
• 微服务：重点在于业务的敏捷性和独立性，服务的设计、开发、部署都旨在支持快速迭代和独立运行。

7. 目标

• SOA：主要目标是提高企业级应用的效率和灵活性，通过服务的重用减少重复劳动。
• 微服务：目标是提高软件开发的速度和可靠性，支持持续集成和持续部署（CI/CD）。

总结来说，尽管SOA和微服务都是服务化的架构风格，它们各有侧重点和应用场景。微服务可以被视为SOA概念的一个演进，更适合快速发展和高度动态的应用环境，而SOA更适合需要高度整合和重用的大型企业环境。

2、什么是后微服务时代

所谓的"后微服务时代"指的是在微服务架构广泛应用并成熟之后，行业开始探索更进一步的架构模式和技术，以解决微服务在实际应用中遇到的一些挑战，如服务管理的复杂性、数据一致性问题、服务间通信的开销等。在后微服务时代，人们探讨和采纳了一些新的概念和技术，以优化和超越传统微服务架构的限制。

主要特点和技术

1. 服务网格（Service Mesh）：

   • 服务网格技术，如Istio和Linkerd，提供了一个基础设施层，用于处理服务间的通信、监控和安全问题，而不需要改变服务的业务逻辑。这种模式允许开发者专注于业务功能，而将可观察性、可靠性和网络策略的实施交给服务网格来管理。

2. 无服务器架构（Serverless）：

   • 在无服务器架构中，开发者可以编写并部署代码，但不需要显式管理服务器。这种模式通常与事件驱动执行结合，如AWS Lambda、Azure Functions等平台所提供。无服务器架构进一步简化了运维工作，开发者只需关注代码逻辑，而底层的扩展、部署和维护都由云提供商自动管理。

3. 功能即服务（Function as a Service, FaaS）：

   • FaaS是无服务器架构的一部分，强调在事件触发时执行短暂、无状态的函数。它允许极端的弹性和自动扩展，非常适合处理高度动态的工作负载。

4. 边缘计算（Edge Computing）：

   • 随着IoT（物联网）和移动设备的普及，将计算任务从中心化的数据中心转移到离用户更近的边缘设备，可以减少延迟并提高应用响应速度。这种模式通常涉及到在多个位置分布式部署和管理服务。

5. 自动化和人工智能（AI）在运维中的应用（AIOps）：

   • 利用AI技术来自动化运维任务，如故障检测、系统修复和优化配置等，有助于管理大规模、复杂的服务架构。

结合现实的挑战

在后微服务时代，技术的选择和架构的设计更加注重可维护性、开发效率和自动化程度。这些新的技术和模式尝试解决微服务架构中的一些固有问题，如服务发现、服务间通信的复杂性和安全问题，同时也寻求减少运营成本和提高系统的可靠性。

后微服务时代不是取代微服务的一种技术，而是在微服务已经部署和运行的基础上，提供了新的优化和改进的方法。这个时代的技术和架构选择往往更具体化、专业化，需要根据具体的应用场景和业务需求来定制解决方案。

Kubernetes与传统Spring Cloud提供的解决方案对比

1. 弹性伸缩

   • Kubernetes: 支持自动伸缩（Autoscaling），能够根据应用的负载自动调整Pod数量。
   • Spring Cloud: 不提供内建的自动伸缩功能，通常需要外部的云服务或容器管理工具来实现。

2. 服务发现

   • Kubernetes: 使用KubeDNS或CoreDNS进行服务发现，自动解析服务名到Pod IP地址。
   • Spring Cloud: 通过Spring Cloud Eureka实现服务注册与发现，Eureka Server作为注册中心，各服务实例在启动时注册自己的位置信息。

3. 配置管理

   • Kubernetes: 使用ConfigMap和Secret来管理配置数据，可以将配置数据作为环境变量或文件挂载到容器中。
   • Spring Cloud: 利用Spring Cloud Config为微服务应用提供集中化的外部配置支持。

4. 服务网关

   • Kubernetes: 使用Ingress Controller来处理进入集群的外部请求，支持路由、负载均衡等功能。
   • Spring Cloud: 通过Spring Cloud Zuul作为API网关，处理路由及过滤功能，提供动态路由、监控、弹性伸缩等。

5. 负载均衡

   • Kubernetes: 内置负载均衡器，可以在服务间自动分配网络流量。
   • Spring Cloud: 使用Spring Cloud Ribbon实现客户端负载均衡，运行时从Eureka中获取服务实例的位置信息，并基于某种负载均衡策略进行访问。

6. 权限管理

   • Kubernetes: 提供RBAC API，支持基于角色的访问控制，管理谁可以访问Kubernetes资源及如何访问。
   • Spring Cloud: 使用Spring Cloud Security提供微服务安全控制，实现身份认证和权限管理。

7. 性能监控

   • Kubernetes: 通过Metrics API和Dashboard提供性能监控和可视化界面，可用于监控集群和应用的各种指标。
   • Spring Cloud: 使用Spring Cloud Turbine收集各个微服务的性能数据，聚合Hystrix监控信息，提供整体的性能视图。

8. 熔断器

   • Kubernetes: 通常不在Kubernetes层面处理，熔断功能需要在应用层面实现或使用服务网格如Istio来支持。
   • Spring Cloud: 使用Spring Cloud Hystrix实现熔断功能，防止服务间的级联故障，通过熔断机制来提高系统的容错性。

这张表格清楚地展示了两个平台各自的技术选择和策略。在选择Kubernetes或Spring Cloud时，可以根据应用的具体需求和已有的技术栈来做出决策：

• 如果你的应用主要是容器化的，并且需要在多种云环境或自有数据中心中灵活部署，那么Kubernetes提供的跨环境的部署、扩展和管理能力可能更适合。
• 如果你的应用主要基于Spring Boot开发，并且团队对Spring生态系统有较深的理解，那么Spring Cloud可能会提供更便捷的开发和管理体验。

总的来说，Kubernetes和Spring Cloud都是优秀的选择，但它们侧重点不同，适用的场景也有所不同。选择哪一个，取决于你的具体需求、团队技能和业务目标。