如何设计最佳的微服务架构 -DZone(微服务)

作者:xinwang_m@163.com
发布时间: 2020-07-21 04:04:50 (5年前)
关键词: 微服务架构；DZone
摘要:

                              
                                     企业正在迅速采用微服务架构来创建灵活，可扩展的应用程序，这些应用程序可以快速迭代，具有较高的容错能力和较低的停机时间。您如何构建正确的微服务架构？

<p>企业正在迅速采用微服务架构来创建灵活，可扩展的应用程序，这些应用程序可以快速迭代，具有较高的容错能力和较低的停机时间。您如何构建正确的微服务架构？</p><p>尽管确切的架构会有所不同，但是有一些最佳实践可以帮助设计有效和最佳的微服务架构。</p><h2><a href="#领域驱动设计" name="领域驱动设计">领域驱动设计</a></h2><p>微服务的重点是将统一架构分解为更小，更易管理的部分。必须以对所有利益相关者都有意义的方式来完成这种分解。</p><p>定义单个微服务范围的几种常用方法：</p>
<ul>
  <li>创建与应用程序开发过程中存在的不同运营团队相对应的微服务。例如，一个团队可能正在研究用户身份验证，另一个团队正在研究数据收集，并且每个团队都应负责创建一组实现特定任务的微服务。</li>
  <li>创建与特定功能相对应的微服务。例如，分析应用程序可以具有聊天机器人功能，可视仪表板，数据分析功能等。这些中的每一个都可以创建为单独的片段，并通过API进行交流。</li>
</ul><p>这个想法是创建一组独立的服务，以提供集中的增值服务。面临的挑战是避免将过多的功能过度填充到一个微服务中。通常建议将代码保持足够简单，以便在需要时可以轻松地重新部署。</p><h2><a href="#独立微服务" name="独立微服务">独立微服务</a></h2><p>微服务的独立性是其有效性的关键。它们松散耦合并且可以在没有复杂的相互依赖性的情况下工作，这一事实确保了整个应用程序不会由于单点故障而崩溃。因此，在一些关键领域中必须确保独立性：</p>
<ul>
  <li>独立团队：理想情况下，每个微服务都应拥有自己的专门团队，其中包括产品经理和DevOps团队。一支团队将每项服务从开发到部署的过程，都有助于减少发布频率和最大程度地延长正常运行时间。</li>
  <li>自动进行独立部署：自动化构建和发布周期，并确保每个微服务都可以独立于其他微服务进行部署，这对于设计良好的应用程序至关重要。这样，它们可以在任何环境下启动并运行。</li>
  <li>单独的存储：每个微服务都应拥有自己的特定数据库，而其他所有需要该数据的服务都应仅通过API进行访问。在短期内，共享数据库似乎是一个方便的选择。但是随着微服务的扩展，这种共享导致它们相互耦合，从而破坏了目标。</li>
  <li>隔离故障：为了确保即使一项服务出现故障，应用程序也可以继续运行，微服务架构需要隔离故障。一种常用的方法是在应用程序中建立断路器。当服务失败超过设置次数后，断路器将跳闸，并立即使给定时间段内对该服务的所有请求失败。该服务提供的功能在该时间段内仍然不可用，即使应用程序的其余部分保持正常工作也是如此。超时后，断路器允许通过几个请求，如果成功，则恢复为正常操作。</li>
</ul><p>与此类似，其他设计模式（例如异步通信和事件驱动的体系结构）也可以用于故障隔离。</p><h2><a href="#不变的基础设施" name="不变的基础设施">不变的基础设施</a></h2><p>不变的基础架构将服务分为数据和“其他”，并且在每个版本中都将“其他”部分替换。创建新版本的微服务，而不是立即更新当前版本。新版本经过测试和微调，而旧版本是应用程序正在使用的版本。仅当新版本稳定时，才可以将其与前一个版本合并。</p><h2><a href="#标准制定" name="标准制定">标准制定</a></h2><p>随着组织更多地依赖微服务架构，不同的团队从事不同的服务，流程和实践可能会因团队而异。每个团队可以开始进行不同的开发，部署和错误处理。这可能导致不同团队重复执行许多代码，从而影响效率和周转时间。</p><p>因此，建议创建团队可以遵守的组织范围的标准。微服务创建和部署的过程以及它们相应的API应该有充分的文档记录。这也使不同的团队可以了解正在使用的其他微服务API，以及如何最好地使用它们。,企业正在迅速采用微服务架构来创建灵活，可扩展的应用程序，这些应用程序可以快速迭代，具有较高的容错能力和较低的停机时间。您如何构建正确的微服务架构？</p><p>尽管确切的架构会有所不同，但是有一些最佳实践可以帮助设计有效和最佳的微服务架构。</p><h2><a href="#领域驱动设计" name="领域驱动设计">领域驱动设计</a></h2><p>微服务的重点是将统一架构分解为更小，更易管理的部分。必须以对所有利益相关者都有意义的方式来完成这种分解。</p><p>定义单个微服务范围的几种常用方法：</p>
<ul>
  <li>创建与应用程序开发过程中存在的不同运营团队相对应的微服务。例如，一个团队可能正在研究用户身份验证，另一个团队正在研究数据收集，并且每个团队都应负责创建一组实现特定任务的微服务。</li>
  <li>创建与特定功能相对应的微服务。例如，分析应用程序可以具有聊天机器人功能，可视仪表板，数据分析功能等。这些中的每一个都可以创建为单独的片段，并通过API进行交流。</li>
</ul><p>这个想法是创建一组独立的服务，以提供集中的增值服务。面临的挑战是避免将过多的功能过度填充到一个微服务中。通常建议将代码保持足够简单，以便在需要时可以轻松地重新部署。</p><h2><a href="#独立微服务" name="独立微服务">独立微服务</a></h2><p>微服务的独立性是其有效性的关键。它们松散耦合并且可以在没有复杂的相互依赖性的情况下工作，这一事实确保了整个应用程序不会由于单点故障而崩溃。因此，在一些关键领域中必须确保独立性：</p>
<ul>
  <li>独立团队：理想情况下，每个微服务都应拥有自己的专门团队，其中包括产品经理和DevOps团队。一支团队将每项服务从开发到部署的过程，都有助于减少发布频率和最大程度地延长正常运行时间。</li>
  <li>自动进行独立部署：自动化构建和发布周期，并确保每个微服务都可以独立于其他微服务进行部署，这对于设计良好的应用程序至关重要。这样，它们可以在任何环境下启动并运行。</li>
  <li>单独的存储：每个微服务都应拥有自己的特定数据库，而其他所有需要该数据的服务都应仅通过API进行访问。在短期内，共享数据库似乎是一个方便的选择。但是随着微服务的扩展，这种共享导致它们相互耦合，从而破坏了目标。</li>
  <li>隔离故障：为了确保即使一项服务出现故障，应用程序也可以继续运行，微服务架构需要隔离故障。一种常用的方法是在应用程序中建立断路器。当服务失败超过设置次数后，断路器将跳闸，并立即使给定时间段内对该服务的所有请求失败。该服务提供的功能在该时间段内仍然不可用，即使应用程序的其余部分保持正常工作也是如此。超时后，断路器允许通过几个请求，如果成功，则恢复为正常操作。</li>
</ul><p>与此类似，其他设计模式（例如异步通信和事件驱动的体系结构）也可以用于故障隔离。</p><h2><a href="#不变的基础设施" name="不变的基础设施">不变的基础设施</a></h2><p>不变的基础架构将服务分为数据和“其他”，并且在每个版本中都将“其他”部分替换。创建新版本的微服务，而不是立即更新当前版本。新版本经过测试和微调，而旧版本是应用程序正在使用的版本。仅当新版本稳定时，才可以将其与前一个版本合并。</p><h2><a href="#标准制定" name="标准制定">标准制定</a></h2><p>随着组织更多地依赖微服务架构，不同的团队从事不同的服务，流程和实践可能会因团队而异。每个团队可以开始进行不同的开发，部署和错误处理。这可能导致不同团队重复执行许多代码，从而影响效率和周转时间。</p><p>因此，建议创建团队可以遵守的组织范围的标准。微服务创建和部署的过程以及它们相应的API应该有充分的文档记录。这也使不同的团队可以了解正在使用的其他微服务API，以及如何最好地使用它们。</p>

0 条回复

动动手指，沙发就是你的了！

登录后才能参与评论