微服务系统是一类基于微服务架构风格的分布式系统它将应用程序拆分成多个独立的小 型服务每个服务都运行在独立的进程中并采用轻量级通信协议进行通信。这些服务可以由 不同的团队开发、不同的编程语言编写并且可以按需部署。微服务系统提供了高内聚、低耦 合的特性使得每个服务都可以独立进行维护和升级提高了系统的可伸缩性和可靠性。同时 微服务系统还支持使用不同的数据库和存储系统使得系统可以更灵活地适应不同的业务需求。 总之微服务系统是一种灵活、可靠、可伸缩的分布式系统架构适用于现代化应用程序的开 发和部署。本章主要从大数据处理系统的架构、开发框架、开发过程、系统测试等方面对微服务系统 的分析和设计进行全面介绍。20.1 微服务系统概述20.1.1 微服务系统简介微服务是一种开发软件的架构和组织方法它将大型应用程序拆分为一系列小型、自治的 服务每个服务都有自己的独立部署、运行和维护并通过轻量级通信机制相互协作从而形 成一个整体的系统。随着国内外软件开发技术和软件架构的飞速发展以及高可用性通信网络的更新换代大多 数IT 应用程序都在向着分布式发展。分布式软件系统的发展在过去十年中迅速增长随后出现 的SOA(Service-Oriented Architecture, 面向服务的架构)成为客户端-服务器体系结构最成功 的表示形式之一它提供可重用的服务。虽然SOA 致力于解决传统单体架构中系统庞大导致的 开发效率、扩展性问题但是由于它仍然依赖于单片系统抽取的粒度较大系统间耦合性依 然较高并不能很好地满足业务期望。微服务架构在2011年左右逐渐兴起打破了传统软件架构开发的模式其借鉴了一些分布 式系统和领域驱动设计的理念注重将系统按业务领域进行划分从而实现松耦合、可扩展和 可维护的架构。微服务系统拥有众多优势越来越多的大型应用采用微服务架构开发。以下是采用微服务 系统的一些常见优势。1)独立性和自治性微服务系统将大型应用拆分为多个小型服务每个服务都是独立的可以对其中的每个组 件服务进行开发、部署、运营和扩展而不影响其他服务的功能。这种独立性和自治性使得团 队可以独立开发、测试和部署各个服务提高开发速度和灵活性。第20章 微服务系统分析与设计 685 2)弹性和可伸缩性微服务系统可以根据需求进行水平扩展只需增加特定服务的实例数量而不需要整体扩 展。这种弹性和可伸缩性使得系统能够更好地应对负载的变化提供更好的性能和用户体验。3)技术多样性微服务系统中的每个服务都可以使用不同的技术栈和编程语言进行开发选择最适合特定 服务需求的工具和技术。这种技术多样性使得团队可以更灵活地选择和应用新技术提高开发 效率和创新能力。4) 专用性微服务系统中的每项服务都是针对一组功能设计的并专注于解决特定的问题。如果开发 人员逐渐将更多代码增加到一项服务中使得这项服务变得复杂那么可以将其拆分成多项更小 的服务。这使得系统中的每个服务都能提供专用的能力提供更好的性能。5)可组合性和可扩展性微服务系统的每个服务都可以独立开发和部署可以通过组合不同的服务来构建不同的应用场 景和功能。这种可组合性和可扩展性使得系统更易于扩展和演化能够快速响应业务需求的变化。6)容错性和可恢复性微服务系统中的每个服务都是自治的即使某个服务发生故障整个系统仍然可以继续运 行。通过适当的设计和实施容错机制可以提高系统的可靠性和可恢复性减少单点故障的影响。1. 微服务系统与单体式系统在微服务架构被提出之前传统的Web开发方式为单体式开发。单体式系统表示一个应用 程序内包含了所有需要的业务功能并且使用像主从式架构( Client/Server) 或是多层次架构(N-tier) 实现虽然它也能以分布式应用程序来实现但是在单体式系统内每个业务功能都 是不可分割的。通过单体式架构单体式系统中的所有进程紧密耦合并可作为单项服务运行这样的优 点是开发简单、基本不会重复开发并且没有分布式管理和调用的消耗。但这也意味着如果应 用程序的一个进程遇到需求峰值则必须扩展整个架构。随着代码库的增长添加或改进单体 式应用程序的功能变得更加复杂。这种复杂性限制了试验的可行性并使实施新技术和试验变 得困难。单体式架构增加了应用程序可用性的风险因为许多依赖且紧密耦合的进程会扩大单 个进程故障的影响。因此使用微服务架构可以解决单体式系统的部分问题表20-1总结了单 体式系统与微服务系统之间的区别。表20-1 单体式系统与微服务系统区别表维 度单体式系统微服务系统 架构粒度一个整体的应用程序所有功能和模块 都集中在一起多个小而自治的服务每个服务负责特 定的业务功能部署和扩展粒度整体部署和扩展每个服务独立部署和扩展技术异构性不支持支持686 系统分析师教程(第2版)(续表)维 度单体式系统微服务系统数据管理共享一个数据库每个服务有自己的数据库 团队组织和协作 适合一个开发团队共同开发和维护适合多团队协作每个团队独立负责一 个或多个服务可靠性和容错性不支持支持开发难度简单复杂微服务系统与单体式系统各有优缺点在实际应用中应根据应用场景的不同进行权衡选择。2. 微服务系统实现方式及平台微服务可以用不同的编程语言实现也可以使用不同的基础设施。因此最重要的技术 选择是微服务之间的通信方式(同步、异步、UI 集成)以及用于通信的协议( RESTful API、 HTTP/HTTPS、消息队列、GraphQL等)。基于微服务的架构和组织方式来创建微服务系统的实 现方式有很多种以下是常见的几种实现方式。1)基于容器化技术使用容器化技术如Docker 或Kubernetes, 将每个微服务打包成独立的容器每个容器运 行一个服务。容器化技术提供了隔离性、可移植性和弹性扩展的能力使得微服务可以独立部 署和管理。2)RESTful API每个微服务通过RESTful API暴露自己的功能并通过HTTP 或HTTPS 进行通信。服务之 间可以通过API 进行数据交互和调用。3)消息队列使用消息队列系统如Apache Kafka 或RabbitMQ, 实现微服务之间的异步通信。微服务 可以通过发送和接收消息来进行解耦和协作提高系统的弹性和可伸缩性。4)服务注册与发现使用服务注册与发现的机制如Netflix Eureka或 Consul, 实现微服务的动态发现和调用。 每个微服务在启动时向注册中心注册自己的地址和元数据其他服务通过查询注册中心来获取 服务的位置信息。5)服务网关使用服务网关如Netflix Zuul或NGINX, 作为微服务系统的入口和流量路由器。服务网 关可以提供负载均衡、安全认证、请求转发和缓存等功能简化客户端和服务之间的通信。6)分布式数据库微服务系统中的每个服务可以有自己的数据库但在某些情况下可能需要共享数据或进 行数据一致性管理。使用分布式数据库如 Apache Cassandra或 MongoDB, 可以实现数据的分 布式存储和管理。第20章 微服务系统分析与设计 687 需要注意的是微服务系统的实现方式可以根据具体需求和技术栈的选择而有所不同。不 同的组织和团队可能会选择不同的技术和工具来实现微服务系统因此在实施时需要根据具 体情况进行评估和选择。目前一些平台和框架可以帮助微服务系统的实现主流的两个分 别是Spring Cloud生态中的微服务框架Netflix OSS和Kubernetes 生态系统。表20-2显示了 Kubernetes生态系统与Spring Cloud生态中的微服务功能的比较。表20-2 单体式系统与微服务系统区别表微服务功能Spring CloudNetflix OSSKubernetes配置管理Spring Config Server、Netflix ArchaiusKubernetes ConfigMaps服务发现Spring Cloud EurekaKubernetes Services和Ingress负载平衡Spring Cloud RibbonKubernetes Service API网关 Spring Cloud ZuulKubernetes Service和Ingress resources、Istio、 Ambassador提供API网关功能的解决方案 安全问题Spring Cloud Security通过Spring Cloud Zuul解决安全问题 Istio能够通过API网关机制提供安全性 集中化日志记录ELK技术栈(Elasticsearch、LogStash、 Kibana) EFK技术栈(Elasticsearch、Fluentd、Kibana)集中的度量Spring Spectator和AtlasHeapster、Prometheus和Grafana分布式跟踪Spring Cloud SleuthHawkular、Jaeger弹性和容错性Spring Hystrix、Turbine、RibbonHealth check、service meshes自动伸缩和自我修复无健康检查、自我修复和自动缩放 打包、部署和调度Spring Boot、Apache Maven。Spring Cloud系统没有真正的调度程序Docker、Rkt、Kubernetes Scheduler和 Deployment、Helm作业管理Spring BatchKubernetes Jobs和Scheduled Jobs单例应用程序Spring Cloud ClusterKubernetes Pods20.1.2 微服务系统特征随着互联网技术的快速发展新兴的系统和软件大多为分布式大型系统为了满足大型系 统的需要采用微服务架构的微服务系统成为首选。这主要也与微服务系统的特征有关微服 务系统具有以下特征每个特征都在一定程度上定义了微服务系统的本质和核心思想。1. 服务自治性微服务系统中的每个服务都是自治的即每个服务都有自己独立的代码库、数据库和团队。 这种自治性使得每个服务能够独立开发、部署和运行而不受其他服务的影响。例如在一个 电子商务的微服务系统其中包括订单服务、支付服务和库存服务。每个服务都是独立开发和 部署的订单服务可以独立处理订单相关的逻辑支付服务可以独立处理支付相关的逻辑库 存服务可以独立处理库存相关的逻辑。 688 系统分析师教程(第2版)2. 服务单一职责微服务系统中的每个服务应该专注于解决一个特定的业务问题具有明确的职责范围。这 种单一职责的原则有助于保持服务的内聚性和可维护性。例如在一个社交媒体的微服务系统 中可以有用户服务、消息服务和推送服务。用户服务负责用户注册、登录和个人资料管理 消息服务负责发送和接收消息推送服务负责发送推送通知。3. 服务松耦合微服务系统中服务之间应该是松耦合的即应尽量减少彼此之间的依赖关系。这种松耦合 性使得服务能够独立演化和变更而不会对整个系统造成波及。例如在一个电子商务的微服 务系统中订单服务和库存服务之间可以通过异步消息进行通信订单服务不需要直接依赖库 存服务的实现细节从而实现松耦合。4. 分布式部署微服务系统中的服务可以独立部署在不同的服务器或容器中甚至可以跨多个数据中心进 行部署。这种分布式部署使得系统能够更好地应对高并发和大规模的需求。例如在一个在线 游戏的微服务系统中可以将用户认证服务部署在一个数据中心游戏匹配服务部署在另一个 数据中心以提供更好的性能和容错性。5. 技术异构性微服务系统中的每个服务可以使用不同的技术栈和工具选择适合自身需求的最佳技术。 这种技术异构性使得团队可以灵活选择和使用最适合的技术以满足各个服务的特定需求和技 术要求。例如在一个电商的微服务系统中可以使用Java 编写用户服务使用Python 编写推 荐服务使用Go 编写支付服务。每个服务可以选择最适合自己的编程语言和框架以满足其 性能、开发效率或特定领域的需求。6. 弹性和可伸缩性微服务系统具有弹性和可伸缩性可以根据负载的变化自动调整和扩展服务的实例。这种 弹性和可伸缩性使得系统能够应对高峰时段和大规模流量的需求。例如在一个电影订票的微 服务系统中可以根据实时的票务需求自动增加或减少座位服务的实例数量以满足用户的订 票请求。7. 独立演化和部署微服务系统中的每个服务都可以独立演化和部署无须影响其他服务。这种独立演化和部 署的能力使得系统能够更快速地推出新功能、修复错误和进行更新。例如在一个新闻发布的 微服务系统中可以独立更新新闻推荐服务的算法而无须停止其他服务的运行。这些特征共同定义了微服务系统的本质和核心思想它们使得微服务系统具备高度的灵活 性、可扩展性、可维护性和可靠性适应了快速变化和复杂的业务需求。然而也需要注意在 设计和实施微服务系统时充分考虑每个特征的权衡和挑战以确保系统能够最大程度地发挥 优势并避免潜在的问题。第20章 微服务系统分析与设计20.2 微服务系统架构20.2.1 微服务系统架构原则微服务架构设计是一种新兴的软件架构设计已经在很多公司和组织中得到广泛应用。它 通过将一个大型系统分解成小型、自治、独立的服务来降低系统的复杂度提高开发效率和部 署效率。微服务的优势在于它们能够扩展和维护保持可靠性和高可用性并且可以快速适应 不断变化的业务需求。在微服务架构设计中有一些重要的原则需要遵循以确保系统的可靠性、可维护性、可 伸缩性和高可用性。这些原则可以帮助团队设计出一个高效、稳定和安全的微服务系统并确 保系统能够快速适应不断变化的业务需求。当设计微服务系统时应该始终思考如何实现这些 原则并在实践中不断优化和改进。这可以帮助团队更好地理解系统的需求和行为并更好地 满足业务需求。下面将介绍微服务架构设计的主要原则。1. 单一职责原则每个微服务应该只关注一个业务领域只提供一个明确的功能。这有助于避免微服务之间 的耦合。每个微服务应该专注于自己的功能不应该尝试去做太多事情。如果一个微服务过于 复杂它可能会成为系统中的瓶颈导致系统性能下降。单一职责原则有助于确保每个微服务都能够轻松地进行部署、测试和维护并且可以在需 要时进行快速扩展。如果一个微服务负责多个业务领域那么它将需要处理更多的请求和数据 这会增加代码的复杂度导致服务不可靠。例如一个电商网站可能包括多个微服务如订单、库存、支付、客户等。每个微服务 应该只关注一个业务领域以确保它们不会相互干扰。订单服务只需要负责订单相关的功能 库存服务只需要负责库存相关的功能支付服务只需要负责支付相关的功能客户服务只需 要负责客户相关的功能。这样每个微服务都可以专注于自己的职责而不会干扰其他微服务 的运行。2. 隔离性原则微服务应该被设计为独立的进程具有自己的数据库和其他资源。这可以确保一个服务的 故障不会影响其他服务的正常运行。隔离性原则有助于确保每个微服务都能够独立运行并且 可以在需要时快速进行部署和替换。隔离性原则可以通过使用容器技术来实现。每个微服务可以被封装在一个容器中容器可 以提供隔离的环境确保每个微服务都可以独立运行并且不会干扰其他微服务。例如使用 Docker等容器技术可以为每个微服务提供一个独立的虚拟机环境并且能够在需要时快速创建 或销毁这些容器。隔离性原则还有助于确保微服务可以快速适应不断变化的业务需求。如果每个微服务都是 独立的那么在需要增加或修改功能时只需要修改相应的微服务而不需要影响其他微服务。这可以帮助团队更快地响应业务需求并减少开发和部署的复杂度。3. 自治性原则每个微服务应该是自治的具有自己的生命周期、状态和行为。自治性原则有助于确保每 个微服务都能够自主地进行管理和维护而不需要依赖其他微服务或中央管理。自治性原则可 以通过将微服务分解为更小的、独立的组件来实现。每个组件都具有自己的生命周期和状态 并且可以独立管理。例如一个微服务可以包括多个组件每个组件都有自己的状态和行为 并且可以通过消息传递等机制进行通信。自治性原则有助于确保微服务可以快速适应不断变化的业务需求并且可以在需要时快速 进行部署和替换。如果每个微服务都是自治的那么在需要修改或增加功能时只需要修改相 应的微服务而不需要影响其他微服务。这可以帮助团队更快地响应业务需求并减少开发和 部署的复杂度。4. 弹性原则微服务应该是弹性的可以快速适应不断变化的负载和需求。弹性原则有助于确保系统具 有高可用性和高可靠性并且可以快速恢复故障。弹性原则可以通过使用自动化的扩展和缩放机制来实现。例如使用自动化工具可以根据 当前负载和需求来动态地增加或减少微服务实例的数量。这可以确保系统在高峰期仍然可以提 供稳定的性能并且在负载下降时能够节省资源和成本。弹性原则还可以通过实现容错和故障恢复机制来实现。例如使用负载均衡和故障转移机 制可以确保一个微服务出现故障时其他微服务可以继续提供服务。这可以提高系统的可用性 并减少系统停机时间。5. 可观察性原则微服务应该是可观察的可以收集和分析有关其状态和行为的数据。可观察性原则有助于 确保系统的健康状况和性能可以得到实时监控和调整以满足业务需求。可观察性原则可以通过使用日志、指标和跟踪机制来实现。例如使用日志记录微服务的 活动和错误信息可以帮助开发人员了解系统的运行情况并快速解决问题。使用指标收集系统 的性能数据可以帮助团队了解系统的健康状况并根据需要进行优化。使用跟踪机制可以帮助 开发人员了解请求的完整路径以便更好地理解系统的行为和性能。可观察性原则有助于确保团队可以快速检测和解决问题并优化系统的性能和健康状况。 这可以提高系统的可靠性和稳定性并减少停机时间和修复时间。6.可测试性原则微服务应该是可测试的可以进行自动化测试和集成测试。可测试性原则有助于确保每个 微服务的功能和性能可以得到充分测试和验证以确保系统的稳定性和可靠性。可测试性原则可以通过使用自动化测试工具和技术来实现。例如使用单元测试和集成测 试可以确保每个微服务的功能和性能得到充分测试和验证。使用持续集成和持续部署可以确保 每次修改都能自动化地进行测试和部署。第20章 微服务系统分析与设计 691 可测试性原则有助于确保系统的稳定性和可靠性并减少开发和部署的复杂度。这可以帮 助团队更快地响应业务需求并提高开发人员的生产率和质量。7. 可维护性原则微服务应该是可维护的可以进行快速维护和修改。可维护性原则有助于确保每个微服务 可以快速适应不断变化的业务需求并且可以快速进行修复和修改。可维护性原则可以通过使用标准化的API 和文档来实现。例如使用RESTful API和 OpenAPI 可以确保每个微服务都具有一致的接口和文档并且可以快速理解和修改。使用规范 化的命名和版本控制可以确保每个微服务的代码和配置都具有一致的结构和规范。可维护性原则有助于确保团队可以快速响应业务需求并快速进行修复和修改。这可以提 高系统的可靠性和稳定性并减少停机时间和修复时间。此外可维护性原则还可以帮助团队 提高代码的可读性和可维护性从而提高开发人员的生产力和效率。8.安全性原则微服务应该是安全的可以提供足够的保护和安全措施以确保数据和系统的安全性。安 全性原则有助于确保每个微服务可以安全地处理和存储敏感信息并且可以保护系统免受潜在 的安全威胁。安全性原则可以通过使用加密、认证和授权技术来实现。例如使用TLS/SSL 协议可以确 保数据在传输过程中得到加密保护。使用OAuth2 和 OpenID Connect可以确保用户身份得到认 证和授权并且可以对不同级别的用户提供不同的权限和访问控制。安全性原则有助于确保团队可以保护系统和数据免受潜在的安全威胁并确保系统的稳定 性和可靠性。这可以提高系统的可信度和用户的信任度从而增加系统的价值和竞争力。9. 智能端点与简单消息传递原则在微服务系统中服务之间的通信是不可避免的。传统的单体应用中通常使用共享库或 其他技术来实现代码的重用但在微服务系统中由于服务之间的隔离性和自治性共享代码 库变得不可行。因此服务之间的通信成为了微服务系统中最重要的一环。智能端点与简单消息传递是微服务系统设计中的重要原则用于处理服务之间的通信。智 能端点指的是服务端点应该尽可能智能和独立不依赖于其他服务或中心化的组件而简单消 息传递指的是服务之间的通信应该是简单的消息传递避免复杂的请求-响应交互。通过使用智能端点和简单消息传递原则可以实现服务之间的松耦合并提高系统的可伸 缩性和容错性。同时使用智能端点可以避免服务之间的依赖关系增加系统的灵活性和可移 植性。使用简单消息传递可以减少服务之间的复杂性简化服务的交互从而提高系统的可维 护性和可测试性。例如一个电子商务网站有一个订单服务和一个库存服务订单服务需要查询库存服务来 确认某件商品是否有足够的库存量。使用智能端点和简单消息传递原则订单服务可以发送一 个简单的查询请求给库存服务然后等待库存服务的响应。库存服务可以独立处理请求并返 回一个简单的响应指示是否有足够的库存量。这种简单的请求-响应模式可以降低服务之间 692 系统分析师教程(第2版)的复杂性并使系统更容易维护和扩展。20.2.2 微服务系统架构模式微服务系统架构模式是一种针对分布式系统中的微服务架构设计的模式它描述了如何将 不同的微服务组合在一起来实现复杂的业务功能。在微服务架构中每个微服务都是独立的、 自治的可以独立开发、部署和运行。使用不同模式开发的好处是可以根据实际业务场景进行 系统设计实现高度的可伸缩性和灵活性从而满足不同的业务需求。以下将介绍聚合器微服务( Aggregator Microservice)、代理微服务( Proxy Microservice)、 链式微服务( Chained Microservice)、分支微服务( Branch Microservice)、数据共享微服务 (Shared Data Microservice) 和异步消息微服务( Asynchronous Messaging Microservice)6种模式。1. 聚合器微服务随着微服务架构的流行系统中的服务数量越来越多服务之间的通信和数据处理变得越 来越复杂。在这种情况下聚合器微服务成为了一个重要的设计模式。它的主要目标是从多个 服务或数据源中收集、处理和聚合信息并将其转换为需要的数据格式。这种模式可以协调多个 服务之间的通信和数据处理流程提高系统的可扩展性和可维护性。聚合器微服务中的关键角色是聚合器 ( Aggregator) 。 聚合器可以是一个简单的Web 页面 只将从多个微服务中检索到的数据进行展示也可以由一个更高层级的微服务扮演聚合器的角 色。聚合器可以理解为一个中心化的服务它的主要功能是接收来自客户端的请求按照业务 逻辑将请求分发给后端的多个服务或数据源最终将这些数据进行处理、聚合和转换以生成 需要的数据格式并将其返回给客户端。聚合器微服务模式的示意图如图20-1所示。图20-1 聚合器微服务模式示意图从图20-1可以看出聚合器微服务模式的关键在于聚合器的设计它将作为用户与系统中 其他微服务交互的桥梁。在设计聚合器时通常需要具备以下几个功能(1)消息转发。聚合器作为消息处理的中心负责接收请求并将其转发给后端服务同时 返回的数据也将由聚合器进行统一传递。第20章 微服务系统分析与设计 693 (2)数据聚合。在聚合器中需要能够根据业务需求对来自多个服务或数据源返回的数据 进行聚合和转换以生成需要的数据格式。(3)数据缓存。为了提高性能聚合器通常会使用缓存技术缓存聚合后的数据以减少后 续重复请求的响应时间避免对于多个服务的高频调用。在聚合器微服务模式下聚合器成为了服务调用的中心这样设计可以带来以下几个 优点(1)减少网络延迟。通过将多个微服务的调用聚合在一起可以减少网络传输和延迟时间。 这意味着客户端可以更快地获得结果提高系统的响应速度和用户体验。(2)减少微服务之间的依赖。在传统的微服务架构中一个服务可能需要调用多个其他服 务才能完成一个请求这增加了服务之间的依赖关系和复杂性。聚合器微服务可以减少这种依 赖性使每个服务更加独立和可复用。(3)提高系统可靠性。聚合器微服务可以通过负载均衡和容错机制来提高系统的可靠性和稳定性保证系统在高负载和异常情况下的正常运行。(4)提高开发效率。聚合器微服务的设计可以使服务之间的通信和数据处理更加统一和直 观从而减少开发人员的开发工作量提高开发效率和代码质量。2. 代理微服务代理微服务是一种微服务架构的设计模式它提供了一种将客户端请求转发到后端服务的 中间层同时还可以实现一些常见的服务治理功能如负载均衡、故障熔断、限流等。代理微 服务可以有效地解耦客户端和后端服务之间的依赖关系提高系统的可伸缩性和可维护性。代理微服务通常由两部分组成代理网关和后端服务。代理网关是客户端和后端服务之间 的中间层负责接收和转发客户端请求并在请求到达后端服务之前进行一些服务治理的操作。 后端服务是实际处理请求的服务它们可以是单独的微服务、容器、虚拟机或物理机器。代理 微服务和聚合器微服务的区别在于代理微服务中代理仅委派请求或者进行数据的转换工 作并不会从后端服务中聚合数据但会根据业务需求的差别调用不同的微服务。代理微服务模式的示意图如图20-2所示。图20-2 代理微服务模式示意图694 系统分析师教程(第2版)代理微服务通常采用HTTP 或TCP 协议进行通信其中HTTP 协议更加常见。代理网关可 以支持多种HTTP 协议如HTTP/1.1、HTTP/2和 WebSocket等。客户端通过向代理网关发送 HTTP 请求来访问后端服务代理网关则将请求转发到对应的后端服务。代理网关通常支持多 种负载均衡算法如轮询、随机、加权轮询等以提高系统的可伸缩性和可用性。代理微服务的另一个重要功能是服务治理。服务治理是一种管理分布式系统中各个微服务 的方法它包括负载均衡、故障熔断、限流、服务发现等功能。代理网关通常可以通过配置文 件或API 接口来实现服务治理的功能。例如可以通过配置文件设置各个后端服务的权重实 现负载均衡也可以通过API 接口监控后端服务的健康状态实现故障熔断还可以通过限流 算法限制客户端请求的速率防止系统被过度请求而崩溃。3. 链式微服务链式微服务将多个微服务连接在一起形成一条微服务链。每个微服务负责完成特定的功 能同时将处理结果传递给下一个微服务以实现复杂的业务逻辑。链式微服务模式可以使系 统具有高可扩展性和灵活性并促进了代码重用和模块化。在链式微服务模式中每个微服务都是一个独立的服务单元它们可以通过API 调用相互 通信。每个微服务都处理特定的任务然后将结果传递给下一个微服务。每个微服务都可以有 自己的独立数据存储但是也可以共享数据存储。在链式微服务中收到请求后会在微服务中产生调用链使后续服务进行下一步处理并等 待返回结果。在后续的服务请求回传结果前客户端会一直阻塞等待链式调用完成。链式微服务的示意图如20-3所示。图20-3 链式微服务模式示意图链式微服务可以实现多种不同的应用程序场景。例如它可以用于实现工作流程将不同 的微服务连接在一起以处理工作流程中的各个阶段。它还可以用于实现电子商务网站 其 中 订单处理、库存管理和支付处理等任务可以由不同的微服务完成。链式微服务还可以用于实现 大型数据分析应用程序其中数据处理和分析任务可以由多个微服务完成这些微服务可以按 需进行动态扩展。4. 分支微服务分支微服务是链式微服务的扩展。在分支微服务中多个微服务将被组织在一起形成不 同的分支结构每个分支代表一种可能的业务场景或决策路径并通过链式调用相应请求。这 种模式使得应用程序可以根据不同的条件和事件来采取不同的行动从而实现更灵活和个性化 的业务逻辑。在分支微服务模式中每个分支都是一个独立的微服务单元它们根据输入数据和条件来 确定应该采取的下一步行动。每个分支可以选择执行一个或多个微服务或者跳转到另一个分 支以响应不同的业务场景或决策路径。分支微服务可以是串联的也可以是并行的具体取 决于应用程序的设计和需求。分支微服务的示意图如20-4所示。图20-4 分支微服务模式示意图分支微服务可以用于实现多种不同的应用程序场景。例如在电子商务网站中可以使用 分支微服务来处理订单流程根据不同的付款方式或送货地址选择不同的流程。在金融服务应 用程序中可以使用分支微服务来决定是否批准贷款或投资申请根据不同的信用评分和风险 评估。在物流和运输应用程序中可以使用分支微服务来确定最佳路线和交通方式以根据不 同的货物和目的地确定最佳的路线选择。5. 数据共享微服务数据共享微服务提供了一种在不同微服务之间共享数据的方法。通过共享数据不同的微 服务可以更加高效地协同工作实现更强大的业务逻辑和功能。在传统的单体应用程序中数据通常是在应用程序内部共享的因为应用程序内部的所有 组件都可以访问相同的数据。但是在微服务架构中每个微服务都是独立的并且有自己的 数据库和数据模型因此实现数据共享变得更加复杂。数据共享微服务模式解决了这个问题通 过将数据访问和管理集中在一个或多个微服务中来实现在不同微服务之间共享数据的目的。数据共享微服务的示意图如20-5所示。图20-5 数据共享微服务模式示意图数据共享微服务可以使用多种技术和方法来实现。其中一种方法是使用共享数据库即 将数据存储在单独的数据库中并让多个微服务共享该数据库如图20-5中的Service C和 Service D。这种方法可能会导致并发问题和数据一致性问题因此需要采取一些措施来确保数 据的安全性和正确性如使用事务和锁定机制。另一种方法是使用数据代理服务即在微服务 之间添加一个代理层用于管理和协调数据的共享。这个代理层可以是一个专门的数据代理微 服务也可以是一个数据共享框架如Apache Kafka或Apache Flink等。这种方法可以更好地 控制数据的共享和访问同时也可以提供更好的性能和可扩展性。数据共享微服务可以用于实现多种不同的应用程序场景。例如在电子商务网站中可以 使用数据共享微服务来共享产品信息和库存数据以便多个微服务可以共享相同的数据源并 保持数据的一致性。在金融服务应用程序中可以使用数据共享微服务来共享客户和账户信息 以便多个微服务可以共享相同的客户数据并实现更复杂的业务逻辑。6. 异步消息微服务异步消息微服务是一种基于消息传递的微服务架构其设计的目的是解决分布式系统中的 异步通信需求。在传统的同步通信模式中当服务A 向服务B 发送请求时服务A 必须等待服 务B 的响应才能继续执行。这种模式的缺点是如果服务B 出现了故障或者响应时间过长那 么服务A 就会一直处于等待状态从而导致整个系统的性能下降。相比之下异步消息通信模式允许服务A 向服务B 发送消息而不需要等待服务B 的 响 应。当服务B 处理完消息后可以向服务A 发送响应也可以将响应发送给另一个服务或者 将响应写入数据库中等等。这种模式的好处是由于请求发送后服务A 不需要等待响应因 此可以立即继续执行其他任务从而提高整个系统的性能和吞吐量。异步消息微服务的示意图如20-6所示。第20章 微服务系统分析与设计 697图20-6 异步消息微服务模式示意图在异步消息微服务架构中每个微服务都可以充当消息的生产者和消费者。当一个微服务 需要处理某些任务时它可以将消息发送到消息队列中然后另一个微服务从队列中获取消息 并处理。这种模式的好处是可以将不同的任务分配给不同的微服务处理从而提高系统的可 伸缩性和灵活性。为了实现异步消息通信模式异步消息微服务通常使用消息队列作为消息传递的中介。消 息队列是一种支持异步通信模式的消息传递机制它允许发送者将消息发送到队列中而不需 要等待接收者的响应。接收者可以随时从队列中获取消息并进行处理。消息队列还具有许多高 级功能如消息持久化、消息过期、消息重试、消息路由等这些功能都可以更好地管理和处 理消息。异步消息微服务架构的另一个核心概念是事件驱动架构 (Event-Driven Architecture,EDA)。 在事件驱动架构中系统中的各个组件都可以充当事件的生产者和消费者它们之间通过消息 队列进行通信。当一个事件发生时它会被发送到消息队列中然后订阅了该事件的组件会从 队列中获取事件并进行处理。这种架构可以实现高度松耦合的系统设计从而提高系统的可维 护性和扩展性。总的来说异步消息微服务是一种基于消息传递和事件驱动的微服务架构它可以实现 高性能、可伸缩和可靠的分布式系统。通过使用消息队列作为消息传递的中介异步消息微 服务架构可以实现异步通信模式从而提高系统的性能和吞吐量。同时事件驱动架构可以实 现高度松耦合的系统设计从而提高系统的可维护性和扩展性。异步消息微服务已经被广泛 应用于各种场景如电子商务、金融、物联网等领域它是构建现代分布式系统的重要技术 之一。
微服务系统是一类基于微服务架构风格的分布式系统它将应用程序拆分成多个独立的小 型服务每个服务都运行在独立的进程中并采用轻量级通信协议进行通信。这些服务可以由 不同的团队开发、不同的编程语言编写并且可以按需部署。微服务系统提供了高内聚、低耦 合的特性使得每个服务都可以独立进行维护和升级提高了系统的可伸缩性和可靠性。同时 微服务系统还支持使用不同的数据库和存储系统使得系统可以更灵活地适应不同的业务需求。 总之微服务系统是一种灵活、可靠、可伸缩的分布式系统架构适用于现代化应用程序的开 发和部署。本章主要从大数据处理系统的架构、开发框架、开发过程、系统测试等方面对微服务系统 的分析和设计进行全面介绍。20.1 微服务系统概述20.1.1 微服务系统简介微服务是一种开发软件的架构和组织方法它将大型应用程序拆分为一系列小型、自治的 服务每个服务都有自己的独立部署、运行和维护并通过轻量级通信机制相互协作从而形 成一个整体的系统。随着国内外软件开发技术和软件架构的飞速发展以及高可用性通信网络的更新换代大多 数IT 应用程序都在向着分布式发展。分布式软件系统的发展在过去十年中迅速增长随后出现 的SOA(Service-Oriented Architecture, 面向服务的架构)成为客户端-服务器体系结构最成功 的表示形式之一它提供可重用的服务。虽然SOA 致力于解决传统单体架构中系统庞大导致的 开发效率、扩展性问题但是由于它仍然依赖于单片系统抽取的粒度较大系统间耦合性依 然较高并不能很好地满足业务期望。微服务架构在2011年左右逐渐兴起打破了传统软件架构开发的模式其借鉴了一些分布 式系统和领域驱动设计的理念注重将系统按业务领域进行划分从而实现松耦合、可扩展和 可维护的架构。微服务系统拥有众多优势越来越多的大型应用采用微服务架构开发。以下是采用微服务 系统的一些常见优势。1)独立性和自治性微服务系统将大型应用拆分为多个小型服务每个服务都是独立的可以对其中的每个组 件服务进行开发、部署、运营和扩展而不影响其他服务的功能。这种独立性和自治性使得团 队可以独立开发、测试和部署各个服务提高开发速度和灵活性。第20章 微服务系统分析与设计 685 2)弹性和可伸缩性微服务系统可以根据需求进行水平扩展只需增加特定服务的实例数量而不需要整体扩 展。这种弹性和可伸缩性使得系统能够更好地应对负载的变化提供更好的性能和用户体验。3)技术多样性微服务系统中的每个服务都可以使用不同的技术栈和编程语言进行开发选择最适合特定 服务需求的工具和技术。这种技术多样性使得团队可以更灵活地选择和应用新技术提高开发 效率和创新能力。4) 专用性微服务系统中的每项服务都是针对一组功能设计的并专注于解决特定的问题。如果开发 人员逐渐将更多代码增加到一项服务中使得这项服务变得复杂那么可以将其拆分成多项更小 的服务。这使得系统中的每个服务都能提供专用的能力提供更好的性能。5)可组合性和可扩展性微服务系统的每个服务都可以独立开发和部署可以通过组合不同的服务来构建不同的应用场 景和功能。这种可组合性和可扩展性使得系统更易于扩展和演化能够快速响应业务需求的变化。6)容错性和可恢复性微服务系统中的每个服务都是自治的即使某个服务发生故障整个系统仍然可以继续运 行。通过适当的设计和实施容错机制可以提高系统的可靠性和可恢复性减少单点故障的影响。1. 微服务系统与单体式系统在微服务架构被提出之前传统的Web开发方式为单体式开发。单体式系统表示一个应用 程序内包含了所有需要的业务功能并且使用像主从式架构( Client/Server) 或是多层次架构(N-tier) 实现虽然它也能以分布式应用程序来实现但是在单体式系统内每个业务功能都 是不可分割的。通过单体式架构单体式系统中的所有进程紧密耦合并可作为单项服务运行这样的优 点是开发简单、基本不会重复开发并且没有分布式管理和调用的消耗。但这也意味着如果应 用程序的一个进程遇到需求峰值则必须扩展整个架构。随着代码库的增长添加或改进单体 式应用程序的功能变得更加复杂。这种复杂性限制了试验的可行性并使实施新技术和试验变 得困难。单体式架构增加了应用程序可用性的风险因为许多依赖且紧密耦合的进程会扩大单 个进程故障的影响。因此使用微服务架构可以解决单体式系统的部分问题表20-1总结了单 体式系统与微服务系统之间的区别。表20-1 单体式系统与微服务系统区别表维 度单体式系统微服务系统 架构粒度一个整体的应用程序所有功能和模块 都集中在一起多个小而自治的服务每个服务负责特 定的业务功能部署和扩展粒度整体部署和扩展每个服务独立部署和扩展技术异构性不支持支持686 系统分析师教程(第2版)(续表)维 度单体式系统微服务系统数据管理共享一个数据库每个服务有自己的数据库 团队组织和协作 适合一个开发团队共同开发和维护适合多团队协作每个团队独立负责一 个或多个服务可靠性和容错性不支持支持开发难度简单复杂微服务系统与单体式系统各有优缺点在实际应用中应根据应用场景的不同进行权衡选择。2. 微服务系统实现方式及平台微服务可以用不同的编程语言实现也可以使用不同的基础设施。因此最重要的技术 选择是微服务之间的通信方式(同步、异步、UI 集成)以及用于通信的协议( RESTful API、 HTTP/HTTPS、消息队列、GraphQL等)。基于微服务的架构和组织方式来创建微服务系统的实 现方式有很多种以下是常见的几种实现方式。1)基于容器化技术使用容器化技术如Docker 或Kubernetes, 将每个微服务打包成独立的容器每个容器运 行一个服务。容器化技术提供了隔离性、可移植性和弹性扩展的能力使得微服务可以独立部 署和管理。2)RESTful API每个微服务通过RESTful API暴露自己的功能并通过HTTP 或HTTPS 进行通信。服务之 间可以通过API 进行数据交互和调用。3)消息队列使用消息队列系统如Apache Kafka 或RabbitMQ, 实现微服务之间的异步通信。微服务 可以通过发送和接收消息来进行解耦和协作提高系统的弹性和可伸缩性。4)服务注册与发现使用服务注册与发现的机制如Netflix Eureka或 Consul, 实现微服务的动态发现和调用。 每个微服务在启动时向注册中心注册自己的地址和元数据其他服务通过查询注册中心来获取 服务的位置信息。5)服务网关使用服务网关如Netflix Zuul或NGINX, 作为微服务系统的入口和流量路由器。服务网 关可以提供负载均衡、安全认证、请求转发和缓存等功能简化客户端和服务之间的通信。6)分布式数据库微服务系统中的每个服务可以有自己的数据库但在某些情况下可能需要共享数据或进 行数据一致性管理。使用分布式数据库如 Apache Cassandra或 MongoDB, 可以实现数据的分 布式存储和管理。第20章 微服务系统分析与设计 687 需要注意的是微服务系统的实现方式可以根据具体需求和技术栈的选择而有所不同。不 同的组织和团队可能会选择不同的技术和工具来实现微服务系统因此在实施时需要根据具 体情况进行评估和选择。目前一些平台和框架可以帮助微服务系统的实现主流的两个分 别是Spring Cloud生态中的微服务框架Netflix OSS和Kubernetes 生态系统。表20-2显示了 Kubernetes生态系统与Spring Cloud生态中的微服务功能的比较。表20-2 单体式系统与微服务系统区别表微服务功能Spring CloudNetflix OSSKubernetes配置管理Spring Config Server、Netflix ArchaiusKubernetes ConfigMaps服务发现Spring Cloud EurekaKubernetes Services和Ingress负载平衡Spring Cloud RibbonKubernetes Service API网关 Spring Cloud ZuulKubernetes Service和Ingress resources、Istio、 Ambassador提供API网关功能的解决方案 安全问题Spring Cloud Security通过Spring Cloud Zuul解决安全问题 Istio能够通过API网关机制提供安全性 集中化日志记录ELK技术栈(Elasticsearch、LogStash、 Kibana) EFK技术栈(Elasticsearch、Fluentd、Kibana)集中的度量Spring Spectator和AtlasHeapster、Prometheus和Grafana分布式跟踪Spring Cloud SleuthHawkular、Jaeger弹性和容错性Spring Hystrix、Turbine、RibbonHealth check、service meshes自动伸缩和自我修复无健康检查、自我修复和自动缩放 打包、部署和调度Spring Boot、Apache Maven。Spring Cloud系统没有真正的调度程序Docker、Rkt、Kubernetes Scheduler和 Deployment、Helm作业管理Spring BatchKubernetes Jobs和Scheduled Jobs单例应用程序Spring Cloud ClusterKubernetes Pods20.1.2 微服务系统特征随着互联网技术的快速发展新兴的系统和软件大多为分布式大型系统为了满足大型系 统的需要采用微服务架构的微服务系统成为首选。这主要也与微服务系统的特征有关微服 务系统具有以下特征每个特征都在一定程度上定义了微服务系统的本质和核心思想。1. 服务自治性微服务系统中的每个服务都是自治的即每个服务都有自己独立的代码库、数据库和团队。 这种自治性使得每个服务能够独立开发、部署和运行而不受其他服务的影响。例如在一个 电子商务的微服务系统其中包括订单服务、支付服务和库存服务。每个服务都是独立开发和 部署的订单服务可以独立处理订单相关的逻辑支付服务可以独立处理支付相关的逻辑库 存服务可以独立处理库存相关的逻辑。 688 系统分析师教程(第2版)2. 服务单一职责微服务系统中的每个服务应该专注于解决一个特定的业务问题具有明确的职责范围。这 种单一职责的原则有助于保持服务的内聚性和可维护性。例如在一个社交媒体的微服务系统 中可以有用户服务、消息服务和推送服务。用户服务负责用户注册、登录和个人资料管理 消息服务负责发送和接收消息推送服务负责发送推送通知。3. 服务松耦合微服务系统中服务之间应该是松耦合的即应尽量减少彼此之间的依赖关系。这种松耦合 性使得服务能够独立演化和变更而不会对整个系统造成波及。例如在一个电子商务的微服 务系统中订单服务和库存服务之间可以通过异步消息进行通信订单服务不需要直接依赖库 存服务的实现细节从而实现松耦合。4. 分布式部署微服务系统中的服务可以独立部署在不同的服务器或容器中甚至可以跨多个数据中心进 行部署。这种分布式部署使得系统能够更好地应对高并发和大规模的需求。例如在一个在线 游戏的微服务系统中可以将用户认证服务部署在一个数据中心游戏匹配服务部署在另一个 数据中心以提供更好的性能和容错性。5. 技术异构性微服务系统中的每个服务可以使用不同的技术栈和工具选择适合自身需求的最佳技术。 这种技术异构性使得团队可以灵活选择和使用最适合的技术以满足各个服务的特定需求和技 术要求。例如在一个电商的微服务系统中可以使用Java 编写用户服务使用Python 编写推 荐服务使用Go 编写支付服务。每个服务可以选择最适合自己的编程语言和框架以满足其 性能、开发效率或特定领域的需求。6. 弹性和可伸缩性微服务系统具有弹性和可伸缩性可以根据负载的变化自动调整和扩展服务的实例。这种 弹性和可伸缩性使得系统能够应对高峰时段和大规模流量的需求。例如在一个电影订票的微 服务系统中可以根据实时的票务需求自动增加或减少座位服务的实例数量以满足用户的订 票请求。7. 独立演化和部署微服务系统中的每个服务都可以独立演化和部署无须影响其他服务。这种独立演化和部 署的能力使得系统能够更快速地推出新功能、修复错误和进行更新。例如在一个新闻发布的 微服务系统中可以独立更新新闻推荐服务的算法而无须停止其他服务的运行。这些特征共同定义了微服务系统的本质和核心思想它们使得微服务系统具备高度的灵活 性、可扩展性、可维护性和可靠性适应了快速变化和复杂的业务需求。然而也需要注意在 设计和实施微服务系统时充分考虑每个特征的权衡和挑战以确保系统能够最大程度地发挥 优势并避免潜在的问题。第20章 微服务系统分析与设计20.2 微服务系统架构20.2.1 微服务系统架构原则微服务架构设计是一种新兴的软件架构设计已经在很多公司和组织中得到广泛应用。它 通过将一个大型系统分解成小型、自治、独立的服务来降低系统的复杂度提高开发效率和部 署效率。微服务的优势在于它们能够扩展和维护保持可靠性和高可用性并且可以快速适应 不断变化的业务需求。在微服务架构设计中有一些重要的原则需要遵循以确保系统的可靠性、可维护性、可 伸缩性和高可用性。这些原则可以帮助团队设计出一个高效、稳定和安全的微服务系统并确 保系统能够快速适应不断变化的业务需求。当设计微服务系统时应该始终思考如何实现这些 原则并在实践中不断优化和改进。这可以帮助团队更好地理解系统的需求和行为并更好地 满足业务需求。下面将介绍微服务架构设计的主要原则。1. 单一职责原则每个微服务应该只关注一个业务领域只提供一个明确的功能。这有助于避免微服务之间 的耦合。每个微服务应该专注于自己的功能不应该尝试去做太多事情。如果一个微服务过于 复杂它可能会成为系统中的瓶颈导致系统性能下降。单一职责原则有助于确保每个微服务都能够轻松地进行部署、测试和维护并且可以在需 要时进行快速扩展。如果一个微服务负责多个业务领域那么它将需要处理更多的请求和数据 这会增加代码的复杂度导致服务不可靠。例如一个电商网站可能包括多个微服务如订单、库存、支付、客户等。每个微服务 应该只关注一个业务领域以确保它们不会相互干扰。订单服务只需要负责订单相关的功能 库存服务只需要负责库存相关的功能支付服务只需要负责支付相关的功能客户服务只需 要负责客户相关的功能。这样每个微服务都可以专注于自己的职责而不会干扰其他微服务 的运行。2. 隔离性原则微服务应该被设计为独立的进程具有自己的数据库和其他资源。这可以确保一个服务的 故障不会影响其他服务的正常运行。隔离性原则有助于确保每个微服务都能够独立运行并且 可以在需要时快速进行部署和替换。隔离性原则可以通过使用容器技术来实现。每个微服务可以被封装在一个容器中容器可 以提供隔离的环境确保每个微服务都可以独立运行并且不会干扰其他微服务。例如使用 Docker等容器技术可以为每个微服务提供一个独立的虚拟机环境并且能够在需要时快速创建 或销毁这些容器。隔离性原则还有助于确保微服务可以快速适应不断变化的业务需求。如果每个微服务都是 独立的那么在需要增加或修改功能时只需要修改相应的微服务而不需要影响其他微服务。这可以帮助团队更快地响应业务需求并减少开发和部署的复杂度。3. 自治性原则每个微服务应该是自治的具有自己的生命周期、状态和行为。自治性原则有助于确保每 个微服务都能够自主地进行管理和维护而不需要依赖其他微服务或中央管理。自治性原则可 以通过将微服务分解为更小的、独立的组件来实现。每个组件都具有自己的生命周期和状态 并且可以独立管理。例如一个微服务可以包括多个组件每个组件都有自己的状态和行为 并且可以通过消息传递等机制进行通信。自治性原则有助于确保微服务可以快速适应不断变化的业务需求并且可以在需要时快速 进行部署和替换。如果每个微服务都是自治的那么在需要修改或增加功能时只需要修改相 应的微服务而不需要影响其他微服务。这可以帮助团队更快地响应业务需求并减少开发和 部署的复杂度。4. 弹性原则微服务应该是弹性的可以快速适应不断变化的负载和需求。弹性原则有助于确保系统具 有高可用性和高可靠性并且可以快速恢复故障。弹性原则可以通过使用自动化的扩展和缩放机制来实现。例如使用自动化工具可以根据 当前负载和需求来动态地增加或减少微服务实例的数量。这可以确保系统在高峰期仍然可以提 供稳定的性能并且在负载下降时能够节省资源和成本。弹性原则还可以通过实现容错和故障恢复机制来实现。例如使用负载均衡和故障转移机 制可以确保一个微服务出现故障时其他微服务可以继续提供服务。这可以提高系统的可用性 并减少系统停机时间。5. 可观察性原则微服务应该是可观察的可以收集和分析有关其状态和行为的数据。可观察性原则有助于 确保系统的健康状况和性能可以得到实时监控和调整以满足业务需求。可观察性原则可以通过使用日志、指标和跟踪机制来实现。例如使用日志记录微服务的 活动和错误信息可以帮助开发人员了解系统的运行情况并快速解决问题。使用指标收集系统 的性能数据可以帮助团队了解系统的健康状况并根据需要进行优化。使用跟踪机制可以帮助 开发人员了解请求的完整路径以便更好地理解系统的行为和性能。可观察性原则有助于确保团队可以快速检测和解决问题并优化系统的性能和健康状况。 这可以提高系统的可靠性和稳定性并减少停机时间和修复时间。6.可测试性原则微服务应该是可测试的可以进行自动化测试和集成测试。可测试性原则有助于确保每个 微服务的功能和性能可以得到充分测试和验证以确保系统的稳定性和可靠性。可测试性原则可以通过使用自动化测试工具和技术来实现。例如使用单元测试和集成测 试可以确保每个微服务的功能和性能得到充分测试和验证。使用持续集成和持续部署可以确保 每次修改都能自动化地进行测试和部署。第20章 微服务系统分析与设计 691 可测试性原则有助于确保系统的稳定性和可靠性并减少开发和部署的复杂度。这可以帮 助团队更快地响应业务需求并提高开发人员的生产率和质量。7. 可维护性原则微服务应该是可维护的可以进行快速维护和修改。可维护性原则有助于确保每个微服务 可以快速适应不断变化的业务需求并且可以快速进行修复和修改。可维护性原则可以通过使用标准化的API 和文档来实现。例如使用RESTful API和 OpenAPI 可以确保每个微服务都具有一致的接口和文档并且可以快速理解和修改。使用规范 化的命名和版本控制可以确保每个微服务的代码和配置都具有一致的结构和规范。可维护性原则有助于确保团队可以快速响应业务需求并快速进行修复和修改。这可以提 高系统的可靠性和稳定性并减少停机时间和修复时间。此外可维护性原则还可以帮助团队 提高代码的可读性和可维护性从而提高开发人员的生产力和效率。8.安全性原则微服务应该是安全的可以提供足够的保护和安全措施以确保数据和系统的安全性。安 全性原则有助于确保每个微服务可以安全地处理和存储敏感信息并且可以保护系统免受潜在 的安全威胁。安全性原则可以通过使用加密、认证和授权技术来实现。例如使用TLS/SSL 协议可以确 保数据在传输过程中得到加密保护。使用OAuth2 和 OpenID Connect可以确保用户身份得到认 证和授权并且可以对不同级别的用户提供不同的权限和访问控制。安全性原则有助于确保团队可以保护系统和数据免受潜在的安全威胁并确保系统的稳定 性和可靠性。这可以提高系统的可信度和用户的信任度从而增加系统的价值和竞争力。9. 智能端点与简单消息传递原则在微服务系统中服务之间的通信是不可避免的。传统的单体应用中通常使用共享库或 其他技术来实现代码的重用但在微服务系统中由于服务之间的隔离性和自治性共享代码 库变得不可行。因此服务之间的通信成为了微服务系统中最重要的一环。智能端点与简单消息传递是微服务系统设计中的重要原则用于处理服务之间的通信。智 能端点指的是服务端点应该尽可能智能和独立不依赖于其他服务或中心化的组件而简单消 息传递指的是服务之间的通信应该是简单的消息传递避免复杂的请求-响应交互。通过使用智能端点和简单消息传递原则可以实现服务之间的松耦合并提高系统的可伸 缩性和容错性。同时使用智能端点可以避免服务之间的依赖关系增加系统的灵活性和可移 植性。使用简单消息传递可以减少服务之间的复杂性简化服务的交互从而提高系统的可维 护性和可测试性。例如一个电子商务网站有一个订单服务和一个库存服务订单服务需要查询库存服务来 确认某件商品是否有足够的库存量。使用智能端点和简单消息传递原则订单服务可以发送一 个简单的查询请求给库存服务然后等待库存服务的响应。库存服务可以独立处理请求并返 回一个简单的响应指示是否有足够的库存量。这种简单的请求-响应模式可以降低服务之间 692 系统分析师教程(第2版)的复杂性并使系统更容易维护和扩展。20.2.2 微服务系统架构模式微服务系统架构模式是一种针对分布式系统中的微服务架构设计的模式它描述了如何将 不同的微服务组合在一起来实现复杂的业务功能。在微服务架构中每个微服务都是独立的、 自治的可以独立开发、部署和运行。使用不同模式开发的好处是可以根据实际业务场景进行 系统设计实现高度的可伸缩性和灵活性从而满足不同的业务需求。以下将介绍聚合器微服务( Aggregator Microservice)、代理微服务( Proxy Microservice)、 链式微服务( Chained Microservice)、分支微服务( Branch Microservice)、数据共享微服务 (Shared Data Microservice) 和异步消息微服务( Asynchronous Messaging Microservice)6种模式。1. 聚合器微服务随着微服务架构的流行系统中的服务数量越来越多服务之间的通信和数据处理变得越 来越复杂。在这种情况下聚合器微服务成为了一个重要的设计模式。它的主要目标是从多个 服务或数据源中收集、处理和聚合信息并将其转换为需要的数据格式。这种模式可以协调多个 服务之间的通信和数据处理流程提高系统的可扩展性和可维护性。聚合器微服务中的关键角色是聚合器 ( Aggregator) 。 聚合器可以是一个简单的Web 页面 只将从多个微服务中检索到的数据进行展示也可以由一个更高层级的微服务扮演聚合器的角 色。聚合器可以理解为一个中心化的服务它的主要功能是接收来自客户端的请求按照业务 逻辑将请求分发给后端的多个服务或数据源最终将这些数据进行处理、聚合和转换以生成 需要的数据格式并将其返回给客户端。聚合器微服务模式的示意图如图20-1所示。图20-1 聚合器微服务模式示意图从图20-1可以看出聚合器微服务模式的关键在于聚合器的设计它将作为用户与系统中 其他微服务交互的桥梁。在设计聚合器时通常需要具备以下几个功能(1)消息转发。聚合器作为消息处理的中心负责接收请求并将其转发给后端服务同时 返回的数据也将由聚合器进行统一传递。第20章 微服务系统分析与设计 693 (2)数据聚合。在聚合器中需要能够根据业务需求对来自多个服务或数据源返回的数据 进行聚合和转换以生成需要的数据格式。(3)数据缓存。为了提高性能聚合器通常会使用缓存技术缓存聚合后的数据以减少后 续重复请求的响应时间避免对于多个服务的高频调用。在聚合器微服务模式下聚合器成为了服务调用的中心这样设计可以带来以下几个 优点(1)减少网络延迟。通过将多个微服务的调用聚合在一起可以减少网络传输和延迟时间。 这意味着客户端可以更快地获得结果提高系统的响应速度和用户体验。(2)减少微服务之间的依赖。在传统的微服务架构中一个服务可能需要调用多个其他服 务才能完成一个请求这增加了服务之间的依赖关系和复杂性。聚合器微服务可以减少这种依 赖性使每个服务更加独立和可复用。(3)提高系统可靠性。聚合器微服务可以通过负载均衡和容错机制来提高系统的可靠性和稳定性保证系统在高负载和异常情况下的正常运行。(4)提高开发效率。聚合器微服务的设计可以使服务之间的通信和数据处理更加统一和直 观从而减少开发人员的开发工作量提高开发效率和代码质量。2. 代理微服务代理微服务是一种微服务架构的设计模式它提供了一种将客户端请求转发到后端服务的 中间层同时还可以实现一些常见的服务治理功能如负载均衡、故障熔断、限流等。代理微 服务可以有效地解耦客户端和后端服务之间的依赖关系提高系统的可伸缩性和可维护性。代理微服务通常由两部分组成代理网关和后端服务。代理网关是客户端和后端服务之间 的中间层负责接收和转发客户端请求并在请求到达后端服务之前进行一些服务治理的操作。 后端服务是实际处理请求的服务它们可以是单独的微服务、容器、虚拟机或物理机器。代理 微服务和聚合器微服务的区别在于代理微服务中代理仅委派请求或者进行数据的转换工 作并不会从后端服务中聚合数据但会根据业务需求的差别调用不同的微服务。代理微服务模式的示意图如图20-2所示。图20-2 代理微服务模式示意图694 系统分析师教程(第2版)代理微服务通常采用HTTP 或TCP 协议进行通信其中HTTP 协议更加常见。代理网关可 以支持多种HTTP 协议如HTTP/1.1、HTTP/2和 WebSocket等。客户端通过向代理网关发送 HTTP 请求来访问后端服务代理网关则将请求转发到对应的后端服务。代理网关通常支持多 种负载均衡算法如轮询、随机、加权轮询等以提高系统的可伸缩性和可用性。代理微服务的另一个重要功能是服务治理。服务治理是一种管理分布式系统中各个微服务 的方法它包括负载均衡、故障熔断、限流、服务发现等功能。代理网关通常可以通过配置文 件或API 接口来实现服务治理的功能。例如可以通过配置文件设置各个后端服务的权重实 现负载均衡也可以通过API 接口监控后端服务的健康状态实现故障熔断还可以通过限流 算法限制客户端请求的速率防止系统被过度请求而崩溃。3. 链式微服务链式微服务将多个微服务连接在一起形成一条微服务链。每个微服务负责完成特定的功 能同时将处理结果传递给下一个微服务以实现复杂的业务逻辑。链式微服务模式可以使系 统具有高可扩展性和灵活性并促进了代码重用和模块化。在链式微服务模式中每个微服务都是一个独立的服务单元它们可以通过API 调用相互 通信。每个微服务都处理特定的任务然后将结果传递给下一个微服务。每个微服务都可以有 自己的独立数据存储但是也可以共享数据存储。在链式微服务中收到请求后会在微服务中产生调用链使后续服务进行下一步处理并等 待返回结果。在后续的服务请求回传结果前客户端会一直阻塞等待链式调用完成。链式微服务的示意图如20-3所示。图20-3 链式微服务模式示意图链式微服务可以实现多种不同的应用程序场景。例如它可以用于实现工作流程将不同 的微服务连接在一起以处理工作流程中的各个阶段。它还可以用于实现电子商务网站 其 中 订单处理、库存管理和支付处理等任务可以由不同的微服务完成。链式微服务还可以用于实现 大型数据分析应用程序其中数据处理和分析任务可以由多个微服务完成这些微服务可以按 需进行动态扩展。4. 分支微服务分支微服务是链式微服务的扩展。在分支微服务中多个微服务将被组织在一起形成不 同的分支结构每个分支代表一种可能的业务场景或决策路径并通过链式调用相应请求。这 种模式使得应用程序可以根据不同的条件和事件来采取不同的行动从而实现更灵活和个性化 的业务逻辑。在分支微服务模式中每个分支都是一个独立的微服务单元它们根据输入数据和条件来 确定应该采取的下一步行动。每个分支可以选择执行一个或多个微服务或者跳转到另一个分 支以响应不同的业务场景或决策路径。分支微服务可以是串联的也可以是并行的具体取 决于应用程序的设计和需求。分支微服务的示意图如20-4所示。图20-4 分支微服务模式示意图分支微服务可以用于实现多种不同的应用程序场景。例如在电子商务网站中可以使用 分支微服务来处理订单流程根据不同的付款方式或送货地址选择不同的流程。在金融服务应 用程序中可以使用分支微服务来决定是否批准贷款或投资申请根据不同的信用评分和风险 评估。在物流和运输应用程序中可以使用分支微服务来确定最佳路线和交通方式以根据不 同的货物和目的地确定最佳的路线选择。5. 数据共享微服务数据共享微服务提供了一种在不同微服务之间共享数据的方法。通过共享数据不同的微 服务可以更加高效地协同工作实现更强大的业务逻辑和功能。在传统的单体应用程序中数据通常是在应用程序内部共享的因为应用程序内部的所有 组件都可以访问相同的数据。但是在微服务架构中每个微服务都是独立的并且有自己的 数据库和数据模型因此实现数据共享变得更加复杂。数据共享微服务模式解决了这个问题通 过将数据访问和管理集中在一个或多个微服务中来实现在不同微服务之间共享数据的目的。数据共享微服务的示意图如20-5所示。图20-5 数据共享微服务模式示意图数据共享微服务可以使用多种技术和方法来实现。其中一种方法是使用共享数据库即 将数据存储在单独的数据库中并让多个微服务共享该数据库如图20-5中的Service C和 Service D。这种方法可能会导致并发问题和数据一致性问题因此需要采取一些措施来确保数 据的安全性和正确性如使用事务和锁定机制。另一种方法是使用数据代理服务即在微服务 之间添加一个代理层用于管理和协调数据的共享。这个代理层可以是一个专门的数据代理微 服务也可以是一个数据共享框架如Apache Kafka或Apache Flink等。这种方法可以更好地 控制数据的共享和访问同时也可以提供更好的性能和可扩展性。数据共享微服务可以用于实现多种不同的应用程序场景。例如在电子商务网站中可以 使用数据共享微服务来共享产品信息和库存数据以便多个微服务可以共享相同的数据源并 保持数据的一致性。在金融服务应用程序中可以使用数据共享微服务来共享客户和账户信息 以便多个微服务可以共享相同的客户数据并实现更复杂的业务逻辑。6. 异步消息微服务异步消息微服务是一种基于消息传递的微服务架构其设计的目的是解决分布式系统中的 异步通信需求。在传统的同步通信模式中当服务A 向服务B 发送请求时服务A 必须等待服 务B 的响应才能继续执行。这种模式的缺点是如果服务B 出现了故障或者响应时间过长那 么服务A 就会一直处于等待状态从而导致整个系统的性能下降。相比之下异步消息通信模式允许服务A 向服务B 发送消息而不需要等待服务B 的 响 应。当服务B 处理完消息后可以向服务A 发送响应也可以将响应发送给另一个服务或者 将响应写入数据库中等等。这种模式的好处是由于请求发送后服务A 不需要等待响应因 此可以立即继续执行其他任务从而提高整个系统的性能和吞吐量。异步消息微服务的示意图如20-6所示。第20章 微服务系统分析与设计 697图20-6 异步消息微服务模式示意图在异步消息微服务架构中每个微服务都可以充当消息的生产者和消费者。当一个微服务 需要处理某些任务时它可以将消息发送到消息队列中然后另一个微服务从队列中获取消息 并处理。这种模式的好处是可以将不同的任务分配给不同的微服务处理从而提高系统的可 伸缩性和灵活性。为了实现异步消息通信模式异步消息微服务通常使用消息队列作为消息传递的中介。消 息队列是一种支持异步通信模式的消息传递机制它允许发送者将消息发送到队列中而不需 要等待接收者的响应。接收者可以随时从队列中获取消息并进行处理。消息队列还具有许多高 级功能如消息持久化、消息过期、消息重试、消息路由等这些功能都可以更好地管理和处 理消息。异步消息微服务架构的另一个核心概念是事件驱动架构 (Event-Driven Architecture,EDA)。 在事件驱动架构中系统中的各个组件都可以充当事件的生产者和消费者它们之间通过消息 队列进行通信。当一个事件发生时它会被发送到消息队列中然后订阅了该事件的组件会从 队列中获取事件并进行处理。这种架构可以实现高度松耦合的系统设计从而提高系统的可维 护性和扩展性。总的来说异步消息微服务是一种基于消息传递和事件驱动的微服务架构它可以实现 高性能、可伸缩和可靠的分布式系统。通过使用消息队列作为消息传递的中介异步消息微 服务架构可以实现异步通信模式从而提高系统的性能和吞吐量。同时事件驱动架构可以实 现高度松耦合的系统设计从而提高系统的可维护性和扩展性。异步消息微服务已经被广泛 应用于各种场景如电子商务、金融、物联网等领域它是构建现代分布式系统的重要技术 之一。
)
