⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 dzone.com/articles/9-fundamentals-to-a-successful-microservice-design 「Akshay Pai」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

人体是不同系统的组合，其中大多数系统是独立的，并且作为一个整体协同工作。每个系统都有自己的特定功能。所有具有多种其他支持框架的器官构成了一个功能完备的机构。现在，如果应用于软件系统，这就是微服务架构的概念。

在技术方面，微服务系统允许开发单个功能模块。这种开发单一功能模块的趋势为大型和小型组织提高了灵活性，性能和成本效率，同时实现了持续测试和早期交付。但是，在我们深入研究微服务设计的基础知识之前，让我们先看看它的优点。

微服务架构的优点

对于单一体系结构，开发人员经常面临有限的可重用性和可伸缩性的挑战。但是，通过微服务设计，可以将这个单元分解为不同的模块，从而简化开发，部署和维护。那么让我们来看看微服务架构的一些主要优点：

技术灵活性

虽然单片架构总是让开发人员寻找“适合工作的工具”，但是微服务架构在一个掩护下提供了多种技术的共存。不同的解耦服务可以用多种编程语言编写。这不仅使开发人员能够进行试验，而且还可以通过添加额外的特性和功能来扩展他们的产品。

提高效率

微服务架构加速了整个创建过程。与单个单元不同，团队可以同时处理软件系统的多个组件。除了提高生产率之外，还可以更轻松地定位特定组件并专注于它们。单个组件的故障不会影响整个系统。相反，这也简化了错误定位和维护。

产品不是项目

根据Martin Fowler的说法，微服务架构可以帮助企业创建“ 产品而不是项目 ”。简单来说，微服务架构的使用允许团队聚集在一起并为业务创建功能而不是简单的代码。整个团队聚集在一起，为不同的功能做出贡献。如果适用，这些可以进一步用于不同的业务。此外，它还创建了一个自主的跨职能团队。

成功的微服务设计的基础知识

现在我们知道微服务架构的优势，但是，我们如何实现完美？我们是否了解微服务设计原则？设计微服务架构的最佳实践是什么？让我们回答这些问题，看看成功的微服务设计的一些基础知识。

1.功能范围

通过不同团队同时实施开发和部署以建立或支持与产品分别独特的功能，定义微服务的范围成为非常重要的任务。虽然许多人担心创建“太多”小型微服务，但通常更常见的是这些微服务过载。

当我们谈论微服务的范围时，我们指的是独立软件模块的功能。微服务作为几乎无状态系统的能力使其能够独立开发。因此，必须确定微服务将实现的功能。这有助于理解微服务的责任吗？实现每个微服务应该服务的预期功能。不仅要防止过载，还要服务于不同的场景。例如，在单片设置中多次调用一段代码，创建微服务将使其更易于访问和使用。最小化代码量只会提高效率并避免膨胀的服务。

问题是关于如何定义微服务的范围。虽然没有明确定义的规则集来实现这一目标，但如果您可以定义范围，则可以使用一些指南或最佳实践。以下是您可以用来定义微服务的一些步骤。

1、第一步是确定在各种模块下复制的代码片段。你经常看到它们重复吗？每次在不同的模块中设置它们需要花费多少精力？如果所有这些的答案都很高，那么微服务的范围就是只处理重复的代码片段。

2、您可以采取的另一个步骤是检查模块是否不依赖于其他模块或更简单的术语，检查模块是否可能与其余服务松散耦合。如果是这样，那么微服务的范围将是整个模块的范围。

3、在定义范围时要考虑的另一个非常重要的指标是检查功能是否将用于重负载。这将检查微服务是否必须在不久的将来扩展。如果确实如此，那么将可扩展位定义为微服务的范围而不是将其与其他功能相结合是一个好主意。

2.高内聚力与松耦合

任何微服务的主要动机是使服务彼此独立。这意味着可以编辑，更新或部署新服务，而不会妨碍任何其他服务。如果相互依赖性很低，这是可能的。松散耦合的系统是一个服务对其他服务知之甚少或什么都不知道的系统。

在将整体架构分解为更小的服务或组件时，将类似功能组合起来非常重要。将相关逻辑组合成单个单元是已知的内聚。内聚力越高，微服务架构越好。较低的内聚力表明不同服务之间的通信过多导致系统性能较差。

3.独特的身份识别来源

遵循微服务设计的基本原则，任何服务都必须成为系统其余部分的唯一识别源。让我们举一个例子来理解这种情况。

在电子商务网站上下订单后，向用户提供订单ID。生成此订单ID包含有关订单的所有信息。作为微服务，订单ID是有关订单服务的任何信息的唯一来源。因此，如果任何其他服务寻求关于订单服务的信息，则订单ID充当信息源而不是其实际属性。

4. API集成

将整体设计分解为多种服务意味着这些服务将协调并协同工作以形成系统。但是，这些服务如何沟通？想象一下，使用多种技术来创建不同的服务。它们如何相互关联？

嗯，简单的答案是使用API（应用程序编程接口）。微服务设计的基础是使用正确的API。这对于维护服务和客户端调用之间的通信至关重要。轻松过渡和执行对于正常运行非常重要。

创建API时需要注意的另一个重要事项是业务领域。域的这种定义将简化区分功能的过程。有几个客户端在系统外部。这些客户端可以是其他应用程序或用户。无论何时调用业务逻辑，它都由适配器（消息网关或Web控制器）处理，该适配器返回请求并对数据库进行更改。

5.数据存储隔离

为特定服务存储的任何数据都应该对该特定服务保密。这意味着对数据的任何访问都应归服务所有。此数据只能通过API与任何其他服务共享。这对于保持对数据的有限访问并避免“服务耦合”非常重要。基于用户的数据分类很重要，可以通过命令和查询责任分离（CQRS）来实现。

6.交通管理

一旦设置了API并且系统启动并运行，不同服务的流量就会有所不同。流量是客户端发送给特定服务的呼叫。在现实世界中，服务可能运行缓慢，从而导致调用花费更多时间。或者服务可能充斥着呼叫。在这两种情况下，性能都会受到影响，甚至导致软件或硬件崩溃。

这种高流量需求需要管理。呼叫和被叫的特定方式是流畅的流量的答案。服务应该能够终止任何导致延迟并影响性能的实例。

这也可以使用称为“自动缩放”的过程来实现，该过程包括在需要时通过快速动作持续跟踪服务。在某些情况下，“断路器模式”对于提供在呼叫中断或服务无响应时可用的任何不完整信息非常重要。

7.自动化流程

独立设计的微服务应该能够自行运行。自动化将实现自我部署和功能，而无需任何干预。此过程使服务本质上具有云原生性，并且能够在任何环境中部署。但要实现这一目标，让DevOps团队不断致力于服务的发展是非常重要的。

8.最小数据库表（最好是隔离表）

访问数据库表以获取数据可能是一个漫长的过程。它可能需要时间和精力。在设计微服务时，主要动机应该围绕业务功能而不是数据库及其工作。为了确保这一点，即使数据条目达到数百万，微服务设计也应该只有几个表。除了最小数量，关注业务是关键。

9.持续监测

想象一下，将单片架构分解为微服务设计。这需要大量的时间和资源。在传统工具的帮助下监控所做的所有更改并不容易。插入数据层和缓存会提高性能，但却难以监控整个过程。

因此，为了设计微服务架构，重要的是建立用于主动监视中心位置的数据存储的过程。这有助于反映频繁的变化，而不会影响系统的性能。在一个常见的场景中，微服务监控工具将监控单个服务，然后通过将数据存储在一个集中位置来组合数据。这是遵循微服务设计原则的必要步骤。

实现API在成功的微服务架构中扮演的关键角色。还必须有一个持续监控API性能的过程。API性能监控对于任何微服务架构都至关重要，以确保功能在速度，响应性和产品的整体性能方面始终如一。

微服务架构的局限性

虽然微服务是降低整体结构的最佳方式。然而，它有其自身的一些缺点。但在得出任何结论之前，让我们来看看其中的一些。

1.开发环境超载

随着应用程序及其数据库的增长，代码库也在不断扩展。随着针对每个微服务的代码扩展，它会使每个加载的应用程序的开发环境过载。这可能导致生产力的重大延迟。

2. DevOps复杂性

单功能微服务的开发和部署并非易事。使用多种技术并创建API来集中系统是一项挑战。这需要一个经验丰富的DevOps团队。采购这样一个经验丰富的DevOps团队对于维护基于微服务的应用程序的复杂性至关重要。

3.增加资源和网络使用

由于多个组件协同工作，因此在某种程度上彼此进行通信非常重要。此通信将导致网络使用量增加。这需要高速可靠的网络连接。此外，运行这些应用程序的费用也会增加。所有服务都单独运行，增加了运营成本。

4.测试

测试应用程序可能具有挑战性，因为有单独的组件。与单片应用程序相比，微服务需要更长的时间进行测试，并且在出现任何错误时更加复杂。有时，由于测试最终会影响整个应用程序，可能会导致延迟。

5.安全

在Web应用程序方面，安全性至关重要。使用微服务，实现这一点很困难。当存在独立模块的集群时，每个模块都需要遵守为整个系统定义的认证和授权规范。

除此之外，每个模块可能与其他模块通信，跟踪数据流变得非常困难。需要其他措施，例如具有负载平衡的API网关，以确保行为一致。这些额外的步骤导致每个微服务的开销。

6.应用程序的复杂性

由于微服务是独立组件，因此每个微服务通常都有一个最适合其需求的技术堆栈。例如，机器学习模块可能使用python堆栈，而计量服务可能使用Java堆栈，UI服务可能使用MEAN堆栈。这会导致复杂性，因为资源池和管理和构建新功能所需的技能将非常高。

7.高初始投资

微服务独立运行，它们需要独立的容器或资源来运行它们。每个项目可能有很多微服务一起工作，需要更高的投资来设置包括微服务，安全容器，负载平衡器，API网关等的所有集群。

这值得么？

在阅读了微服务设计的基本原理之后，很明显需要遵循一系列最佳实践。但是，我们还观察微服务设计原则如何通过打破单片架构来简化创建应用程序的过程。但是，与此同时，在调整微服务架构时需要克服某些挑战。这些复杂性会影响运营流程，但从长远来看，克服这些挑战可以带来优化和更高效的应用。

此外，它还可以克服延迟和缺陷，同时提高灵活性和性能。记住上面提到的，可以说微服务架构对于成功的软件系统是必要的。

包括PayPal，Twitter，LambdaTest和Netflix 在内的许多企业都支持微服务架构的可靠性，以部署更具可扩展性，功能性和强大的软件。

芋道源码 —— 纯源码解析博客

一个牛逼的微服务！