微服务架构

洋葱丸子
301 阅读6分钟

内容

  1. 挑战

  2. 解决方案

  3. 概念图

  4. 真实示例

  5. 好处

  6. 缺点

  7. 什么时候应该使用它？

  8. 概括

1.挑战

您正在开发一个服务器端企业应用程序，该应用程序：

  • 支持各种不同的客户端、包括桌面浏览器、移动浏览器、本机移动应用程序，以及为第三方提供API；

  • 通过Web服务或消息代理与其他应用程序集成；

  • 通过执行业务逻辑来处理HTTP请求和消息；访问数据库；与其他系统交换消息；返回HTML / JSON / XML响应；

  • 由对应于应用程序不同功能区域的逻辑组件组成，这些组件可能会承受不同的负载，因此需要适当且独立地进行缩放。

2.解决方案

将应用程序安排为一组松耦合的交互服务。

  1. 服务使用与技术无关的协议(例如HTTP / REST或AMQP)进行通信。因此，数据合同是恒定的；

  2. 独立开发和部署服务-使团队可以开发和部署服务，而无需与其他服务和团队进行协调；

  3. 每个服务都有自己的数据库，以便与其他服务分离；

  4. 通过事件渠道或消息代理将业务事务实现为一系列本地事务(服务到服务)；

3.概念图

假设的微服务应用程序包含以下组件：

  • API网关从客户端获取所有API调用，然后通过请求路由，组合和协议转换将它们路由到适当的微服务。
  • Web App实现用户Web界面。
  • 后端服务包括服务A和服务B，它们是带有数据库的业务逻辑执行单元。他们通过消息代理进行通信。

                                                         微服务架构概念图

4.实际的无服务器微服务架构（AWS）

此示例是实现为具有无服务器后端的微服务的电子学习平台，组件说明：

  1. Cognito处理用户注册，登录和访问控制。
  2. CloudFront在边缘缓存静态S3 Web内容。
  3. API网关处理API调用。使用API​​ Gateway的“ Lambda授权者”，它连接一个Lambda函数，该函数处理Authorization标头并返回IAM策略。然后，API Gateway使用该策略来确定它对于资源是否有效，并路由请求或拒绝请求。API Gateway会缓存IAM策略一段时间，因此您也可以将其分类为“代客密钥”模式。API Gateway将日志分发到CloudWatch。
  4. Lambda处理运行和扩展执行所需的一切，以高可用性满足实际需求。Lambda支持多种编程语言，可以直接从任何Web或移动应用程序中调用它。Lambda与API网关集成。从API网关到AWS Lambda的同步调用使应用程序可以作为无服务器运行。AWS Lambda将动态数据存储在NoSQL数据库DynamoDB中，并将静态数据存储在S3 Bucket中。
  5. MQ Broker-负责微服务之间的异步通信。
  6. RDS存储用户配置文件和其他业务对象。

                                             电子学习平台无服务器微服务架构

5.好处

  1. 支持大型复杂应用程序的连续交付和部署。

     A）每个服务都相对较小，因此更易于理解和更改-易于维护。

     B）服务更小且测试速度更快-测试更轻松。

     C）服务可以独立部署-易于部署。

     D）开发工作是围绕多个自治团队组织的。每个团队都拥有并负责一项或多项服务。每个团队可以独立于所有其他团队开发，测试，部署和扩展其服务。更轻松，更可扩展的开发。

   2.每个微服务都相对较小。

    A）开发人员更容易理解

    B）IDE更快，使开发人员生产率更高

    C）应用程序启动速度更快，这使开发人员生产率更高，并加快了部署速度

  3.每个微服务都是隔离的。

    如果一项服务失败，则其他服务将不受影响并继续处理请求。相比之下，整体架构的一个行为不当的组件可能会使整个系统崩溃。

  4.没有对技术堆栈的长期承诺。

    开发新服务时，您可以选择新技术堆栈。同样，当对现有服务进行重大更改时，您可以使用新技术堆栈将其重写。

6.缺点

  1. 创建分布式系统的额外复杂性

    A）开发人员必须实现服务间通信机制并处理部分故障

    B）难以实现跨多个服务的请求

    C）测试服务之间的交互更加困难

    D）跨范围的请求多种服务需要团队之间的仔细协调

    E）开发人员工具/ IDE面向构建整体应用程序，不为开发分布式应用程序提供明确支持

  1. 部署复杂性

在生产中，部署和管理由许多不同服务组成的系统也存在操作复杂性。

  1. 增加的内存消耗

      微服务体系结构用NxM服务实例替换了N个单片应用程序实例。如果每个服务都在其自己的JVM（或等效版本）中运行（通常是隔离实例所必需的），则JVM运行时的开销是M倍。此外，如果每个服务都在其自己的VM（例如EC2实例）上运行（例如Netflix的情况），则开销会更高。

7.什么时候应该使用它？

     对于应用程序的第一个版本绝对不是一个好主意，因为您根本就没有这种方法可以解决的问题。使用精心设计的分布式体系结构将减慢开发速度。对于初创企业来说，这可能是一个主要问题，这些初创企业面临的最大挑战通常是如何快速发展业务模型和随附的应用程序。功能分解可能使快速迭代变得更加困难。但是，稍后，当挑战在于如何扩展并且您需要使用功能分解时，复杂的依赖关系可能使将单片应用程序分解为一组服务变得困难。

8.总结

  1. 微服务架构的核心思想是将应用程序后端拆分为一组松散耦合的服务，这些服务独立开发，部署，测试和扩展。

  2. 好处是：1）能够连续交付和部署大型，复杂的应用程序；2）对技术栈没有长期承诺；3）维护更简单；4）增加了故障容忍度。

  3. 缺点是1）开发和部署的复杂性增加；2）增加内存消耗。

  4. 申请 开发后期的微服务架构模式 缩放 成为最重要的问题。

文章转载至：

levelup.gitconnected.com/microservic…

avatar
文章
阅读
粉丝