您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 开发技术 > 正文

服务架构:微服务架构

发表于:2023-07-30 作者:赵帅虎 来源:今日头条

微服务架构是由很多小而自治的微服务组合而成,每个服务都提供一套独立自洽的业务能力。从应用的层面,我们首先对业务进行建模,业务域定义的边界也自然而然作为每个微服务的职能边界。

什么是微服务?

微服务的定义比较直白,但只有理解它的设计理念和原则,才能真正用好它。从单个服务/服务间关系来看,有以下特征:

  • 微服务通常很小、提供很少但独立的功能,服务间耦合度很低。一个很小的研发团队就可以开发和维护一个微服务。
  • 每个服务都是一个单独的代码库,可以由一个很小的研发团队来管理。
  • 服务可以独立部署,而不需要重新构建和部署整个应用。
  • 每个服务负责维护自己的数据和状态,数据所有权归本服务所有,其他服务必须通过该服务访问数据和状态。
  • 服务之间通过定义好的API进行通信,对外隐藏API的内部实现细节。
  • 支持多语言编程,不同服务可以使用独立的技术栈进行开发,自由选择编程语言、框架和库。

如果从更全局的视角来看,微服务架构还必须下面几个组件:

  • 服务管理和编排。该组件负责把服务部署在物理机/虚拟机节点上、做失败检查、在多个节点上负责对服务的多个实例做负载均衡等。我们通常可以使用现成的开源技术来充当这个组件,比如k8s。
  • API Gateway。API Gateway给所有Client提供了访问入口。Client通常不会直接访问提供业务支持的服务,而是调用API Gateway,由Gateway负责把请求转发给后端对应的服务。

使用 API Gateway 有很多优势:

  • 解耦Client和服务,我们可以单独对服务进行更新或重构,client端可能不需要更新甚至不需要感知。
  • 服务间通信可以使用更灵活的方式,比如不走HTTP协议,而是走rpc等二进制协议、消息队列等,某些超大数据量的场景甚至会走p2p协议。
  • API Gateway可以承担一些跨业务的职能,比如权限认证、日志、SSL校验、负载均衡等。
  • API Gateway一般会提供一些开箱即用的能力,比如限流、缓存、请求篡改、权限校验等。

架构优势

  • 支持敏捷迭代。由于微服务可以独立部署,所以修复bug和上线新特性也更容易。你可以独立更新特定的服务,而不是重新部署整个应用,如果更新出现问题,也支持快速回滚。在传统应用中,一旦在应用的某个环节发现问题,整个发布流程都要被阻塞。新特性也可以等着bug修复后再去测试和发布。
  • 小而专的研发团队。微服务可以很小,小到一个独立的小团队iu可以构建、测试和阿布。小团队非常适合推行敏捷迭代流程。往往大型团队的生产力更弱一些,因为沟通满,管理成本上升,由此也不适合再推行敏捷迭代。
  • 代码库小。在大型单体应用中,随着时间推移,代码依赖越来越复杂。增加新特性意味着要改很多地方的代码。由于不共享代码和数据,微服务架构将依赖最小化,部署新特性也更容易。
  • 可以融合使用多种技术。团队成员可以选择最适合服务的技术,并在适当的情况下混合使用多个技术栈。
  • 故障隔离。如果一个特定的微服务挂掉了,只要上游微服务在设计时考虑到容灾处理,通常不会影响整个应用的正常功能。比如,采用适当的熔断机制,或者服务间通信走异步消息队列。
  • 架构扩展性好。每个服务都可以单独进行扩容,这样的话,我们就能独立扩容需要更多资源的子系统,而不是整个应用。使用K8s等对服务进行编排,我们可以把多个服务的实例部署在同一台机器上,以提高资源利用率。
  • 原生支持服务间的数据隔离。如果要更新数据的schema,只有单个服务受到影响。在单体应用中,更新schema往往不太容易,因为应用的多个模块都会通过库依赖的形式访问数据,在更新时,很难追踪到所有使用的地方和使用方式,导致schema的迭代有很多未知的风险。

有哪些挑战

微服务的架构优势是有代价的,在采用微服务架构之前,我们要认识到未来可能面临的挑战:

  • 架构复杂度高。相对于单体应用,微服务应用有很多可变的组件。每个服务都更简单了,但整个系统变得更复杂了。
  • 开发和测试麻烦,尤其是集成测试。在实现一个微服务时,如果它依赖了其他服务,编写和测试过程都会比单体应用更复杂。现存的工具在设计时可能并未考虑到服务依赖。如果我们要对相互依赖的多个服务进行重构,难度也会比重构单体应用高。在测试时,涉及到服务依赖,需要单独维护多套与线上相似的测试环境。考虑到每个服务都有多个测试版本,迭代比较快时,很容易出问题。
  • 互相独立的服务,很难做治理。由于微服务以区中心化的方式去构建各个服务,在服务治理上增加了额外的难度。最终整个应用中可能包含多个编程语言,使用了多种框架,开发人员可以更自由地选择小众的技术,导致后期维护成本反而更高。
  • 容易产生网络拥塞和延迟。很多小且功能独立的服务需要通过API或消息队列继续频繁的通信。由于底层走网卡进行通信,对比单体架构的代码库依赖,网络通信的代价可能很高。当服务的依赖链很长时,比如 A调用B,B调用C,C调用...,额外的网络延迟会高到无法接受。所以在设计服务时,需要慎重考虑API的设计,应避免过度繁琐的API,考虑到编码格式(二进制协议优于文本协议),优先使用异步通信模式或消息队列模式;
  • 跨服务的数据一致性问题。每个微服务负责自身的数据持久化,导致多个服务的数据可能存在不一致。通常我们使用最终一致性原则解决这些问题;
  • 服务管理难度高。微服务架构的成功采用离不开成熟的DevOps文化。处理跨服务的日志追踪,尤其是一个用户操作触发整个链路的微服务调用,日志都要记录下来,并且在发生错误时,能够把整个调用链的日志拉取出来;
  • 服务的发布版本管理。在更新服务时,不能对API做破坏性的更新,否则依赖它的服务可能会挂掉。由于多个开发团队在同一时间段可能都要对服务做更新,所以接口设计必须保持向前或向后兼容。一个典型的低级错误是:删除了API定义的某些字段,或修改了某些字段的业务含义;
  • 要求研发团队懂分布式系统。微服务通常是分布式的,需要认真评估团队是否具备对应的能力和经验;

最佳实践

  • 基于业务场景对服务进行建模;
  • 尽量去中心化。每个团队都要负责设计和构建服务,避免分享代码或底层数据结构。
  • 数据存储只允许单个服务访问,每个服务根据自己的业务需求设计选择存储方案和数据格式。
  • 服务间通过设计良好的API进行通信,应尽量避免透露实现细节。API的定义应当基于业务场景进行设计,而不是根据内部的技术实现进行设计。
  • 避免服务间的耦合。服务间耦合的原因通常是把数据库schema透传给外部,或通信协议弹性比较差。
  • 将跨业务域的需求交给API Gateway来处理,比如身份认证、SSL验证。
  • 保持API Gateway的纯粹性,不掺入业务逻辑。API Gateway只处理和转发client侧的请求,不感知任何业务逻辑。否则API Gateway将成为一个依赖,导致服务间的耦合。
  • 服务间应该高内聚、低耦合。应该一起变化的逻辑应该被打包到一个服务里,统一部署。如果他们分散在不同的服务里,这些服务将高度耦合在一起,一个服务的更新也将连锁导致另一个服务的更新。两个服务间繁琐的通信是“高耦合低内聚”的体现。
  • 故障隔离。应当采取一定的恢复策略,以避免一个服务的故障引发连锁反应。