微服务

一种开发应用所用的架构形式

微服务

微服务（英文名：Microservices），也称为微服务架构，[11]是指开发应用所用的一种架构形式。可将大型应用分解成多个独立的组件，其中每个组件都有各自的责任领域。[12][13]微服务与传统的单体式开发方式有很大的区别。[1]微服务中的每个独立组件都在自己的进程中运行，并通过轻量级的机制（通常是基于HTTP协议的RESTful API）进行通信和协作，以实现具体的业务功能和价值。根据需要，微服务可以采用不同的编程语言和数据存储技术，并在不同环境中，通过自动化的方式进行独立部署和扩缩，使服务之间的管理尽量简化。[12][14]微服务是由传统的单体式开发发展而来的，[15]最早由Peter Rodgers（彼得·罗杰斯）在2005年提出，当时他把这种模式称为“Micro-Web-Service”。[4]2011年5月，在威尼斯举行的一个软件架构会议上构架师们首次提出“微服务”这个概念，用来描述一种他们共同的想法。[16]2014年，Martin Fowler（马丁·福勒）发表了一篇关于微服务的文章，这篇文章详细介绍了微服务架构的概念和特点，从而推广了这种软件架构风格。[14]之后，受数字化转型、客户导向和微服务架构本身的优势的驱动，微服务的市场价值持续增长。[17]

微服务（英文名：Microservices），也称为微服务架构，[12]是指开发应用所用的一种架构形式。可将大型应用分解成多个独立的组件，其中每个组件都有各自的责任领域。[13][14]微服务与传统的单体式开发方式有很大的区别。[2]微服务中的每个独立组件都在自己的进程中运行，并通过轻量级的机制（通常是基于HTTP协议的RESTful API）进行通信和协作，以实现具体的业务功能和价值。根据需要，微服务可以采用不同的编程语言和数据存储技术，并在不同环境中，通过自动化的方式进行独立部署和扩缩，使服务之间的管理尽量简化。[13][15]

微服务是由传统的单体式开发发展而来的，[16]最早由Peter Rodgers（彼得·罗杰斯）在2005年提出，当时他把这种模式称为“Micro-Web-Service”。[5]2011年5月，在威尼斯举行的一个软件架构会议上构架师们首次提出“微服务”这个概念，用来描述一种他们共同的想法。[17]2014年，Martin Fowler（马丁·福勒）发表了一篇关于微服务的文章，这篇文章详细介绍了微服务架构的概念和特点，从而推广了这种软件架构风格。[15]之后，受数字化转型、客户导向和微服务架构本身的优势的驱动，微服务的市场价值持续增长。[18]

微服务的特点是灵活扩展、自动化管理、数据分离、弹性等，这些特点带来了开发和维护的便利，提高了团队的效率和灵活性，增强了系统的可用性和容错性等。[19]微服务广泛应用于互联网、物联网、电商、金融等领域。[2][3][4]

发展历程

软件架构的发展经历了几个阶段，从单体架构、垂直架构、SOA架构到微服务架构。[16]

微服务的发展阶段
微服务的发展阶段

单体架构

2005年，Peter Rodgers（彼得·罗杰斯）在Web Services Edge会议上提出了“Micro-Web-Service”这个术语，他主张使用支持微网络服务的软件组件，而不是传统的思维方式，并在演讲中介绍了“软件组件即微Web服务”的观点。[5]该观点建立了微服务的功能模型——单体结构，该架构是一种把所有的代码都放在一个项目里的简单架构风格。这种架构的代码之间耦合度高，系统变更会影响部署，开发效率低，部署结构复杂，系统启动慢，可用性和扩展性差。适用于规模小的系统，或者需要快速原型的场景，不太关注质量。[16][20]

垂直架构

2011年5月，一些软件架构师在威尼斯附近举行了研讨会，他们提出了“微服务”这个概念，用来表达一种他们观察到的常见的架构模式——垂直结构，这是他们当时一直在尝试的一种风格。[17]该架构是一种把一个复杂的单体应用按业务功能拆分成多个小型的、独立的应用，每个应用都可以自己部署和运行，通过网络协议和其他应用协作的软件架构风格。垂直架构是一种过渡性的架构模式，它是从单体架构向微服务架构的演进。[16]

SOA架构

2012年3月，Thoughtworks首席咨询师James Lewis（詹姆斯·路易斯）在波兰克拉科夫举办的33rd Degree Conference大会上，做了一场题为《Microservices-Java，the Unix Way》的演讲。在这场演讲中，James讨论了微服务的一些原则和特征，例如单一服务职责、康威定律、自动扩展、DDD[注1]等。[21]在同年4月，Netflix的前云系统架构总监 Adrian Cockcroft（阿德里安·科克罗夫特）在一次会议中，将这种构架风格描述为“fine-grained SOA（细粒度SOA）”。[22]SOA构架是一种面向服务的软件设计方式，微服务架构在一定程度上是SOA架构的进一步发展的产物。而SOA架构是取代单体架构的垫脚石，它提供了一个更加灵活和敏捷的环境。[23]

微服务架构

2012年11月，Fred George（弗雷德·乔治）在一次技术大会上，首次提出了“微服务架构”的概念，并在演讲中阐述了如何将一个复杂的系统拆分为多个松耦合的服务，这是微服务架构的最初雏形。[24][15]这是一种面向服务架构的专业化实现方法，它用于构建灵活的、可独立部署的软件系统。[25]Martin Fowler（马丁·福勒）于2014年发表了一篇关于微服务的文章，这篇文章详细介绍了微服务架构的概念和特点，从而推广了这种软件架构风格。[15]2016年2月，Lightbend公司的创始人兼CTO Jonas Bonér（乔纳斯·博内尔）发布了一篇名为《响应式微服务架构》的文章。在这篇文章中，他探讨了如何基于响应式原理设计微服务架构，以及如何利用这种架构构建可扩展、可应对故障的隔离服务，并与其他服务协同以形成一个高效的整体。[26]

2018年，根据《云微服务市场研究报告》推断，2018年微服务市场价值为6.832亿美元，截至2023年，市场价值增长至18.80亿美元，复合年增长率为22.4%，而推动市场发展的主要因素包括数字化转型、微服务架构的普及以及以客户为导向的业务，在此研究中，2017年被视为基准年，2018至2023年被视为预测期。2023年4月，根据《云微服务市场研究报告》，微服务市场价值五年后将预计达到2.70136亿美元，预测期内的复合年增长率约为21.7%。[27][18]

微服务架构与SOA构架

微服务架构和SOA架构都是一种将应用程序拆分为多个协作的服务的软件设计方式。但是，它们之间也有一些区别，主要体现在以下几个方面：

（1）服务粒度：微服务的粒度更小，更专注，每个微服务只负责一个业务功能，而SOA服务的粒度更大，可能包含多个业务功能；[23]

（2）服务通信：微服务架构中，每个服务有自己的通信协议，不依赖于其他服务。而在SOA架构中，所有服务都通过一个叫做企业服务总线（ESB）的通信机制来交互。SOA依靠ESB来管理和协调服务，但如果ESB或某个服务出现故障或延迟，会影响整个系统；[23]

SOA架构与微服务架构的通信差异
SOA架构与微服务架构的通信差异

（3）服务数据：SOA架构通常有一个共享的数据存储层，供所有服务使用，而微服务架构中，每个服务有自己的数据存储服务或数据库；[23]

（4）服务部署：微服务可以独立部署，而SOA服务通常需要部署到一个统一的应用服务器平台上。[28]

与传统开发模式的区别

传统的开发方式一般被称为单体式开发（Monolithic）。微服务构架与传统的单体式架构有很大的不同，在传统的单体架构中，应用程序的所有功能和特性都集成在一个可执行的应用程序中，所有任务都在一个大型项目中进行。[2]而微服务架构风格，是将系统分为一系列低耦合[注2]的微服务，每个服务可以独立部署和运行，服务之间通过REST[注3]等方式进行通信和协作，同时利用自动化的测试和运维技术减少服务拆分带来的复杂性。[16]

单体式构架与微服务构架区别
单体式构架与微服务构架区别

服务注册与发现

服务注册与发现是一种用于管理微服务实例地址变化的技术。它可以让微服务之间通过一个统一的服务名来进行通信，而不需要知道对方的具体位置。它主要包括两个组件：服务注册中心和服务发现客户端。服务注册中心是一个中心化的组件，负责存储所有微服务实例的位置信息（如IP地址和端口号），以及提供查询和更新这些信息的接口。服务发现客户端是微服务的一部分，负责向服务注册中心注册自己的信息，以及从服务注册中心获取其他服务的信息。[6]

API网关

API网关是一种用于统一管理微服务的访问入口的技术。它可以提供一些公共的功能，如鉴权认证、路由转发、负载均衡、限流熔断、日志监控等，以减轻微服务的负担，提高系统的安全性和可用性。API网关还可以实现协议转换，将外部的HTTP请求转换为内部的RPC[注4]或者消息调用，以适应不同的通信方式。[7]

服务通信

服务通信是指微服务之间如何进行数据交换的问题。服务通信的方式一般有两种：同步通信和异步通信。同步通信是指服务之间直接调用对方的接口，等待返回结果，这种方式简单直接，但是会增加服务之间的耦合度，影响系统的可靠性和性能。异步通信是指服务之间通过消息中间件进行数据传递，不需要等待对方的响应，这种方式可以降低服务之间的耦合度，提高系统的可扩展性和容错性，但是会增加系统的复杂性和一致性问题。[19][8]

服务监控

服务监控是一种用于实时观测和分析微服务的运行状况的技术。它可以收集和展示微服务的各种指标，如响应时间、吞吐量、错误率、资源利用率等，以帮助开发者和运维人员发现和定位系统的性能问题和故障。服务监控还可以实现告警机制，当系统出现异常时，及时通知相关人员，以减少系统的损失。[9]

数据管理

数据管理是指如何处理微服务之间的数据依赖和一致性的问题。由于微服务架构中，每个服务都有自己的数据库，这样可以提高服务的自治性和隔离性，但是也会导致数据的冗余和不一致。[10]

容器化

容器化是一种用于简化微服务的部署和运维的技术。它可以将微服务的代码和依赖打包到一个轻量级的、可移植的、隔离的、可复用的容器中，从而实现快速、一致、可靠的部署和运行。容器化还可以实现跨平台的兼容性，让微服务可以在不同的环境中运行，无需修改代码或配置。容器化的主要工具有Docker、Kubernetes等。[19][11]

持续集成/持续部署（CI/CD）

持续集成/持续部署（CI/CD）是一种用于提高微服务的开发效率和质量的技术。它可以实现微服务的自动化构建、测试、发布和部署，从而缩短开发周期，降低人为错误，提升用户满意度。[29]

聚合器设计模式

聚合器微服务设计模式是一种常见的微服务设计模式，它有两种形式。一种是聚合器作为一个网页，它通过调用多个轻量级的REST服务，获取数据并进行处理和显示，实现应用程序所需的功能。另一种是聚合器作为一个复合微服务，它不需要显示，而是从多个单独的微服务收集数据，对其应用业务逻辑，然后将其作为一个REST端点发布，供其他服务消费。这种设计模式遵循DRY原则[注5]，如果有多个服务需要访问同样的服务组合，那么将这个逻辑抽象为一个复合微服务，可以提高系统的灵活性和可维护性。如果聚合器是一个复合微服务，那么它也可能有自己的缓存和数据库层，以提高系统的性能和可靠性。[30][31]

聚合器设计模式
聚合器设计模式

代理设计模式

代理微服务设计模式和聚合器微服务设计模式有些相似，但有一些区别。聚合器微服务设计模式是在客户端把多个服务的数据聚合起来，而代理微服务设计模式是在服务端根据业务需求选择调用不同的服务。代理有两种类型，一种是哑代理，它只是简单地把请求转发给某个服务。另一种是智能代理，它可以对请求或响应做一些数据处理。一个智能代理的例子是，它可以根据不同的设备类型，提供不同的界面显示。[30][31]

代理设计模式
代理设计模式

链式设计模式

链式微服务设计模式是一种微服务设计模式，它通过多个服务的协作来生成一个请求的响应。客户端的请求先被服务A处理，然后服务A再把请求传给服务B，服务B也可能再把请求传给服务C，以此类推。这些服务之间都是用同步的HTTP请求和响应来通信的。这种设计模式的一个重要注意事项是，不要让服务链太长，因为这样会导致客户端等待的时间过长，尤其是如果客户端是一个需要显示响应的网页的话。[30][31]

链式设计模式
链式设计模式

分支设计模式

分支微服务设计模式是在聚合器微服务设计模式的基础上，增加了更多的灵活性和选择性。它可以根据业务需求，同时或者分别调用两条可能相互冲突的微服务链，从而得到不同的响应。作为一个网页或者一个复合微服务，可以根据客户端的请求，选择调用两条链中的一条或者两条，从而实现不同的功能。[30][31]

分支设计模式
分支设计模式

数据共享设计模式

数据共享微服务设计模式和其他模式的不同之处在于，它让两个服务使用同一个数据源。这和微服务的设计原则之一自治有些冲突，因为自治要求每个服务都是全栈的，有自己的UI、中间件、持久化和事务层。但是，在实际的开发过程中，往往是从一个复杂的单体应用逐步演化成微服务架构的，而不是一开始就完全按照微服务的方式来设计。在这个过程中，有些数据可能很难分离，它们可能涉及到多个服务的业务逻辑。为了提高效率，可以暂时让这些服务共享数据，但这只是一个过渡阶段，最终的目标还是要让每个服务拥有自己的数据，实现真正的解耦。[30][31]

数据共享设计模式
数据共享设计模式

异步消息传递设计模式

异步消息传递微服务设计模式可以克服REST设计模式的同步和阻塞的缺点。它使用消息队列来实现服务之间的异步通信，从而提高系统的性能和可靠性。例如，服务A可以先同步地向服务C发送请求，然后服务C可以通过消息队列异步地与服务B和服务D交互。服务A和服务C之间的通信也可以是异步的，这样可以更好地支持可伸缩性的需求。这种设计模式并不排斥REST请求/响应，它们可以根据业务需求结合使用。有些情况下，使用REST请求/响应可能更简单或更合适，有些情况下，使用异步消息传递可能更灵活或更高效。[30][31]

异步消息传递设计模式
异步消息传递设计模式

支持工具

工具简介logo参考
Docker[32]Docker是一个开源的应用容器引擎，它可以让开发者将应用和依赖包打包到一个可移植的容器中，并部署到任何支持Linux的机器上。基于Docker容器的微服务架构系统，可以通过容器编排、自动弹性伸缩、自动修复和监控管理等功能，实现高效的集成部署和运维，降低用户的成本和难度。利用Docker容器技术，还可以开发出数据库微服务系统，该系统具有快速和高扩展性的优势，为大数据处理提供了可靠的技术保障
Docker
Docker

[33][34]
Spring Cloud Gateway[35]微服务是由很多服务组合而成的系统，为了保证服务之间的通信和安全，需要使用API网关来进行鉴权、限流、权限校验等功能。Spring Cloud Gateway是一种常见的API网关工具，它可以与Ribbon配合，实现微服务的负载均衡，提高系统的可用性和性能/[1]
Apache Kafka[36]Apache Kafka是一个分布式的消息队列系统，它具有高吞吐量、可扩展性、持久性、高可用性和容错能力等特点。它采用发布–订阅模式传递消息，适合于实时流处理和大规模数据处理的场景。随着业务量的增长，Kafka可以支持更大的消息处理能力和更高的吞吐量，满足不同的需求
Apache Kafka
Apache Kafka
[37][38]
Nacos[39]Nacos是一种服务注册与发现工具，它可以维护微服务的状态和位置，实现负载均衡和故障转移。Nacos不仅拥有更好的负载均衡策略，还支持DNS访问协议和动态更新，使得微服务可以更灵活地适应变化。此外，Nacos还支持配置中心，可以将配置统一集中管理，简化配置的维护和更新。Nacos的部署也非常方便，只需要在官网下载Jar包，就可以启动服务，无须创建新的应用实例
Nacos
Nacos
[1]
Jenkins[40]Jenkins是一个持续集成和持续交付的工具，它可以实现自动化的构建、测试、部署和监控等功能，支持多种插件和脚本，支持流水线和分布式的方式。Jenkins可以作为微服务的自动化运维和交付平台
Jenkins
Jenkins
[1][41]

核心特点

微服务架构由离散组件和服务组成，它们的相互通信和数据交换创造了一个完整应用程序的功能。[42][19]微服务设计的典型特征包括以下几点：

灵活扩展：微服务允许独立地扩展各个服务以满足其所支持的应用程序功能的需求。这使得团队能够适当地调整基础设施需求，准确地衡量功能成本，并在服务需求激增时保持系统的可用性。[19][42]

自动化管理：微服务支持持续集成和持续交付，使得新版本的发布和故障时的回滚变得轻松。由于故障成本较低，因此可以更轻松地更新代码，并缩短新功能的上市时间。[19][42]

数据分离：在微服务架构中，每个微服务组件几乎没有依赖关系，[19][42]这种设计可以确保数据的一致性和独立性，避免了不同服务之间的数据耦合，提高了系统的稳定性和可扩展性。[15][42]

弹性：服务的独立性增加了应用程序对故障的弹性。在整体式架构中，如果一个组件出现故障，可能会导致整个应用程序无法运行。然而，通过微服务，应用程序可以在面临全局服务故障时通过降低功能来避免整个应用程序崩溃。[19][14]

优势

易于开发与维护：每个微服务都专注于一个特定的业务功能，其代码量较少且逻辑清晰，这使得开发和维护变得更加容易。此外，每个微服务可以独立部署，无需等待整个应用程序的更新，也不会影响其他服务的运行。[19][42]

提高团队的效率和灵活性：在微服务架构中，每个服务模块都可以使用不同的语言和工具进行开发，并部署在不同的平台上。微服务组件之间通过API进行网络通信，这为应用程序开发带来了极大的灵活性。此外，模块化的应用程序组件可以被其他应用程序重复使用，从而进一步简化应用程序设计的投资并加快开发时间。[19][42]

提高系统的可用性和容错性：由于微服务应用程序的每个组件都是独立运行的，因此监控每个组件的运行状态和性能以及管理大型应用程序的运行变得更加容易。此外，可以根据需要对特定的服务进行扩展，这种灵活性使得系统能够更好地应对变化的需求和负载，从而提高了系统的可用性。[19][42]

挑战

分布式复杂性高：分布式操作可能会带来一定的复杂性，这使得理解和排除故障变得困难。此外，分布式操作可能效率较低，并可能涉及到服务之间的紧密运行时耦合，这可能会降低其可用性。由于远程通话速度较慢，并且始终存在失败的风险，因此分布式系统的编程可能更具挑战性。[3][42]

性能影响：尽管微服务容器为其任务提供了出色的计算性能，但许多容器必须通过网络进行通信才能使整个应用程序正常运行。网络拥塞和延迟可能会影响性能，并可能抵消这些单独的性能优势。此外，支持应用程序的微服务数量可能需要额外的网络管理和控制，并可能需要多个负载均衡实例。[19][42]

网络限制和安全风险：微服务组件依赖于网络上的API驱动的通信。这可能会在带宽和延迟方面给现有的企业网络带来巨大压力。如果众多微服务应用程序在企业环境和基础设施中同时工作，这种压力可能会进一步增加。某些微服务采用者可能需要进行网络升级，以支持繁忙的微服务应用程序的通信需求。此外，在复杂的微服务环境中，网络漏洞和安全风险可能会加剧。[19][42]

部署及检测困难：微服务应用程序环境可能非常复杂，需要监视和报告为构建应用程序而部署的所有组件。这些组件的短暂性质加剧了这一挑战，必须在部署和删除这些组件时对其进行监控。这需要高水平的运行状况和性能监控，以及自动化和编排。[19][42]

平台对比

功能Spring CloudApache DubboKubernetes服务发现Spring Cloud Netflix Eureka[注6]Zookeeper[注7]、Nacos[注8]Kubernetes Services[注9]服务调用REAT API[注10]RPC[注11]REAT API[注10]服务网关Spring Cloud Zuul[注12]、Spring Cloud Gateway[注13]Kong[注14]、Dubbo Proxy[注14]、Zuul[注15]Kubernetes Service[注16]、Ingress resources[注17]、Istio[注18]、Ambassador[注19]配置中心Spring Cloud Config[注20]、Netflix Archaius[注21]Zookeeper[注7]、Apollo[注22]Kubernetes ConfigMaps[注23]负载均衡Spring Cloud Ribbon[注24]Random[注25]，RoundRobin[注26]，LeastActive[注27]Kubernetes Service[注16]分布式跟踪Spring Cloud Sleuth[注28]、Zipkin[注29]Dubbo-opentracing[注30]、Zipkin[注30]Hawkular[注31]、Jaeger[注32]熔断器Spring Cloud Hystrix[注33]Alibaba Sentinel[注34]Health check[注35]、service meshes[注36]消息驱动Spring Cloud Stream[注37]RocketMQ[注38]、Kafka[注39]NATS[注40]、RabbitMQ[注41]logo参考资料[43][44][45][46][47]

应用领域

微服务的应用领域非常广泛，包括互联网、物联网、电商、金融领域等。[4]例如，Netflix、亚马逊、Spotify、谷歌、eBay和Thoughtworks等都是典型的微服务架构的应用。[2][3]

互联网企业

互联网企业（例如Amazon、Netflix、Uber 和 Etsy）将其IT的成功计划部分转向微服务的采用。这些企业完成了他们的单一应用程序，然后，将其重构为微服务的架构，以快速实现扩展优势、更高的业务敏捷性和难以想象的利润。[48]

物联网

在物联网中运用微服务可以开发一系列全新的端点设备、应用程序服务器、数据库和基于人工智能的分析工具，其连接性可在本地或云端的部署中，提供所需通信的定制信号，而由于微服务架构中存在松散连接，对于大型系统的吸引力可以降低，并通过安全更新快速修复，微服务架构的FPGA特性能够快速引入新服务或替换旧服务，从而取消应用程序，在收集和处理关键数据时[注42]，可以更快或更安全的在本地部署服务。[49]

电商

微服务在电商领域运用有缩放、误隔离、提供技术堆栈独立性、确保数据安全等优点，凭借松散耦合的架构，可以轻松与任何第三方系统集成。使用更少的资源，升级速度更快，电子商务微服务架构有利于快速数据交换，可以给企业带来新机遇，另一个好处是可以更好的开发微服务框架。[50]

金融领域

在金融领域采用微服务有敏捷、可扩展性、力弹、安全等优点，微服务允许公司独立于整个应用程序进行试验、开发、测试和部署新功能，而不影响当前向公众提供的服务，从而增强金融机构应对这些变化的能力。微服务允许金融机构根据流经特定服务的流量独立扩展特定的应用程序部分。因为它提供了缩小某些服务规模和扩大其他服务规模的选项，同时确保将资源分配到最多需要的地方。微服务使金融组织能够更轻松地隔离和解决问题，从而恢复弹性的应用程序。微服务架构可以极大地提高安全性，因为服务弥漫独立，并且可以通过不同级别的保护进行隔离。[51]

无服务器微服务

微服务领域最重要的趋势之一是无服务器计算的采用，无服务器微服务允许组织构建和部署单独的功能或组件，而无需管理服务器。这种方法增强了微服务的可扩展性、敏捷性，优化了资源分配，减少了运营开销，加快了开发周期。无服务器计算在微服务中越来越受欢迎，抽象化基础设施管理使开发人员能够专注于代码，该趋势成为微服务架构的游戏规则改变者。[52]

容器化和Kubernetes

Kubernetes已经成为微服务容器编排平台，用于管理和自动化微服务的部署、扩展和监控。凭借其强大的编排功能，简化了大规模微服务的管理，确保了弹性和高效的资源利用，使其成为微服务架构的核心部分，由Kubernetes等平台提供支持的容器化是一个关键趋势，容器提供了跨不同环境打包和部署微服务的一致性。[52]

事件驱动架构

事件驱动的架构在微服务中允许微服务通过事件进行异步通信，从而实现更好的解耦、可扩展性和响应能力。Apache Kafka和RabbitMQ等技术有助于实现事件驱动的微服务，非常适合物联网、实时分析和需要无缝集成的应用程序。[52]

人工智能和机器学习

人工智能和机器学习是微服务不可或缺的一部分，它们在基于微服务的应用程序中实现预测分析、个性化推荐和自动化决策。人工智能驱动的微服务可以增强用户体验、优化资源分配并从数据中发现有价值的见解。[52]

微前端

微前端将微服务概念扩展到用户界面，将前端分解为更小的、可独立部署的单元，与微服务的原则保持一致。这种趋势有利于前端组件的持续交付，从而实现更快的更新并改善用户体验。[52]

参考资料 52

  1. 参考 1
  2. What is Microservice Architecture? — ionos
  3. Pattern: Microservice Architecture — microservices.io
  4. Microservices in Industry: Insights into Technologies, Characteristics, and Software Quality — researchgate.net
  5. micro-service — predixteam.files.wordpress
  6. Service Discovery in a Microservices Architecture — nginx.com
  7. Building Microservices: Using an API Gateway — nginx.com/
  8. Building Microservices: Inter-Process Communication in a Microservices Architecture — nginx.com
  9. Pattern: Distributed tracing — microservices.io
  10. Event-Driven Data Management for Microservices — nginx.com
  11. deploying microservices — nginx.com
  12. What are microservices? — microservices.io
  13. 什么是微服务架构 — cloud.google
  14. 什么是微服务? — aws.amazon
  15. Microservices — martinfowler
  16. 基于Dubbo、Spring Cloud和ServiceMesh — msainaction.github.io
  17. https://www.google.co.jp/books/edition/Present_and_Ulterior_Software_Engineerin/KW48DwAAQBAJ?hl=zh-CN&gbpv=1
  18. Cloud Microservices Market Dynamics — marketsandmarkets
  19. What are microservices? Everything you need to know — techtarget
  20. A Brief History of Microservices — dataversity-net
  21. Demanding Professionalism — 2012.33degree.org
  22. Cloud Computing Done the Netflix Way — cio.com
  23. SOA vs. Microservices: What’s the Difference? — IBM
  24. Fred George — archive.oredev.org
  25. 构建未来：用微服务智慧为您的应用程序提供支持 — Medium
  26. Defining a reactive microservice — oreilly
  27. Cloud Microservices Market - Growth, Trends, COVID-19 Impact, and Forecasts (2023-2028) — researchandmarkets
  28. SOA 和微服务有什么区别? — aws.amazon.com
  29. CI/CD for microservices architectures — learn.microsoft.com
  30. THE TOP SIX MICROSERVICES PATTERNS — MuleSoft
  31. What Are Microservices Design Patterns? — Codemotion
  32. Docker:
  33. 参考 33
  34. http://cww.cww.net.cn/pdf/7A6977662975499AA9744FB94946198A.pdf
  35. Spring Cloud Gateway
  36. Apache Kafka
  37. https://www.hanspub.org/journal/PaperInformation?paperID=77392
  38. https://ieeexplore.ieee.org/document/9446179?denied=
  39. Dynamic DNS Service
  40. Jenkins
  41. https://arxiv.org/pdf/2008.07729.pdf
  42. What are Microservices? Characteristics, Examples, and Pros & Cons of It — ashutec
  43. Spring Cloud中文网 — springcloud.cc
  44. Spring Cloud — spring.io
  45. 概念与架构 — cn.dubbo.apache.org
  46. Featured — developers.redhat
  47. 服务、负载均衡和联网 — kubernetes.io
  48. 4 Microservices Examples: Amazon, Netflix, Uber, and Etsy — dreamfactory
  49. Why microservices and IoT apps are perfect together — techtarget
  50. Microservices Architecture in eCommerce — /vuestorefront
  51. The Benefits of Microservices in the Financial Sector — dragonspears
  52. The Future of Microservices Architecture and Emerging Trends. — blog

注释

  1. DDD是一种软件开发方法论，它的全称是领域驱动设计（Domain-Driven Design）。它的核心思想是以业务领域为中心，通过建立和维护一个与业务需求紧密相关的领域模型，来提高软件的质量和可维护性。
  2. 耦合是指两个或多个系统或组件之间的相互作用关系，当一个系统或组件发生变化时，会影响或受到另一个系统或组件的影响。
  3. REST是一种软件架构风格，它描述了如何设计和开发网络应用。REST的全称是Representational State Transfer，意思是通过表现形式（如JSON，XML等）来传递资源（如数据）的状态。
  4. RPC是远程过程调用（Remote Procedure Call）的缩写，它是一种通过网络从远程计算机上请求服务的协议。RPC可以让客户端像调用本地方法一样调用远程的方法，而不需要了解底层的网络细节。
  5. DRY原则是一种编程和设计的基本原则，它的全称是Don’t Repeat Yourself，意思是不要重复你自己。DRY原则的目的是减少重复的信息，提高代码的可维护性、可读性和可扩展性。
  6. Spring CloudEureka是Spring Cloud Netflix微服务套件中的一部分，它基于Netflix Eureka做了二次封装，主要负责完成微服务架构中的服务治理功能。
  7. ZooKeeper是一个分布式的、开放源码的分布式应用程序协调服务。
  8. Nacos是一个开源的动态服务发现、配置管理和服务管理平台，它是阿里巴巴公司开源的项目之一。
  9. Kubernetes Service用于为一组提供服务的Pod抽象一个稳定的网络访问地址，是Kubernetes实现微服务的核心概念。
  10. 拿来描述一个类库的特征或是如何去运用的程序接口
  11. 全称为远程过程调用（Remote Procedure Call），是一种计算机通信协议。
  12. Spring Cloud Zuul是Spring Cloud的一个组件，是一种服务网关，可以帮助构建基于微服务的应用程序。
  13. Spring Cloud Gateway是Spring Cloud官方推出的一款第二代网关框架，设计用来替代之前的Zuul网关。
  14. Apache Dubbo的一个扩展接口
  15. Zuul是Netflix开源的一个网关组件API Gateway服务器，在云平台上提供动态路由，监控，弹性，安全等边缘服务的框架。
  16. Kubernetes Service用于为一组提供服务的Pod抽象一个稳定的网络访问地址,是Kubernetes实现微服务的核心概念。
  17. ingress resources就是一个类型为Ingress的k8s api对象了，这部分则是面向开发人员。
  18. Istio是一个开源的、用于服务治理的开放式平台，它提供了一系列功能，如连接、安全、控制和观测，以简化和增强微服务架构的部署和管理。
  19. Ambassador是一个基于Envoy构建的Kubernetes原生API网关，专为微服务而设计，它本质上是一个Envoy入口控制器，但具有更多功能。
  20. Spring Cloud Config是一个基于Spring Cloud的配置管理工具，它可以帮助开发人员更好地管理和分发配置。
  21. archaius是Netflix公司开源项目之一，基于java的配置管理类库，主要用于多配置存储的动态获取。
  22. Apollo是分布式配置中心。
  23. ConfigMap是一种api对象，用来非机密性的数据保存到键值对中。
  24. Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。
  25. 每次随机调用一台服务提供者的服务。
  26. 是dubbo里面提供的按照权重进行轮询的负载均衡算法。
  27. 最少活跃调用数
  28. 是Spring Cloud提供的分布式系统服务链追踪组件
  29. Zipkin 是一个开源的分布式追踪系统，它能够收集服务间调用的时序数据，并提供调用链路的追踪。
  30. 分布式跟踪系统
  31. 属于开源监控解决方案
  32. 一款调用链追踪系统
  33. 是一个用于实现服务熔断和降级的组件
  34. 一款高性能且轻量级的流量控制、熔断降级可替换方案
  35. 用于检测应用实例是否正常工作
  36. 是微服务时代的 TCP/IP 协议
  37. 是一个建立在Spring Boot和Spring Integration之上的框架，有助于创建事件驱动或消息驱动的微服务。
  38. RocketMQ是一款由阿里巴巴开源的高性能、高吞吐量的分布式消息中间件，它旨在为分布式系统和互联网应用提供异步解耦、削峰填谷以及海量消息堆积等功能。
  39. Kafka是一个开源的流处理平台，由Apache软件基金会开发，主要用Scala和Java编写。
  40. 一个开源的，云原生的消息系统
  41. 开源消息代理软件
  42. 尤其是当数据存在于传承系统中时
广告位：底部（ad-bottom）—— 请到中台「公共区块」编辑此内容