微服务:架构、组件与互操作性

长期以来,对于开发复杂应用程序,如管理系统或操作程序,已经不再采用单体架构,即将所有功能集成在一个代码单元中。相反,更倾向于将系统拆分为相互独立且可互操作的小组件(服务)。这就是所谓的微服务架构

实际上,系统被拆分成多个独立的应用程序,每个应用程序只承担单一职责,通过与其他服务交换数据,提供与单体系统相同的功能。

TechWorld with Nana 图片

选择这种架构的优势有很多:

  • 可扩展性:每个微服务可以独立扩展,资源可以根据服务的关键性和需求分配。
  • 开发便捷:每个服务可以独立开发、修改和修复。
  • 集成与更新便捷:服务可以独立更新和修改,使系统更灵活地适应用户需求。
  • 错误隔离:当某个组件出现错误时,更容易隔离和修复,且对系统其他部分的影响最小。
  • 开发速度快:不同团队可以并行开发不同服务,且可使用不同技术
  • 测试便捷:测试单个微服务更简单,尽管需要为其交互组件创建模拟对象。

当然也存在一些缺点:

  • 数据一致性:由于团队独立工作,服务间数据传递必须经过仔细设计和共享。
  • 团队协调:协调多个团队的工作更具挑战。
  • 集成测试:集成测试复杂,因为涉及不同人员和技术开发的程序交互。
  • 系统管理:管理如此复杂的系统需要自动化部署的软件支持。
  • 通信开销:服务间通信依赖网络,导致网络流量显著增加。
  • 系统成本:微服务系统需要复杂的基础设施和专职的DevOps人员负责配置、运行和监控。

开发此类系统的关键点和挑战包括:

  1. 正确识别微服务
  2. 管理微服务间通信
  3. 保障系统安全
  4. 监控系统状态

正确识别微服务

服务拆分必须谨慎进行。系统应根据功能划分,使每个子系统在逻辑上独立,优先于功能上的独立。应将各单元视为真正的独立应用。重要的是,每个应用只承担一个职责,且不依赖其他应用

管理微服务间通信

微服务系统的核心问题是各组件间的通信。常用解决方案包括:

  1. 使用API(同步通信):每个应用暴露一系列端点用于数据读写。例如,结账模块可以通过购物车模块的getItems端点获取购物车内商品列表。最常用的API技术是REST,还有如SOAP(个人认为已过时)、RPCGraphQL[8]
    TechWorld with Nana 图片
  2. 使用消息代理(异步通信):此时有一个称为消息代理的组件作为中介。采用发布/订阅协议,所有消息发送到代理,由其根据订阅频道机制分发给正确接收方。此类通信的实现之一是广泛应用于物联网MQTT协议
    TechWorld with Nana 图片
  3. 使用“服务网格”:这是许多商业云基础设施提供的服务。每个服务关联一个网关(或sidecar),负责所有消息的发送和接收。还有两个组件,数据平面包含所有网关,负责消息路由;控制平面负责配置数据平面,包括路由策略、安全和监控。最流行的实现之一是Istio
    TechWorld with Nana 图片

保障系统安全

微服务系统依赖组件间消息交换。信息传递必须安全可靠。通信至少应通过某种形式的身份验证加密保护。前述协议除了基本的安全机制外,还具备更高级的安全功能。另一个提高安全性的措施是限制请求仅接受来自特定IP地址。

监控系统状态

如此多组件组成的系统管理复杂,需要合适的基础设施和工具快速定位错误、不一致或性能瓶颈。常用工具包括:PrometheusZabbixNagios等。

从单体系统迁移到微服务

许多软件公司近年来或正在经历将庞大旧单体应用迁移到微服务应用的挑战。重写复杂软件风险大且耗时,最明智且风险较低的方案是识别系统的逻辑组件,逐步隔离、开发、测试并集成。这是一条漫长的路,但成功率更高。

参考资料:

*** 注意:本文通过使用n8n和OpenAI自动翻译生成。原文版本为意大利语。

3 years ago

Leave a Reply

Your email address will not be published. Required fields are marked *

评论审核已启用。您的评论可能需要一段时间后才能被显示。