畅聊「架构扩展性」：一场不念PPT的真干货流量架构公开课！原创

也开始说话喽，好的好，直播间各位小伙伴大家晚上好，我是开发者社区的运营负责人泽敏，很开心这一次又跟大家见面，一起来聊技术，欢迎大家来收看我们腾讯云架构师技术同盟的直播栏目，下一站架构大师，那今天我们将一起来走进一场有干货，有温度，有温啊有故事的这样一个技术交流，那这一期呢，我们邀请到了同盟的学习主席沈沈建老师来作证啊，我们这一次来聊一个主题架构扩展性，那在开始之前呢，我们先做一个嗯，重磅的好消息来给到各位啊沈迪老师呢，其实是咱们下一站架构大师的首发讲师，就第一期就是沈老师来讲的嘛，然后我记得当时我印象很深刻，有飘了一整瓶的求返场老师，老师什么时候再来，那些大家的呼声我们都记在心里，所以从这一期开始，沈静老师将正式成为咱们直播。

播间的常驻首席讲师，他将要更高频的来陪伴大家啊对，就不只是今晚以后咱们的架构大师的直播，关于啊你想要了解技术难题，职场规划还是说架构一些新法，沈老师都将来陪大家一一攻破，成为一个可以常常见面的一个技术好友，那这么值得庆祝的时刻啊，社区也准备了非常丰富的礼品来回馈大家，那今晚我们一共有5轮超然的抽奖，每15分钟我们就会为大家来送出腾讯的一些周边好礼，呃，包括大家非常喜欢的同盟的知识刊物，架构之道，然后也有一些腾讯的一些周边，一共有50份奖品等着大家，那只要你今天坚持看完全程，说不定下一个新人儿任你对，那这一次呢，我们的节目也做了全新的升级，呃，我看现在评论区有好几个眼熟的小伙伴，大家应该是前几期有来。

的，那这一次我们的整一个节目节奏有一个小小的调整哈，那其实也是希望说我们更好的去聚焦内容的深度，然后更高效的来回应大家关心的问题，所以我们整一个节奏会变成，首先呃，我们的沈建老师会先围绕我们这期的主题交入扩展性来做一个深度的干货输出，那大家也可以准备好笔记本，或者是打开你的电脑备忘录，待会儿敲一敲，然后啊，我们有一些小福利会相送，这里先做一个小预告，那呃，干货输出之后，沈老师会解答，我们提前在屏幕左侧啊，这有一个同盟学习群的入口，我们之前在这提前收集了大家对于教扩展性的一些经典的疑难杂症，那今天沈老师选了部分有代表性的问题来做解答，他其实也是能够覆盖到很多人的一些共同的一些痛点，那大家也可以期待一下，沈老师接下来会开出一个什么样的方子啊，当然如果你之前没来来得及进群去提问，或者说今天。

整个过程中啊，还有更多想要跟沈老师去交流了解的，也可以在整个直播过程中，在我们的评论区来实时留言，在今天的节目尾声，我们特地设置了一个呃有奖答疑环节，大家有没有什么难题，今天我们就当场盘清楚，还能够领到一些周边奖励。好，那我们进入今天干货分享之前，我们先来第一轮官宣的这个首轮福利好不好？那这一轮的福利规则领取的方式很简单啊，大家转发我们的直播间到你的朋友圈或者是技术类的社群之后呢，扫描屏幕左侧的二维码进入同盟学习交流群，就可以在到我们的群公告小程序中抽奖，这一轮我们为各位准备了架构师知道的实体书，还有鹅厂的程序员定制马克杯，我们会在稍后就开奖，那每位小伙伴进群除了能够参与抽奖之外呢，在群公告我们也有一个架构之道的电子刊啊，包括今天沈老师会有一个很硬核的干货分享了，这个材料我们也会在直播结束之后在群内送给到大家，对好，那接下来呢，咱们就把时间交给到今天的主角沈健老师。

哈喽，哈喽。哈喽，沈老师好，怎么样？听得到吗？大家评论区来一波互动。嗯。好。好，很高兴再一次来到，呃。这个同盟跟大家这个来社群跟大家做做直播啊。啊，如刚刚泽明所说呀，就是他们做的第一次直播，就是邀请了我，当时的那个形式跟现在还不一样，当时应该是邀请了一些同学，然后做做做做问答的互动啊，啊后面其实跟呃泽敏他们讨论了几次，就说我觉得啊，我觉得这种方式的话可能嗯。

不能够更系统性的去讲一个架构知识点啊，所以跟泽敏他们，呃，跟泽敏他们讨论说，诶，我们形式上是不是能够能够做一些更新。所以当时的话就是和和同盟这边和社群这边啊的负责人就系统性的聊了，说我们要讲什么啊，后面定了两个方向啊，一个方向是这个架构的方向，一个方向是职场发展的方向，然后每一个方向上的话就是规划了，大概有10多个话题吧。总共规划了有20多个话题。然后好像这边未来规划是每月两次的，然后会邀请一些一些行业的一些架构师，邀请一些行业的一些大咖来讲，对吧。

然后包括那个呃，这个系统性的结构啊，架构的知识点，也是当时我们学习组啊，学习组的这个架构师们一起讨论出来的，包括职场发展相关的一些点了，那这样的话就是能够更更系统性的啊，跟大家去介绍架构和职场发展，架构师市场发展的一些一些东西吧。然后嗯，就大家可以看到啊，就是我这边，呃，就是挂了一个叫做学习交流复习。的一个的一个开头啊，其实我现在也有很大的一部分时间在和这个同盟一起吧，去去运营这个学习组的一些一些东西吧。所以在这个过程中呢，就是很多同学问我，就总有同学问我说架构师技术同盟是一个什么样的啊，社区啊，包括我这个学习组的主席在里面承担一个什么样的职责啊，因为问的人太多了，所以在这个今天的内容讲这个架构扩展性的开头啊，我简单的跟大家说一下。

其实自己的话，现在是花了呃一些时间和精力啊，在这个社区，在这个学习组啊，不管是做内容的输出啊，问答呀，包括直播呀，在做一些这样的事情。啊，大家可以看到啊，就这是这应该是呃。全国首个吧架构是在线的一个交流社区。啊，它里面有有很多的干货，知识库，包括知识库的这个结构啊，其实当时我们也有很多架构师一起讨论了。有很多干货知识库，有很多一线的案例啊，包括有很多这个圈内的一些架构师吧。嗯。这边包括智慧，智慧老师也是我和他一起在，呃学习组啊，在学习组规划一些内容，规划一些事情。包括还有技术讨论啊，应该有很多同学在问问题对吧，我们其实每天每周也是在在社区里面回答大家的问题。

啊，包括有很多这个交流会，应该有不少同学参加过这个线上的或者线下的一些一些活动啊。反正我感觉整个技术同盟跟我之前做架构师之路的理念是非常非常像的，就是能够传播一些架构的知识，帮助一些架构师做职场的发展啊，所以当时就是答应了这边说，诶，我们一起一起来做啊，我觉得就是能够影响到比架构师之路更多的人吧。所以对这个组织我这边还是非常非常认同，并且也花了很多时间和精力吧，在里面做这个知识的贡献吧。文章的内容啊，问答呀，包括直播。啊，除此之外还有刚刚。是这个同盟最新发布的一个，呃，架构师的一个成长共学计划吧，啊，因为很多同学他可能他不是架构师，他想成为架构师啊，从新人呐到一个啊，资深的一个到资深呐，到资深的开发者啊，新进的开发者，资深的开发者到架构师，他有一个一个一个路径啊，所以这边也是规划了一个成长工学的计划吧。

啊，大家感兴趣的话可以啊，截个图这个扫个码进群。啊，进群。好行，这边就是两页材料，简单的介绍一下，就是这个，呃，架构师同盟嘛，技术同盟啊，技术同盟，以及我作为学习组的主席啊，可能在做的一些事情。那么今天啊，进入我们的这个，呃，正题啊，今天的话我会有3个方向，刚刚泽敏其实也介绍了，开始的话我可能会有。集中的介绍架构。这个扩展性。啊，就讲今天主要是讲这个知识点啊，第二个部分是提前收集了一些社群同学的提问，我这边会选取一些针对性的公共的做回答，然后第三部分的话是和大家一起聊天互动嘛。

第一部分是关于架构的扩展性。啊，大家就是看到这个话题的时候会想到什么。哎，我们可来一波互动啊。就是当你听到别人聊架构扩展性的时候，你觉得是在聊什么。A啊，实现了功能1，未来实现功能2比较方便啊，这个叫扩展性好。啊，还有一种说法是我们家机器就能够扩展性能。啊，叫做架构的扩展性好。啊，还有其他有有一些同学有其他的一些想法和看法。啊，那有些同学会说我面临我面对架构扩展性这个问题的话，我没有想到这个问题。大伙对于这个怎么看？

啊。就是大家都在聊架构的扩展性啊，我们在做设计的时候要有良好的扩展性啊，这个是针对新的需求的扩展还是针对性能的扩展，我们在聊架构扩展性的时候，更多的是在聊什么。啊。好，好几个同学聊聊。说A啊，不做虫子啊，A马斯克，A这个。呃，Syis啊A。就是我们说系统的扩展性好，是指实现了功能1，未来还能方便的实现功能2是吗？就是业务功能，业务架构的扩展性，可能聊的更多的是功能的扩展，但是业务功能的扩展性的话，它其实是个性化的，就是不同的业务系统它的扩展性，它保有良好的扩展性。他实践的方法可能不一样。比如说我们做啊，我早期做及时通信的扩展性，或者做啊像五八同城的话，是帖子平台的扩展性，包括后面做快国打车的车货匹配的扩展性，就是你在一个业务领域中实现了功能，未来能够方便的实现功能。二这个扩展性的话，它不同的业务可能不通用。

可能不通用。所以更多的时候，我们家公是在聊扩展性的时候，通常是指相对通用的我们一个系统，比如说站点或者APP的后端。啊，在面对用户数据请求的增量的时候。我们有什么方法可以来通过不管是增加资源啊，改进架构啊，来提升它的处理能力啊，同时保证稳定性和成本可控。啊，架构师们聊通用的扩展性的时候，更多的说的是这个。啊，一句话来说。啊，我们更多的聊的是在面对增长的时候，系统是否能够友好的去扩展支撑。

面对增长的时候，系统能够友好的扩展支撑。打个比方就是，如果你的系统是一个小餐馆，那么突然有一天来了3倍的客人，你要怎么办？啊，你要怎么办？啊，所以架构师们在聊通用的扩展性的时候，更多的是聊系统层面，性能层面的扩展支撑。啊，而不是业务层面的功能一，实现功能2，这个的话，它不同的业务，它的扩展性的实现方式，或者叫方法论它不一样。啊，所以我们聊扩展性的时候，更多的是聊这个系统层面，性能层面。好，那么问题来了，那面对增长系统，如何能够友好的扩展支撑呢？面对增长系统，如何能够友好的扩展支撑呢？那我可以想一想。啊，如果你是系统的负责人啊，突然有一天来了10倍的流量，你怎么办？你怎么扩展资产。

啊，扩展性。啊。从有两个核心的维度。两个核心的维度，一个叫做，这个叫纵向的扩展，叫scale up.或者也叫做垂直的扩展啊，另外一个方向是叫横向的扩展，是叫scale out.啊，你要水平的扩展。啊，水平的扩展。还是刚刚那个比喻，就是你的系统是一个小餐馆，突然有一天来了3位的客人怎么办？啊，怎么办？就是still up. 你可以理解为。你让厨师变强。你让厨师变强，让同一个厨师变得更厉害。啊，给他换更快的刀啊，给他安上三头用臂啊，这个是scale up, 而scale out, 它不是让一个厨师变强，而是直接雇佣更多的厨师来响应你的客人。

就是就是不知道表达清楚了没有，就是扩展性有两个核心的维度，一个是scale out, 一个是scale out scale up是一个变强，Scale out是更多。聊到扩展性方向上，就是这两个方向。好，那么对于一个第一个方向scale up是如何实现的呢？Scale up是如何实现的呢？大家有没有碰到过这种情况，特别是在创业初期的小系统的时候啊，到了一个节点，用户突然增多了，你马上系统要扩展性能。你是怎么实现的？啊，A通过加强硬件实现B，通过软件加强软件实现C啊，其他的方法B我没有想过这个问题。随时扩展scale up是怎么实现的？啊，大火是怎么实现的？

通过硬件还是通过软件？啊，可以评论区说出你的想法。好。啊，有同学说A，也有同学说B啊。都对啊。就是垂直扩展，实现的方式有两种，第一种就是通过增强硬件来实现的，比如说CPU核数增加。啊，网卡。升级、磁盘升级、硬盘扩充、内存扩充等等等等，它使得单机的能力性能加强了。啊，通过提升硬件层面，也可以通过提升软件的架构来实现，软件的优化来实现。比如说。我加入catch来减少IO的次数，是不是系统的性能就加强了？也可以使用异步来提升服务的吞吐量，是不是就能加强了？你可以做一些无锁的设计啊，来减少响应时间啊，是不是你的系统的这个处理能力能够扛住的用户就更多了。

然而在互联网业务发展非常迅猛的你系统的早期啊，当你的预算，如果你的预算不是问题，强烈的建议使用增强单机硬件的方式来提升系统的性能。因为公司发展在这个阶段啊，公司的战略往往是。所以快速的发展还要抢业务发展的时间，如果你花大量的时间去做系统的改造，去提升系统是不值得的。国增强单机硬件的性能往往是在业务发展早期啊，抗性能、抗用户、抗数据量最快的方法。啊，造型但是。不管是你提升单机的硬件力呢，还是提升单机的软件架构，都有一个致命的不足。啊，什么致命的不足呢？叫做scale up总有上限。

就是说你硬件软件，软件的优化，硬件的性能提升，它总是有极限的。啊，总是有极限的。但是你的用户量的增长、数据量的增长、吞吐量的增长、并发量的增长，很有可能是无限的。啊，比如说现在可能有一些系统。啊，谷歌的系统啊，Facebook的系统，可能就是几十亿的规模的系统。那你的CPU合数，你能够从32~64~128，能到无线吗？不可能，内存你提升内存能到无线吗？不可能。所以说。互联网的分布式架构设计。好的，具备扩展性的，具备高并发的终极解决方案，还是skill out还是水平的扩展？只有水平扩展才能够支持我们将信任无限的扩展。

所以怎么说呢？叫做你想要无限扩展，最终还是必须依赖于scale out.啊，对于一个好的架构，如果我们说它扩展性好。我们一般来说有一个评价标准。啊，扩展性好的架构的评判标准是我们线性的增加，机器就能够线性的扩展性能。啊，宏观上来说是这样的啊。叫做扩展性提升扩展性still up still out.啊，这个C p2它快啊，加硬件能够快速实现，但是它总有上限。啊，终极的评判标准，终极的解决方案是skill out, 宏观上来说是这样的。那么微观上来说。我们的分层架构是怎么样实现？啊，性能无限的呢，增加机器就能够扩展性能等等。啊，微观上来说。

我这边放了一个就是互联网公司非常非常常见的叫分层架构图。分层架构图大大，我可以看一下自己公司的一个这个系统的分层架构是不是类似这样的。是，是类似这样的。就最上层啊，是客户端层，典型的调用方式，浏览器啊，Browse者或者是手机应用APP对吧。然后往下是反向代理层。啊，是整个系统的入口发向代理。再往下是3点应用。啊，实现这个站点的业务逻辑啊，返回Jason或者是返回HTML。再往下是服务层啊，当然如果有一些公司他没有使用微服务的架构的话，那可能没有服务层。啊，那就是站点应用底下直接是缓存数据库，那如果你的业务比较复杂，或者量比较大啊，服务比较多，那你可能会出现服务层啊，实现了孵务化，就有这一层。

啊，服务层再往下，服务层是对上游提供友好的接口。啊，向上游屏蔽底层数据获取的复杂性。啊，所以服服务层下游还有缓存啊，有缓存有数据库啊，缓存是加速数据访问，数据库是固化数据存储。啊，数据库又有读库和写库。就是。典型的互联网的分层架构，是不是是这样的一个架构？好，那在这个架构中。他能不能实现。又是如何实现每一层加基基金的扩展性能的呢？比如说大家大家大家可以想一想啊。我说你们的反向代理能不能无限扩展呢？We也不一定用，We也知我能不能无限扩展，Service能不能无限扩展。你一台数据库能能存1000万，你两台数据库你能存2000万吗？

就。很多时候，如果你在架构上没有做特殊的设计。你其实是没有办法很好的实现。加急器就过去了。你可能要设计系统改造，架构改造，对吧，如果你的扩展性设计的好。是不用做架构改造的，或者是不要调配置。啊，他就能不给你更多的机器，你的反向代理层，外部应用层，服务层，缓存层，数据库层就能够扩展系统。我们一层一层的来看啊。啊，大家可能了解的比较多的是外部应用层服务层啊。啊，因为外部应用层是以集群的方式给我服务的嘛。啊，你一个反向带，你后面可能有3个toet 5个toet。那你变成8个toca是不是加机器性能优扩展。服务层也是啊，你有服务层的集群。啊，你用这个打火机瓶。

你有这个服务的集群，3个节点，5个节点，8个节点，增加机器就可以雇更多的节点。但是对于反向代理，整合数据层可能就没那么容易。因为整个反向代理N是整个系统的入口嘛。啊，比如说你访问啊，我这边这个图的例子是你访问道家点。Com.啊，它它通过DNS server返回了你一个NX的外网IP 1.2.3.4。那如果你的假设in，它每秒能抗1万。那么你现在用户每秒卡访问2万，你怎么增加？包括数据库也是。数据库的话，你一个数据库实例可能能存3000万。啊，这个读写都能够抗一定的性能。啊，因为数据库的缓存是有状态的，它它不能够像。比如说web service, 和service这种无状态的服务一样啊，加机器他就能够增加集群的数量。

啊，数据库它有状态，你加机器它可能是不数据迁移的。啊，包括n English是作为唯一的入口，他可能也没那没法那么快的通过加基地，就1万变2万，2万变5万。那么如果是这样的话，那整个系统的扩展性其实是有问题的。啊，那么它又是如何解决的呢？又是通过什么样的技术去解决呢？啊，可以一层一层的跟大家聊一聊，可能有一些比如说Ning啊，数据库啊，可能。在很多公司是运维侧关注的啊，作为可能开发工程师，测试工程师，前端工程师可能没有关注这些细节，但是如果你作为架构师的话，宏观上你必须了解。啊，包括这个每一层使用的技术方案，你是必须必须了解的，否则你的系统扩展性就是可能会。好，我们从第一层来啊。第一层是这个海洋代理层。

啊，一台反向代理能够扛1万，我能不能加机器变成2条。2个反向代理卡2万。啊，是可以的。啊，是可以的。反向代理层的水平扩展，它是通过DNS轮询去实现的。是通过DNS轮询去实现的。嗯。啊，前面前面你访问道家点。Com.啊，你的客户端不管是浏览器还是APP。访问，大家点com，我也会访问DNS server DNS server, 他这一次是可以配置多个IP的。是可以配置多个IP的。啊，一个IP是1.2.3.4，你可以配置1.2.3.5，然后这两个你就可以部署两个window的是一台扛1万，两台就可以扛2万。DNS人群是什么概念呢？就是。你来进行DNS解析，我DNS生活。

第一个请求返回1.2.3.4，第二个请求返回1.2.3.5。啊，轮询的去对同一个域名做IP解析的返回。而这2个外网IP对应的两台，它就可以实现加机器就扩容。啊，一台扛1万，两台扛2万，假设你有5万，那你再加5个那个啊，你这边设置5个外网ID。啊，是通过DNS轮询的方式啊，现在这里还没有讨论高可用啊，高可用好像是前面几章的这个架构跟大家聊的，今天重点聊扩展性啊，啊，当然在架构设计的时候，扩展性和高可用都得同时这个同时考虑啊，但是高可用使用的是不同的技术方案啊。使用的是。完全不同的技术方案，高考用用的是需IP加学master啊，应该前几讲其他的架构师跟大家聊过了啊，我今天讲这个扩展性啊，因为我重点聊扩展性，所以目前的这个反向代理的架构，它不是高科能源。

啊，如果你用DNS人群，其中一台就挂了，可能有流量会受影响，但是你结合上，你结合上高可用的技术，比如说每一台S，它又有学IP啊，拥有keepb来保证高可用，它就是既高可能又能够扩大。就通过这种方式，就是当N成为系统的平颈的时候，就能够实现增加机器的数量，增加N部署的数量，增加一个外网IP，就能够扩展反向代理层的性能，理论上可以做到。无限的地方。啊，这是方法向代理商。那第二层的话，可能大家就比较熟悉了啊，反应代理层的下面是web server层，大家可能部署了啊，Party light这个等等等等web server呀。就是站点层的话，Web serve层啊，我也他不开的决议，它其实是在的后端的对吧。在nnux的后端，Nnux反向代理通过N尼克X康复来配置多个后端。

你只要修改康复。啊，就是增加微部sor集群的数量，节点的数量，服务器的数量，就可以线性的扩展web so的。处理能力。啊，因为web层在设计的时候是无状态。啊，我的状态，所以是比较容易能够实现增加机器，增加节点数，就扩充性能。啊，这个我们在架构设计的时候需要注意的点是什么呢？是需要注意的点就是什么。还是无状态？尽量不要搞一些什么写写云字性，或者叫我说我内存缓存。啊，不要搞一些这样的一些，就是把一些数据存在web server, 就是一个请求，一个用户的请求，一个筛选的请求，必须落到同一台web server.不要做这样的事情，这样的话就相当于在we过程引入了状态。嗯，无状态的话，你只要将二进制和配置文件CTRLCCTRLV，它就能够实现。

啊，先生的过程。回复操作的时候应该是比较容易的。We travel层的下一层是服务层，服务层应该也是相对比较容易的，大家应该也比较追求了解，大家都会有服务集群，对吧。如果有服务集群啊，有的就是会有啊。大家一般会有一个RBC的框架对吧。底下是ABC sor, 然后上端通过ABC client调用。然后up client里面有一个可能性负的组件。啊，底下是service集群，同一个service还有多个节点啊，我这边图上画的是两个节点，2个节点扛不住了，你可以变成5个节点，5个节点扛不住了，你可以变成10个节点。啊，这个10个节点。那上游的r bc client.啊，它在初始化的时候，它里面的考那些库连接起组件，在启动的时候，它会对你的2个节点，5个节点，10个节点建立连接。

啊AB client中的连接词会与服务下游多个服务建立连接。啊，然后通过不管是人群的方式，还是ID取模的方式啊，来做负载均衡。会将这个rpc client的流量平均的分到下游的搜索上去。啊，10个节点扛不住，20个节点会平均的特别上去，所以只要实现。啊，只要增加服务器的数量，增加服务的这个节点数，增加服务的复数。OBS, 它就能够自动的做扩容。现在的话就是有一些服务治理的能力，都不需要重启加节点发信号，哎，它流量就自动过去了。啊，可能很多公司他的服务都是用容器化部署的，你加容器，然后发信号，流量就过去了。啊，当然这么做的前提也是服务要做到无状态。

啊，站点层和服务层我们都不要存数据，我们就不要存状态啊，二进制配置文件，CTRLCCTRLV就能够扩充性能，所以相对容易的也能够做到无限的并发，无限的扩大。嗯，包括很多公司，他为了实现自动扩容，自动扩展，他可能还实现了这个配置中心服务发现等等一些功能吧。现在容器化啊，容器化，很多公司做容器化，其实做起来也比较比较容易吧。相对比较难的其实是这个数据层啊，因为数据层它本身就是状态。不管你是缓存还是数据库啊，它本身存储的就是状态。反向代理层、web server层和service层。它的扩展性，更多聊的是这个并发的能力。而数据层的扩展性，它讲究两个东西，第一个是读写并发，第二个是数据的存储。

啊，读写并发是你原来能够读1000，现在读1万怎么扩展，你原来写1000，现在写1万怎么扩展，就是读写能力的扩展。数据层，它还多了一个叫存储能力的扩展。它本身是状态，他要存数据，你原来存了1000万，你现在要存1亿，怎么扩展。啊，所以数据层的扩展比反向代理层这个外部应用层和设备层又多了一层考虑。5处理能力、读写能力和存储能力。最常见的方式有2种。啊，一种是按照号段来进行拆分。其实也是水平拆分啊，一种是取模来进行拆分。啊，这边有2个图啊，2个图。左边一个图是按照号段进行拆分，也很容易理解啊，第一个节点从1~1000万，第二个节点存1000万到2000万。

你原来一个节点能存1000万，你两个节点能存2000万，它的存储能力它就扩展。你原来一个节点能够扛，这个写1000啊，读5000，你两个节点你就能扛。这个呃，前两天就1万了。啊，对不对，这是很常见的一种方式。这种方案的好处就是，首先它规则简单啊，Service层只要判断一下ID的范围，就能够知道路由到哪个节点。它的扩展性也比较简单，比如说你再要扩展一个新的节点，那你加一个2000万到3000万的实力就扩展了。然后改一下配置就行了。代码都不需要做大的签，大的变化。但是它的不足是啊，我们讲扩展性的时候，一般是结合负载均衡统一来讲的。但是这种方案的话，它可能导致负载不均衡。因为一般来说，比如说这里有1000万，这里有1000万，你新增到2000万到3000万的时候，数据还没有来的那么快，所以新增的节点，它的存储不足1000万。

对，他的压力会比这两个节点要小。而且一般来说，即使他的数据量是一样的，一般来说新注册的用户会比老用户更加活跃。啊，所以即使是1100到一千万，一千万到两千万。这个2000万的这个号段，他可能的压力也会很大。而取模的话，就不存在这样的问题。啊，如果按照ID取模来进行分片的话。那你只要你的ID啊。只要你的ID，它的分层是均衡的，那么每一个节点它的流量负载一定是均衡的，包括存储也是均衡的。所以这种方式取模的方式啊，不管是一定他西啊，还是取模，还是什么什么方式啊。取模的话啊，当然它的规则也非常的简单啊，来了一个ID取模啊，就能够路由到对应的存储服务啊，负载均衡也比较好，数据存储均均云，负载也均云。

但是他的不足是它的扩展可能会更复杂一点。啊，前面按照范围的话，你加加节点2000万到3000万，3000万到4000万就行了，改配置就行了。但是如果你哈希的话，如果你的架构设计的不合理，当哈希的你原来是2个节点，现在变成3个节点。那你原来模2和模3那数据路由的发生变化了。那这个时候就有可能要进行数据迁移。啊，所以这里面就涉及一些。这个快速迁移，或者叫平滑迁移，或者叫这个成倍扩容的一些方案。啊，就就是及一些细节，但是都是有相关的方法去做平滑扩容，两节点或3节点怎么平滑，两节点或4节点怎么两级实现。是有的。

啊，因为今天讲扩展性啊，可能而且时间的关系，我可能这个咱就不展开了。啊，反正存储层啊，缓存和数据库都是存储层。啊，它在存储能力和这个并发能力上的扩展，很常见的是这两种方式，一种是按照号段。范围。一种是阿西。啊，为什么是还行。好，这个缓存也是一样的，缓存也是数据存储啊，也基本上是按哈希或者是按照范围来做缓存的。好，最后做一个简单的总结，做一个简单的总结啊。就是聊通用的架构扩展性。一般我们就是指面对增长的时候，系统能否友好的扩展支撑。业务的扩展性。啊，一般是和业务系统紧密结合的，它的方法方案都不通用。

啊，像我刚刚说的五八同城的帖子业务啊，百度的搜索业务啊，包括快手打车的车货匹配业务，它的功能扩展性，需求扩展性，它都是不一样的。对架构师们聊，说你的架构的扩展性好。大伙儿也可以去BP的问一问啊，啊说这个互联网的系统的扩展性是指什么？啊，有什么常见的方案，有什么这个这个最佳实验，你也可以去问一问啊，跟架构师们聊架构的扩展性的时候，通常是指面对增长系统能够友好的扩展支撑。然后扩展的话，有两个方向，两个维度啊，一个scale out啊叫纵向扩展，一个叫scale out啊，叫横向扩展。纵向扩展，我们可以通过提升硬件的技能去实现。也可以通过优化软件的系统。

啊，这个并发呀，无所呀，这病呀。来来，提前。嗯。然后我们建议在你的业务发展的早期啊，性能初期遇到瓶颈的时候，如果预算不是问题，建议早期的时候使用提升硬件的方式。啊，用钱换时间啊，因为架构如果要改造的话，一般来说周期会比较长。然后但是scale up, 它的问题是性能总上线。性能总有上限。啊，不能够无限提升系统的性能。给硬件的性能不能无限提升，软件的优化也不能够无限的提升，所以最终还是要回归到out。我们一般评价一个好的架构。通常。它能够支持增加机器的扩展性能。增加机器扩展性能真的没有那么容易实现啊，因为大家如果印象中啊。

可以想到N年前。这个阿里的系统，京东的系统都出现过大范围的不可服务，都出现过什么系统挂掉啊，系统比如说双十一，比如说618啊，挂了很长的时间。那个时候就是他的。这个这个扩展性有问题啊。不是说给你10倍的经济，你就能够抗10倍的容量的，不是这样的，你在设计上要做特殊的考虑了。好，最终啊，是要skill out, 然后对应互联网最常见的分层架构。反向代理层、站点层、服务层、数据层，数据层包括了缓存啊，读数据库和写数据库。基本上每一层都有非常具体的、通用的方案来实现它的扩展性。当然这些方案啊，很多时候啊。很多时候是运维层去帮你干了这个事情了，但是架构师你得了解。

啊，反向代理层应该大家作为开发公司应该接触不到了。啊，因为别太负责了。包括数据库应该也是运维在负责。可能研发工程师更多的是在web service和service层面做开发的。反向代理层的线性扩展DNS人群，同一个运营，它可以解析到不同的。增加运营增加就可以增加增动手术了。站点层的扩展是通过站点集群化啊，通过反正代理的负载均衡去实现的。服务层的扩展是通过服务层集群，是通过连接池层面的负载均衡去使用。数据层的扩展有两种常见的方案，一种是数据按照范围扩展，一种是按照哈希扩展。啊，它包含两个维度，一个是数据量的扩展，一个是读写吞吐扩展。呃，这个我也看了一下时间，这个超了一倍的时间啊，之前给了我20分钟的时间，然后我还是想。

嗯，跟系统性的一致的，把一个一个知识点，一个架构知识点聊透吧，所以有一些有一些超时。嗯，这个是我今天这个分享的第一趴吧的第一趴。然后第2趴呢。第二趴呢，是这个回答社区社区的同学的提问。然后我看了一下，呃，社区收集上来的问题啊，反正有几百个问题，几百个同学提问。啊，当然有很多问题啊，上面的分享已经解答了。啊，也有很多同学问，哎，这个战略层怎么扩展呢？反正代理怎么扩展啊，数据库怎么扩展。啊，有些问题上面的已经解答。有一些问题呢，相对比较烦。比如说什么是扩展性？

什么是高可用？扩展的过程中要怎么考虑安全性？这些比较泛的问题呢。这种回答起来可能又是40分钟了。所以我选择了什么呢？我选择了场景，比较具体的问题。来跟大家聊一聊。啊，跟大家来讲一讲啊，选了有5个问题吧。好，我们一起来聊一聊，就是场景比较具体。好，第一个问题啊，这个啊，您在分享中多次强调。这个价格是远近而来，而不是设计来啊，这个应该是。应该是架构师之路的这个老粉啊啊，因为我在文章中说这句话说的非常多啊，叫做架构。不止是演进而来的，更是设计来的啊，不止是设计而来的，更是演进而来的啊。包括并于五八同城和快速打车为例，说明不同业务的架构设计逻辑的差异啊，这个同学问的是想请教。

业务从单一模式向混合模式演进的过程中啊，他取了快要打折率的。原有的架构的扩展性，这个原有的架构的扩展性啊，更多的就是指业务层面的。通用瓶颈啊，通用瓶颈是系统层面的，出现在哪里？是优先对于核心的服务进行水平扩展。模块功能化，还是重新划分业务域来进行催产的？这个问题很具体啊，啊，不知道描述清楚了没有？就你的业务由简单变复杂了，同时你的量由由小变大了啊，你系统架构要调整啊，一方面是刚刚说的这个水平扩展是不二的调整。一方面是功能模块的重新划分。啊，这个怎么搞，这个我说一下我们的经验啊。就是你这边提到的架构瓶颈。

啊，它一方面是性能，一方面是业务特性，就是性能和业务特性的冲突啊，你说的这个情况。他不不是简单的性能不足。不是简单的性能不足啊，业务从单一变混合，业务发生发生变化了。原有的相对确定的、相对长流程的稳态的架构。可能对于新的混合模式的业务啊，就很难适应新的业务模式的并发了。这个时候啊，你这边问瓶颈通常出现在哪里啊，根据我们的经验啊，瓶颈可能容易出现在这几个方面。这几个方面，第一个是数据模型与存储。啊，大家都知道数据库最容易存瓶颈啊，因为他要做磁盘IO，磁盘IO是最慢的。啊，数据模型，你如果原来符合的是原有的模式，那如果你新的模式数据模型不符合的话，你数据库肯定要重构的。

啊，这个架构改造的程度会比较大，包括存储也是最容易出现瓶颈，这是第一块啊。叫做数据模型存储，第2块呢？是服务的耦合与通讯啊，你这边也提到了哈，原来是简单的业务模式，现在是符合复杂的业务模式。啊，你上面原来有很多站点，有很多服务，你加了很多服务，加了很多站点，然后整个蜘蛛网式的这个交叉依赖，交叉通信，交叉连接。所以需要我们花时间去做业务的重新梳理啊，站点的重梳理，服务的重新梳理，要做垂直产生，要做垂直重构的。啊，所以这是第二块服务之间的耦合，站点之间的耦合和通信。啊，第三块的话，还有资源之间的调度和是因为不同的业务，他对资源的需求不一样。啊，有些业务是CPU密集型的。有些业务是网络运行，有些是存储运运的，所以面对不同的需求，它与原有的匹配不一样，所以混合的话容易相互干扰。

啊，然后对于你们这个问题呀。我旗帜鲜明的认为，应该优先进行业务域的垂直拆分，再进行每个子业务域的水平拆分。啊，因为你的架构变复杂了，你先重构，把业务理清楚了，服务站点理清楚了，先做业务的垂直拆分。业务群开发好了，你每一个业务的范围内，用前面我提到的那种通用扩展性的方法，性能应该不是问题。就是对于这个问题我的经验和建议吧。它不止是一个性能的问题啊，更是一个。这个原有的架构难以适应性业务的一个。一个一个的分子啊，我的建议是先做业务的重构，系统的学习，拆分梳理和去三分再做。

前面我提到的水平扩展。好，这个这是第一个问题。好，第二个问题。啊，第二个问题，这个应该我印象中是一个测试的同学啊。梁又急了。啊，应该应该也是架构师之路的粉丝啊，因为我看他这边提到这边五八同城的这个转型啊，应该是我之前在文章中写过。就是五八同城经历从Windows技术站网、Java开源体系的转型。然后。呃，应对流量增长带来的性能与成本的压力，现在创业型公司很多在初期选择云原生。啊，但往往面临过度设计导致资源浪费，或者叫架构僵化难以扩展的两难。站在架构师的视角，如何基于业务前3年的流量预判啊？做技术站的选型是否有可复用的评估方法？

我印象中是测试的同学啊，2两Q级的一个问题啊。这是一个非常务实、非常实际且非常关键的问题。啊，就是业务的前三年。啊，对应到五八同城啊，就五八同城的架构，现在这个分公司啊为服务呀，很复杂。你让我回到10年前，那我们回到15年前，重新来设计五八同城的架构。在当初会跟现在今天一样吗？不会。你看不了15年。你让他重来一次，可能他设计的架构还是当年那个架构，这个叫什么呀。啊，前一位同学说叫做架构是演进而来的是吧。如果你在15年前就设计今天这样的架构，你的架构会成为累赘，会成为业务发展的负担。所以第一点，你早期1~3年的这个架构，你就用1~3年的架构选型，最多多看一步。

最多多看一步。而且在技术选型的时候，很多时候。不是选择最先进的技术。很多时候选择的是。叫做当初的架构师或者叫当初的技术合伙人。他擅长的。架构擅长的技术学习。为什么呢？你看就像啊，大家想五八同城早期为什么选择Windows技术站。大伙想过这个问题吗？五八同城早期为什么选择Windows继续站啊？当时是I is这个server Windows server.他是大鹏，为什么？是不是因为当时的技术负责人他自己最擅长？最熟悉，真的真的。他当时会选择他不熟悉的，或者叫先进的，或者叫流行的地代码。

所以很多时候啊，你业务1~3年，业务在初放的时候啊，要选型啊，是决定于那个人呢啊，这对于我们的体质是什么，这对于我们的体质是如果你和一些同学合伙创业啊。啊，他负责产品，他负责运营，有一个人负责制作。负责技术的那个人的技术高度和技术视野还是挺重要的，对吧。他选他熟悉的，但他熟悉的是什么？是不是扩展性好的，是不是最流行的是不是？这个这个呃，适合的。所以呃啊，再回到这个问题啊，回到这个问题啊。就现在确实基本上。主创业早期会选择全托管的云服务。应该现在大家创业都是用于嘛，全托管的云服务吧。就在早期，在你的产品验证期，你的系统的核心目标是降低运维成本，加速迭代。

啊，这个时候的资源浪费是远低于早期去搞复杂架构带来的人力浪费的。最开始的一段时间啊。浪费一些资源。啊，特别是1~3点啊。他不会成为你这个业务发展的瓶颈，所以早期我觉得浪费一些资源就浪费一些资源是我个人个人观点。到了未来打三年五年，你有100台服务器的时候，你有300台服务器的时候，再去考虑教育的提升。你早期1~3年，你的用户都没几个，你的产品都还不成熟。对吧，你的这个业务成功了没有都不知道，你就先用3台5台，先扛着3台5台可能资源利用率也跑不满，对吧。啊，早期的话我觉得。想浪费一点就浪费一点吧。

你早期你花那个人力去这个系统资源利用率提高30%，只能一台机器，它不值得的。但是对于对于扩展性的话是需要考虑的。啊，比如说。系统的边界，这个清晰的接口，数据库的拆分，它是在架构设计上是是可扩展的。啊，这又回到我们早期的bad case呀。就早期没有考虑扩展性，真的啊，等未来等你到100台机器的时候啊，你架构考虑过来的时候啊。这说明你的业务成功了，说明兄弟你你创业成功了。对吧。啊，那个时候是幸福的烦恼。啊，扩展性的预留，我举个例子吧，比如说存储城，那早期的话，我们五八同城，在五八同城他就没有考虑预留，他搞了一个大库啊，一个数据库的实例里面几百个表相互关联。

啊，后面公司成功了的时候发现猜不出来。因为表与表之间都相互中位，在一个室里面，在一个库里面啊，叫做五八大库啊，几百个表，几千个表。他就是没有做好这个边界，没有做好拆分啊，那个时候是给你数据库，给你实力，给你机器，你也扩容不了。啊，这个就是不好的。啊，后面花了。嗯，用力单位的时间去做重构。啊，当然我刚才也说了呀，这种重构说明公司成功了，幸福的烦恼。啊，早期也没有那么资深的架构师来做，做隔离呀，做边界呀，做设计呀。啊，所以这是我的观点啊。早期浪费了资源无所谓。但是你。做好扩展性一流清晰的边界。也需要一些有经验的架构师。好，第三个问题。啊，沈老师好。

对于制造业来说，数据量规模的增加最多就是最多的是曝工记录啊，传统的单一MYSQL数据库的量突破千万亿的。啊，日常使用非常卡顿，针对这种场景，如何在架构上进行改造，保证工作量最小，这个投入成本较低啊，这个问题也非常具体，这是一个后端的同学小明起的啊。后端的小名词的一个问题。制造业，他说，哎，我们的并发量可能没有互联网公司那么大啊，我们的数据量是瓶颈啊，是曝光记录啊，传统的买收L部署不过千万。啊，在互联网公司啊或千万基本上再加上不图，一上来就要分库分表了。啊，分工分表，分工分表的价格要改造，可能要微服务改造啊，或者是风险中间件啊。但是你这边只能是针对这种场景，在原有的架构上扩展。

工作量最小，投入成本最低啊。啊呃，我不确定，像假如你们公司的这个it团队啊，采联团队啊，大概有多大规模呀。啊，对于制造业来说，可能他不是就是没有那么大的这个，这个没有那么多人，没有那么大的研发规模来做改造。那么我的建议是什么呢？所以你原来用的是MYSQL啊，上层的应用用的是MYSQL协议，MYSQL的客户端去调用MYSQL。数据量大了，你可以切换一个MYS协议兼容的存储系统，花一些钱啊，当然得花些钱啊。不知道表达清楚没有，你去底层的存储，你去切换一些买思可协议兼容的存储系统。啊，比如说呀。啊，比如说啊太基地。

啊，就是用的比较多的台币啊。包括。啊，你可以跟这个腾讯云这边去了解一下，他们也有买SQL协议兼容的替代产品。啊，你的程序不怎么要改啊，他有比较成熟的方案，可以帮你做数据迁移里面的存储迁移。啊，对于你的应用程序来说，它就是买sol，但是它的存储就是变成了一个分布式的这个存储与计算分离的，高可用的这个好运维的一个系统。啊，但是可能得花一些费用，这样的话架构基本上不怎么需要改造。啊，不怎么需要改的。嗯，有一句话怎么说呢。就是如果你没有足够的预算。那你就把自己自己去解决那些复杂的这个用技术去解决那些复杂的问题。如果你有一些预算，你就买一个产品让别人。

用技术去解决那些复杂的问题。所以你开始你们公司是可以自己去解决那些复杂的技术问题，还是买别人的产品，让别人啊，让腾讯云帮你去解决那些复杂的这个技术问题。反正我的观点是啊，专业的人在干专业的事情。啊，像我们在快手打车，他不可能自己去搞什么机房，搞一些什么。组成的都是用比较成熟的云的方案。就我们自己专注在。业务开发的就好了。对吧，然后技术的归技术，让业务的归业务开发。好。下一个问题。就在实际的业务中，分库分表虽然能够解决数据库瓶颈。对，分工分表，今天聊的啊是扩展性啊，增加读写容量，增加读写性能的方式。但也带来了分布事务全局、ID跨越分片等复杂性问题，想请教，想问一下哪些场景下不建议过早的分布分表，是否有更优更优雅的方式，期待啊。

啊，你这边别乱丢说和开了。如何看待分工分量？研究搜索之间的。循环。啊，这应该是后端的工作，Time同学提的问题。啊，后端的不探的风险这个。怎么说呢，其实刚刚那上面那个问题啊，其实也。也有或多或少提到提到过啊，就首先。在创业的早期，我的建议就是不要分部分表，创业的早期不要分部分表，因为分部分表的话，你的这个业务代码会更复杂，甚至早期你都不一定要为服务啊，单体架构。先搞着，因为早期创业、早期业务产品追求的是快速迭代。啊，是试错。向市场要的是时间。这个时候。这个存储啊，架构啊，包括数据库啊，可以简单点好。

就是真的当你的架构成为瓶颈，你的存储量成为瓶颈的时候，我刚刚提到说明你创业成功了，说明你用户量足够多了，说明你的产品很受欢迎，这个时候我们再来投人投钱，给架构改造。但是在这个里面预留一个。分库分表的可能性、可行性，不要像这个五八早期一个库，所有的表都在里面，大家都相互作用。就你要有一些规则，你要有一些规范，早期的话，你可以在一个实例里面是没有问题的，但是你别所有的库，所有的表都耦合关联。做好这个规则，未来的话撑不住了，你家机器就能够很好的拆开，就是预留分布分表的可能性。啊，就是刚刚说的，第一早期不建议分工能量，其次预留分工分量的可能性。关于这个new搜狗和TDB这个优雅过渡方案的选择和权衡，跟上一个问题啊，我想表达的，我想说的是一样的。

就是说你们如果没有足够多的预算，你就自己分工分量，用技术去解决。如果你有一些预算，你就买别人的产品啊。IDD或者是腾讯云的一些产品，让别人技术来解决。啊，你就专注在这个业务系统业务需求的研发的。数据库层确实是啊，数据库的是最复杂的啊，它有状态，在架构设计中也是最复杂的啊，你最容易成为这个系统的瓶颈，包括你这边提到的分支事务啊，全局VID啊，跨片这个跨分辨查询啊，其实。啊，都有一些技术手段去解决，也都有第三方的产品来帮助，这个都是有的。好。最后一个问题的话，我选了一个很有意思的问题啊。啊，是一个数据分析的同学问的。啊，一个比较W的同学，第一天进的同学们。

啊。他应该是看了那个架构扩展性的一些一些一些那个吧。他说，反正对于他来说，这些内容太高大上了。了解这方面的知识是偏理论性的。呃，很好奇，就是架构师的作用啊，在某个行业中充当什么样的角色？相关的知识很重要，但是哪里重要，能够改变什么？啊，这是一个注意分析的朋友问呢。就是我不确定你们企业的架构师在做什么。架构师有什么作用？我能够跟你说的是。啊，我作为架构师的身份在企业里是干嘛。啊，有什么作用，能够改变什么？就是我在企业里做架构师的时候，其实也是写代码对吧，做架构设计对吧，解决系统中出现的问题是吧。解决业务架构中出的问题。

啊，如果你还觉得太宽泛的话，我可以举几个例子。啊，我作为架构师做过的一些项目。比如说五八同城要做。百万同时在线的即时通信系统。对吧，这个东西它不是所有的研发同学一上来他就能搞的。很复杂的。对吧，我作为架构师会去设计模块，会去设计架构，会去设计流程，去保证高可用，保证扩展性，保证加机器就能够扩充性能。对不对。啊，这是。做设计写代码，然后做实践嘛。啊，包括五八同城的智能推荐系统。啊，我做架构设计做实践。包括五八转转啊，地板的架构设计。啊，我去做做设计，做模块，做交互，做扩展性，做可用性。等等等等。啊，包括不只是从0~1啊，系统出现异常的时候。我八同心早期有一次支付系统异常。

啊，就相当于只是数据量并发量太大了，然后很多用户比如说充值啊，消费啊存在异常，那原来的系统可能架构是不合理，加机器解决不了。啊，那我就要做以架构师的身份去和相关的同学去分析系统，分析代码，分析业务，分析瓶颈。啊，做代码的重写，系统的重构，来保证系统正常运行。啊，所以架构师没有大家想要的神奇，可能经验丰富一点。写代码，做设计。啊，解决业务问题，系统问题，做0~1的系统的方案。然后我从五八。到到家的最后一个项目。是一个最后一个一个大项目吧。啊，是机房迁移。啊，当时五八同城应该是至少有几千台机器。他自己有机房，然后迁移到腾讯云机房，好像迁移到腾讯云上海云的机房了。就是你看，说起来很容易，你这边有2000台机器，你要迁到腾讯云的天津的机房里去。

做一个方案。啊，架构师就是甘肃的。当时就是整个软件的架构的一个迁移啊，是我这边架构师以项目经理的身份做的方案，前前后后一年的时间，一年多的时间。自己机房的几千台机器迁到腾讯云天津的这个几千台机器。架构是干嘛，架构是干这些的。对吧，你整个过程中你怎么样保证不停浮平滑和回滚分层分任务。所以对于架构师如果好奇的话。嗯。做方案，做设计，解决问题。然后这边有一个同学说啊，有些项目一上来就要求微服务架构啊，就是我是旗帜鲜明的反对啊。叫做。任何脱离业务的架构设计师团什么？啊，微服务分层系统会更复杂的。

系统会更复杂，运维、定位问题、迭代需求都会更复杂。都会用出来，如果你的业务早期用户量小，数据量小，并发没那么高，属于产品的试错阶段。早期上来单体。最快的高可用都不用，先不用保证高可用，最多是加两个他配的做高可用数据库，搞一个组成。就是不是架构，是要求用什么架构，而是你的业务在当前阶段，你的业务复杂度、数据量，这个业务的阶段适合用什么样的架构来做选择。好5个同学的提问啊，我今天有点超时了啊。啊，超时了。然后第三趴啊，第3趴。就是和大伙的互动啊。和大伙的互动，原来的话计划是7:45啊，我现在抄了有20分钟。

啊，看大家有什么问题，然后据说啊在这个环节。会抽奖和送礼品对吧。啊，这个环节抽奖和送礼品。看大家有什么问题，哎，我现在手机切到了这个互动区啊。那有什么问题啊，机会往往是给到主动的人。嗯。按合同要求如何应对啊？这个6月暴雪飞梨花啊，那我懂你的意思了。啊，我懂你的意思了。相当于是一个甲方给你们提了要求，对吧，你说的这个场景跟我们在企业内做自己的系统的场景不一样啊。啊，我们在企业内，我在五八，我在百度，我在快手打车，那是自己的产品研发业务这个技术团队。

啊，我们一起来做系统，一起来做产品，一起来实现业务。一家助的业务啊，那不是是自己，所以我们用最适合的。这个架构最适合的技术选型去应对我们的产品，我们的业务，我们的业务阶段，公司阶段。你说的这个场，你说的这个场景。啊，这个叫六月暴雪飞梨花的这个同学啊。应该是别人给你提需求，别人付了钱给你提需求，那你就按照甲方的办呗。对吧。对吧，付钱的人对你提要求，那谁付钱，他要求你用微服架构，那你就微服加入买。那你要你可以跟他讲清楚，说微服架构很复杂，周期很长，你得多付些钱。可以给他建议说ABC三个方案优缺点是什么，费用是什么，你选。

六月暴雪飞梨花啊，要么这位同学发了礼品呗。发给好下一个同学。啊，宋文清。啊，想进腾讯云架构和后台团队，在校阶段要补哪些能力？从大三到学习，再到正式的工程师，理想的成长目的是什么啊？这应该是一个校招生的同学啊，要进想做后后端啊，想做架构啊。做架构的话，应该时间还久，你先进后端团队吧。因为我自己是后端出身的啊，我是后端的出身，从这个这个实习工程师啊，到初级工程师，到高级工程师，到资询工程师呀，到什么。这个在职场一年一年学技能嘛，学本领嘛，做项目嘛，做系统嘛，从别人带到自己做到到带别人嘛，从做小系统做大系统。然后做系统多了，踩的坑多了，对吧，Bug多了，问题多了，后面材料架构师了。

好，对应到你具体的问题啊。后端团队在校阶段要补哪些能力在学校啊？呃。你一定懂一门开发语言，对吧？啊，CC加加这个Java，那go不管什么呀，你得懂一个开发语言。啊，你得懂常见的。这个工具吧。这个开发工具调试工具啊，现在AI这么这么火，对吧，你得懂AI编码的一些工具对不对。你的底子得基本功得过硬吧？啊，这个会议原来我们是对于计算机网络，操作系统，数据库，我们得有要求，对吧。包括基础的数据结构和算法，你都懂吧？啊，常见的设计模式应该懂吧。反正我记得，我记得我在校招毕业的时候，可能也就懂这些吧。

啊，大学里学的一些东西，再加上有一些实践编程语言工具这个。数据结构算法操作系统等等等等啊，应该越大的公司啊。在校招的时候越看基本功。约看基本。我印象中那个时候在0809年，那个时候我相当。我校招的时候考算法考的特别多。就结构算法。行，那么这个宋文清同学啊，宋文清同学啊，后面可以记一下，可以领一个礼品啊。大家继续有问题提问互动啊。好，今天。呃，穿过生命，散发芬芳，同学，他说单节点到最多节点，保证数据的完整性和一致性是挑战啊，没错啊，你这是个陈述啊。

但是基本上保证完整性和一致性啊，也有相关的技术方案，嗯。就关于一致性啊。后面我记得，我记得我们的架构话题的系统性规划里面有一张是一致性，可能过几个月会有，或者过几期吧，应该会有其他的架构师，那也可能是我的。啊，跟大家来聊架构一致性的问题啊，看后面腾讯这边同盟这边是怎么怎么规划怎么安排的。就是我先我就先这么说。就是在高并发的分布式环境下。高并发的分布式系统里。高效的一致性问题是行业没有解决的难题。啊，这个知道，所以一般会有一些折中的方法。比如说像CP，大家相对的相关的理论啊，可能或多或少有些了解啊。

啊，包括最终一次性啊，对这些了解就是实时的高并发的高效的。这个分布式一致是行业内的主要问题。好。这个今天减肥了吗？哎，这边提了一个问题。啊，今今天减肥了吗？面对AI快速发展的时代背景，架构设计需要做出哪些调整和创新？这个是这样的啊，这个我说一下我的看法啊。首先，架构。原来要设置的什么高可用啊，扩展性啊，高性能啊，包括刚刚提到的一致性啊。原来该怎么设计还得怎么样设计。AI它它起到一个什么样的作用，或者是一个什么样的角色呢？就不管你是对编码还是对架构设计，还是对技术以外的其他岗位啊，我个人的理解，AI是停效的工具。

啊，在AI时代应该也有很多AI的话题啊。啊，这个，呃，我们学习组，包括今年上半年就在社群里面的很多每个月的主题的方向啊，也是我和腾讯这边一起策划的AI应该有好几期都是AI的方向，因为AI确实特别。大伙不用焦虑，说AI会不会颠覆你，会不会替替代你，会不会取代你？现在很焦虑，或者师程序员技术员很焦虑，对吧，会不会连对的。我个人的观点是。AI只是工具，它是帮我们提效提质的。再举一个例子。这个IDE它是工具，你最早用IPS开发，你现在用VS开发。这个工具能够提高我们的开发效率和开发质量。AI也一样，它是工具。

啊，使用这个工具，我们开发代码能够更快。质量能够更高。那替代我们的是什么？是谁呢？或者说我们要有压力的是什么呢？我们要有危机感的是什么呢？是那些率先使用工具拥抱变化。保持开放心态，掌握了先进生产力的人。也就是说，与你竞争的你是技术人，与你竞争的是也是技术人，但是他掌握了AI工具。我期待你的不是别人。啊，不是那个工具，这对我们的启示是什么呢？不管你是开发者还是架构师啊。你要去学这个工具，去使用这个工具啊，你要保持开放的态度，去拥抱新的工具。啊，这3年是AI工具，未来3年可能是其他的工具。啊，这是我的观点啊，面对AI快速发展的时代，架构师开放心态，去学，去看啊，去拥抱这些工具啊，成为那个率先掌握工具的人。

去取他别人。支付管理。啊，这个今天减肥了吗。我们给他这个这个记录一下，可以发个奖品啊。嗯。架构需要为业务服务啊，没错。嗯，好，这边有一个用户8019388。8019388的用户。住户。他说有些项目上上哦，这个刚刚啊提到这个刚刚解答过的，上来就要求用微服务，这个是不合适的。好。啊，这个全站开发日志，他问的问题也是类似的啊。叫做多大的紧急量，多大的并发需要上微服务架构，一开始设计就是设计好的啊，刚刚提到了，不是一开始设计就是设计好的。

啊，一开始早期的阶段。啊，你用估量这个并发量，数据规模，产品复杂度来决定啊，一般来说早期还是单体架构，不要一上来就上复杂的架构，这样的话早期运维复杂，追查问题复杂，开发慢啊，影响业务的发展。然后。好，还有没有其他问题？哎哎，这边好像又刷新了一波。还发新工作。嗯。好，稍等啊，我这边评论又刷新了一遍，来看一下啊。信息安全大事哪方面可以选，这方面有哪些可以选啊？付10886946。

我是信息安全的，我大四是信息安全的。啊，新疆安全应该我们0809年，我是零几年。嗯。17年毕业的，07年新疆全毕业的。啊，华科信息安全学的跟计算机差不多啊，我是读研的时候软件转的这个软件方向啊，也是我刚刚说的那些东西，一门语言工具啊，底层的这个数据结构算法设计模式。在学校的时候。哈喽，第一个同学。哈喽，第一个同学跨云双活的情况下，延时一致与流量就近接入，你这是一个问题还是一个陈述啊？跨云双活这个架构有点复杂。啊，首先装火解决什么问题。双活容的是机房错是第一，双活容机房错，一个机房出故障了，流量切到另外一个机房。

第二，双活解决就近访问。就近访问与C间差不多啊。就是说用户在上海访问上海机房，用户在北京访问北京机房，双活一般是解决这两个问题，第一个叫容机房错，容机房故障。嗯。所以这个这个呃。就近的用户，他的速度就快了。我就就快。然后那么哈比格哈比，你给他发个礼品吧，还有多少个礼品啊，是要发。啊，就是您觉得是监考证优先还是做项目优先，我内心是觉得一定是做项目优先。啊，至少因为我待的公司都是互联网的公司啊，啊从百度到五八同城到快国打车到家集团都是互联网公司。

几乎不看证。像那个什么软考的证我也有啊，不看还是看你的动手能力和做项目的能力。啊，我我所经历的公司是互联网公司，我能够告诉你的是，这些公司是优先看动手能力，项目能力。啊，但是其他的公司是不是健康证，那我不太清楚。还是马斯克？Hello, 第一个，今天重新设计一套0~1的出行订单系统，你会先单体还是直接serve match啊，我个人。会先单体啊，当然这个0~1的促销系统，当然早期的时候他可能是这样的，你做一个业务，做一个项目，它在早期的时候，他的需求里面就有有有一部分性能需求。你在系统做设计的时候，你的第一版。你的性能需求是什么？如果他的性能需求就是比较高，那你可能会做更复杂的事情，我举例子啊，还是转转。

转的大家都知道。转转我们做第一版架构设计的时候，他的系统设计目标就是100万用户。那我们一上来呢，可能就是微服务分层。但是我们。比如说道家集团，快给打车，他一上来可能他没有那么多用户。啊，现在来的1万用户，那就怎么快速来。啊，当然预留一定的扩展性。所以不会一上来就有很复杂的架构。这个二个记了吧，给他发一个。啊，已经拿下ACP开发里面说一下垂直更深的内容。这个不做虫子，如何应对职业瓶颈期？解决1跳槽不基本解决，2输出但没有遇到合适的场景。这个是职业发展的问题啊。啊啊，最后2个名额。

好，最后最后两个名额啊。这个不做虫子说的这个是这个。职业发展的问题。就是你觉得。遇到了职业平衡。我想问你的是什么呀？我想跟你互动的是。你现在是公司技术最厉害的人了吗？如果不是你为什么说学不到的东西遇到瓶颈了？跳槽不是根本解决方案。他早不是跟那个有关。我的建议是。我不要知道他想清楚你要什么，你到这个问题是向内归因还是向外归拢，更多的时候我们向内归因。不要总觉得是公司的问题、产品的问题、老板的问题、同事的问题，多想一想。数字。啊，就是因为我也面试很多同学啊，他说我在公司学不到东西啊。你是公司竞争最厉害的人了吗？

对吧。啊，如果是那公司成为你的瓶颈了，那你来跳槽。呃，最后刚刚说的最后两个礼品对吧，那我最后最后两个问题啊。哎，这是还是刚刚那个用户啊，8019388，那我换一个朋友啊，嗯。这个。哈。Hello, 这个的一个，由于等一下，我尽量选一个别的工具，这个用户1187。3553。好，我们记一个这个叫用户11873553这个同学解决问题啊陈老师API消费关系在生产环境呃运行态要不要做校验，另外微服务网关和ESB共存的情况下，如何进行网关和EB的当生？

是这样的。微服务，首先这里面有几个东西啊，第一微服务网关是干嘛的？微服务网关是做微服务的，请求路由和分发那个。他可能统一的做一些这个验证啊，权限啊，校验啊，路由好像做这个。ESB是做什么的？我可以理解为是消息发送中间的一个消息的服务。对不对，所以它两个应该我的理解啊，应该是解决不同问题的。网关的话，不是所有的系统一上来都要有，比如说HTTP网关或者是微服务网关的。只有当你的。HTTP的外部收入太多了，架构太复杂了，变成自蛛网了，你可能引入HTTP的网关来统一做路由分发，并且做一些什么权限呐，校验啊，认证的事情。

微服也一样。微服务，当你的服务数量少的时候，你直连就好了。只有当你的系统足够复杂，微服务足够多，系统变成蜘蛛网了，你会用这个微服务网关来做分发呀，或者一些权限啊，或者一些治理的事情。啊，就是。回复网关。消息呢？什么样的情况用消息啊，这个是个复杂的话题啊。啊，上下游解耦很多时候用消息。啊，MQ这个ESB等等等等对吧，所以你去看你的那个场景。复不复达到要用微服网关。或者说你们那个场景通讯是不是用USB。MQ, 我之前写过文章啊，其他的场景啊，调用方不关注结果啊，包括跨公网，包括关注结果跨公网时间很长，包括。

啊，这个，呃。这个数据依赖等等等等，它用椰子语。好。这个用户11873553啊，我们这个就行好最后一个问题。啊，最后一个问题。这个桥卓越。啊，乔卓越如何看待面试严打？使用AI，物质疯狂push，使用AI，一个与时俱进的技术面试，理想中应该是怎么样的？这个怎么说呢，AI是工具，在面试的过程中，那他面试你站在面试官的角度，你站在企业的角度，那他当然希望他了解的是候选人的。这个就是对平常，而不是。这个AI的水平。

但是入职之后。就把AI作为你必须掌握的功能技能，要提高研发效率，提高研发质量，那如果你不用的话，你就落后于别的公司。所以我是偷偷你能够理解的，面试的过程中，他其实考察的是你的人。啊，面试之后，他得想办法去这个提高，再把质量提高代码效率，保持他研发的竞争力了。好，所以呃，最后一个这个给到这个调作业嘛。好。我今天超了大概25分钟了。好，那要么咱们直播间的互动先到这里，然后大家多去这个社区啊，多去社区发消息发问题啊。啊，我刚刚也提到，你在发问题的时候，尽量不要一些泛泛而谈的问题，你的场景具体一些。

这个问题具体一些，这样的话，后续的话呃，会优先被挑出来，然后在直播间解答啊。行，那泽理我是不是这边结束共享就行了，然后给到你那边是吗的好的好的，那我这边结束共享了呀，反正大家持续关注加入之路，持续关注这个，呃，技术同盟嘛，持续关注我们的社区吧。然后这个好像刚刚有同学提到的这个PPT材料，PPT材料的话，我会给到泽敏他们，他们应该会在群里面。会在群里面发给大家啊，大家就扫码加群吧。好，那我这边啊就结束共享了啊，后面交给张总这边吧。好的，再一次谢谢沈老师，天，我感觉今天还有好多的问题来不及解答，大家真的太热情了，而且感觉这个议题其实很多小伙伴确实是有，呃，很多工作中确实遇到类似的一些问题，那大家也可以在我们的学习交流群，或者是我们的架构师社区啊，继续跟沈老师后面保持一个互动，那陈老师也会在我们的社区里面啊，常驻跟大家做一个交流，好啊，我今天开场时候其实有跟大家介绍我们这一次的一个。

呃，特别的惊喜，那可能该开头的时候有些小伙伴不在，那这里也补充介绍一下，就是咱们的沈计老师后面会正式成为下一站架构大师的常驻首席讲师，更高频的来陪伴大家，嗯，当然但但是大家也放心啊，我们也不会说就让沈老师为了咱们这个节目之外什么时候不能干啊，呃，只只能说他就是会成为咱们这个节目大家可以常常见面的一个技术老友，那我们也会合理的安排让他高频的跟大家畅聊，同时呢，也会有其他的同盟的老师们啊，名人堂，名人堂的大咖们也会来参与，保证我们每一期都很精彩。那总的来说呢，今天这一期啊，到现在其实我觉得不算结束，而是一个新的开始啊，各位未来的一些技术困惑，或者是一些架构的难题，我们都有一个可以长期交流的引路人，就是沈建沈老师，那也请大家务必持续关注我们的直播间，锁定沈。

沈老师下一次的登场，我们一起把这里打造成一个技术人成长的加油站。那下一期大家想要听沈老师来聊什么，大家也可以在评论区打一下对。好，那最后再送一个福利吧，我们会为各位啊提供沈健老师今天直播分享的这个干货PPT材料，同时呢，我们也会有一位直播小助理为大家总结今天的一个呃课堂笔记，那如果您想要找到更多的一些同路人，或者是下一次直播啊优先被沈老师选中，然后优先答疑，那可以扫描我们屏幕左侧的二维码进群，资料都在群里，我们会在直播结束之后尽快发放给到大家，那技术之路期待和大家在一起成长，我们就直播到这里啦，下期再见，再次谢谢沈老师，还有今天陪伴了我们一个多小时的各位小伙伴们，谢谢大家。