安信可nbiot模块_案例丨安信证券服务化平台实践

最新推荐文章于 2024-04-14 01:06:50 发布

weixin_39985842

最新推荐文章于 2024-04-14 01:06:50 发布

阅读量376

点赞数

文章标签：安信可nbiot模块

本文链接：https://blog.csdn.net/weixin_39985842/article/details/111677179

版权

文 / 安信证券股份有限公司信息技术中心段苏隆周巍沙烈宝李银鹰

建设之初的思考

互联网应用的海量用户、快速迭代、不间断服务和流量突增等业务特征促进其技术架构从传统集中式到分布式SOA和微服务架构方向演进。当前，以Docker、Kubernetes和服务网格等为代表的云原生技术进一步促进微服务的发展，解决了标准化交付、自动化调度和无侵入式服务治理等复杂问题。

在工程实践方面，诞生了一系列基础框架、工具组件和基础平台支撑微服务的敏捷迭代和服务治理等特性,如Apache开源的Spring Cloud、Dubbo等框架;在同行业中，有东方证券开源的微服务治理框架gRPC-Nebula、国信证券开源的Zebra微服务框架和恒生闭源JRES3.0分布式服务开发平台等，这些框架通过嵌入SDK的方式实现如服务注册与发现、负载均衡等服务治理功能。同时，也有新一代如服务网格的无侵入式方案，通过对服务间的通信进行代理，能够在不修改源代码情况下实现复杂的服务治理功能。

随着敏态业务的逐渐增多，对业务连续性、交付效率和故障处理效率等方面提出了更多的挑战，这些需求促进着技术架构的转变。安信证券服务化平台实践,以赋能业务为中心，积极拥抱微服务、容器和云原生等新兴技术来应对业务系统研发过程中的实际问题。

1.解决什么问题

尽管微服务和容器等技术已广泛使用，但仍然需要结合具体的业务场景落地。因此，我们从实际出发，针对15个具有代表性的自研业务系统负责人进行问卷调查和访谈，同时对近两年的生产事件进行归类，梳理出不同优先级的服务化相关需求。

(1)内部调研结果。从业务系统建设方角度，期望平台提供如下能力项：使用手册、配置中心、服务网关、负载均衡、链路分析、熔断限流、注册中心、工程脚手架、指标监控等。

(2)生产事件分析。平台研发团队对近两年来1800+生产事件分析，归纳整理出中间件配置、外部调用、监控、环境差异、突发流量5类共性问题，对应能力项需求包括：中间件最佳实践、开发规范、指标监控、灰度发布、限流熔断等内容。

2.服务化探索

针对上述能力项需求与架构演进方向，安信证券服务化实践主要包括以下几个要点。

(1)演进式架构设计。实际的研发过程中，大部分业务系统的服务拆分并不是一蹴而就，当出现有多个功能模块紧耦合、不同模块需要根据业务需求独立演进等情况下才会考虑适当拆分，否则，单体架构或者“小服务”(拆分粒度相对微服务低)更能降低系统的开发、测试和运维等阶段中的复杂度。

(2)解决实际问题。从应用的全生命周期考虑，在研发阶段提供脚手架、开发规范并约定服务间通信协议等内容；在运行阶段，以应用的可观测性(主要包括指标、链路和日志数据)为中心收集并展示其运行状态数据，同时提供多种规则实现异常状态的告警。

(3)结合容器云落地。随着安信证券容器云平台建设的完善，并规划全部自研业务系统“上云”，微服务架构基于容器云平台落地，有效解决运行环境和操作系统的标准化、应用灰度发布和弹性伸缩等复杂操作。在服务治理方面，优先考虑Kubernetes和服务网格的无侵入模式，而不是以SpringCloud、Dubbo为代表的SDK嵌入模式，主要原因是这类服务治理框架会带来一些负担：一是注册中心提供动态的注册与发现功能，但不解决网络权限等问题。例如两个服务A和B间的通信，引入注册中心C后，需确保A和B、B和C、A和C之间的所有实例通信正常。二是注册中心内外调用容易混淆。服务A和B间的通信，服务A必须明确服务B是否注册在同一注册中心，如果是，则使用注册名动态发现服务的多个实例地址后发起调用，否则，需要使用IP或者域名进行调用。实际使用中，这两种调用模式往往同时存在而导致混淆。三是SDK耦合问题。SDK与业务耦合，当服务端升级且对低版本不兼容时，将面临所有业务系统需升级的大量工作。