「下一站，架构大师」第二期直播：系统崩过?架构师有招! 15年服务端研发大神带你玩转高可用防崩秘籍!原创

好，那咱们来看今天的第一个问题啊，这个小伙伴今天呃，因为自己工作的一些安排啊，时间冲突了，没办法来连线啊，特地委托我们，呃，希望说能跟毛老师请教一下。呃，第一个问题是，作为s re, 工程师，日常工作中最重要的一些职责是什么？跟运维的区别是什么呢？OK, 对，我先给大家打个招呼，王老师来跟大家打个招呼，对对对，行啊呃，我就反正今天就分享一些这个经验吧，然后大家呃一会有什么呃疑问或者问题都可以在留言，留言评论的时候可以跟我来进行一个互动，然后我在呃每个问题结束的时候跟大家就是简单讲一讲，那我们看第一个问题啊，就是呃，其实我之前也被人经常问到啊，就是。作为s re, 它到底和运维的工作区别是什么？那我先讲一下我自己理解的传统的运维的啊工作啊，例子像们用了某一家，比方用腾讯啊，那我们基于腾讯云，我们工作逻辑是什么？就是开发，可能找你申请一些资源啊，你给他开了一些呃，云资源，比方这个存储计算网络，还有一些pass产品，那么呃。

这个结束之后呢，他可能有自己的一些呃业务，一些应用，我们可能要把它交付到线上，然后呢，整个生命周期，包括量，包括各种东西需要去关注，那实际上有很多部署的动作等等啊，我们可能呃运维工程师可能会开发一些呃或者工具，然后他会去部署，然后同时自己会一些呃监控的面板，然后当出问题的时候呢，在呃做一些应急响应，然后呢去联系联系研发，然后问我，哎你大概什么问题，为什么出问题了，对吧？我觉得这是一个比较偏传统运维的一个。啊，工作逻辑吧，然后我也讲一下呃，我自己目前就是公司里面我怎么去看S的一个工作的一个区别的，其实呃基本上还是会沿用，就s re的这个概念，首先是呃谷歌s re提出来的，就是谷歌提出来的，那么Google s1它的一些实践呢，其实也行业里面也有一些书，嗯，包括像呃Google s的运维解密这本书，我觉得应该很早出来之后，给了大家的一些明确的一些方案啊我我我基本上可以分为几个阶段，呃第一个叫做叫做呃。

一个相对不太成熟的服务，然后呢，你把它改的越来越标准化之后呢，托管给应维这么一种模式，再到呢，我们叫呃以就s re1，它是以一种业务视角，或者说以呃更像是一个工程师的视角，我们叫BP的方式去参与到某一个业务，再到下一个阶段，就结合公司内各种呃基础设施，比方它有有KS对吧等等各种基础设施，包括我们现在提到的平台工程，呃举个例子，你可能提供了一套比较完善的呃CD的平台，然后监控平台等等，让他自动让让研发同学自己去呃去部署这些应用，监控，关注这些质量等等。

啊，他基本上有引用一个大的一个这样的一条一条脉络走来，S要做什么的工作呢？拆解为呃几大块，首先刚刚说了我们提到的BP的方式去支撑不同的业务线，对吧？比方说我是负责电商的啊，你是负责广告，他是负责这个推荐搜索等等，那么呃，首先你去BP一个业务，那么我是不是就要进场去看这些业务的工程的，它的架构设计，它的模块是做什么用的？有没有一些问题对吧，那么是要去跟研发的同学一起去，呃，面对质量或者性能问题，要去关注它的。

就是总体的一些全貌，我们叫over over overview的一些它的呃架构设计，那么在这个过程中呢，你就要去推动，比方说全公司的s re1，或者说全公司的s re1和这些呃横向团队之间有没有一套标准的，呃，这个我们叫叫工程的一致性啊，有很多，比方说可观测你的指标是不是统一的，所以第一块呢。你要去围绕可观测的能力，以so为核心啊，去度量它的可用性，度量它的度量它的这个饱和度，我们就要环境监控四指标啊，包括它的QPS啊等等，那么你有了这个可观测的一些基本的指标标准化之后呢，你去推推动报警和这个告告警的响应，和这个应急协同，以及说无效报警的治理，所以这里面其实就就会提到他的工作脉络，其实就会沿用一五时啊，我的一分钟响应，五分钟介入，十分钟恢复这这套逻辑去展开，那有了可观测之后呢，因为。

公司很多横向业务之间，它的呃框架我们叫研发框架，比如Java go, 它的C加加这些。这些能力啊，刚刚说的可观测试一个点，包括RPC是不统一对吧，包括你依赖的中间界啊，有有redis mysql这些标准的服务标准化，或者治理能力的建设啊，包括像整个微服务的一些体系，对吧？所以你要去推嗯，把一些通用能力集成到我们的开发框架里面，然后配合，因为有些开发框架可能是由呃基础架构的同事维护，也有可能是由呃业务团队维护，把他们形形成一套统一的标准去推进所有一套治理体系，这个我认为是很重要的工作，所以它其实有1点半研发半运维的，半S的这些呃。工作在里面，那第三个呢，你要去做en靠对吧？那么En靠呢，你就要去沟通，要去答疑，要去协作，要去对技术方案，比方他多活怎么去设计，所以呢，你还得去靠，就要去响应啊，做应急响应，做协同啊，以及优化，呃，事故就是在这个，比如说应急响应之后，他出了一个事故，他要去做复盘，对吧，那么你要去组织这些人去做，呃，围绕整个括生态的啊，从事故处理到响应到到复盘，对吧，然后。

在下一块的工作实际上是容量。因为核心链路上的这些。核心链路，核心场景，它对应有哪些服务，有哪些接口，那么你要对它的资源进行我们叫资源池的管理，包括核池，包括它的VPAHP怎么去做，它的弹性伸缩，还有它的扩塔管理，还有它的水位管理，如果它是个多活资源，还有涉及到它在双机房，呃，在多个机房是否资源对等，那么在一个机房故障的时候能能否切换，那这些都处于容量管理的范畴，也要去关注，另外就是还要去关注，今天我们知道it成本占比很高，所以有很多呃降本增效的一些动作，你要去，你要去配合推进，以及说还有很多这个性能有关的。

那最后一块我认为是变更管理，因为大家知道啊，就是有很多细，有很多生产事故其实来自于变更，那么你要去做一些防控平台，我举例子啊，呃，像我们的K平台，你去发布的时候，你就去分发布，对吧，可能是要灰，然后有个测，然后下一个阶分百分之三十五十流量去，呃去去放，那这个放流量你是靠人去，你系统背后通过so，定义了so之后，你去度量它，如果发现它发布过程有一些异常，你要自动去阻断，对吧，那本质上它就是一种变工防控啊，甚至说我研发有的这些平台工程有的这些工具，它自己去运维的时候如何欠减少，让他少放错，那你这里面其实就涉及到，呃，我要去避免他一把锁啊，有多个机房，我可能就是涉及到机房的分机发布，所以这些都是需要去往云原生平台，往框架去沉淀。把一些标准的so体系融。

同量管理，然后呃，等等吧，我们将服务治理的一些能力做到框架里面去推进，去观测，同时s re1还要定期的去做全链路的压测和混沌工程，我认为这些是日常s re要做的一些工作，和传统运维只关注交付啊，做做运维里面有对吧，我觉得还是有很大的区别的。那么从。那s re的职责来说，我认为他又分就是s re可以细分有很多领域啊，呃，我我我自己对s re的要求是说他日常因为要跟很多呃研发的同学，就尤其是业务研发的同学对接，同时又要和基础架构有很多做pass，做很多平台的同学去对接，所以沟通和协作是他们日常很重要的两个维度，所以s re的负责人要对他的沟通和协作要去做绩效考核，包括相应的培训。

呃，因为你你你要去协同，协同很多上下游嘛，所以如果你一旦出现一些认知偏差，就会出很多矛盾啊，所以有很多事情需要去多人协同，那具体来讲呢，我认为S的团队的技能方面，他要对公司内各个pass啊，比方我刚才说的red my这些这些pass，呃，包括KS等等，他需要去很熟，他不能说自己都不会用啊，要求研发去怎么标准化使用它，我觉得他自己要对这些产品很熟，当然有可能是云产品他要很熟。啊，呃，你因为你懂里面的技术细节，你懂这些平台怎么构建的，你才能正确去引导研发，更合理的去使用，所以某种意义上我认为无论是呃，大家的业务是基于云构建的，还是说基于自己私有云去搭建的，那么它都得像是一个。

我们叫云的一个授权架构师，或者说像一个云的sa去帮助。帮助我们的研发同学上云，或者说更标准化的去使用云啊，所以我我希望把呃，我们的S同事定位为就是就是叫sa啊，就是一个售前架构师，帮助他正确去用营和上云，从工种上分类的s re, 其实又分为啊，技术负责人，他会专注在这个内部的s re的平台，举例子像CMDB，我们的on call的平台，我们的。啊，我们的这些，呃，做做这个，因为我们要做多活吧，对吧，我们知道可用性是很重要的一块，那么多活的这些，呃，调度的一些平台，我觉得也是属于这个就是。S技术负责人要去注的内部的一些平台的建设，其平工就是S经理啊，我们S因为很综合能力啊，既动技术就是S责也要去直面业务啊，所以他要去管一大堆的S的BP，不同的业务线的人他要去管起来，所以他涉及到大沟通协作，要比较强的对内和对外的团队管，呃这个呃，管理能力。

那第三个职责我觉得偏PM，它变更更偏项目管理，嗯，负责的组织啊，的组织啊，项目的一些推进啊，所以整体来说是分为嗯这三种角色，那么我认为很多的系统的设计也好，或者说最佳的实践也好，其实是诞生于生产环境里面的很多运维和。呃，或者说历来的一些事故堆接起来的一些最佳实践，那么这些实践就是由s re整理在各个横向部门之间遇到的一些呃共性的问题，那么他要去组织攻防，去比方说做这个防呃变更管控的平台，他要去做这个框架标准化的工作，呃比方我们发现诶经常一些流打可能整呃A流，限流不或者不具者管这些项，我认为从从S。

嗯嗯嗯，好，谢谢马老师给我们快速呃科普一个re，工程师的一个诠释图，嗯，好，那我们来看下一个啊，这个同学还有另一个疑问。S re, 能否单独作为合同的保障啊？他说，啊，在他们项目中其实就规划了一个服务可用性，但是目前没有明确的s soi跟loo，那这种情况下，Sua能否单独作为一个合同保障，还是一定要有前两者？

的支持。呃，我说下吧，其实s SOA啊，更偏向于说客户和云厂商之间会用的更多，呃，我先想一，我先提一提我我我自己的啊，就是我认为SSO是一定要推进的，首先我们知道啊，就是。从一个请求驱动型的，它就是个一个一个一个微服务啊，它可能是暴露个HP或者GRPC或者某种协议的接口，那么前面提到就是s re1的那本书里面提到环境监控指标，其实包含几个，第一个就是说。你服务到底流量是多少，但QPS是要有的，第二个就是说你的延迟是多少，你的耗时是多少，第三个是你的错误率，你每一个接口到底返回的错误码是什么？第四个是饱和度，这个饱和度包含你内存、CPU的这种容量啊，或者说你的假设你的服务是有个硬扩塔，就只能提供1000QPS，那么这也是一种饱和度等等，就是稀缺资源，它都是有一种饱和度的，那么围绕这四个指标，其实你就要去建立一套通用的标准么？你的耗时不能超过多少毫秒。

那么它就是一种so，那么它当它这个so被break要被破坏了，那么它就应该通过告警卡片的形式去爆出来，或者说呃企就是大家可能如果用企业微信，他可能通过企业企业微信的这种卡片的方式通知出来一种应用啊，或者说他如果呃这个so break的时间持续了一段时间，那那么他可能会上升成这个一个事故，那么这个事故就会通过微信群去应急协同，拉更多人进来，你有了so你才能去做应急响应啊，但是我们现在做做so，像呃微服驱动型基本上都是基于错误预算啊，大家如果不了解这个概念，可以去搜一下叫error，呃，Error rate的这种呃错误。

啊LL泵就是它的错误预算消耗的速度，来去召回一个告警啊，通过长短窗口去呃做。故障的，呃，这个这个拉拉群这个这么一个动作，其实我觉得S的平台平台很重要，就是说管理这些微服务的siso，当然。SISO它需要运营，那我我自己觉得运营的经验会，呃定义成如果它是个L0很重要的服务，它应该是一套什么样的标准？L1，呃，相对核心的，它又是个什么产场景？那么L2它相对次要一些，对用户影响面较小，它应该是什么标准？我避免每一个服务都靠人去治理，那么个别个性化的一些服务呢，就根据他过往的报警的情况去修正，或者说去优化他的soi或者so。

这种是请求驱动型，那么还有一种呢，就是叫呃data drive, 就是它偏数据或者偏嗯，偏这种消息驱动型的，那么它就要数据，涉及到数据新鲜度啊，数据完整性啊，涉及到这个消呃消费延迟啊等等，同样的道理也要去覆盖，呃这个是从业务角度。那么对于。我们的中间键，那么中间键的定义呢，会复杂一些，它会偏偏向从集群视角去看这个集群，比方你是一个reddis集群，那么他get get put这些，呃，这些命令它肯定是有成功或者失败率啊，或者说他当前啊，整个不可用的持续时间是多少，他去召回，就他报警策略上会有一些区别，它整体的大的逻辑都是有先有SOSO，你才能去做应急响应，合作协同，那么当我s re1去应急协同之后，那么。

如果啊，出故障了，这个SOA跟内部的研发同学怎么去，怎么去基于so去工作呢？就我是这样考虑的，就是说你有so，你就能度量出月度的呃，T级别的月度的或者这个呃，季度性的或者年度的，它的一个质量是什么样的，那么我们可以说我的一个组件，我的一个微服务，对外要去承诺它是几个9，比方说它对外承诺是3个9，或者三个九一个5啊，那么更上游的业务，假设你是处于底层的一个业务，那么你更上层业务你要做4个9，那么其实你就要去考虑要去做一些容错，降级，或者说甚至是多火等等，你不能说，因为我知道大家比方你一个服务依赖三个组件，每个组件4个9，但是到你这，你大大家知道4个9的三次方对吧，它一定是低于这个4个9的，那么你你意味着上游业务就要做一些动作才能去做自己的4个9。

所以我我认为就是当这个被break掉的呢，其实呃，我觉得内部不会搞这么严格啊，去做so啊，更多是说上游对下游的要求啊，或者说下游对上游的一个承诺，当break掉了哎。通过绩效的方式，或者通过呃，类似的一些机制去定义这个奖惩，我们不能只罚啊，我觉得我们内部更像是说，嗯，有进步就要去奖励，但是对于严重事故，比方P0P一定的一些事故，那么他相应的要承担这个一定的管理责任，对，但是我们其实更关注事故的一个复盘和代办，能够做到更好，或者说避免重复犯错。对，就更像是云云和这个客户之间是SOA，呃，对于内部的话，首先一定要度量，度量之后呢，再去看你跟上下游承诺如果做不到应该怎么样，做得到应该怎么样对。好的，谢谢马老师的解答，好，那咱们就正式开始今进入今天的一个实战问题的分享，嗯。

第一个问题。其实来自于咱们社区交流圈的一个呃小伙伴，他是一个运维工程师艾恩啊，他想要去了解说我们要怎么去选这个靠谱架构保障啊，这个高可用是扛得住，扩展性也撑得起的，嗯，那么呃，请艾en来跟大家聊一聊啊，你是具体是在做什么业务，为什么会突然有这么一个困扰呢？方便跟大家讲一讲吗？没有开麦，没有开麦对。呃能呃大家好啊，呃感谢毛老师做的这个，呃分享的啊，我们这边个遇到的问题是这样子的啊，就是说我是在那个能源行业做一个运维工程师啊，主要业务是在内部的一个在线教育平台啊，内部用户量呢，大约有啊36万左右。

呃，主要关注的点呢，就是说一些不定时的在线学习，还有一个期中考试这两块的这个突出的内容啊，由于它是一个内部系统啊，在业务刚上线的时候呢，没有太多的规划，只部署了一个单机房，就是和单机房的一个多接点，嗯，到了后期呢，领导就重视那个文化建设啊，加强文化沟通和交流，项目呢，提升了那个level。啊，用户使用量呢也上去了，就随着来说，我们发现的应用系统的支撑能力不足，因为有些时候会可能导致他系统的卡顿呢，网站啊使用的拥挤，后期呢也做过一些整改，但是呢，效果不明显啊，所以说这个提出这个问题，就是说我们在这个当前同事这个架构做一个靠谱的架构保证这个。后期的支撑啊，能保证这个用户量的访问，还有这个啊，后续的社会运营工程啊，就后续我们扩展性啊，呃，要怎么去处理。嗯，就所这以这一点OK啊，呃，我我先说一下我的理解啊，其实很多业务早期因为还比较早嘛，你不太可能去做，呃，非常复杂的一些这个技术引擎或者规划，其实包括我带过的公司也是一样的，就是早期，呃就怎么简单怎么来都是都是从单机房涨起来的啊，甚至说都是从巨石架构的单机房涨起来的，再到慢慢的单机房的这个微服务，或者叫服务化，再到多机房，呃，基本上都会有一个演技的脉络，那我我说一下我的理解啊，其实很多人会有个误区，认为可用性它就和多机房或者和多活去关联，但实际上。

我们最好是能够根据过去他出现过的一些事故啊，比方说到底是变更引起的，还是说呃容量管理引起的等等。先去复盘它，到底它的故障，它分布是在什么类别比较重要，那么再去针对性的去优化，其实我认为大部分问题其实应都来自于你单个机房内的很多稳定性都做的不好，那如果这个时候你强行去做多火锅架构。

我认为绝大多数它只会更糟糕，为什么？因为如果你单机方的稳定性不好，意味着你整个服务的标准化，或者说治理就做的不好，比方说我们知道微服务可用性包含像熔断、限流，容错啊，包括像这个超时处理，然后还有一些，呃呃，应该有很多的一些这个微服可用性的领域的工作做的不够好。啊，包含像我们刚刚说的变更等等，那如果这些问题你没解决，你的标准化做的不足够好，然后强行去做多活，它其实会引入更多的复杂度，为什么呢？因为你单个机房的标准化不够，如果你要维护两个机房，无论是运维人员还是研发人员，他。

复杂度上升之后，它只会出更多问题，我随便举个例子啊，就是如果变更管控做的不好，呃，你发你在一个机房内的分级发布灰度啊，或者说呃，线上推流到全量，这个过程都管的也不严格，不控不控的很很这个呃很好的话，那么你到多个机房的时候，你的基础设施首先你就要关注到两机房的，我们知道专线你就涉及到你的你的数据中心的这个数据数，数据中心的专线护点，那么又涉及到你的机房的出口的啊，破不点的这个冗灾同时还要考虑。你的K8S在两个机房研发，要发既要发A机房，又要发B机房，对吧，你是不是要做多集群的管理，如果不不管理的话，你要么就忘记发某个机房，要么就是说每次一把锁，就是我认为他会带入很多很多复杂度，其实我会更你建议说你在单机房内做的足够好了，而考虑就我认为多活，它更多是考虑单个机房内出现，呃，大面积的这种集群不可用，或者说我们当个机房，因为pop点的一些故障，因为我们知道top pop点甚至也可以做多pop，做多pop，做top多pop的一些容灾嘛，就是先把这些问题解决的七七八八，再去考虑从多期房角度去啊，去演进，那么从运维角度呢。

我会关注就是啊，比方说它的平均故障，平均故障就是就是平均故障率和这个平均的故障时长，然后以及它故障的类型，先从这些指标去倒推它架构到底存在哪些什么风险，如果人员和这个呃研发能力比较强，再去梳理它的业务架构和标准化做的怎么样啊，所以我认为呃，So关注的是他服务的指标，那么你再去关注MTTRMTT，呃，MM那个MTP啊，就是有一个叫平均布制时长和平均修复时长，关注质量，包括它的故障类型，去分析它当前的一些。

症结是在哪里，然后呃，我们再去去优化。对，这我这是我的一个视角吧。好。安en，不知道有没有解决到你的一些疑问，那咱们啊直播间的小伙伴呢，大家如果有问题啊围知道这个问题，大家如果还有其他想要了解的，也可以在我们的评论区发出来，如果被咱们的嘉宾选中的话呢？呃，这次咱们下一站架构大师的项目组会给大家送出小礼品一份给大家评论，嗯，大家有没有其他想要补充了解的？嗯。Hello an可以听到吗？哦哦，可以可以，嗯，我这边暂时没有补充的。

呃，王老师分析的，呃这个点呢，对于我们现在的呃来讲啊，就是说我们就是目前的哈，还是是说是一个啊单机房，呃但是呢，就是说业务上呢，呃也做了一些，呃比如说毛建老师刚刚说的什么应急场面啊，协同啊，还有一些监控之类的，呃也都做了一些相应的这些处理去来呃做一些应对。嗯，我学到了很多，非常感谢啊马老师，嗯，好，就反正我就补充一下吧，就是尽量避免，就是因为想你因为计房机的故障其实很少你会你会发现日常的故障其实都不是，都不是机房机故障，就所以我会建议就是说先单机房标准化做的足够好，然后再从单机房内做出多集群，比方说我们账号服务你可以做多套集群，对吧，那么集群之间可以去做一些这个，呃，同时负载或者说呃，因为我们知道做多集群，比方你做一个账号服务，那么它应用服务是有多套资源部署冗余嘛，本身就是冗余，那我下面的catch也是多套集群，那我的DB，因为DB我们知道存储层比较难去做多集群啊，一般来说都是呃主从架构，或者说类似呃那种那种类似像kv rap的这种方式，那么可能还是一套集群，那就是说你会发现你的应用层，Catch层其实都是多套的，那么它其实天然就是具备一定的容错能力，然后再去做到这个程度之后呢，你去应对一些。

长期灾难的时候呢，再去考虑多火，当然有时候因为一些中间件，它某一个呃，刚刚说的多集群，你甚至某一个中间件reds一下在这个地方莫名其妙全挂掉了，那这种时候再去做一些呃s re1这个时候再去建设多机房的流量切换，更多是做南北流量切换，比方说你从呃上层的这个动态加速去做流量切换，或者说你去做域名的切换，都去通过一多活的架构，再去应对这种区域性的啊啊机房的问题，这这个是我的反正一些建议吧，嗯。

好。嗯嗯，好的，那谢谢艾玲跟马老师的分享，那咱们进入下一个问题，那这一轮呢，我们也为各位直播间小伙伴准备了丰厚的专属礼物，我们会为各位送出5本架构知道的实体书，还有4个腾讯的QQ斜挎包啊这一轮领福利的规则呢很简单，各位呢，转发我们直播间到朋友圈或者是呃技术群架构师兴趣交流群，扫描屏幕左侧的二维码进入我们的群，点击小程序就可以参与抽奖，我们20分钟后就正式开奖，嗯，然后我看到这个评论区也有些问题啊，然后呃，我我我来回答一些问题啊，然后我看到有同学高可用方通常到哪些方面，呃，我我先推荐一些书吧，就是呃S密。谷歌运维啊，还有一个叫Google s的运维手册吧，我名字忘记了，一共有3本，嗯的S的书其实是可以去阅读一下，它里面有些。

它是从数据中心内，呃，再到机房之间，再到整个网络啊，我们知道用户网络，用户接入网络等等全局去考虑的，呃，这个可用性应该怎么做，其实很容易被忽视一点啊，尤其是研发的同学，业务研发的同学，嗯，一定要重视这个s re的工作，包含像on扣，你的应急响应医务室，包括你的SSOP应急预案应该是怎么做啊，包含像这个我的我们的这个容量管理怎么做，对吧？还有说我们对基础设施的一些故障演练和压测，这些反而容易被忽视，因为它不是你的。主业务价值生产流程中的一些工作啊，像是呃，为了让这个业务连续运营的一些工作，对，所以这个我就解答一下啊，啊我看到有同学说现场因为硬件升级导致软件一堆错误，这种情况怎么避免，其实我们内部像涉及到内核的升级，或者像涉及到硬件的这个驱动的升级，其实也是要走分级发布的，呃，我我说一下我们怎么解啊，因为我们规模也有一定体量和规模，我们现在更像是说这一些裸金属。

这些裸金属它上面跑的到底是什么一些pass，或者是跑的是什么一些应用，我根据每一个pass平台，因为大家知道啊，所有的业务最终都会跑到呃，K8S上，绝大多数的K8S上，这个物理机其实也是一样的，就我能搞清楚我的一台宿主机。我我的一台裸金属，它上面变更之后产生的影响是什么，我就能去针对。KS的资源池也好，或者说这些中间件的这些机器也好，我就要去做，呃，内核升级也好，或者硬件升级也好，去做分级发布。举例子，我现在要升级内核，我就要圈圈选出一批机器，它分别命中不同啊，Pass平台啊，Red myl ks等等，我就缺一个范围去它的部分机器变更，看它带来的影响是什么，然后再去，呃，做这个批次去升级，当然也要一个很长的观测，观测周期啊，就这个，其实反而是基础设施层面容易忽视的，我们之前就因为升级这个GPU的，嗯，这个。

应该叫个从面去做，呃，这个裸金属的分级发布啊，包括我们讲像很多内核参数的不一致，我们要去修正内核参数，也会做分级发布，先判断它对上游的影响面是什么，然后再来，呃，再来去做分级。这个我就解答一下啊。

然后有个同学问怎么提高故障转移效率和降低故障率和恢复效率，我先说，呃，提高故障转移效率，其实本质上就是说我如何快速止损啊，快速快速这个，呃，因为很多同学啊，知道一五十里面的10叫十分钟恢复，所以呢，很多工作不是去排账，而是说先思考它怎么回复我们这个，呃，这个恢复大法嘛，还是重启重启扩容这个啊。一般出问题就是先肯定是先重启嘛，重启扩容，然后啊限流等等，有一些这样的预案，那比方对于一个复杂的多活的业务，我觉得第一域啊一一一定是它是自动去切流的，它一定是自动，比方核心场景你A机房不行，你应该要支持一个自动重试到另外一个机房，当然这里面要要做一些这个重试的呃策略，比方说我们知道这个5叉叉可能可以去重试，但是你对于对于这个像呃500可以去，可以像500业务报的错，内部的一些错误，你可能不重试，503你可能会重试啊，或者你的呃呃网络超时你可能会会去重试等等，就我理解，就是说对于特别核心场景，其实是来不及去做人工的这个预案的，那么可能是自动去处理，那么对于一些需要人工去界定和判断，那么你就要有白屏和黑屏的工具。

去快速去召回这个故障，并且推荐一个预案给你，你要去人工确认点一下啊，这个其实也就是阿里do OC, 或者说呃，做这种s ree on Co的工程师要具备的能力，就不纠结他为什么炸了，直接赶紧切流吧，对吧，切流的时候也有很多工作，就个日常基为你切流要涉及到日常的容量水位管理的一些工作，对吧，我我我我认为就是说你先考虑怎么恢复比较重要，当然有一些问题，说实话，我们生产事故大家都知道要去止损啊止损，但实际上有很多故障是你完全意想不到，你甚至扩容也解决不了，重启也解决不了，恢复不了，那么这个时候就要引入因involve更多的人上下游去帮你做一些工作，然后你这边你你自己的这个组件影响到上游一大片的这些业务，他们要去考虑止损，然后你你的话引入了更多的同事，对这个系统有了解的同事一起去想办法。

那对于降低故障率和这个问题呢，就是说你去统计过往出现的故障，比方说来自变更呢，你就做变更防控，呃，来自于这个呃，容量的问题，你就去做容量规划和管理，对我觉得其实就是嗯。把s re的这个一些运营数据给建设起来，然后再去针对性的去优化。当然更全面的话，故障演练是。我们叫实践，叫什么？就是真理去去去，真理就就就在于你日常的这个实践工作中，所以呃，故障演练一定是能够召回非常非常多你想象不到的问题，就像我刚刚说的多活，你要去切换，结果你发现出故障的时候，你根本用不了，要么界面打不开，要么没有黑屏工具啊，要么就是切失败了等等，这些只只能靠演练，只能靠演练演出来。

嗯嗯，好，时间关系，那马老师可能就先只能答疑到这一块，嗯，然后咱们接下来就进入第二个问题啊，各位也可以先扫码进入咱们的学习交流群，活动结束之后，马老师也会在群上持续为大家去做一个解答，好，我们看第二个问题是我们的，呃，交流圈中一个小伙伴喵喵想提出来的复杂请求找上门了，前端要快，后端要稳，怎么两头顾？喵喵侠在吗？嗯，方不方便讲一讲是遇到了一个什么样的问题。嗯，可以的，嗯，毛建老师你好，嗯，我是那个喵喵霞，然后我是腾讯云创作之星，然后也是一名前端开发，然后我们目前是在一个国企就职，然后主要是做政府相关的一些项目，然后这种项目的话，呃，就是有很多就是那种可视化大屏这种项目，然后也会有一些情况需要去应急保障，对一个呃数据的一个实时性和一个准确性都会有一个比较高的一个要求，然后呢，我们最近我们的那个技术经理提的一个问题，就是说比方说像这种大屏嘛，它会有很多数据需要在页面上展示，它可能都是来自于不同的接口，有的可能是来自我们呃自己的后台，然后有的是来自于第三方，然后呢，比方说一个页面有几十个接口，比方说有30个他是同时请求的，然后如果这种情况的话，是同时去发这种请求比较好，还是说我们分批了。

发，比方说6个6个这样发，然后呢，除了说要保证这个接口的及时响应，然后前有没有就是他，当然其实是前端有没有更好的处理方式，然后我们部门的同事就纷纷就展开了一些讨论，有人说就是前端可以去控制一下那个并发数量，呃，再就是排队的方式去解决，然后有人说可以去通过优化后台响应速度，缓存、定时任务索引，异步多线程等方式去解决，然后这些方案呢，呃，我觉得更有优劣吧，然后也会存在一些不可控的因素，比方说呃，就像刚刚提到的第三方的一些接口，它可能。

稳定性啊，或者是他的那个实时性可能也不是特别好，然后有些接口可能就是说他有一些前置的接口，我需要从第一个接口去拿到了数据，再去请求后面的接口，这样的话也会有一个比较长的一个延迟，然后有时候我们的那个网络环境也比较复杂，有些是内网，有些是政务网，然后呢，这个服务的稳定性也会比较差，所以我也想请问一下毛建老师，从这个高可用的角度上来看，怎么样去平衡前端请求速度和后端的稳定性。呃，就是看老师有没有什么好的经验分享一下，好，你刚刚指的是你是一个大屏的一个应用，对吧，就是像电视机上的电视上那种，呃就对，就是一个，呃就是一个很大的一个屏幕，可能就在一个演播厅里面，嗯，就是会有一些领导会经常去视察，会去现场去调度，去指挥这样子。

OK, 呃，其实我们也在公司内搭建过这种这种大屏的一些叫大盘嘛，我们叫大盘呃。我我自己会建议啊，就是这种大屏片展示类的这种这种业务呢，最好是呃，在。这里面比较复杂，因为这个整个数据链路又涉及到第三方，也涉及到你自己内部业务等等各种环境，其实我会偏建议呃。最好是做SSR先去在服务端渲染好，然后对于前，就是对于大屏来说，它其实打开这个H5页面或者说。我不知道是一个是个APP还是个什么，就是如果它是个前端页面的话，直接这个在服务端做渲染，那么在服务端去做创行或者并行的一些请求会比较好，同时呢，对于因为你也请求第三方嘛，那么对于呃第三方的一些不可用，那么你可以做一些第三方数据的一些catch，因为本质上就牺牲了一一定的数据一致性，然后至少让这个界面不会崩掉或者打不开啊，所以呃这种大频类的页面啊，我们其实会做很多数据链路的保障，以及说呃会把它数据，呃会做一些catch，就是基本上你看到的就是如果他正确数据能够正确正确刷，那么我们会把数据更新上，如果他有一些请求是。

这个失败的啊，就是有一些信息失败的，我们可能去这个数据就不刷了。他不会去刷啊，所以它有点偏异步请求，然后让这个数据刷掉，然后呃，我的打开的时候，其实就直接这个页面一下就出来了啊，我会我会建议说针对这种场景可以这样给可以这样去做啊。

我呃，我想补充一点，就是说呃，我们的这个大屏其实改动的需求还是挺频繁的，他比方说他会有一些呃，就比如点击交互啊，或者是有一些下钻的一些呃二级页面啊，再比方说它会有一些呃，就是支持一些呃复杂的查询啊，再比方说它会有一些地图相关的一些联动啊，呃就是呃他。就是会对前端这一块的要求会比较高，就是如果他会经常会有各种各样的改动，比方说这个地方哦，领导不满意那个地方要需要做一些什么调整，就是我们可能就是说还是呃，而且我们这个项目已经维持了很多年了，就是还是属于呃技术站相对比较老旧一点，如果说要从头到尾去重构的话，可能也要比较呃花费比较大的一些精力，就是说我目前的话就是可能还是呃，包括我同事可能还是想先基于现有的一个情况再去先去做一些优化迭代，然后后续的话，如果说有呃更多的精精力去把它，呃，比方说是重构也好，还是说通过像老师说的这种呃，呃通过这种服务端渲染的方式也好去做，呃，就是不知道老师，呃，对我们目前这个现状的话，有没有一些比较，就是立竿见影的一些解决方案呢？我觉得现状的话，你估计就是去摸一下老老代码的比较。

呃，一些坑，然后先修一修，这个可能是比较快的，那么对于这种数据下的这种需求，呃，基本上如果是偏大厅展示类，我建议都是做预计算，就数据一定是全部算好，根本不需要去跑C口或者跑一个复杂的查询，而是直接预计算好，你点你的下钻，因为你下钻的我理解这种下钻场景，尤其是大屏啊，它基本是可枚举的，基本上就预计算好点查缓存肯定是效果更好的。对。就我会建议就是说你还是先梳理一下当前的一些明显有问题的点去优化，然后再去做重构，嗯。

嗯嗯，谢谢老师。嗯，好，那咱们评论区我看也有很多小伙伴在。提问了哇，好多，我看了一下啊，天呐。啊，好多优化超时处理，连接池管理，呃，其实超时我过去做过很多次分享，其实超时啊，核心就是关注，呃，我的连接超时，读超时和写超时，那么它一定是在一个可控范围内，这是第一个，甚至你的很多框架默认的超时策略就应该是一个保守的，比方说默认就是50ms或者30mm，或者或者100ms，呃，第二个呢，就是说。如果你是一个RPC框架，最好是支持超时传递，从链路最上头的超时一直往下传递，去控制整个链路的超时，否则你很容易就是说到下月服务因为超时，呃因为请求堆积导致自己OM掉，这也是很常见的一个问题。第三个就是说基于呃这个超时的，我们叫late的so去对上对上游的业务去承，去承诺你的你的延迟应该是多少，那么它基于你的late so它才能去做超时的控制，就否则你你上游说呃我要500ms，结果你下游600ms，那你就永远都对吧，你每次都会超时，就一定是要有这种so，基于so去做呃接口交付承诺的。

啊，最后就是说超时里面。呃。就是我们有很多这种同步请求啊，尤其涉及网络和内部，内部流程处理的，一定也一定也是要注意内部的这个超时进程内的超时传递和控制的，要及时去退出，我们叫feel fast对吧，那么连接池呢？我自己觉得啊，所有带连接池的设计，本质上都是一种设计缺陷啊，你像其实新一代的这种呃，内部的这种RPC的一些网呃，一些做法，基本上都不是连接池，都基本都是单连接，通过多路复用啊，我们知道HHHP2.0也好，或者说新的一些RPC框架也好。

其实都应该设计成这个单连接请求复用的方式来去做是更好的，因为你你公司内网是不太会存在说，呃，我们叫叫那个叫tail tail request blocking的方，就是我们叫。就类似TCP最后一个包会被卡住的这种问题啊，所以首先就省视我们的中间界是不是应该做成一个pre request啊，一个这个一个一个一个连接池的这么一种设计，然后对于层量的一些老的系统，比方red啊等等，那么它的连接池管理其实都比较比较成熟了啊，我自己觉得比较成熟了，这个我就简单说一下吧。啊，问问问题好多啊，啊我我先扫一眼啊，等我等我等我扫一眼看一看。

嗯。有个同学问rag rag这个系统。怎么去做准确率，其实对于文档的准确率。这个要展开讲，要展很很长时间，因为这个也今天也不是不是高可用的话题，这个我单独回头再讲吧，嗯嗯，好呀好呀，那其实我对我这我我我自己觉得的这种系统还是要要要有应该有一个评测指标的，对一些top的这个回头再讲了，嗯嗯，好好，那时间关系咱们就继续往下进入今天的第三个问题。嗯啊，这个问题呢，是由呃社区中的一位小伙伴严同学提出的哈啊在进入这一轮之前，我们同样呢为各位准备了一个小的互动福利哈，那这一轮大家可以在咱们直播间去评论啊聊一聊，如果啊是你遇到林同学遇到了这个问题啊，就手中的资源有限，那老板又要求说咱们要保障这个业务系统高可用，那你会怎么做？你可以聊聊你的一些看法见解，或者是你有没有遭遇过类似的一些问题，欢迎在评论区去分享啊分享之后呢，同样是扫描屏幕左侧二维码进群在小程序中进行这个抽奖，这轮我们为各位同样准备了5本架构知道的实体书以及5个超级玛丽定制马克杯，20分钟后开奖。

好，那啊，有请咱们的严同学来聊一聊。嗯，喂，可以听到吧，哎，可以，嗯，好，首先感谢王新老师能回答这个问题，嗯，就是是这样的，因为就是我们现在就是商业化，主要有两种嘛，一种是TOC，这样to b, 嗯，比如说TOC，就是说比如说我现在一个博客系统就专门有自己维护啊，大家都可以从我的系统上去写博客，发博客，看博客等一些。业务，然后只要TOC，就是做customer，针对用户来使用，然后突然有一天某个大厂觉得我这博客写的很优雅，想捕捉到他们自己的公司里边去。

然后很多公司要都想这样做，这个就是叫to b, 就是to business, 就是这种情况下就跟我自己部署不一样，因为我自己部署TOC的话。那就像刚刚您说的，就是说重启大法一旦出问题了，重启扩容嗯就很容易解决，但是to b的话，可能每个环境它都是不一样的，这个环境它可能嗯。资源多，人也多，就是用的用户也多，然后有的环境可能是资源少。然后这个场景下，就是我该去如何，就是保证我系统能就是尽可能的去高可用，少数故障啊，因为我需要部署各种各种什么环境啊，包括的业务节点啊，核心模块，包括一些存储和监控等等基础设施啊，都需要有的，嗯。呃，其实我理解就是本质上你是一个SARS类的一个应用，对吧，需要你这个交付给呃，B端的这个。应该偏公司的这种to b端的客户对吧，嗯嗯呃，我我我是这样想的，就是说呃to b展开讲的，我们现在有很多to b是实际上我们叫SARS吧，它它是构建在云之上的，它是构建在云之上的，所以SARS我认为两两种模式，一种呢，它是呃共通，通过这个标准的云资源去搭建的，这是一类，第二种呢，它是通过私有云，就是说由。

由用户由由这个客客户他提供他的内部私有云的基础设施，你去部署啊，还其实还有一种啊，就是我也见过。就软硬一体的方式去交付的，那我认为你这个问题如果是to b场景下，呃，现在主流的SARS模型其实非常流行是构建云之上，是SARS内去做多租户隔离，比方说啊去举例腾讯来说，腾讯ta pd这个产品，它就是个标准的云SARS，那么在云之上呢，他通过他通过呃开放不同的这个账号，通过租户级的隔离，你比方我们要买一个HR系统，EHR这种电子HR系统或者招聘系统。

你现在去用，基本上它都是呃构建在云之上，然后呢，这个呃这个去对不同的B端客户去提供支持，它的好处是什么？首先你依赖的云资源，它是高度标准化的，那么你就不需要去考虑它的它的这个呃资源节点的问题，我我认为这个是更好的一个解法，当然有些公司会有一些要求啊，就是啊，它必须是这个数据不能呃呃呃这个外泄，那其实就这个就考考验你这个SARS在云上的这个数据的隐私保护的一些能力等等，那这个其实包包括你数据的一些加密存储啊，包括说你的之前的一些安全防控呃防控啊等等的能力证明给他看，对吧。

我觉得这个是新新时代的saars的一些构建方式，但是对于特别偏这种，比方说呃呃偏这种呃正企之类的，它可能要求就是必须部署在它自己的数据中心之内的这种形态，我建议你把你的运行环境，通过容器啊，云原生的一些一些标准形态，比方说它是个标准的美SQ reddi啊，或者是它是个标准的这个业务应用，一代KS，你它交给交付给你的物理机，你去让他搭建好KS，或者你自己搭建好KPS，让你的整个业务形态都部署在他的这些呃这个KS环境之内，我认为也可以解，呃，像我有一个朋友是在。某那个某某这个云文档的一个一个公司，它其实就是只要求客户你能够提供K8S集群，那么我的mysq red, 还有我的业务应用全部是部署在标准的MY，呃，标准的这个呃容器环境之内啊就可以了，这样的话你就不对它的易购的这些，呃，它的这些资源就不不需要感知啊，这个这个是我建议的两种模式都能够比较好的运转，然后第三种呢，就是。

软硬一体，这个我其实不是很建议啊，就相当于买兜售硬件，同时提供这个SARS能力，对，嗯。然后呃，这种标准的交付方式呢，那么你就比方说我现在有4，呃呃4扣。4个核心4g，那么你部署了20个实例，那我就可以非常精准的估算出。他大概能够提供多少，呃，这个请求的一个承载多少用户，或者叫提供多少的这个查询或者存储的请求数量，你就可以告诉他大概是多少，那么你现在假设公司企业内用户大概是五百一千，那你就可以去对他资源提出反向要求啊。

这个我认为SARS呢，应该会用这种方式会更好，嗯。嗯，好，谢谢毛老师。我看这个社区还有好多题目没回答。我的我们有最一个一题，要么我一社区一问题。啊对，然后我们如果还有新的问题也可以提啊。呃。我看这个问题啊，说说做刚刚老师说做一些应急的演练，目前我们做了灾应急演练，并网应急演练，数据恢复应急演练，应急演练在架构中的地位如何？呃，在条件适当的时候，是否多级演练能更好的适应到架构，使架构更稳定，让运维人员更好的运维？我说一下啊，我们自己的演练呢，也是分析的，呃，比方说啊，我们认为呃，真正去考验你的你的多活，它的有效性，其实就是最直接就是做做断网的演练。

啊，就是这个呢，可能因为断网的成本。是比较高的，比方说你可以每季度或者说每双月做一次。那么对于不同的。再下往下拆啊，你就一定会遇到你的这个，呃，网络出口的一些演练啊，或者单个数据中心内的这个，呃，我们叫。应该是叫核心吧，叫root吧，我们叫呃对就是就是你核心交换的一些演练，那这个其实你要拆到系统部它去做啊核心核心交换的一些这个演练，那么你拆到你的业务团队呢，他就是制造他单个业务场景的这个一些演练，然后再到中间的话，你可能就拆，拆到他某一个某一个实例挂掉，或者说他某一个副本挂掉他，他能不能自愈，这个其实既要做，其实有一些pass的演练，可以在生产，在生产环境之下，在测试环境，其实可以去做展开演练，我认为这个是呃比较有价值的，所以呃我我会拆成就是说偏全局性的，就是做断网演练，那么偏区区域性的呢，就是做一些呃控制面啊，业务啊，呃中间界的演练，那这些就要看你的当前的架构的成熟度，或者说组件的成熟度，确定它到底是在叫protection去演练，还是说在呃测试环境去演练。

对，那么你使得你每一次演员召回的这些问题呢，就有个PM，有一个呃这个S，或者说有一个项广去跟进这些问题的代办，解决完代办之后再去看从上层你的平台如何去规避掉重复放这些问题，这个其实是比较难的啊，比方说我们曾经就发现做呃这个断网云的时候，发现业务多活，一开始生效后面不生效，那么你做完整改，过段时间它又不生效，那是不是能够做到他在合并代码的时候去有有流水线去触发，其实我们知道一个业务应用啊，它无非就是启动依赖还是运行依赖，是强依赖还是弱依赖，那这些当你。

当你去呃经常召回类似的问题之后，你就要去思考怎么在框架层面，在流水线，就是我们这CI的阶段，一旦合到主干，怎么去触发这些流程，让他能够很快速的就知道呃不会存在这个问题，比方他跨完请求啊，我怎么去提前就能感知拦截掉等等，这个是我呃我觉得就是在演练过程中，虽然修正了当下的问题，但是如何去更长远的防控，这个需要做很多很多工作啊。哎，啊，还有好多。那么剩下的咱们可以等待会儿直播结束后，然后马老师可以继续给大家做一个解答，好嗯，好，那大家如果有疑问也可以继续在咱们的直播评论区去发问，好，那现在来到今天咱们的最后一个压轴的问题哈，嗯，啊这个问题呢啊，进入这这一轮之前啊，同样也是有一些小礼物送给大家，我们这一轮给大家准备了非常多的一些啊，腾讯的系列的周边公仔，然后大家也可以在我们的直播间去评论。

分享聊一聊你对这个议题的看法，聊一聊就是如果是你面对了这样的一个呃，平衡的这样这样一个选择的困境，你会怎么去做，分享一下你的看法之后同样是进群点击我们的小程序来进行抽奖，嗯，然后之前的我们很多人抽奖已经开奖了，大家可以在群内呃去查看最新的一个公告名单，好，那咱们来看这个问题啊，这个是。咱们社区的小伙伴尹峰提出来的啊，多活架构怎么去落地啊，面对跨区域节点的数据一致性的这么个挑战，我们要怎么去平衡同步的效率和业务的连续性，来欢迎尹峰来给大家介绍一下你业务的一个具体的情况。

嗯，大家好啊，很很高兴来到这里，就是我们这个系统的问题，就是就是我们最开始拥有一个档案系统，就我我就比如陕西就每个地市的档案系统，就它虽然一样，但是每个系统它都有不同的服务器，都在不同的地点上就面临。嗯，有点连备份的时候就嗯有点儿同步延迟的这些情况，就是我们有尝试过采用批量嗯部署，然后监控代理的方式，然后保证10多个地是99%的可用性。嗯，但是并发查询的时候，就是经常会出现数据过载的这个问题，对，所以就呃想问问，就你们公司在自动化运维的过程中，就对于服务器的一些动态动态扩容性啊，一个全链路监控的一个设计，就是呃，有哪些结合业务设计的一些策略。

对啊，呃，就是说现在现在系统是呃已经是多机房的对吧？嗯，对，这是端机房，对，然后他现在就是比较容易遇到的一些问题是什么，就比方说数据数据复制延迟吗。嗯，对，就是就是就是它不同，它虽际然都是一个系统就要，但在不同的服务器上，就连一些市级的数据，然后往省级的一些数据同步备份的过程，对省级的需要查看。对，然后就有时候就数据就没加载过来。对，嗯，我们说要将通落在。了解，呃，我我我我先其实说一下，就是多活这个业务呢，首先你要先去看你整个大的多活架构，它到底是。

它是一个什么样的形态，比方说它到底是作为同城的呃多活，或者叫同城的双活，呃，还是说它是做一个同城的读的多活，还是说去做个写的多活，其实这个要根据你具体的业务形态去定义啊，他到底是读多啊，还是写多，还是说他是同城的，还是说他是一个异地的，因为我们知道啊。你第一步其实就决定你的读写的流量是什么样的，来再来决定你，呃，你的业务形态到底是做一个这种，呃同城的还是异地的，我们知道做异地，异地多活，基本上异地多活你。要么就是放弃这个一致性。就是你要么就是做，要么就是说你用多，要么做单元化，就是说每一个每一个region，每个region的这些az存储的数据一定是用户分片的数据，它一定是A+B两个region才能共建出完整的数据，数据集就是它才是完整的数据，所以你决定它到底是单元化还是非单元化，那么如果它是一个全局，全局全全局性的数据啊，举个例子，你的写的模式是写的某一两个数据中心，它要广播到所有的全国的各种region整类，那么它大概率就是个独多活，那么这种场景下呢，其实你只要。

保障好你的数据的复制的链路的监控也好，还有说它本身的一些这个成功率啊，等等一些指标，它大概率是不会出现，呃，这个比较大面积的延迟，或者说很长时的延迟导致的数据一致性的问题，因为我们如果是写单点。我们如果架构是写单点独多活的架构，呃，只要做好这个数据复制的啊，无论是专线还是说公网的这个复制，我觉得大部分情况是不出问题的啊，我我认为其就算举个例子啊，我现在是个电商业务，我的商品的修正的修改价格或者修改标题，他们呢，那大概率它都是它都是写的，他都是做了一个，呃同城同城啊，同城的一个架构，那么因为它是个全局，它是从全局来看啊，它是个单点，呃，虽然你可能是做了数据中心，呃，就是一个region址内的切换，但是他如果要把这个数据复制到各个地方去，他们大概率它就是个独多。

他是个写单点独多火的一个一个业务形态啊，那么这种情况下，呃，就是它的一致性，肯定是说这种一致啊，但是对于我如果是个卖家。的视角，我的交易数据就是单元化的，非常适合在，呃一个一个region，那么他就是在比方他在华北啊，但是另外一个用户，华南用户他就在华南机房，华北用户就在华北机房，他他是两个人构成一个完整的呃，全国用户的一个数据级的，所以就我自己会觉得，就是说你要先去判断你是读多还是写多。

啊，这个定义好清楚之后，你再去看你的架构到底是适合同城多火，还是说做异地多火啊，呃，对，这个其实就啊很关键，然后再去看，如果你的问题是说它数据经常延迟，那么你优先就要去解决它数据复制的这个延迟的问题，到底是是说它存在性能瓶颈，还是说因为它设计上有缺陷导致数据丢失等等。对，所以我认为啊，就是像国内呃，中国的这个呃，机房之间，我们知道南北的比方说大几千公里对吧，那么它大概就是多是说百毫秒的一个延迟，那么我认为这种你看像级市级的这种数据。存存在个几秒延迟，我认为大部分情况是可接受的啊，因为我不知道你具体业务啊，文档系统的话，大概率是能接受的啊。那就可能更多还是你中间件的一些问题，要去去优化对。

嗯，对，非常感谢艾马老师，我们应该更多的是偏向于朵朵的，就很多人都需要查。对，那我理解就是说它的业务设计上可以做城，呃同城，同城就是我们叫globe zone, 就是它在呃一个region内，它的写是支持同城去做呃这个。我们叫就是主从切换的，就是它至少不会全挂，但是呢，它独毒火的话，那么如果它是有各种省份的数据同步的话，那就只要做好这个复制链路的话，他就能做好独毒火。它就能做好独朵火，那么写它是一个萝卜zone，它支持主从切换，那么它对于那个独多火基本上就是我们叫r zone, 叫regional zone, 呃，叫叫叫啊c zone说错了，CTCT纵，那么它大概率是做独家速用的，那么只要保证好这个啊，这个复制电路的稳定性，基本上大部分情况都。都还好。那真要出。

某一个省份它的流量不不可用，你只要在DNS，或者说在你的动态加速层，或者说你的域名流量调度层能够去做流量切换，基本上你的系统就非成靠了。对。嗯，好的好的，谢谢老师，非常有收获，嗯。嗯，我我看评论区还有一个小伙伴问了一个问题哈，他说数据复制有延迟，主库崩了没有恢复，那怎么去做到100%无损，做不到啊，我我觉得就是我接触到啊，除非你们实现了一个非常呃非常强的类似像呃这种。有，呃举个例子啊，就是呃，像ocean base这种支持CP级别的这种，呃，带这个raft或者PE的这种系统是做不到的啊，就是如果你有这样的一个基础设施。呃，云上可能有啊，我不知道啊，比方说这个TTC口是不是支持这种。

啊多A之间的这个，呃，比方呃三副本，然后两个数据中心可以成功啊这种我不知道啊，一般上可能有啊，我们自己像像我像我我我我所在公司，我们基本上就放弃这一点，因为你半同步复制也会丢一条数据，那你如果是做主主从复制，那就丢最后的，呃最后的这一些数据，那你就像你系统都已经。这挂成这个样子了，你大概率要么等主机房就是你要么就是先提供服务，把最后的一些交易啊之后再去补偿掉，你要么就是就是你就是。呃，怎么说呢，就是等因因为你完全不能做任何丢失，那你就等等这个主机方恢复，等数据复制，等数据复制同步结束，你再去恢复业务，对就看你怎么取舍，但你如果你很有你有个很强大的这个。啊啊，这种基础设施类似欧贝斯这种架构，我觉得你才能做到所谓的所谓的这个，呃，主库崩溃就是因为它不存在主啊，它就是说它存在leader德的概念啊，对吧，你才能做到100%无损，否则我觉得我觉得绝大多数业务都做不到啊。

对，我觉得我觉得我觉得这个这个确实是是是比较难做的，嗯。其实很多情况都会牺牲一致性的啊，我自己会觉得，嗯。我们看评论区还有很多的问题啊，老师可以看一下好。还有一个小伙伴在问说啊，马老师高可用的异地多活适合哪些类型，有什么特征的一些项目呢？嗯，我我我觉得我首先我绝不绝不推荐大家去做异地多活，因为它的成本非常之高，非常之高，而且复杂度非常之大，呃，就是当你对你的。当个机房的血已经解决不了的时候，需要去考虑用户风险，才能去承担这些流量，你再去做。

要大到什么程度呢？就是你一个机房，一个数据中心，假设。你大概是这个，呃，30或者50兆瓦大概。五六万台机器都承载不了你的写业务的时候，你再考虑去做你的写的封片。就我觉得绝大多我觉得觉得top不10亿内的头部互联网公司，基本上大部分情况都遇不到，当然如果你是一些金融业务，天然有这种强的诉求，那么可能会去考虑要是不是要做这个用户风险啊，因为我我自己没做过金融啊，就是就只有这种情况，呃，你再要去考虑这个异地多活，因为单元化有非常多的工作要去做，比方说像我们如何去划分业务单元数据，对吧，你到底是按物地理位置，按业务业务划分，还是说按某个ID，用户ID或者商家ID对吧？你的这个分区维度就决定你这个架构就非常复杂，然后同时你再去考你的流量怎么去做调度。

流量怎么调度，然后流量调调调度的之外呢，你还会遇到，就是因为你知道整条多单元化的，这这这这个这这一条链路啊，它涉及的东西。嗯，非常的多，非常的多，包括流量的调度，包括流量纠偏纠正，存储层的写保等等，就是我其实是真的不建议大家一开始就去考虑多活的，对它会涉及到基础设施方面面包像你的接入层，你的接入，你的流量的接入层，然后你的啊，你的你要应对机房延迟，你的数据同步怎么做，你的流量路由等等吧，就是我觉得还是非常复杂的，嗯，包括部署成本，改造成本，还有你的存储的成本。对。呃。这个肯定是你要去面对的啊，就是啊，就是我认为大部分业务，其实单个机房的写业一定是满足的，所以我会更建议大家优先做数，就是做同城双活去做写的，呃，读写读，就是主从的切换，然后再去做，再去做跨入一整的独多活，最后再去做，因为你企业已经扛不住了，当个数据中心内，那么你必须涉及到用户分片，你再去做。

单元化啊，这个是我的一个建议吧，嗯。好，我我我再看一下评论区的一些问题啊，还蛮多。啊，这么多。资源有限，Java经常内存很高，公司PHP内存很低，领导希望换成PHP。我不是PHP黑啊，我在想，现在还有人用PHP写业务代码吗？这PHP。

哎，算了，不黑了，就是我觉得他无法。无法就是。就我没见过复杂，就是大型业务用用大规模用PHP的，我只能这么说。嗯，我我不是PHPK啊，我觉得一些场景确实有，但是这AP架构啊，还有PHP的我觉得很少见了，就你自己去看头部互联网公司有有还有用PHP做业务的吗？应该很少很少，要么是go，要么加入，要么C加加，对我我认为只有一个工程化的语言才能去承载非常大的业务体量。而且你用Java，用PB省的这点内存，其实真的收益非常有限。啊，我问了很，我看到很多同学问一致性的问题啊，其实我自己会觉得微服架构。不存在一致性问题，为什么我我是这样理解的呢？就是说如果你在做业务划分的时候。

你在做业务划分一个，我们知道，呃，微服的划分，它其实是按照所谓的就是如果你做的高级的话，我们按DDD啊，按按领域去设计，那你做的差一点的话，你就按大的一个，嗯。我们知道按如果按DDD的领域，按所谓的上下文，现接上下文嘛，啊contest一个闭环的业务，一个闭环的业务是不存在，只有业务就是业务场景的一致性，数据一致性是复杂的，但是对于单个闭环业务内的一致性是不存在的，那么如果是单个业务内的数据一致性，基本上你通过买SQL的事物就能解决，对吧？但如果你是涉的涉及到一个复杂业务场景的数据一致性，你大概率就像转账，你如果做的差一点是。你自己先扣钱对吧。这是一个，这是一个交易单元，这是一个事物，再到对方转账，那么你这个时候其实要么通过呃命令驱动去解决，就是你发个消息给他，他自己一不去一不去做掉，对吧，就是我认为就是说很多很多场景的一致性。

啊，它更像是说通过消息系统的流扭转去可以解决的，对，而不是说你单个业务场景去，因为单个业务场景一定是通过这个我们叫联系事务处理去解决的，当你还多更多业务场景呢，都是通过消息驱动去解决的啊，比方说你可以通过呃，T, 我们叫transaction ting log对吧，你的b log的回放的方式解解决，或者说你如果用了一个支持这个二阶段提交的一个消息队列去和你自己的这个数据库做一个嗯，组件级的分布式事务，或者说类似叫C塔这种组件做做做一个这个分布式事务，然后再去解决异构场景的这个消息传递的问题，基本上都可以解啊，你可以把它这个问题简化。对，这是我这是我自己的理解啊。呃。我看到有个同学在问。不重构的情况下，降低数据库连接池溢出概率，其实数据库打包这个问题啊，我很常见，优化慢，CC口是最直接有效的一个方式，这是第一个，第二个就是说，但这个是涉及到数据库的一些细节啊，就是说嗯，老版本的一些数据库做法，基本上是连接和请求是绑定的，如果我忘记是马瑞亚哪一个版本，就是连接和请和你的query它线呃执行线程是分离的话，那么你其实可以开数据库就可以开超大连接。

你可以开1000个连接啊，你可以开成1100甚至一万个连接，那么它不会和它的执行线程绑定，那这个问题会缓解，第三个就是要去做呃，DB的。代理，当然你如果你在云上，你用TDC口，其实不存在这个问题啊，就基本上我们类似RDS或者DRDDRDS这种场景，前面前置的前前置的DB的proxy可以让这个连接池非常之大。

可以在这个连接是非常之大，就不会有连接的问题，但是你的慢查询，如果你数据库存在瓶颈，那么它慢查询还是会慢查询，就连接不会打包，但是如果你慢查询堆积多了，你要么就是说你的DB process拒绝请求，要么就是说这个你慢查询堆到MYSQL这一层，或者这个你的你的存储引擎层，但是你。你的你的client的连接最终还是会耗尽的，所以优化慢查询是最直接的效果，第二通过呃MYSQL的一些优化，对吧，刚刚说的连接和执行版解决吧，然后通过前置DB PRO去做限流流控都可以缓解你这个问题。对。嗯，好的，那时间关系，咱们今天的这个直播差不多就要到尾声了，那也看看咱们今天直播间的四位小伙伴还有没有想要交流的问题，还有呃，咱们评论区我刚刚好像还一直在新增一些一些问题哈，大家可以扫码进我们的啊，屏幕左侧的这个二维码进群，进我们的学习交流群啊毛老师稍后呢也会在群上为大家继续去答疑半小时。

好，那非常感谢今天毛老师空降到咱们的交流圈的这个直播，我感觉今天应该有给30多个小伙伴都针对性开了一个药方啊，希望对大家都能够有帮助，好，那也非常感谢我们今天的四位嘉宾，还有我们直播间一直在陪伴的每一位小伙伴，嗯。好的好的。好的，那最后再次感谢大家的参与，我们今天的直播就到这儿了啊，大家可以进群，我们继续去做交流，嗯。好，谢谢马老师，谢谢大家。