2024年云原生体系在中小金融机构的实践与创新报告

2024.8 主讲人吕太原 建设现状0203规划演进建设背景01 目录 企业云化演进路径：融合池化->自动化与敏捷->智能化 我行科技建设三大阶段-平台化->服务化->云化 云原生建设-微服务+容器+DevOps 没有DevOps实践的微服务实施是运维（应用和基础设施）人员的灾难 容器云+CI/CD解决方案，支撑全场景微服务业务上线需求 三者有所侧重，又紧密关联 建设现状 微服务架构建设历程 去中心化微服务运行生态 微服务治理体系建设 实时监控 健康检查 链路追踪 1、基于skywalking的微服务应用调用拓扑与关联关系展示2、基于skywalking的微服务应用链路追踪，API级别的交易全链路展示 1、skywalking监控：应用级别监控采集2、prometheus监控：机器监控采集3、自实现监控：API网关、文件网关、边车、分布式定时任务 1、注册中心服务健康状态心跳检测2、边车与应用双向健康检查 性能分析 日志分析 告警中心 1、基于prometheus的虚拟机/容器层面的系统层面监控（CPU、内存、网络IO、文件IO、磁盘等）2、基于skywalking的应用层面监控（API响应率、慢交易、接口耗时统计等） 1、针对应用、系统、文件交互、接口交互等不同维度的监控与统一告警能力2、告警信息汇总运维平台提供统一的基于业务场景下的明细化告警输出，具备API级别响应异常与耗时异常分析与告警能力 1、汇总微服务日志信息，打通链路追踪中的唯一traceid，快速关联API接口与业务场景，实现跨系统全日志链路打通2、快速可视化日志检索（ELFK），提供快速便捷的日志检索能力，日志关联链路 新信贷、新核算、营销管理平台、企业网银、远程视频银行等超30套高频核心类业务系统微服务化改造。 边车模式试点了直销银行、互联网信贷系统、风险决策平台、多渠道数据中心4套常用业务系统。 微服务网关共计230个新、老应用系统接入使用，3451个接口精细化治理。API网关的集群交易数据日均300万+笔，高峰日均1600万+笔。整体的网关性能与TPS通过压测可达6000+笔。 全行级注册中心、配置中心、分布式定时任务、监控中心等一系列微服务治理套件进行统一，既节省大量的资源，还简化了运维操作。 容器云建设历程 容器云建设背景 传统虚拟化技术 容器化技术 1、秒级启动，秒级停止，空间资源占用少2、共享宿主机资源3、实现进程级别的隔离 1、传统虚拟机启动慢，空间占用大2、资源利用效率低2、单物理机多应用无法有效隔离（进程空间，cpu资源，磁盘） 容器的优势及问题 更轻量化编排管理快速启动资源利用 轻量化：每个容器都共享同一个宿主机操作系统和硬件资源，因此更加轻量化。 快速启动：利用镜像的分层存储机制，容器的启动速度很快。 资源利用：多个容器可以共享同一个宿主机的资源，因此资源利用率更高 编排管理：应对多服务容器协同工作能力不足，需要编排能力Docker Compose×Kubernetes√ 生产环境按两中心三个区域进行规划 两中心：主中心、灾备中心三区域：业务区、OA区、DMZ区 运管区部署容器管理平台和镜像仓库 各网络区按需部署容器业务集群 每个业务集群包含主中心和副中心计算节点 无状态容器云建设成果 目前容器云平台已接入企业手机银行、统一消息融合平台、远程视频银行、智能柜台等6套常用业务系统与敏态运行平台、统一门户等4套管理类系统正式试点使用，为后续信创云建设奠定基础。 有状态中间件云化建设背景 ■各业务系统自行搭建：中间件搭建、运维工作量大，任务重；版本众多、部署架构不统一、性能优化困难；缺少资源池化和弹性的能力；学习、传承耗费太多精力，无法专注于帮助业务优化中间件管理和性能。 ■私有云资源静态分配、分散管理：云平台初始规模要求高，落地成本高；各分散的业务系统通常按照规划的最大资源申请虚机资源，无法实现真正的资源共享；数据中心利用率维持在低水位，资源利用率不高。 ■中间件选型五花八门：技术架构、中间件由系统独立选型、使用，中间件选择不统一，版本不统一，类型众多，SLA保障难、运维难、成本高。 云原生中间件平台架构 中间件平台是基于云原生编排能力构建的PaaS平台，提供消息队列、搜索等具有高SLA、高性能、低成本的分布式中间件服务。可快速便捷构建稳定可靠、运维高效、性能卓越、成本节约的中间件PaaS平台。 ➢提供详细的监控面板、告警指标，更细致全面的中间件监控➢简化运维和故障处置操作，快速拥有云原生分布式系统运维能力 中间件平台内嵌了对容器的19项事件、11个维度的治理手段，对每一种中间件提供平均20项指标监控等。通过这组监控告警数据的支撑，增强了中间件的可观测性和稳定性。目前已接入了78个中间件实例，按照新旧资源对比，已节省360+的CPU资源、780+G的内存资源，以及50+T的存储资源。 形成Redis、RocketMq、RabbitMq、Kafka、Elasticsearch各个中间件的使用标准与规范 敏捷建设历程 敏捷建设背景 研发运维一体化–DevOps (敏捷&持续集成/持续交付） 以精益的价值理念为指导，以价值交付为目标DevOps的核心是构建自动化的持续交付流水线通过组织协作和技术架构保障DevOps的落地不断优化和丰富的各种具体实践是实现DevOps的基础通过标准化、自动化和敏捷来拒绝浪费，加快交付 持续发布流水线 ◆开发测试环境和生产环境为网络隔离，通过制品晋级+OA流程审批的方式，将测试通过的制品流转到生产环境 ◆持续交付支持虚拟机与容器平台的镜像发布能力 ◆在安全合规的基础上提升工作效率及发布质量 建设成果 平台推广：CI部分已完成33套（年底计划增加73套），CD部分已完成16套（年底计划增加151套）敏捷文化：需求交付版本火车、需求版本规划SCCB会议、JIRA研发流程、敏捷站会等多项敏捷文化建设研发规范：开发、源代码管理、分支管理、制品库管理、流水线管理、环境管理等6大研发管理规范，提供从“需求->开发->测试->发布->运维->运营”端到端的开发运营一体化平台 微服务发展历程 2012年3月，James Lewis做了题为《Microservices-Java, the Unix Way》2012年11月，Fred George提出了“微服务架构”概念 微服务演进：服务网格–Istio生态 通过在部署的每个应用程序中添加代理“sidecar”（图中的Envoyproxy），Istio可以为应用程序感知流量管理、不可思议的可观察性和强大的安全功能编程到网络中。 数据面与控制面分离 数据面板：接收请求，提供服务发现，健康检查，路由，负载均衡，保证服务认证/授权，以及监控的功能。控制面板：为正在网格中运行的数据面板提供策略和配置。控制面板将所有的数据面板转变为一个分布式系统。 全面实现开发运维一体化提能增效 从需求提出到上线发布一体化的建设方案，真正能够打通开发运维并且实现流程自动化、标准化 云原生2.0（两转变三阶段四个现代化） 阶段1：服务器 阶段3：云原生化 阶段2：云化 •统一云原生基础设施•软件云原生架构•以“应用”为中心 •统一云化资源地•软件迁移上云•以“资源”为中心 •碎片物理设备管理•软件与硬件割裂•以“设备”为中心 转变2：应用快速化 转变1：资源自动化 服务器阶段：其特点是以硬件设备为中心，业务应用随不同厂 云化阶段：各类资源如计算、存储、网络的池化和云化，通过统一的云平台，为上 云原生阶段：从以资源为中心转移到以应用为中心，包括应用敏捷交付、快速弹性 商设备、操作系统的差异化进行定制；设备的安装、调试，应用的部署、运维基本靠人力完成。虚拟化软件提升了资源的利用率、扩缩容的灵活性，但并未从根本上解决基础设施与软件割裂、运维复杂的难题。 层业务软件提供统一的资源管理接口，屏蔽一部分基础设施的差异，使得应用的通用性增强。但因为虚拟技术和云平台差异化较大，应用还是无法以完全标准化的模式构建，应用部署还是以资源为中心。 、平滑迁移、无损容灾等。将基础设施与业务平台融合，为业务应用提供标准的运行、监控、治理平台，并将业务的通用能力下沉到平台侧，更好的实现应用的快速构建和自动化运维。 路漫漫其修远兮吾将上下而求索