美团外卖架构师曹振团分享：从0到1业务系统架构设计与优化经验
“我相信大多数人都用过美团外卖，尤其是每天的两个用餐高峰期。美团外卖从创立到现在经历了多次迭代，不断适应需求，提供更好的体验。这篇文章就是这样的美团外卖架构师曹振团在2016深圳站分享。曹振团，美团外卖技术专家/架构师，目前负责美团外卖业务系统的架构设计和优化。 2013年加入美团，早期参与了多项创新业务的探索。经历了美团外卖白手起家的创业历程和业务快速发展的高成长期，从0到1积累了丰富的业务系统架构设计和优化经验。加入美团之前，曾在网易网站工作部门，负责后端服务的设计和开发。拥有丰富的架构设计经验和高并发系统实践经验。
本视频时长39分钟，建议在Wifi环境下观看。
技术架构演进
我简单介绍一下外卖的现状：我们是2013年10月开始做外卖的，从餐饮外卖开始。经过两年多的发展，我们不仅可以提供外卖，还可以向超市、便利店提供水果、鲜花、蛋糕、下午茶甚至一些送货服务。我们在做外卖的时候，发现用户对于外卖体验有两个顾虑：
首先是质量。用户对质量的要求非常高。送来的食物不能是冷的、难看的，送餐的人脏了也没关系，影响食欲；
还有一个值得关注的点就是准时性，一定要准时交付。比如我要求12点发货，那么一定是12点发货。不能早也不能晚。如果还早的话为什么不呢？ 11点40分不行了，因为我们正在跟老板开会，一会电话就太烦人了； 12点20分不行了，因为我太饿了，我会饿晕过去的。中午的安排比较多，可能要等到晚饭后了。小睡一下。中午不睡觉，下午就会崩溃。
我们发现，如果我们想要做到极致的用户体验，并且做得足够好，保证用户获得足够好的体验，我们就必须提供专门的配送服务。所以我们做的就是美团的外卖平台和我们自己的配送服务。
我们2013年10月就立了这个东西，11月份就正式上线了。截至2014年11月，我们每天的订单量突破100万份。 2015年5月，我们每天的订单量大概超过了200万个，然后到2015年12月左右，5月份，我们实现了每天300万个订单。今年5月份，我们每天的订单量达到了400万份。我们希望响应国家号召，进行供给侧改革。我们希望为您提供更多、优质、可选的配送服务，希望未来能够达到日均1000万单。
我介绍一下我们的业务以及做这个业务的过程中技术架构的演变。当我们开始做外卖时，我们发现订外卖是通过电话完成的。小餐馆的老板会发传单，我们就用传单上的电话号码给老板打电话下单。我们正在考虑能否把电话点餐变成网上点餐，让用户只需要在网上点餐，而不需要打电话。
所以我们在公司周边的业务中探讨了这个问题。我们早上下了地铁，就在地铁口发传单。我们怎样才能尽快验证这一点呢？
我们提供非常简单的网页版和App。我们不为商家提供任何软件服务。用户在我们平台下单后，我们给商家打电话下单。有时我们会发传单。 ，有时候我们是运营商，用户在我们平台下单，我们然后调用商家下单，然后写代码。当时我们基本上没有对架构思考太多。我们只是尽快地工作，尽快地改进我们的功能。
经过核实这件事情，我们发现确实是可行的。我们发现“懒惰”是一个巨大的需求。因为懒得换频道，所以我发明了遥控器。如果我懒得爬楼梯，我就发明了电梯。人们很懒。因为他们懒得打电话订餐，就直接上网点击。
我们发现这是一个非常强烈的需求，所以我们考虑规模化，因为规模化之后边际成本才能降低。这个软件可以在一个地区、一个城市、全国范围内使用。我们的开发成本如此之高，所以我们正在努力扩大规模。
这个过程爆炸性地产生了许多系统。我们在用户端提供各种APP，在商户端我们也开始提供服务。我们为商户提供PC版、App版、打印机。
打印机连接到我们的后端。如果用户在我们的平台下订单，我们会将其直接推送到这台打印机。这台打印机可以直接打印出订单，同时可以用林志玲或者郭德纲的声音告诉你：“您有美团外卖，请及时处理您的订单。”这对于商家来说是一个非常好的效率提升；同时，我们在我们运营的系统中添加了很多功能。我们拥有爆炸性发展的下单、审核等各种系统。
这个阶段我们的业务发展非常快，导致我们有很多系统。我们当时还没有一个非常清晰的架构，因为我们只是想尽快把这个系统上线。这个时候所有的表都在一个数据库里了，这个事情大家都非常熟悉了。我可以做订单，也可以做管理系统。
但是，这件事在规模和用户数量迅速增加之后给我们带来了很大的麻烦，因为我们之前有很多技术债务。这一阶段，我们进行了重大的结构调整。在这次调整中，我们主要说两点：
第一点是拆解
我们将许多耦合服务拆分为面向服务的服务。服务是通过接口来调用和访问的。服务本身保护自己的库：不能访问别人的库，否则就叫作弊；您的数据库不能被其他人使用。拜访，否则就叫戴绿帽子。
第二点是中间件
我们现阶段引入了很多中间件，包括基于开源的自研KV系统。我们还使用了搜索。我们捕获数据库中的变化，并将实时变化刷新到缓存和索引中，使这个中间件提供稳定可靠的服务。
总结一下，我们的演进大致可以分为这个阶段：总体来说，存在多种逻辑耦合在一起，按照面向服务分离的情况。每个服务独立，专注做一件事情，然后我们做应用级的容错。 ，到现在为止我们都是在做多个机房的容错。
对于缓存，我们早期使用Redis。在Redis发布之前，我们使用的是他们的Alpha版本，当然也遇到了很多陷阱。后来我们采用了自主研发的KV系统。最早我们是共享所有业务的KV。这也带来了一个很大的问题：如果所有业务共享一个KV集群，那么其中一个业务就会导致KV集群出现问题。如果是这样，所有企业都会受到影响。后来我们还把每个业务拆分成自己专用的KV集群。
在数据库层，我们基本上把一些大表查询和对数据库造成很大伤害的查询变成高级搜索，并在数据库和应用层之间添加中间件。
我们基于360开源Atlas进行了自己的定制。这个中间件有一个优点：我们对数据库的改变对于业务层来说是透明的。比如我们觉得容量不够，需要扩展，我们加几个从库，业务层是感觉不到的，我们就会做SQL分组，即数据库分组，哪个SQL到哪个数据库，无论是主库还是从库，我们的业务不需要关心。
遇到的挑战
下面介绍一下做外卖遇到的挑战：
第一个挑战是外卖有一个典型的特点，那就是聚集在中午和晚上两个进食高峰期。这自然是一个非常集中的闪购场景，因为大家都会在11点10分到11点30分之间聚集。去下订单吧。高峰时期，我们收到了每分钟2万订单的巨大流量；
第二个挑战是每个人都明白送餐是一件非常简单的事情。我点了饭，送上来，高高兴兴地吃完，就结束了。但是，当谈到外卖时，我们发现确实是相当复杂的，因为当我们发现用户想要下单并付款时，我们还需要派遣一个外卖员。我们找到最快、最合理的骑手，请他及时取餐并送达。同时我们也给骑手最好的路线规划，告诉他走这条路线是最快的。所以整个流程是非常复杂的，有很多很多的服务；
此外，外卖仍处于快速发展阶段。我们面临的挑战是迭代太快。您可能必须频繁发布版本，这会带来稳定性、错误和不完整测试的风险。另外，项目周期短，业务发展迅速。排队的业务需求很多，架构优化的工作可能排队不起来。在做技术架构设计时甚至可能会做出一些妥协。这是一个巨大的隐患。我们称之为技术债务。
我们有一个清单来记录这些技术债务。我们会清楚地记录这个计划是在什么条件下制定的，在什么情况下可能会出现什么问题，什么时候需要做什么；另外一块监控压力也很大，因为业务变化很快。如果你今天这样设置监控规则，明天业务又会发生变化。
如何保持稳定
https://img2.baidu.com/it/u=218001383,2638330443&fm=253&fmt=JPEG&app=138&f=JPEG?w=897&h=500
让我们介绍一下我们对稳定性的定义。我们也用四个“9”来衡量稳定性，但我们用它们来衡量两个指标：系统可用性和订单可用性。
系统可用性四个“9”意味着全年停机时间不超过52分钟。我们按季度进行评估，相当于一个季度系统宕机时间不超过13分钟；
订单可用性的另一个维度也是四个“9”，也就是说如果我们一个季度有1亿个订单，那么这个季度的订单损失不能超过1万个订单，而在我们高峰期，每分钟接近2万个订单，所以只要这个系统出现问题，我们的KPI就无法完成。
我们还是要保证四个“9”的可靠性，怎么做：我们从四个阶段扎扎实实做这些事情：一是日常运行，二是预警，三是事故处理，第四个是事后总结，我将详细介绍这四个环节：
1、日常操作
首先，在日常操作中，我们要做好稳定的架构设计。这里有几个原则：
第一个是大型系统上的小工作
我们不想制作一个可以做所有事情的非常大的系统。我们想做一个非常专注、功能相对独立的小系统。我们首先拆解功能相对独立的系统。在早期的开发过程中，你可以看到我们有一个可以做所有事情的系统。它实际上是一个Web项目，同时还提供Web服务和App API服务。 ，它也消耗消息队列，同时也是Job的执行者。这就带来了一个问题：如果你消费消息的逻辑发生了变化，你就必须发布版本。其实其他功能没变，版本会受影响。到其他功能。当我们把几个系统拆开时，它就变成了四个独立的系统；
第二个原则是稳定性原则。您提供的服务必须稳定可靠。
这里的希望是将可变的与不变的分开。比如对于商户服务来说，对于C端用户和服务来说，使用最多的场景就是了解商户的信息，但是我们对于商户管理还有很多服务需求，比如商户满足什么条件才能上线，什么条件才能上线，什么是商户管理等。换菜品需要流程吗？这些管理功能是不断变化的，而读取的信息是不变的，所以我们把它拆开，变成了读取服务和托管服务。管理服务随时可以发布，没关系。阅读服务非常稳定，基本不发布版本；
最后一个原则就是设计这个稳定性的时候需要考虑用户体验。
你需要考虑当系统出现问题时用户该怎么办？相信很多同学都有这样的经历：可能突然出现故障提示、服务器异常、或者APP上有空APP。我不知道是什么情况。相信用户遇到这种情况会不断刷新。如果这个时候后台已经出现了问题，那其实是一件坏事。因此，设计时必须考虑用户体验以及异常情况下如何引导用户。
在日常操作中，另一项任务是进行例行的稳定性检查。
1、比如我们进行专项检查
对于DB，我们需要每个月测量DB容量。我们看哪些表大，读写QPS和容量，能否支撑未来某一天的业务发展；
2.我们会进行静态排序
我们按照场景来梳理，比如首页、列表页，这些场景用到了哪些服务，这些场景用到了哪些服务，以及它们的下游调用在这些流程中是否被放大。在某些情况下，并发量会虚高。
例如，有一项服务可以告诉商家今天有多少新订单。这个功能非常简单。就是在前端页面进行轮询。其实这个过程中80%-90%的查询都是无效的，因为一旦有新的订单，我们就会推送给商家，商家会及时处理。经检查，该请求实际上是无效的。这么多无效的检查订单服务的请求最终都会落到数据库上。这是假高并发。这里我们在它前面加了一层缓存，去到数据库的这一层来伪造高并发，将其干掉；
3、另一个日常工作是指标检查。
我们有很多监控指标，尤其是重点关注的秒杀，这些秒杀不会放过。
平时，最靠谱的让我们有信心提高稳定性的方法就是在线压测。我们与其他主要制造商类似。我们也在做在线压力测试。我们有一个在线压力测试平台。我们希望通过压力测试发现什么？首先找到系统中的性能瓶颈，哪个系统最弱，我们需要知道系统服务的上限和能力。
更重要的是，我们需要通过压力测试来验证我们的监控和报警机制是否有效。很多时候人们可能会说我们配置了一个非常完整的监控方案，但是可能并没有生效。一旦不生效，那就悲剧了。 。另外，我们需要用压力测试来指导我们如何设置报警线，CPU是设置到30%还是70%，什么时候报警，我们都会通过压力测试来建立。
此压力测试告诉我们在哪里设置警戒线，以便为您提供足够的时间。如果报警发生后立即挂断，报警其实就没用了。我们可以通过压力测试来设定预警行动线。这个时候我们就必须考虑和重视这个问题，为稳定性处理留出足够的时间。
我们该怎么做？我们通过日志收集线上流量，并将收集到的流量放入我们的压测平台，用于读取请求。对于写入请求，我们做了一些事务模拟，并且我们有一些模拟脚本来根据我们的场景伪造一些数据。
这些数据被再次染色，以将真实数据与测试数据分离。在通过我们的异步梯形图压缩模块之后，我们首先快速异步输入它。我们可以把音量调得很高；另外，我们使用“我们不会一次达到20,000”。我们可能会先达到 5,000，然后是 9,000，然后是 15,000，然后继续 10 分钟。
我们将监控到的流量压力过程与我们的监控指标联系起来。在我们做压测之前，我们首先检查一下有哪些指标与之关联。当指标达到一定阈值时，我们会自动停止压测。毕竟，我们是在网上做的。这些东西不能对网上的真实情况产生影响。对于其他依赖服务，比如支付，这些确实不能交给银行。我们为外部服务做了一些模拟。
2. 预警
对于预警阶段来说，如果出现意外的话，我们希望能够更早的曝光，触发警报，然后有足够的时间来处理这些事情。这里我们有一些预警阶段的监控经验：
首先是分层监控：有系统级的监控，比如性能指标监控、业务监控等。我们还进行日常健康分析，以了解我们的应用程序是否健康。
让我们分享一下我们对业务监控的想法。业务监控其实是最让你放心的事情。你有一个商业市场。如果这个市场有波动，你马上就会发现，说明现在可能有影响，你可能会收到警报。比如CPU报警的时候，你看市场，市场可能会说没有影响，所以你就不会这么慌。
此外，我们的系统输出与订单和重要节点相关的所有信息的日志。日志通过flume收集，然后传输到Kafka，然后传输到Storm。我们在 Storm 中聚合这些日志，并将聚合结果放入 HBase 中。我们在这些结果中有几个非常好的应用：
比如说，首先，只要你告诉我一个订单号或者手机号码，我就可以查到订单到达了哪个链接，哪个服务、哪个服务器死掉了。解决此类问题非常方便；
另外，我们还可以将这些指标制作成监测曲线。比如说你要下单，订单量那么大，但是到了接单的时候就下降了。可能与订单接收服务相关的 ABC 服务有以下三种： 可能有 我们的曲线可以很容易地看出哪个服务问题导致了商家、PC 和打印机市场的下滑。
三、事故处理
也可能会发生一些意想不到的事情。如果发生意外怎么办？第一个原则是及时止损。我们知道，发布是引起稳定性变化的第一个因素。如果立即判定事故是因释放造成的，最快、最有效的方法就是回滚。此外，可能会出现一些交通异常情况。针对流量异常，我们有限流模块。我们提供三种限流策略：
https://img1.baidu.com/it/u=3837918902,1269169359&fm=253&fmt=JPEG&app=138&f=JPEG?w=674&h=500
一是防闪，防止用户频繁刷新导致后台流量持续放大；
另一种策略是等待+限时服务。当用户实际使用我们的平台时，用户确实需要选择。他们在下订单之前可能必须一遍又一遍地选择。对于这些服务，我们希望您愿意等待一段时间，我们可以提供，比如您愿意等待10秒，我将为您提供20分钟的服务。在此期间，您应该能够完成订单；
另外一个策略是保护单机的QPS：在我们压测验证的过程中，服务在单机上能够稳定可靠。如果进一步出现问题，我可以启动这样的保护，以确保您能够为它提供最大的服务能力。服务无需挂断。另外，在单机QPS保护上，我们需要放开关键路径。你真的不希望用户在下订单和付款时杀死它们或清空它们。所以我们会让这些服务通过白名单。
四、事故概要
事故发生后，我们需要对事故进行非常深刻的总结。这里有几个非常强烈的要求。首先是找到根本原因。我们使用5whys分析法来分析根本原因。我们必须追根溯源，从现象入手。另外，我们需要计算清楚这次造成了多少伤害，因为我们需要计算我们的稳定性。另外一个方面就是你需要总结一下系统问题的流程、你的处理流程、中间流程，看看哪里可以优化。
我的建议是，我们需要详细记录事故处理过程。它可能需要精确到分钟。例如，谁在某一时刻与谁做了什么动作。这对我们总结很有帮助。因为事件处理流程本身可能存在问题。比如你扩容花了30分钟，那就有问题；例如，如果您在处理过程中做出了错误的决定，那么也存在问题，所以我们把该过程做了详细的记录。
我们对事件的总结以及我们希望看到什么？在这个总结中，我们希望看到问题出在哪里，是否能够更快地发现它，如果以后再次发现它，我们是否能够比现在更快地处理它。
讲完了这些处理原理，我们来介绍一下我们这样做的做法。我们对稳定性的要求非常高。我们对每一个订单的损失都非常敏感。我们有实际行动：确保关键路径不被破坏。如果我们想保留订单，就必须保留与订单相关的所有交易。路径不能挂起。
所以我们通常会梳理订单交易的关键路径，从用户下单开始，从用户选择店铺开始，然后开始选菜，然后下单，最后完成配送。这个流程中的每个环节都关联着哪些服务？这些服务应该都具有降级能力。
以排名服务为例。当用户第一次打开我们的App时，我们会给他提供最近的可以送货的商家。这些服务会根据用户之前的购买记录进行推荐，我们会给他一个更好的排名。 。
如果我们的Rank服务出现问题，我们可以快速降级Rank服务，改成默认按销量排序，这样用户也可以选择餐食。因此，我们可以对这个环节的每一步进行降级，保证下单关键路径上的服务是OK的，而其他服务可以接受它的失败。
此外，在制定计划时，你总是需要考虑将来可能会发生什么。如果出现这些情况我们该怎么办？所以在做这件事之前你必须要考虑清楚。我们认为性能是功能的一部分，稳定性也是功能的一部分。而不是大家这次设计技术方案，完成后再优化性能和稳定性。
我们在设计这个架构的时候需要考虑性能和稳定性。它们是产品功能的一部分。我们还需要考虑如果性能稳定性出现问题，用户体验会怎样。用户不想看到愚蠢的提示。
所以我们在设计功能的时候就考虑到了这样的情况可能需要降级。降级方案可能是一个交换机，而且降级交换机会有很多次。在某些情况下，这将是一个更复杂的场景：如果现在发生这种情况，我们可能会关闭这个开关和那个开关。这是我们的降级管理平台。我们真的把降级开关做成了一个开关，就是打开和关闭。同时我会告诉你开启它意味着什么。它有什么影响？
我再介绍一下，在这个平台我们有灰度管理、压测管理、健康分析。还有就是我们所说的“核按钮”，就是发生事情时你要坚守的底线。如果我们的系统出现问题，商户无法接受订单或无法送货，用户所下的订单将被取消。这次体验非常不好。
我下了订单，然后5分钟后你告诉我商家不能接受订单，订单被取消。我忍着又找到了另一家店，却发现又被取消了。这将是一种侮辱。如果商家无法接受订单，则不允许用户下单。如果出现这些情况，我们会快速激活验证按钮，并迅速将我们筛选出的无法接受订单的商家转为休息状态，这样可以保证用户向能够为其提供服务的商家下单。一。
在整个实践过程中，在斗智斗勇、稳定的过程中，我们总结了很多流程，我们称之为标准操作程序（SOP）。这些流程涵盖了从需求、开发、测试、在线、监控和故障排除的各个方面。每个环节都是标准的、非常严格的、经过深思熟虑的流程，供大家参考。您必须遵循该流程。为什么要这样做？
让我举个例子。遵循这一步是值得信赖的。每一步都有非常好的计划和系统的配合。例如，如果发生意外，每个人都会非常恐慌，因为有那么多人在抱怨，有那么多人等着说不能点餐。为什么，美团外卖怎么了？然后我们处理事故的同学就说：别慌。怎么可能呢？那么多用户投诉，老板还在问你怎么样，什么时候解决。怎能不惊慌？我不能那样做。
这个时候你一定很慌张。这时候你几乎不可能想清楚很多问题。有同学说我这里需要这样做，我需要写一条SQL，但是他们忘记了Where语句，所以你很担心。如果你很紧张，根本无法思考问题，你该怎么办？我们只能提前想一下，如果出现这种情况，我们会执行这个SQL，然后把它放在那里。经过无数人的实验，是可靠的，可以执行的。因此，我们在整个过程中收集了很多操作规程，每一步都有非常严格的要求。
我们对这些流程进行了梳理，并希望将这些流程自动化。否则，我们可以要求大家严格实行手工操作，但毕竟也是低效的。我们需要自动化许多操作。
比如下图就是我们的发布流程。看起来相当复杂。总共有10个步骤。我们有很多要求。发布版本之前需要验证什么？版本发布后需要验证哪些功能？ ，最重要的是你要评估，你要评估影响，对下游有什么影响。
更重要的是，我们每次发布都要有回滚措施，这是一个应急预案。您想回滚到哪个版本？如果是一个大项目，大家共同发布，回滚流程是怎样的？ ，谁先操作，谁就后操作。对于每次发布，没有计划就不允许发布。
你可能会说，我要改数据库，我要改表，表结构已经改了，还需要写数据。这个时候我就无法回滚或者后退了。那是行不通的，那是不可能的。你必须有办法将其回滚。另外，我们每次都有降级计划和灰度策略。如果是本次发布造成的故障，我们会在发布后对整个流程进行非常详细的审核，找出问题所在。
我想跟大家分享一下这个过程中的一些总结：
第一句话：如果你想要稳定性非常可靠，灰度，灰度，灰度，没有别的办法；您不应该使用所有数量来验证此事。对于灰度，我们可以按城市、按某个函数、按URL的某个参数、或者按一定的流量比例进行灰度化，比如先灰度1%，然后灰度到50%，再灰度到100%。
此外，我们对发布有很强的要求。我们有一个时间窗口发布，从星期一至周四下午2点至下午4点。在其他时候不允许发布。如果要发布，则必须提前提交。申请和批准。
为什么要这样做？因为我们的外卖的特征是中午时分很高，晚上很低。在此之前，我们发现兄弟俩实际上很努力地工作，非常努力地编写代码，直到晚上八点。最后，他们完成了写作并开始发布，然后对其进行了测试。到十点钟，有十几个服务器要释放，并且必须恢复这些功能。 ，我终于在11点钟完成了头发，我精疲力尽，以至于我终于可以回家，然后回去休息。第二天早上我十点钟接到电话。出了点问题。我应该怎么办？我应该去公司吗？不要去，在家看。
由于第二天中午有一个很高的高峰，因此我们不想在中午使用如此大的验证。我们想在晚上验证它。尽管晚上的峰值远低于中午的峰值，但仍然是一个很大的峰。我们使用它来根据流量来验证，我们将发布时间调整为下午，而不是在夜间发布。这会让您非常疲倦，您可能无法清楚地思考。与您有关的其他同事不在这里，许多事情无法处理。
因此，我们将在下午发布该版本。这将非常安全。每个人都在这里。我们将在晚上通过高峰进行验证。如果没有问题，第二天将是安全的。如果有问题，我们将在晚上进行压力测试。
第二句：缓慢的查询通常会造成灾难。缓慢的查询是一件非常烦人的事情，它的发生可能非常有害。如果一个缓慢的查询悬挂库，我们的负载平衡将转到其他图书馆并继续悬挂，然后一切都会悬挂。解决数据库的问题悬挂的问题非常耗时，因此对SQL的要求非常高。在我们的实践中，我们不允许写入和喜欢。每次在SQL中都会发生这种情况。这次在线过程将记录。这次是谁的SQL；
第三句话：防御性编程，不要信任任何人或服务。不要相信您的下属怎么说。我会把你转移三遍。别担心，不会有事的。不相信，必须有邪恶的东西。您必须保护自己，不要相信别人提供的服务。我向您保证了五个9s的可靠性。任何服务都不能100％可靠。可靠，这是不可避免的。即使是5 9s，也会有损失。别相信。确保依靠下游和断路器；
第四句：SOP确保安全。我们已经将所有过程变成了标准化的过程，这比崇拜不朽的过程更有效。有时我们开玩笑说我们失败了，因为我们没有在发布前崇拜。实际上，这不是真的，但是由于我们未根据标准过程运行，因此我们失败了。如果每个步骤都严格按照标准过程进行，那么它是值得信赖的，细致的，并且保证在各个方面都可以完成；
最后一句话：您担心的是肯定会发生，并且可能很快就会发生。最近，已经安装了一些功能，您说这个地方可能存在问题。您最好看看，也许很快会有问题。因此，我们建议进行例行检查并定期检查您的服务，服务指标和依赖项。有一天，您去检查并发现突然有额外的服务，您可能还不知道。此外，我们对中间件（例如DB和KV）进行例行检查，以及时发现其中可能的问题。
页:
[1]