Java|行业 SaaS 微服务稳定性保障实战( 二 ) 组织架构|阿波罗|jvm

虽然微服务和组织架构趋同使得系统沟通效率较高，但是这也带来了很多分布式的系统问题。比如微服务之间的交互，没有人能够对服务有整体性、全局性的了解，研发人员最直接的期望就是在分布式系统中也能有单机系统的排查效率，这促使我们需要将系统以服务器为中心的思路转变为以调用链为中心的思路。
稳定性诉求激增
F6 最早进行业务开发时采用烟囱式的建设。单体应用比较简单，但是它在扩展性和可维护性上存在很多问题。比如所有研发都在系统上进行，代码冲突较多，什么时间点能发布，发布会造成多少业务量损失等皆难以明确。因此，越来越多情况导致我们需要进行微服务拆分，而微服务拆分和调用又会导致调用链十分复杂繁琐，如上图右所示，几乎无法人为分析出调用链路。
那么，怎么样才能尽可能降低线上排查故障的难度？
可观测演进传统监控+微应用日志收集 ELKStack 获取日志和查询 ElastAlert 完成日志告警
传统的监控和微服务日志收集一般采用 ELKStack 进行日志收集。 ELK 是三个开源项目的首字母缩写，分别是 Elasticsearch、Logstash 和 Kibana 。
我们重度依赖 ELK 进行微服务日志的收集，与此同时，还使用了开源的基于 ES 的报警系统 ElastAlert 组件，主要功能是从 ES 中查询出匹配规则，对相关类型数据进行报警。

上图描述了通过日志收集进行日常查询的思路。比如研发人员会通过 pipeling 查询线上日志， ElastAlert 通过匹配规则告警获取到 ES 日志中发掘出来异常数据， kibana 可以进行查询，也可以优先定位出系统中发生的异常。
架构升级+可观测性引入 Grafana 看板+Zorka 支持 jvm 监控
随着业务发展，系统对日志的要求也逐步增加，比如团队非常多，需要配置各种各样的告警规则，因此我们引入了 Grafana 逐步替代 kibana 和 Zabbix 的查询功能。可以通过 Grafana 的 ES 插件查询对日志进行告警，然后通过 alert 功能完成原先 ElastAlert 的排除，同时可以使用 Grafana 做出更直观的可视化大屏进行展示。
除了日志外，我们也期望收集到 Java 应用指标，因此又引入了 Zorka 开源组件。 Zorka 和 Zabbix 可以简单地进行结合，可以通过 Zorka 将收集到的信息上报给 Zabbix 进行展示。而 Zabbix 又可以通过 Grafana Zabbix 插件直接输出数据，最终将整个应用大屏和看板信息都收集到 Grafana 界面。

Zorka 的工作机制类似于通过 Zabbix Java gateway 的方式，通过 Java Agent 自动挂载到 Java 进程中，用于统计常见应用容器和请求数指标等，初步解决了我们对于 Java 进程的观测需求。
云原生改造 K8s 的编排能力和微服务相辅相成迫切需要 trace 组件的支持
随着微服务程度不断提升，传统方式的运维成本越来越高，因此，我们启动了云原生化改造。
首先，云原生化的改造是 K8s 侧就绪探针和存活探针的编写。存活探针的编写提升了服务的自愈能力，出现了 OOM 后服务能够自动恢复、启动新节点，保证数据服务正常提供。除了 K8s 外，我们还引入了 Prometheus 和 ARMS 应用监控。
Prometheus 作为 CNCF 仅次于 K8s 的 2 号项目，在整个 metrics 领域形成了足够的话语权；ARMS 应用监控作为阿里云商业 APM 的拳头产品，使我们能够结合云原生的方式，实现研发无感，无需进行任何代码改动即可拥有 trace 功能。更重要的是，阿里云团队能够保持持续迭代，支持越来越多中间件，因此我们认为它必定会成为诊断利器。