开发者学堂课程【阿里云可观测峰会-行业实践分论坛：阿里云可观测峰会-行业实践分论坛】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/776/detail/13940
阿里云可观测峰会-行业实践分论坛
内容介绍
一、行业 SaaS 的微服务稳定性保障实战
二、万节点规模云服务的SRE能力建设
三、友邦人寿可观测体系设计与落地
四、阿里云 ACK 容器服务生产级可观测体系建设实践
五、微服务异常诊断与根因分析算法实践
六、阿里云 Sernerless 可观测实践
七、阿里云可观测峰会
一、行业 SaaS 的微服务稳定性保障实战
今天带来的主题是行业 SaaS 的微服务稳定性保障实战。
1. 自我介绍
一六年加入南京艾福路汽车科技有限公司也就是F6。负责F6后端的架构设计，实施了微服务的相关拆分，主导了k8s在F6的落地和实践，全程参与F6内部DevOps的设计建设和演进，目前主要负责F6基础设施和稳定性的一些工作。目前主要专注于的领域包含Java，包括微服务的架构、云原生领域，DevOps实践以及CICD这些流程，以及最终还有SRE领域。这幅漫画
应该很多同学都有看过，研发同学每天都碰到一些日常的问题需要处理，研发合作的两个问题。竟然是可以运行的为什么么？竟然是可以运行的为什么么？期望可观测能够给大家提供一些解决问题的思路。
2. 引言
首先来了解一下可观测性最近持续火热的来龙去脉，2017年Twitter工程师发表了一篇文章叫<<Monitoring ：and ：Observability>>，首次是将可观测性这一次带入到了可观开发者的视野，通过开玩笑的方式调侃关于可观测性和监控的区别，是这说的，可观测性什么么意思呢？就是因为研发不喜欢做监控，所以需要把监控重新包装成一个新的名词，让它流行起来。真的是这样吗？参考上一次的个漫画，监控能够告知服务究竟是否能够正常运行，但是可观测性可以告诉为什么么服务没有在正常运行。从谷歌趋势图当中可以看到的观测性逐年呈现整体上升的一个态势。可观的信息也会被视为系统的一个属性与功能性、安全性等等，都会成为系统在开发设计过程当中就需要具备的一个特性。
3. 可观测发展趋势
2020年之后的可观测的这个搜索趋势出现了井喷，相关词包括keepEyes,SIE这个其实和疫情应该有密切相关，包括一些合规政策的缩紧，就是越来越多的基础服务面临的这个稳定性的挑战。而破解稳定性的很重要的一个手段就是在于服务需要提供可观特性，当然，很大一部分原因也是因为谷歌的一本站点可靠性工程的逐步普及。国内的大厂纷纷设立相关岗位和对应的招聘指标可观测性在国内也得到了较大的关注。图片所示是整体在全球搜索趋势，明显判断就是在中国这边的搜索其实是热度较高的。
4. 可观测性定义
再回到可观性这个词的来源，从维基百科当中可以得到关心，最早是匈牙利的工程师提出来的，是一个数学上的概念，可观测性是指系统可以由外部输出，推断其内部状态的一个程度。换句话说，可观性应该可以回答漫画的问题，为什么么服务没有正常的运行呢，可能是因为比如说现金池不足，或者是说年金数不够等等。图片也是维基百科提供的一个关于可观测性的一个数据。也就是说应当是可以从它的数据的产出分析出来，究竟内部是如何运转的。今天分享的主题主要分为三个部分，第一部分难点与挑战，第二部分可观测的演进，第三部分关于未来的畅想。
难点与挑战 ：业务蓬勃发展 ：稳定性述求激增
难点与挑战，业务的蓬勃发展对于稳定性的诉求是激增的。首先来介绍一下F6汽车科技，是一家专注于汽车后市场信息化建设的互联网平台公司。目前是在这个行业，市场占有率可以说是pop的行业SaaS，随着业务发展，F6支持的商户数目短时间内暴增数十倍。同时，也逐步开展的面向技师等等低端产品的一些业务，比如说密码的解析，包括数据的查询等等服务，这样对于稳定的要求也是显著的提高的。
5. 难点与挑战 ：康威定律的作用
业务膨胀，可以看到有一个定律叫做康威定律，这个康威定律也是it史上对整个组织架构提到一个微服务的拆分是一个指导性的一个定位，就是任何的组织在设计系统的过程当中，它都是一个组织架构的一个翻版。随着业务膨胀发挥的作用会导致设计微服务的时候拆分的方式趋同于组织架构，业务增长会导致部门拆分，既然设计微服务的时候也会十分的靠近组织架构，哪怕你前期组织架构和恢复的产品不一致，后面微服务也会逐步的妥协与组织架构。虽然说微服务和组织架构的这个趋同导致整个系统的沟通效率是比较高的，但是带来了很多分步式系统一些问题，比如说保温服务之间的交互没有人可以对服务有整体性的、全局性的了解。
研发最直接的希望就是希望在分布式的系统当中有单机系统的排查效率，促使需要将系统的以服务器为中心的思路，要转变为代用量为中心的思路。F6最早进行业务开发的时候也是烟囱似的开建设应该和绝大部分公司都是类似的，单体的应用是比较简单的。但是在扩展性里面存在很多问题包括可用性，比如说所有的研发都在这个系统里面进行开发的，代码冲突会比较多。什么时间能发，发布会造成多少业务量的损失。有可能都是比较危险的。所以越来越多的情况会导致进行微服务的拆分，但是微服务的拆分的作用就会演化出来，像类似于这张图
这个是淘宝的文章摘录出来的一张图，整个概念是十分的复杂、繁琐，从人的角度基本上是分不出来，到底有没有什么么方式能够去尽可能的降低的线上排查故障的这种难度，以淘宝这个这张图为例，比方说它有一个这个服务里面出现一些问题。如何知道是的下面当中任何地方出现问题呢。下面就来具体聊聊F6的可观测上面的演进。
6. 可观测演进
（1）传统监控+微应用日志收集
传统的监控和微服务日志的收集，对于日志收集采用的是ELKStack是三个开源首项目的首字母缩写，虽然很多现在可能中间采用，但是目前大家仓库的时候还是ELX进行恢复日志的收集，与此同时，还使用了一家公司开源的基于ES的报警系统，ElasAlart这个组件的主要功能是从ES当中查询出来匹配的规则，对这些数据进行报警。第二，这个公司是类似于国内的大众点评也许是类似这样的公司，提出来这样一个关于ES查询的一个组件，其实还比较好用，提供了比较多的规则，比方说spark，或者是说其的一些出现监测。也出现了较多的记录，比如说flag，或者是说book等等email。这张图是
描述了通过日志收集整体进行的一个日常的查询的一个思路，比方说研发会通过批量查询线上的日志，ES是通过匹配规则进行报警，获取到ES的当中发掘出来的异常的数据，然后就可以进行查询，通过这种方式也可以优先定位出来一些系统当中发生了异常。
（1）架构升级+可观测性引入
随着业务发展诉求，对于日志的要求会更加的多，比如说团队非常多，需要去配置各种各样的规则，因此引入了Grarana逐步替代了其软件的一些查询的功能，可以通过Grarana去查询对应的日志，进行报警，然后通过功能能够完成对应的这样一个排查排除，同时可以用Grarana做出更加直观的可视化大屏，通过电视或者是一些大屏进行展示。
除日志之外，也更多的希望收集到一些Java的指标，比如说线上应用可能出现OM等，比方说可能出现线程，线程数过高等等这些问题。所以呢，引入了一个叫做Zorka组件，也是调研了一段时间之后采用，由于当时使用的是David ：Zorka和David，可以比较简单的进行结合，可以通过Zorka将收集出来的基本的一些信息上报rapid进行展示,rapid又可以通过组件直接输出数据。所以整体来说，就可以将整个的用的都收集效果还算是比较不错的
Zorka的工作机制是类似于通过在自动对位的方式，它也是一个的java，通过这种java组件直接进行当中，可以用来统计出来，包括一些常见的应用容器，比如说ipad等等这些请求的一些指标都可以收集到，初步解决对代码进行的观测需求。
（2）云原生改造
随着服务的程度不断的提升，发现传统方式的运维成本越来越高，尤其是比如说服务资源等方面，一旦发生了一个应用的OM，如果没有写比较好的自动恢复的脚本，这个应用很有可能就少了一个节点，一个节点可能如果没有察觉到，到时候其的节点会越来越多，请求越来越受不了之后可能会出现整体服务的pass，所以也启动了云原生的改造，云原生的改造，其实这边可能重点关注一下，关于就去探针和这个中国探针的一些编写，通过这些探针编写，尽可能提升了的服务自愈能力，如果这样有可能的服务就会恢复启动一个新的节点然后完成的数据的服务正常提供。
除了k8s之外，也引入了Peometheus和ARMS应用监控，Peometheus作为这个仅次于k8S的二号项目，基本上在整个这个领域形成了足够的安全。ARMS应用监控作为阿里云商业PM的全套产品，作为一个线上服务，全部是重度依赖阿里云的这样一个公司，比如说使用阿里云的ack ：acm ：各种各样的组件，当然里面也提到了。
结果云原生的方式做到让研发不需要做任何的代码的改动，就可以直接拥有到一个trace的一个功能。而且阿里云团队还在不停的迭代，可以支持越来越多的中间件，会是一个诊断的利器。可以看到，虽然没有整体的可观测性的这样一个认识，但是事实上已经在围绕的就是亚非，比方说magic、shoes这样的一个Peometheus一个工作。
由于对云原生的改造，这里面的监控模型也发生了变化，最早监控模型postgreSQL每次发货在同一个机器上面，同一个应用在机器上面，所以它有固定的host，但是当上到云原生之后进行容器化改造，整个pod应用的是在不停的飘飘飘，而且有可能会出现新的应用，扩容缩容等问题，整个的监控模型就逐步从不转换成po，也更加契合Peometheus的这样一个收集模型。
所以将把jmxExporter也逐步的从可客观的体系当中进行了玻璃，需要通过一些其的数据来进行的Mac ：Pro的数据。里面有个插曲，为什么没有使用直接涉及假面指标，是因为arms不会覆盖的线上和线下所有的Java应用，比如说测试环境，愈发环境等等，希望有一些基本的数据的收集，但是因为arms是有成本的，所以并没有将作为一个完整的记录，当然线上的服务已经完全进入了，通过刚刚说的这种方式，选择了一个叫做maxpro的组建，style也是Peometheus官方社区提供的第一加特通过加密呢，直接利用Java的JX机制读取GM的信息，可以将这个数据直接转化成为詹姆斯，可以变成。则是对其进行。进行监控和采集，通过operator注册对应的monitor完成指标科技。
第二，这就是一个典型的smarter，监控的一个level ：APP为节目呢，这样的一个Sernerless，但凡是有这个Sernerless的指标的这样一个，就可以自动收集到它的应用的基本数据，它会抓取到这个对应的叫max，这样的一个HP的。通过编写对呢，本次如果完成对应的监控，可以看到这边有一个Java的，Java进程的这样一个关系，就是通过定时的去发掘的数据，去保存到自己的数据库当中，然后定期的变形，对az入能够完成应用的指标的话题。
业务蓬勃发展之后，人员激增，恢复暴增，研发人数和报警都是剧烈的增长，为了提升报警的复杂的响应率，又重新使用了阿波罗这个配置中心的多元匹配，通过这样的一套发给的业务，业务的整体流程大概是这样子的，通过关门会去收集到另一个DS的报警，或者是一些其的一些方面，由于它有一个matrix是应用范围应用。通过这个应用去关联，到最后这个用的报警的时候，会转发到刚刚这个编写的精准告警服务上面，精准告警服务解析到对应根据应用阿波罗内容当中获取到对应的姓名、手机号等信息，通过这个信息通过钉钉进行报复。这样子的话，可以极大地提升了消息的阅读率。
除了这个之外，还有阿里云的应用实施监控服务，Arms ：arms能够在无需代码进行任何改造的前提下，支持绝大部分中间件和框架，包括比如卡夫卡等等。同时人员说话之后，仅需要在朋友里面添加附件，就支持相关的记载，比如说这边有一个选择或者怎样，这样的两个主体，通过这两个就可以创建一个对应的同名的，在arms实力下面的监控连同需要关注的差异发布，重启之后就会自动升级，整体的微服务的进行会有好，同时它提供了一个比较完整的测试图，就是一个线上的应用节点调用一个整个电路。
包括它里面的整个一个类似于单独的这样的一个，其实大部分都是从可观测的这个一个很好的实践，给提供了一些伊拉克，上下游耗时图等等。
2020年之后可观测深入人心，整体在国内恢复领域基本上是遍地开发，整体也升级了的可观测的思路。业界广泛推行的客观性包含三大支柱，分别是日志事件，分布式链路追踪以及指示监控，任何时代都需要监控，监控其实一定是一个重要的东西，但是已经不再是一个核心需求。可以看到监控集体包含了造型和应用的概念，但是事实上可观性包含了包括没错，分析，以及依赖分析，研发同学原先最早的监控主题是运维同学，但运维同学大部分只能处理的是系统服务的报警，比如说机器服务或者是其。如果现在上升到的这个微服务的领域里面来看，还有更多的可能是应用之间的一些问题，比如说需要问题的拍照，举个简单的例子就是。
比如说，现在的服务出现了，出现了这个很慢请求是因为什么么问题，有可能是因为的代码写的不好，有些所或者是说的线程池不足，或者是说年纪数不够，或者是说可能因为的漫长，，这些种种的问题都可能表现出来是一个可能，就是慢，或者服务无法响应，这么多的可能性，要通过可观测性才能够尽可能发挥到种很多不可能的。或者说是额外的这种分支能够确定未来真正的声音，但是定位又不是一个完全真实的需求，其实更多的就是利用客观地尽可能的提出来的问题是在什么么地方，然后通过替换对应组件，通过去进行相关的垄断，或者说限流等措施。就是说不能尽可能的去提升整体的spa，同样的东西也是同样的道理，就是项目可能出现的问题呢比如说节点的耗时，各种各样节点的耗时。除此之外，依赖分析这也是一个微服务相辅相成的课题。或者微服务的依赖调用链路是否合理，正常。都可以通过可观测性进行视察。
随着应用越来越多，对于可观性的需求越来越多，也是讲了一套简单的分析通过文本相似度的算法，将当前服务日志进行归类、聚类分析。这是一个典型的OS发生故障的一个依赖的服务进行服务升级，但是如果。这是通过日志的抓取智能分析出来的一个值，但是如果说的可观测性做得足够好，已经进入到了OAS的升级的公告，或者说相关的一些变更，其实做了很长时间的SRE之后，其实变更对于线上的破坏也是非常大的，如果能把变更等等也收集到的可观测体系当中，这是一个很好的做法。这样也是同样的道理，如果能将OAS升级的这样的一个信息收集到的客观的系统当中，通过总总的事件关联，能够分析出来，的更新是因为的基础语法团队战升级对应的MQ，或者是说其的一些特点对于系统的稳定性和对应的问题的排查是极为关注的。
可能在此期间，团队也深入合作，探索了一些可观测的最佳实践，最近提供了一个新的功能，将CAD直接恢复到C，可以看到一个商标头，可以再精彩的日志当中加大输出，比如说S或者说es等等，输出到对应的位置当中，进行解锁。如果的客户在发生故障的时候报错，或者是说它的一些请求异常板，如果在客户在上传的时候，将这些日志信息，包括cheese一起上报到的知识同学，获得的服务器。最后们也通过这个cheese ：id就可以很快的定位到问题的原因，还有一个电脑也不至于说可能需要根据业务同学的这个报错的IP时间段分类信息再去精确的去查询一下，这边确实是打个引号的其实这两个相似的查询。但是在整个店面当中，不一定是可以用来做一个很好的一个解锁条件，同时AMS支持在直接用MB传输3D，它包括Java ：ID，包括整个货架，可以将这三个作为标准输出，就是一个典型的支付的一个场景，就是阿姆斯的后台的被打开。它里面支持各种各样组建，只需要将一个IP在的日志系统当中。这个方案比较小，比较简单，对研发的修改也很少在这边修改，对于整体的locking何处的关联程度就已经做了比较大的提升。减少的数据故障。阿姆斯除了支持整体的观测，为了进一步降低LPR也是做了不少努力。
刚刚提到了整个UPS，它提供了很多的数据，但是这个数据如何到达或者说研发运维同学的手里呢？其实是要花点心思阿姆斯上线运维报警平台，通过可视化的方式完成了报警、转发、分流等等事件处理。可以通过经络，功能分组等等，支持多种集成方式，目前在用的包含米修斯版本了，阿姆斯以及云监控可以展开一下，云监控里面的数据包含信息还蛮多的，包括比如说NS刚刚提到的个APP里面如果出现了危机等等，等等服务都可以研发同学或者同学在群里面跟你们对应的相应事件即可，同时这也支持相关的报表功能，定时提醒，还有事件升级等部门，也便于事后的复盘和改善。这就是一个典型的线上处理处理这种问题的一些截图
就是在钉钉群里面的一个告警，它会提示你上次的保单，上次是谁处理的一些大概的一些数据，然后有一个告警列表，然后还有对应的一个事件处理流程，比如说可以过滤，可以分割，内容是自带的丰富
通过丰富或者是说匹配更新等等这些方式，内容填充模板可以用来去做精准告警，比方说识别到这个应用是叫名称，然后就可以通过让去关联到对应的，或者是说关联到对应的人员即可，这样子的话，刚刚个通过后写的个SDK的个应用也是可以退出的。还算是比较方便。
同时，也借鉴了奥姆斯的免修改注入背景的这种方式，可以看看这个资本通过一个叫做into ：container的方式，注入了很多的奥克斯的一些信息。其实也挂着一个帽子，然后后面的人都在这上面，所以如果使用的同学可以关注一下，得也是这样的，应该会是APP上。因为这样的一个考验的，所以可以做。要用阿姆斯的接口获取到当前奥斯丁的最新。然后下载这个交易的最新版本注入了很多的阿姆斯的一些信息，其实也挂了一个，然后后面的日子都在这个上面，所以如果同学可以关注一下，里面会做APP的一些信息，也正因为有这样的一个状态了，所以可以做到自动升级。要用奥斯的接口获取到当前奥斯的罪行。
然后下载这个加微信的最新版本，放到对应的这个方子的目录下面，然后呢，在这个目录下面和对应的数字进行通信，通过共享的方式，就是这边提到的共享的方法加二技能的共享，然后最核心的是通过家乐福o型是实现了加一点的话，你看这边就是一个Java ：to ：options里面有个Java技能组建的，核心思路就是这样。这样的一种方式，也模拟了这样的一套流程，通过Windows的组件去做快的完全对应的单词的方式，修改代码，可以看到这里面做一个简单的实验，就是用用CAD的去给对应的专门的打一个注解，这个注解就不需要研发，或者是说一个团队。这个CD进入了一个加速，然后就可以去做用流量。流量回放，比方说或者是说出口。用来做自动化测试的，比方说其实概率等等等等有很多种方式去做出来。
商业化产品之外，还积极拥抱，开源拥抱社区，进入了比较多的组件，极大地提升了整个系统的观测性，包括是，这个还有一些，比如说亚瑟，或者是一块儿。可以用来干什么呢？是可以做一些黑客探针，比如说仅仅需要探测HTTP请求是否正常，BF，求证是否正常等。服务的入口，证书异常其实就更经常会出现每年都会出现证书过期没有及时更新的问题，通过这些，可以去定期的轮询证书是否过期，对应的正是获悉通过这种方式。
除了日常服务的关系，还实现了全面客观地等持续优化上。对于修改，就可以利用这个开源组件进行成本优化，可以直接输出资源的使用率、相关报表等进一步的反馈，研发同学优化，甚至可以用来发现cpu和内存是否已成一个cpu太多使用，但实际上没有优惠或者是相反的意见。通过这样一些方式能够尽可能实现资源的合理的分配。这是一个比较简单的报表，26这边的业务团队，研发团队们是以车进行，比如说奔驰、迈巴赫、八路等等，可以看到这是一个完整的报表，定期会把这个数据反馈给研发，研发组根据这个报表来去判断是否需要进行一个持续的优化。
7. 未来畅想
为主线发生了水军排查问题的时候很多，不再是一种信念。更多的可能是系统的员工网络前面的，比如说过年导师走动，或者是说网络同款等等，需要更加底层的数据进行追踪和拍照。用PPS可以更好地回答翻译出来的延迟、流量，错误，饱和度等等行情指标。出现的问题，一个典型的例子就是，比如说这里学习斩断切换的过程当中，有可能会形成一些PP的半开连接，连接对来说有害的，在使用过程当中可能利用了很多的类似于的一些功能，当一旦发生了这种半开连接，就会产生一些业务。这个也是存在的一些问题，包括比方说你常见的一种对MQ的这种订阅，或者说其的一些都会有这种相关的，比如说有一些，比如说TCP连接建立的连体边是否合理，可以通过这些数据能够得到一个相应回答。
混沌工程主要福利和利用客观特性施工帮助先发制人都发现了系统的弱点，二年六月份CF战队的观众性提出了特别小组，除了三大支柱之外，其三大支柱呢，就是刚刚说的，在这边可能非常非常黑或者黑，然后产品建议Magic的话主要就是，然后它里面可能涉及了一些自定义的业务数据，或者是说将这些数据各种各样。对于混沌工程是否能够划分在可观测性里面，其实是有社区是有建议的，但是CF确实是把整个可观测性的特别兴趣小组里面是包含了PNG和持续优化为什么么呢？其实是有一定道理的，这个工程虽然说认为是一种客观理性的分析工具，或者说是一种可行的，但是农场种地确实也不关心，你试一下，如果在实施互动过程中发生了故障，不确定是否能引起的，这个问题其实比较麻烦，利用客观罪行，尽可能少的半径为的问题，通过C能够持续优化的系统提前发现系统的一些薄弱点，三点问题解决。对系统稳定性更好的保驾护航。
Open ：Telemetry ：简称OT ：这是一个通过多个项目合并出来的开源框架，需要更加面向终端研发的统一的客观性的视图。就是按照刚刚说的，比如说把单词。观点达标尽可能的减少。通过数据关联减少可观测性，比如说刚刚通过的一个IP，通过日志里面收集的这个数据，然后就可以和24ID进行。这里面其实阿姆斯特丹其实也可以单独再说一下，就是奥德赛的本质上，虽然说有可能是有奖励的，但是这个ID呢，本质上它已经生成了，也就是说当中基本上都可以利用到这个决赛只是。阿姆斯的个圈子的采样，有可能会联系到这个数据而已，但是这个确实，同样的本质上也是一个很有效的信息也希望通过探索出来更好的，比方说magic和tess的互相关联的方式，减少这种数据孤岛，提升整体服务的可观测性，利用这种可观自信，尽可能的缩短线上，如果真的发生故障的，这样的一个排查问题的时间。给业务服务恢复争取时间。以上就是今天分享的全部内容。
