top of page

Microservices - 架构考虑事项

已更新:2022年7月7日



数字化推动银行通过Microservices架构中设计的银行API在各种开放平台上提供服务。本文分享了Microservices的关键架构考虑事项。


Microservices是一种在容器化环境 (containerized environments) 中用于设计分布式和可扩展 API 的架构风格。常见的用例是下订单、信息查询和数据流。


这些用例的 API 是自发的、松散耦合(loosely-coupled)的并以协作方式处理事件。


以下是Microservices API架构设计的五个考虑事项。


1. 动态配置

2. 服务发现

3. 负载平衡

4. 断路器

5. 分布式跟踪


1. 动态配置



Microservices API支持不同环境下的多个实例。每个环境可能有不同的配置,例如IP地址、CPU或内存。


因此,设计应该考虑一个集中的配置服务,为不同的API实例提供不同的配置。


此外,设计还应考虑无需重启API实例即可自动刷新配置。其中一种方法是定期从服务刷新配置。


或者,我们可以利用消息代理实时刷新API配置。当配置发生变化时,配置服务可以将新配置发送到消息代理,然后通过消息队列将其推送到API。


2. 服务发现



除了从外部调用Microservices API外,Microservices API 还可以协作以满足要求。


因此,设计时应考虑API发现服务,该服务发布所有当前在线API及其调用详细信息的在线实时目录。


在容器环境下,API调用是可以动态改变的,比如容器每次启动时可能会为API实例分配不同的IP。


为了维护发现服务的实时信息,每个API可以在服务启动时向服务发送注册消息。然后定期向发现服务发送心跳信号。一段时间内没有心跳信号的API应视为离线并从列表中删除。


3. 负载平衡



由于Microservices API具有高度可扩展性,因此可以同时运行多个API实例。设计应考虑在运行的API实例之间分配传入请求的负载平衡。


有两种负载平衡方法:服务器端和客户端。


服务器端方法将硬件或软件服务器置于API与其使用者之间。所有传入请求都将传输到负载平衡器,负载平衡器将根据其负载平衡策略将请求重新定向到API。


服务器端方法的优点是独立于API和使用者的实现。缺点是网络延迟高。


客户端方法在API客户端中嵌入了负载平衡模块。所有API实例信息都包含在API客户端的内存空间中,因此可以直接调用API实例。


客户端负载均衡的优点是网络延迟低。缺点是依赖于API实现。


常见的用例是外部API使用者使用服务器端方法,并使用客户端方法进行API间协作。


4. 断路器


由于Microservices API会对客户端请求进行协作,因此一个API的故障将导致级联故障并使客户端请求无响应。


Microservices设计应考虑使用断路器来保护API免受级联故障的影响。


断路器是一种软件设备,可根据预定义的条件和临界值检测API故障。在API失败的情况下,它将应用恢复或回退的方法,例如调用替代API或返回缓存值。


断路器有三种状态:


关闭 - 此状态表示所有API都正常,断路器不会干预API调用过程。


开启 - 这种状态意味着存在API故障,断路器将应用恢复或回退方法。


半开 - 在开启状态一段时间后,断路器将自动变为半开状态。在这种状态下,断路器将再次调用失败的API。如果调用成功,则将其状态更改为关闭,否则将其状态更改为开启。


5. 分布式跟踪


Microservices API的分布式特性让执行跟踪和调试非常困难。因此,Microservices API的设计应该考虑分布式跟踪机制。


我们可以应用审计跟踪服务,为AP使用者的每个调用提供唯一标识符。唯一标识符将传递给每个API之间调用并写入日志条目。


审计跟踪分析工具会从不同的API实例中检索日志条目,然后根据唯一标识符和时间标识对日志进行整合、分析和重组,以确定API事件的执行链和时间顺序。



感谢您阅读这篇文章。有关详细的Microservices的架构考虑事项,请联系我们 如果您想获得更多关于金融科技的信息,请关注我们的 LinkedIn 或订阅金融科技透视”。



纬泓是香港、新加坡和中国的顶级金融科技企业。自1998年以来,我们一直在帮助金融机构实施全球银行解决方案。


24 次查看

Comments


bottom of page