服务治理在猫眼娱乐的演进之路.docxVIP

服务管理在猫眼消遣的演进之路 我们开篇之前，我们先来争辩一个问题，我们谈到服务管理的时候，说的其实是什么呢？我们认为，服务管理的关键要素在于两点，人和系统，我们在系统层面期望服务能够依据业务愿景和架构师的理念进行运转和持续演进。而在人的层面，我们期望在这些系统之上工作的工程师能够取的最大的温馨感。听起来有点像废话，但的确是我们很简约在一些高大上的名词中忽视掉的点。在微服务设计一书中，其实也提到了类似的论点。猫眼的服务管理体系在几年的演进过程中，其实也遇到了一些问题。 猫眼作为国内互联网在线票务的领头羊，也在全消遣领域在做持续深耕，目前有数千万的DAU，每日百亿级的调用和百万级的QPS。 在这个领域，猫眼目前面临的次要难点有如下几个， 从系统层面来说，次要面临的是系统稳定性的问题。大家都晓得，每一家公司都会有一些数据资产是很敏感的，所以需要对于一些爬虫和恶意流量进行准实时的处理。另外，猫眼消遣作为一个全消遣领域的平台型公司，也会承载业务在大档期和大活动中流量几倍、十倍甚至百倍千倍的压力迸发，如何在这种情况下，保障系统的可用性，也是一个值得争辩的问题。以及，毛病是无法避开的，无论流量凹凸。所以如何保障系统的日常柔性可用，也是需要关注的问题 从人这一层面来说，次要面临的是人效问题。服务管理的各种两头件接受的总体上是一个富SDK的方式嵌入业务方。所以这必定会带来两个问题，多言语的情况下会带来更高的维护成本，以及SDK升级所会带来的和业务相互耦合掣肘的问题。 以上难点都在过往的几年中困扰着猫眼，也肯定程度上妨碍了猫眼业务的进展。 举两个典型的例子， 在稳定性这方面，2021年春节档Redis千兆网卡打满带来的严峻影响，我们常规时候的流量曲线会有两个规律的早晚高峰，而大家可以看到，在毛病当天，由于网卡打满导致了格外长时间的服务不行用。这也是猫眼经受过的一个格外严重的事故。 而在人效方面，目前猫眼有1000+的服务，两头件的升级动辄半年以上的版本升级周期，这个其实对于业务方或者底层架构团队来说都是格外不友好的一个体验。 所以基于这些问题，猫眼开头开展服务管理的演进之路。 高可用管理中心在猫眼的落地 我们关注发觉，猫眼次要面临的场景是大流量下的概率性毛病。基于这样一个前提，我们需要开放了毛病前、中、后全生命周期的共享优化。基于这样的一些背景，我们得出高可用管理在猫眼的落地理论架构是：面对毛病全生命周期进行管理，悲观与乐观并济。 怎样理解这句话呢，从乐观角度上来说，我们通过各种测试和评估，我们的系统应当可以避开全部的问题。但是从悲观角度来看，基于墨菲定律，我们晓得可能发生的就肯定会发生，所以我们必需来看假定问题发生，我们能做什么。以及问题真的发生，我们又能做什么。 而高可用在猫眼落地，需要面临实际生产中的诸多难点与挑战，比如前面有提到的，如何应对永无尽头的爬虫和恶意流量的攻击，如何应对大档期洪峰或者秒宰场景，另外，基于墨菲定律我们晓得，毛病是无法避开的。所以如何应对随时随地可能消灭的各种上下游的毛病，如何避开快速毛病恢复可能带来的服务雪崩。这些都是做高可用中需要去应对的挑战，也是猫眼几年历程中真实消灭的问题。 另外，高可用领域中，流控的常规处理方案是用富SDK来做的，而富SDK能否能满足业务快速滚动以及流控本身灵敏迭代升级的诉求呢？而假如将流控功能都剥离到Server端，我们晓得分布式环境中会带来最大麻烦的就是网络，全部剥离到Server端的话如何保障实时性和牢靠性？也就是所谓的Client Side或Server Side，我们应当如何选择？ 再者，我们有了限流、熔断、混沌工程等等的工具后，很简约就消灭有工具但实际上用不好的情况，更有甚者，由于分布式网状拓扑下的这些限流熔断工具的滥用，反而可能将你的系统推向不行控的深渊。我们如何避开有术而无道的局面呢？ 基于这样的一些考虑，我们开展了专项的管理举动，自研了猫眼高可用管理中心，代号大禹。旨在供应自动化的限流、熔断、降级、隔离、演练、监控报警的一站式可用性保障方案。由于篇幅限制，下面我们次要引见系统的全体架构以及一些产品上的特点。愈加具体的架构实现会在后续大会上去做逐渐的披露。 首先，这个是我们高可用管理中心的一个分层架构。我们来做一个简约的引见 在最上层，是我们的产品层，高可用管理中心目前供应出了恶意流量探测、演练、限流、熔断、降级的产品，同时，为了达到策略上线效率的最大化，我们还供应了可自定义规章的模块，我们将一条策略笼统为以断言、条件推断和处理三个组件为核心的一个表达式，这样就可以在无需前端任何产品级别开发的前提下完成策略的快速上线。同时你可以基于我们原子的策略组件的自在拼装，来实现你想要的自定义的策略力量。 左下角的演练管控中心则支撑起了演练产品，他底层依托阿里的Sandbox实现动态注入