成功的微服务设计的基础知识
现在我们知道微服务架构的优势，但是，我们如何实现完美？我们是否了解微服务设计原则？设计微服务架构的最佳实践是什么？让我们回答这些问题，看看成功的微服务设计的一些基础知识。
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性能监控对于任何微服务架构都至关重要，以确保功能在速度，响应性和产品的整体性能方面始终如一。

外，运行这些应用程序的费用也会增加。所有服务都单独运行，增加了运营成本。
4.测试
测试应用程序可能具有挑战性，因为有单独的组件。与单片应用程序相比，微服务需要更长的时间进行测试，并且在出现任何错误时更加复杂。有时，由于测试最终会影响整个应用程序，可能会导致延迟。
5.安全
在Web应用程序方面，安全性至关重要。使用微服务，实现这一点很困难。当存在独立模块的集群时，每个模块都需要遵守为整个系统定义的认证和授权规范。
除此之外，每个模块可能与其他模块通信，跟踪数据流变得非常困难。需要其他措施，例如具有负载平衡的API网关，以确保行为一致。这些额外的步骤导致每个微服务的开销。
6.应用程序的复杂性
由于微服务是独立组件，因此每个微服务通常都有一个最适合其需求的技术堆栈。例如，机器学习模块可能使用python堆栈，而计量服务可能使用Java堆栈，UI服务可能使用MEAN堆栈。这会导致复杂性，因为资源池和管理和构建新功能所需的技能将非常高。
7.高初始投资
微服务独立运行，它们需要独立的容器或资源来运行它们。每个项目可能有很多微服务一起工作，需要更高的投资来设置包括微服务，安全容器，负载平衡器，API网关等的所有集群。
这值得么？
在阅读了微服务设计的基本原理之后，很明显需要遵循一系列最佳实践。但是，我们还观察微服务设计原则如何通过打破单片架构来简化创建应用程序的过程。但是，与此同时，在调整微服务架构时需要克服某些挑战。这些复杂性会影响运营流程，但从长远来看，克服这些挑战可以带来优化和更高效的应用。
此外，它还可以克服延迟和缺陷，同时提高灵活性和性能。记住上面提到的，可以说微服务架构对于成功的软件系统是必要的。
包括PayPal，Twitter，LambdaTest和Netflix 在内的许多企业都支持微服务架构的可靠性，以部署更具可扩展性，功能性和强大的软件

我这边整理了免费的Java技术干货和一些面试资料
零基础和架构方面的都有
如果想免费领取这份资料，关注并私信我哦！
下面是部分资料的图片
（不会真的没人私聊我叭）