数字化推动银行通过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事件的执行链和时间顺序。
纬泓是香港、新加坡和中国的顶级金融科技企业。自1998年以来，我们一直在帮助金融机构实施全球银行解决方案。