学生模拟网站开发,WordPress海报封面主题,家居网站建设策划开发,百度小说排行榜第一名业务场景与挑战 友邦保险是香港联合交易所上市的人寿保险集团#xff0c;覆盖 18 个市场。截至 2021 年 12 月 31 号#xff0c;总资产 3400 亿美元。 友邦保险于 1992 年在上海设立分公司#xff0c;是改革开放后最早一批获发个人人身保险业务营业执照的非本土保险机构之…业务场景与挑战 友邦保险是香港联合交易所上市的人寿保险集团覆盖 18 个市场。截至 2021 年 12 月 31 号总资产 3400 亿美元。 友邦保险于 1992 年在上海设立分公司是改革开放后最早一批获发个人人身保险业务营业执照的非本土保险机构之一也是第一家将保险营销员制度引进国内的保险公司。2020 年 6 月友邦获批将友邦保险有限公司上海分公司改建为友邦人寿保险有限公司。2020 年 7 月友邦人寿正式成为中国内地首家外资独资人寿保险公司。友邦友享 App 在 2021 年荣获最佳保险科技平台。 业务特点和架构 为了践行友邦健康长久好生活的 slogan 上云过程中我们对应用做了大量微服务化改造以适应快速变化的业务要求和性能要求并将此前在 AS400 里的 core 包程序做了微服务化改造提高了可用时间。此外我们采用了容器化方案使应用运行在 K8s 上以获得弹性扩容能力和自愈能力。 上述改造导致了应用系统复杂度的提升因此观测微服务和 K8s 的运行成为了一大挑战。 与此同时部分外采应用没有源码不适合做微服务化改造但我们仍然对这部分应用进行了容器化改造将它们部署进 K8s还有一部分应用由于各种原因不适合上云改造最终留在了 IDC 机房。因此服务之间的调用会涉及云上到云下、云下到云上等复杂情况。 迁云之后实实在在为我们带来了 SLA 的提升但也导致了访问链路和部署复杂度的提升如何更好地观测应用成为了无法回避的挑战。 可观测性建设痛点和挑战 建设一个优秀的观测系统会面临以下痛点 观测复杂度提升云原生微服务化虽然带来了很高的 HA但也提升了系统的复杂度加大了可观测的难度。核保通过率、交单成功率、用户的日活/月活散落在各个业务模块里业务需要提供全局视角以观察整个保单生命周期里重要业务节点的运行情况并获取研发态的具体情况。技术选型困难由于历史原因友邦内部应用技术选型不一版本各异导致可观测技术和调用链追踪面临很大的困难。统一观测困难友邦是一家金融公司开发系统和应用运维完全分开日志也完全分开存储和维护因此无法将以上数据在同一个大盘里呈现。指标治理IaaS层、PaaS 层和应用层有很多指标单数据库方面就可能有超过 200 多个指标。如果希望指标达到比较容易理解与追踪的数量则需要不断地进行回顾、删减。快速故障定位在 IDC 机房时代没有直观的方式让应用查看自己的资源是否足够。虽然已经有商业 APM 工具但其价格高昂不属于经济有效的方式。问题发生时因为只有少量应用安装了 APM 所以调用链不完整无法实现快速故障定位。 可观测性建设流程和规划 可观测系统的建设主要分为调研分析、方案设计、改造实施和上线验证四个阶段。 一个优秀的可观测系统至少需要满足五个要求 服务资源追踪可以将服务运行节点上的 CPU 内存、网络磁盘、 IO 应用指标进行聚合。问题发生时能够轻松观察到异常指标。提供服务 Top 视图按照服务的调用量、请求耗时、热点排名应用可以很方便获知哪些是热点 API、哪些 API 请求量较高等可以更好地规划自身的服务资源。调用链追踪关联服务上下游并且最好是无侵入式可以很方面地从 Trace关联到日志获取到链路问题所在。调用时长分布观察服务的上游与下游观察异步耗时请求慢时可以很方便地判断是服务资源耗时还是依赖服务资源耗时。数据库关联操作帮助应用观察到 API 的关联 SQL、慢 SQL、 Redis 的查询存在慢 key 查询 、Mongo 存在慢查询等操作。 实践与落地 可观测性整体设计思路 友邦为了满足业务发展需求在技术层面需要做云原生技术架构的升级和改造。因此阿里云与友邦在应用容器化和可观测性上展开了深度合作。结合业务情况和监控痛点通过几十次的讨论和推演我们最终明确了两个重要建设思路 首先根据业务价值自上而下设计可观测体系。从业务监控、应用监控和资源监控一直向下推进。如果使用自下而上的设计方式出现问题时团队会浪费大量时间和精力排查从来不会导致客户受影响的问题或客户先于监控系统发现了问题。因此需要最先关注和设计与用户体验、核心交易相关的业务监控。 其次需要结合业务设计服务的链路追踪、应用性能监控。比如将某应用的 API 接口翻译成业务可读懂的语言比如依靠保单生效的接口处理时间和处理数量以及接口还调用/依赖了其他哪些服务等来最终明确问题所在最后结合应用诊断工具 Arthas、 JVM 的调优工具、应用日志以及资源级别的监控来确认是代码问题还是底层资源的使用问题。通过从确定事故发生再到定位引起事故的原因进而确认问题本身来提升故障发现和问题定位能力。 确认了自上而下的可观测体系后接下来需要明确可观测的指标范围。 全生命周期监控指标设计 可观测指标不仅是运行态还需要包含研发态形成应用全生命周期的监控指标体系。 系统经过云原生改造后友邦的 CICD 流水线通过 Jenkins 进行自动化。为了提升软件的研发效率需要抽象出可衡量的指标比如应用每天的构建次数、构建时长、构建成功率、部署频率或部署成功率以及形成这些指标的基础元数据信息等。 运行态分为系统层监控、应用层监控和业务层监控三层监控重要性等级依次升高。资源监控层主要聚焦在 K8s 集群的 node 节点、磁盘网络、运行 Pod 监控、核心云产品等监控指标应用层主要聚焦于应用的健康度、状态码、性能监控、JVM、GC 等性能指标上业务层主要监控业务的核心指标如 PV、UV、投保人数、投保金额、签单数等它直接影响着监控系统设计的成败因为这是最能够体现业务价值的部分。 可观测性架构大图 上图为友邦人寿可观测性体系的架构总体设计思路分为三层 第一层为采集层。因为要符合友邦的技术架构和建设需求我们选择用 Java 编写流水线的 CICD 数据采集器。研发人员在使用 Jenkins 进行应用的 build 或 deploy 时该采集器能将应用构建的数据和部署的数据全部存到数据库里。另外采集数据时加上了相关联的 tag 实现了元数据的共享。比如流水线构建的应用名称必须与 K8s 的服务名称一致构建失败时即可快速找到出错的应用。 此外针对应用的 APM 探针社区一般使用字节码增强的无侵入技术。但是由于友邦架构的复杂度Skywalking 探针无法完全覆盖友邦的场景。同时友邦对于深度性能的诊断也有较高要求希望能够集成阿里开源的 Arthas、 Memory dump 等能力APM 探针也会影响应用性能因此我们最终选择经过双 11 大规模检验的 ARMS Agent。 各类云产品中间件、集群的监控指标采集主要通过 Prometheus应用日志主要使用 DaemonSet 的方式进行采集相比于 Sidecar其占用资源更少工程上也更为简单。 第二层为存储层。研发态的元数据和 pipeline 的构建数据因其数据量不大而且是结构化形态因此存储在 MySQL 里。Metrics 监控指标的数据存储在阿里云的 Prometheus 产品上日志和调用链 Tracing 数据存储在阿里云的 SLS 产品上。考虑到业务的增长未来会产生大量的数据这两款产品能够保证监控系统的稳定性、可扩展性和高可用性。同时两款产品都是 Serverless 化持续按量付费不存在磁盘或空间浪费。 第三层为统一展示层通过 Grafana 进行汇聚和展示。当时阿里还未推出托管版的 Grafana因此我们选择自建推荐使用 8.0 以上的版本。为了保证运行的高可用需要多实例部署并将配置的数据统一传到数据库里然后根据此前设计的监控指标选择对应的数据源编写查询语句最终结合 Grafana 丰富的图表进行统一展示。 业务监控的实现是通过将采集到 SLS 里的业务日志和应用日志做统计分析。SLS 的 SQL 查询功能非常丰富语句编写也非常方便。再通过 SLS Grafana 插件集成到 Grafana 里最终业务统计数据即可在 Grafana 大盘进行展示。 统一监控平台 上图为建设成果。通过大屏、中屏和小屏的方式形成指挥决策、研发仪表盘应用性能展示以及告警推送、多维度的监控能力。 其中左侧大屏展示核心指标比如容器集群的资源利用率、service Pod 健康度以及联通性等通用指标为公司决策提供支持。 右上方中屏主要展示流水线的研发效率指标、应用性能的指标以及全局调用链帮助研发人员提升效率和问题定位的速度。 右下方小屏通过历史数据的对比设置了报警阀值。出现异常时通过钉钉或短信报警的方式推送到电脑、手机终端帮助运维人员及时发现和处理问题。 作者沈斌、右京 原文链接 本文为阿里云原创内容未经允许不得转载。