01  畅谈架构演进史

王晓波：其实架构演进，这件事情在我看来正好是对自己职业生涯的一个总结，我之前是做基础架构、中间件等一系列的东西，这些年在做业务架构和应用架构。
从我的角度来看，架构技术演进史可以分成两个部分看待：一个是应用技术架构部分，一个是基础技术架构部分，两个演进方式和关键节点不太一样。但应用架构是建立在基础架构演进史基础之上的。
架构演进史可以分为三个阶段，首先是单体时代。在 2006 年左右，当时国内对架构师的定义还不是那么清晰，很多人不清楚架构师是什么。刚开始我们仅仅是把技术做得比较好，能够规划框架开发规范的称之为架构师。
第一代的架构演进就是技术编程框架为核心展开的一系列规划和解耦部分或者一系列的模型建设部分。那个时代来看，很多开源主要的东西都是编程框架，更多的是单纯的编程。
第二代就进入了高并发、分布式，应对大流量的状态。这个时候的架构演进更加注重的是外围基础设施，也就是关系数据库是不是 OK、Cache 是不是 OK、整个负载是不是 OK，是不是可以做横向的扩展，是不是足够分布式，是不是足够拥有对流量的控制，或者是不是有足够的稳定性、高可用的控制……
这一代架构的演进特点是注重于基础建设，就是大量的资源变成了基础建设，应用在这个基础上更好地迭代。

第三阶段应该是基于数据的应用架构，应用架构到了现在这个状态更加注重数据驱动，也就是越来越多的基于数据的挖掘产生新的应用。

或者可以这样说：当“机器学习”这一类的技术不再是作为一个广告词推出的时候，并且真正落到系统的每一个角落的时候，那么我们的架构新挑战也就来到了。

这一代的数据驱动的架构更加注重的是对于海量数据的挖掘和实时应用，对于大量数据的快速计算，甚至我们要求做更快的应用开发部署，这个时候更多的特点就是延伸，更多地做数据驱动等等一系列的东西，源源不断创造新的数据驱动架构理念。
王超：我从另一个层面来看，架构是随着整个行业的发展和社会需要去发展的。
首先是门户、社交时代，在 2000 年前后，当时是 PC 互联网蓬勃爆发的年代，有四大门户，互联网主要是新闻内容传递为主。所以那个年代分布式内容分发网络，也就是 CDN 蓬勃发展。再经过几年开始有 SNS 社交这一类的产品出现，解决的是人和人之间信息传递的问题。
技术上从编译型语言，逐步过度到动态解释性语言的广泛应用，便于编写一些复杂的业务逻辑关系代码，同时像关系型数据库也开始被广泛应用。
除此之外，因为关系网络非常复杂，要满足性能要求，开始大量应用缓存，弥补关系型数据库存取能力不足的一些场景需求。
当时还有一个快速发展的技术就是搜索引擎，综合搜索解决的也是信息快速被查找的需求和问题，但因为是全网检索，就对存储、计算有了非常高的要求，这个时候呈现出了分布式系统和 NLP 的雏形，进一步提升工程能力。
第二阶段是是移动互联网阶段，就是从 PC 到手机再到各种各样的端，大家对互联网的认知逐步加深，流量开始指数级增长。
这个时候需要的是更强的存储和计算能力，所以云计算就被广泛提出来，随之出现了很多超大规模集群。

最后是消费互联网和产业互联网的高速发展期，工程能力在上个时期已经被很好的解决了，在 IoT 广泛应用之前不会再有指数级终端设备联网，基础工程能力不再是问题，主要的技术发展会聚焦在大数据、AI 架构方面。比如，如何用图数据库解决复杂关系图谱的问题，GPU 集群、弹性计算、机器学习框架都越来越重要。

所以在我看来，架构技术的演进和发展是因为社会发展和用户需要发生变化的。

马文霜：晓波老师和王超老师对互联网的产品、技术架构演进做了非常好的归纳和总结。我想以云硬盘的技术演进给大家讲一讲我们在这里的一些思考以及获得的经验教训。
2013 年我们设计云硬盘的时候认为这是一个分布式的存储系统，腾讯在分布式系统是有着多年的积累的，分布式文件系统 TFS、KV 存储、CKV 都是非常成熟的产品。用成熟稳定的产品去支撑云盘可靠性好，能够快速上线，就集结了腾讯的三大明星产品TFS、TSSD 和 CKV，设计了云盘 1.0。
TFS、TSSD 和 CKV，这些系统的可用性都非常好，然后用它们搭建出来的云硬盘可用性肯定也是有保障的。冷热分离，冷数据下沉到由 HDD 组成的 TFS 里面，热数据就上浮到由 SSD 组成的 TSSD 集群当中，既保证了性能，又照顾了吞吐，还可以无限扩容、成本有优势，各种优点可谓一应俱全。
但是到了 2014 年底，运营不到一年半的时间就发生了三次比较大的不可用故障，小问题不断。2014 年有一次不可用时间超过十二个小时。
1.0 架构为什么会有这么多问题？我们认为核心的问题还是我们没有从客户的需求出发去做这个架构设计，这也是刚刚王超老师提到过的。我们是基于已有的技术去做架构和设计产品功能，过分强调复用已有的系统，导致这个架构复杂，难以保障可用性。
一个典型的例子是，底层存储用的是一个 KV 的存储系统，这个系统的特点就是对更大的键值更友好，承载的云盘性能就会更好，成本也更低。
我们线上的 linux 云主机比例更高，如果设计 4096 的云盘给 linux 云主机用，对于用户来说能够得到更好的性能，成本也更低。我们设计了 4096 和 512 两种大小的云盘，把 512 给 Windows 的云主机去用，4096 就给 linux 系统用。上线以后直接遇到了用户的疯狂吐槽：Linux 云主机重装到 Windows 以后数据没法用了。
这个例子当中我们为了支撑不同大小的云盘把我们的系统架构做得更复杂了，本以为会给用户带来更好的性能，但是用户对这个产品的功能根本不认可，不能换系统，硬盘就只能锁定在某种系统上面，认为这个体验非常槽糕。
经过反思，我们决定一切从用户需求出发，总结下来其实是三个核心需求：数据可靠性、可用性、稳定的性能。
基于用户对云硬盘的三个核心诉求，我们设计了第二代架构。特点是扇区大小统一、一致的存储介质、固定的集群规模等等，静态数据路由，设计力求简单。
第二代架构系统的可用性有了质的提升，支撑了云主机在 2015 年到 2016年 的快速发展。
接着，我们在第三代架构中去掉接入层，SSD 和 HDD 混合存储降低成本，再到后面的引入 SPDK，RDMA 技术降低延迟，都非常自然。
因此我们总结的教训是，产品的架构设计一定要基于用户需求，在不同时期抓住用户当时的核心痛点，演进架构，解决掉用户的这些问题，才能成功。而不是根据已有的技术能力，YY 出产品功能，然后推给用户，可想而知，这样的产品一定会被用户用脚投票，无论背后的技术架构多么巧妙，业务注定会失败。
王晓波：看来，合格的演进应该来自真正的需求，当需求发生了变化、体验发生了变化，需要更多更新更好的体验的时候，架构也将开始下一步的演进。
02  如何实现高可用架构？

马文霜：一般来说，整个系统的可用性一定会有一个数值来度量，大家都是用当月的不可用时间除以当月的总时间，比如算下来这个可用性是 99.99% 或者 99.999%，感觉很高了。
但问题在于，系统在业务低峰期挂掉十分钟和业务高峰期挂掉十分钟对业务的影响可能会相差很大，如果照搬算出来的可用性又完全一样，这个时候可用性不能反映系统的真实情况。
腾讯在内部计算可用性的时候采用了另一种算法，不是去看这个系统，而是从请求的角度出发。因为系统都是去提供服务的，在这个系统被拒绝的请求量，加上超时的请求量，然后除以总的请求量，如果你的系统算出来的可用性接近 100%，那么你的系统的可用性肯定很高的。
在设计、运营系统的过程当中，一定要警惕系统中单个服务器的服务能力陡降导致的系统可用性的下降，甚至不可用的问题。
举例来说，假如我们设计一套系统，有一个负载计算器去做请求的分发，后面接了很多的业务服务器，单台服务器的 QPS 是一万，我们接十台服务器上去，系统的处理能力就是十万，如果有一台服务器挂掉，系统的 QPS 会降到九万，系统的处理能力是可以被估算出来的。
我们在做架构设计的时候总是假设系统里面的服务器状态是正常的，或者是故障，正常的服务器留在了线上，故障服务器被负载均衡器快速地踢掉。其实我们往往没有考虑到在系统运营的过程中，单个服务器会突然进入到了一个亚健康的状态，这是非常常见的。
比如因为交换机异常导致转发能力下降，这个时候服务器的网络能力肯定就会有一个明显的下降，CPU 如果有降频，内存在做 ECC 纠错，整个服务器的计算能力是会有一个骤降的。
硬盘也是经常出问题的地方，硬盘异常导致 IO 延迟陡增，甚至 IO 直接 hang 住不可用。单个服务器进入到了亚健康状态以后，服务器的请求能力急剧下降，甚至完全堵塞。
很多开源的系统，比如 HDFS ，就会因为单个节点的处理能力下降导致整个系统的处理能力下降，甚至整个系统就会变成不可服务。
因此我们在做高可用的架构设计过程当中一定要考虑，系统中单台服务器进入到了亚健康状态，处理能力变差了以后，系统是不是仍然是高可用呢？其实从这个问题上来看，主要应对有几个方面：
首先如果能够从设计上避免业务请求的依赖，这个事情是比较好办的，相当于每个业务逻辑比较单一，直接就是在单个的服务器上面能够完成这个业务逻辑，这样的话即使单个服务器处理能力下降，对系统可用性的影响也是可控的。
如果业务链条比较长，业务之间有依赖，就比较麻烦了。比如 HDFS 在写数据的时候需要把三个副本写到三个节点上面，但是这个写作又是一个串行的写作，这样就会出现三个数据节点，任何一个出现写入慢都会导致客户端的写入无法完成。这个业务链条越长，亚健康状态或者服务能力下降的节点的影响越大。
这种情况下有通过一个全链路的探测和监控，快速地把这些异常的，处于亚健康状态的节点剔除，才能让系统可用性快速恢复。
两三年前腾讯云团队在全链路监控，剔除亚健康状态节点上投入了非常大的精力。比如在网络出现大面积故障的时候，其实是不能做剔除的，但如果是单个服务器的节点网卡异常，或者你的接入交换机故障网络性能下降，就应该快速地剔除掉，不能出现误判。
王超：作为一个架构师真的是要对很多的细节扎得深，抽丝剥茧看其中的问题，并有针对性地解决。比如高可用怎么定义，基于请求还是基于 RunTime 都是不一样的，这个边界要搞得非常清楚。架构师要看的有深度，同时又需要广度。
举个例子，我曾遇到过一个问题，发现团队上线代码容易出现 Bug ，紧急修复再上线，结果又有新问题，每次出问题解决时间又很长，形成了一个恶性循环。而且，问题经常被运营和产品先发现，而技术却第一时间发现不了，总是被动通知。
基于这个问题往下拆解，会发现每天很多团队发布多个项目，项目之间有些依赖问题没有解决掉，很多团队又同时都在发，出现代码冲突，并且没有好的发布系统，发布完也不能做到立刻回滚。这些问题总结下来，有监控不到位、系统不完善，也有机制上的一些缺失。
作为架构师，首先要有基本的解决思路，比如如何去单点？发布怎么设计？怎么监控？这些常规知识网上都能找到，但用理想的方式去解决往往周期太长，业务等不了。
在我看来，长期方案固然要有，但短期方案也非常重要。不一定需要用最理想和技术方案去解决，但可以借鉴架构的思路。
比如，能不能把这些团队的代码发布，集中到一个团队去做，甚至一个人去做，类似解决数据库写冲突问题。如果发布很多，可以分成几个时间窗口去发。类似于 Log Structure Merge 的思路，就是合并写，也是简单高效的做法。
我觉得架构思路可以应用到方方面面，生产架构本质上也是一种架构，这就是我从另外一个角度去思考的架构内涵。
另外就是要分析公司的特点，比如贝壳业务都是在白天去跑，晚上没有多少人去看房子，这个时候晚上做混沌工程，即使系统短时间出问题影响也没有那么大，还有时间修复。大家要学会用这种优势提升系统鲁棒性。
王晓波：完全的高可用是不是存在？这个问题需要辩证的去看，什么样的情况是高可用，高可用到什么情况我们才能把这件事情做完呢？换句话说，在高可用这件事情上我们的目标是什么？需要达到什么样粒度的高可用？对我来说，我想到的第一件事情就是成本。举个例子，如果宕机影响非常大，做异地多活的话，对于整个架构来说高可用成本比较大。如果挂掉的时候能够恢复，降低成本的方式就是降级。
对于熔断和降级这样可能比较廉价的高可用措施，是一个架构师的进阶条件，特别是做应用系统的架构师。其实关键点在于明白降级要降的是什么？在什么条件下熔断什么样的东西对我们的损失是最小的？这件事情反映了一个架构师是不是对技术有非常深刻的了解，或者是对基础技术有深刻的了解。
做高可用架构的时候首先技术肯定是要好的，但是反过来，是不是只要技术很好就能完全搞定？我认为不是，如果对业务流程或者业务场景不了解的话，会带来非常大的问题，就是降成什么样子才是真正的降级？是对业务没有影响还是对业务体验没有影响，或者是对整个交易的过程或者收入没有影响？
一系列的降级方式其实完全不一样，取决于这个架构师对于业务的了解，并且把这样的业务流程模型化成一个系统架构，然后在系统架构当中完全实现如何把它降级。
所以不仅要技术好、逻辑好，还得去挑时间，最后还得比业务更懂业务。
03  如何快速把控项目架构？

王晓波：对于一个新的项目来说，对系统架构设计能力的挑战分为两种情况。一种是全新的、从零开始的项目。这样的项目因为是从零开始的，需要按部就班的去做。更难的点就是接手了一个完全陌生领域的业务系统，在这种情况下挑战很大。
大部分的架构师在实际工作当中更容易碰到这样的问题，比如接手了一个前辈的系统，看完第一遍系统架构或者代码的时候心里有“动物”在奔跑。
面对这样的情况，他第一时间想到的事就是把整个系统的边际和现在的系统逻辑过程看完，然后把业务梳理完，最后自己把这样的业务和技术重新地、完整地设计出一个新的架构，完全全新，基于他自己思想。
这个全新的架构一定先放在心里，因为在新接手项目之后的架构，从你认为的乱码发展到你认为的好，这是一个时间的过程，这件事情其实要是通过时间、通过步骤到达最好的状态。这个状态如果是一步到位的话，当然不是说百分之百会失败，但这种情况很容易会翻船。
因为从你心中最理想的那个好到现实的差，其实它的距离感不仅来自于技术的好坏，还有来自于对业务的理解，以及你对团队的理解，包括来自于你对时间和商业成本的考虑。所以我会自己设计一个全新的架构，但我把它放在心里，不停地用每一步的目标对标我这个心里的最好。
那么什么才是最好呢？要随着时间的发展去看，前提条件是第一次要让这个系统能够可用，并且达到商业目标，这是最快要做的，剩下的事情就是心中的理想。
马文霜：接手一个新项目之后，最先要做的事去找优秀的人加入自己的团队。毕竟任何一个架构的落地，实际上还是要有相应的程序员去落地。
任何一个架构首先都要简单可控，如果一个同学跟我说做这个架构可能要花至少1年时间，比如要花一到两个季度调研某个技术，然后再花半年时间去做相应的落地，在我看来是不可行的。
我认为应该有一种快速的、成熟的架构，去快速地试错，然后先把这个原型搭出来。看看这个是不是用户要的，高可用、高并发、高性能，哪个方面更重要，就投入相应的资源在上面去做相应的演进。
王超：如果我接手一个全新的项目，首先会摸清现有系统的情况，先把整个代码的关键逻辑和分层结构列出来、画出来，弄清楚有哪些模块，模块之间是怎么通讯的，中间件都有哪些，三方服务有哪些等等。之后再去分析风险点，把风险点、呈现的问题和故障列出来，再去设计合理方案。
千万不要拿到一个通用解决方案马上就去实施，要去分析自己的业务情况，是不是真的需要高并发、需要低延迟。
比如，传统互联网、电商，因为纯线上操作成本低，同一时间会产生大量的请求，这种业务对并发、流控的要求就非常高。你的架构设计要考虑怎么用队列解偶、怎么熔断。
而产业互联网线下和线上的动作是联动的，所有的请求动作都伴随着线下物理动作发生，所以并发请求就不会太大，就没必要去追求几十万 QPS 的容量。
但 Latency 比较重要，以贝壳业务举例，因为房地产交易有超长链路，完成一条链路可能经过三四百个服务，每个 Latency 都很高的话，请求短时间回不来，体验就会很差。所以，要考虑怎么缩短、合并链路，怎么做缓存。
另外，这种业务特点，问题的定位和追溯是比较难的。经常出现一个问题，搞不清楚到底是哪一个服务或者哪几个服务的问题，整个排查定位成本就非常高。一个问题往往好几个团队都在查，就是组织的惊群问题。
那么怎么快速地定位，一是要对一个请求、一条数据生命周期进行 Trace 管理。二是要对平台发布、网络环境、中间件等配置的变更做感知。三是要用到一些数据分析和 AI 辅助定位。
架构师首先要了解系统现状、业务现状、团队能力现状，再因地制宜。要基于你现在的系统情况、业务情况以及团队的组织情况去思考真正的架构，最终才会出现刚才晓波老师说的脑子里面的画面，做出长期规划，按照演进路径过渡到那个画面 。
04  如何综合提升架构能力？

马文霜：我团队里的成员也问过类似的问题，就是该如何去提升架构能力。我认为比较有效的途径就是去做不同类型的项目，多去解决业务问题，解决业务难题，相当于更多地去练。
但是可能有人会说：我在这个团队当中完成自己的本职工作都显得没有余力了，不太有机会能参与到其它的项目里面，很多互联网的技术我也接触不到，成长很慢怎么办？
对此，首先肯定是要去看一些关于架构的技术书籍，或者是在云+社区看各位老师的架构分享直播，学习一下高可用架构的思路和方法论。但从这上面只能学习到了理论基础，更多更重要的其实还是要自己去实践，去练。
比如高可用的架构、高扩展性，系统的扩展性怎么去做？是不是可以在腾讯云上面买一个负载计算器，去挂逻辑服务器，自己搭建一个简单的、具有横向扩展能力的系统。
其实虽然没有机会去参与项目，但还是要通过自己去搭建环境、自己去做业务、自己去模拟真实的业务场景，然后去练手。
比如要做模块解耦，那么可以去搭建一个 Kafka 用起来，这些其实都非常简单，尤其是现在云的环境上面非常简单，关键是我们自己要动手去练和实操。
王超：我刚开始接触技术的时候，大家都不知道什么才是技术架构师，随着技术的演变，我自己也做了一些总结。首先我建议工程师和架构师要主动多去承担和解决一些横向的技术问题，跳出自己的技术边界，去思考和触及，多去推动一些横向的事情，逐步就会有更多的机会。另外就是要有开放的心态，无论什么样的新技术，可能现在不够成熟，还是在概念期或者 POC 阶段，其实都是可以去关注的，不要去排斥，同时要去学习。当然因为现在技术发展很快、方向很多，每个方向都学得很深也很难。

所以重要在于找到适合自己的，跟你现在这个领域有结合、有发展，自己又有兴趣去做的，再深入进去。可以找对应优秀的开源项目看代码，理解它是怎么设计的。因为架构无处不在，代码里面其实也包含了很多优秀的架构设计思路，所以要去深入理解。
以马老师熟悉的 linux 为例，发展了那么多年到现在架构的精髓依然被应用在非常多的地方，底层核心的东西是不太会变的，一定要去深入理解。
最后一点，当你自己有了一定的沉淀、积累和产品之后，要把这个东西尝试着去开源，放到网上让更多的人使用、验证、给你反馈。这个反馈非常重要，总是闭门造车、没有反馈的话架构能力很难提升。
马文霜：主动的同学一定是有目标的，知道自己要什么，要去做高可用的架构的时候知道自己缺什么，然后会给自己设定目标，比如这个月我就去做状态服务器的设计，下个月就去做可扩展性的设计，什么时间点要完成什么样的目标，主动性真的是特别重要。
王晓波：程序员和架构师虽然是两个名词，但我认为，代码才是正道。架构师只是一个过渡阶段的某种时期的词语，就是程序员当中的一个片段。其实本质上每个人都是技术世界分工的一部分，不管是程序员还是架构师，或者是测试和运维，本质上来说都是程序员，因为我们都在为代码工作，我们的工作内容都是代码。
想要成为一个优秀的架构师首先要定义的是自己想成为一个什么样的架构师，这件事在整个成长的过程当中非常重要。如果目标是像马老师这样对 Linux 非常了解，那就需要未来掌控整个存储技术。
架构的意义在于我们怎么去理解技术的原理，真正深入计算机原理，计算机是什么，存储是什么，为什么今天这样的东西存在，然后去想像这件事情，不停地在这里探索一系列的东西。
如果目标是像王超老师这样去做商业的决策，去解决产业链的问题，除了去了解技术的原理之外，可能也要加上一些商业原理。因为这件事情本质上是在做商业操作系统，所以深入了解可能也不太一样。
我和王超老师的成长经历很相似，刚开始都是做技术架构，然后又转到应用架构。在这个过程中我们都会碰到一个问题：技术怎么会越做越宽？我的优势点好像由某个点变成了一个面。
其实我想说的是整个过程可能也是程序员到优秀架构师的转换过程，应用架构师应该把面拓宽，因为架构师和程序员的本质差别在于全局思维的不一样，如果只是写一行代码完成一个功能，思维会停留在这样的一个角落。
但如果要从架构师出发其实需要升得更高，就是从全局的角度去看待整个项目、整个系统，整个要完成的任务的边界在哪里，难度在哪里，解耦部分在哪里，才可以把这个架构设计好。
另外，如果我们只是一味站在这个高度去看，没有深入直接地去做技术的话，其实就会变成技术型产品经理，能够设计很好的产品，但需要找一位兄弟帮我变现。
所以架构师一定要自己去做很多的技术，而且有自己实现技术的能力。技术的东西太多了，展开面的同时要去把点突破，然后深入某些点去做某些点的深入，有点有面之后，这样的一个架构师一定是优秀的架构师。
那么什么是点和面的架构师的区别呢？有位同学曾碰到过一个奇怪的现象，就是跑着跑着突然自己的进程不见了，这对于上面的业务来说是瘫痪级了，起来了又不见了，这是很恐怖的。
架构师可能会先看应用有没有自己的 BUG，因为是突然就不见了。要是知识面更拓宽一点的同学就会说我们把 DB 的代码看一下，是不是 DB的 Bug 造成的。最后发现也不是，那就试试重启大法。正在苦恼的时候，他遇到了一位老前辈，提醒他去看看内核，是不是这个版本的内核有问题，终于解决了问题。
如果在设计架构中，知识面不全，站的高度不够，深度也不够的话，设计出来的技术架构永远是留在 PPT 里的架构。技术发展到今天，架构的基础技术百花齐放，但架构的本质意义上还是在于整个技术面、技术深度这两方面，一个宽度一个垂直，两个方向真正的掌握了，这样才能得到更好的结果，这也是高可用或者架构设计最核心的部分。
马文霜：我非常认同一句话“架构能力就是解决问题的能力”。我认为优秀的同学一定有一种特质，就是对技术有好奇心，遇到一个问题会非常兴奋，去思考这个到底是怎么产生的，该如何解决，有哪些解决方案。
这也是问题驱动，无论是老板分派的问题还是看到别人正在解决什么问题，都会提起兴趣，也有迫切把它解决掉的态度。这是可以驱动能力更好发展的。
王超：技术是一个领域，程序员是一个职业，架构是一个能力，是这样的三个层次。架构是可以穿越很多职能的，比如写代码，代码关注扩展性和鲁棒性，会有插件设计等。系统有架构、还有产品架构、组织架构、商业架构，可谓无处不在。
技术出身一个非常大的受益之处就是从一开始就在锻炼这种思维，既是一种思维也是一种能力，这种能力会随着时间不断成长，无论做什么都要有这种架构的思维和能力，这种就是可迁移能力。
大家一定要去长期培养和珍惜架构的思维和能力，既有深度又有广度，过程当中一定会带来新的认知，新的成长倒逼能力的提升，形成这种良性的循环。

05  Q&A

Q：monodb的那个问题，你们除了在翻看内核找问题的同时系统频繁瘫痪，你们怎么做的？王晓波：因为系统频繁瘫痪，那个时候又没法快速地解决这个问题，业务还是要保证的。因为我负责的是整个技术架构，包括运维团队都是归属于技术架构，发生故障后我们当时首先做的是去止损。为什么要先做止损呢？理论上来说除了常规的看流量有没有增加，有没有发生变更，除此之外就是发生了一件未知现象，所以首先需要止损降级。
如果是故障的一刹那来做这件事是很难的，这件事一定要做在之前。也就是在故障之前要对整个系统有了解。架构师和运维要了解每一个使用的东西在什么场景出现，在什么场景不可用。
当时我们就是决定把相关业务降级，对于商业来说，这个时候的损失是最小的。降级之后的第二件事情就是快速地去解决它。
总结下来在这样的情况下，事前准备非常重要，作为基础架构和基础运维团队，最重要的就是对自己的业务充分了解，每个可疑的点上去把应变方案、相应的降级方案做起来，然后演练这些东西也要做起来。
Q：请教老师，云环境的负载均衡高可用是如何保障的？马文霜：虽然我不是做负载均衡的，但是稍微有些了解，可以把我的了解和这位同学分享一下。
针对外网的负载均衡，会有一个 BGP 的调度，这是端到端可用性保证。比如现在你的负载均衡器是放在上海，假如现在你是从广州访问上海，就是走最近的 BGP 的链路访问上海。假如广州到上海的链路断掉了，腾讯云会做 BGP 路由的发布，把这个 BGP 的路由发布到北京，广州去访问上海的负载均衡的时候会绕到北京，然后去访问到你的负载均衡，这个时候延迟会略有增加，但至少在我们的链路断掉的情况下会有一个可用性的保障。
负载均衡器是在我们的云机房的网关的出口，以集群的方式去提供服务的，一般都是有好几台，现在腾讯云的负载均衡还具备迁移的能力，某一个集群因为一些机器有些故障或隐患，比如内存有些隐患，这个时候我们会把负载均衡器从一个集群迁移到另外一个集群。迁移的过程当中对外的业务是完全不感知的，这样的话可以保证负载均衡器的高可用。
Q：从哪里能够学习到真正的架构技术？王超：现阶段学习架构其实已经比十几年前容易太多了，像腾讯云+社区都提供了非常多的资料、文章和课程供大家学习，而且这些课程都是成体系化地梳理出来传授给大家。
二十年前大家基本上没有什么信息，能够做的学习架构就是看开源代码，甚至开源项目都很少。所以早期的架构经验都是从 Linux 内核中学到的。
现在学习门槛已经非常低了，有很多描述原理的书，要能够深入到代码逻辑，比如分布式系统的选举策略，为什么用这种选举策略，数据一致性策略，强一致或弱一致性的实现，数据同步怎么实现等等，要深入到这种程度。
Q：系统出故障了，怎么快速定位问题？王超：怎么才能快速定位，要训练这种能力。比如进程被杀掉了，通过coredump、source mapping，可以很容易定位到哪一行代码，这是作为优秀工程师最基本的一个能力。
Q：楼盘字典中包含个人住址信息， 如何防止被***？王超：防***的方法差不多，要对数据脱敏，个人和住址也要分开存放，用的时候拿到密钥再去组织，密钥也要动态更新，单独被读取只能是一个无法识别的数据片段。
Q：架构演进的未来是什么？10年后会和现在有什么不同吗？王晓波：这个提问正好和我们的主题倒过来的，我们讲的是架构演进史，我们是站在今天总结过去。其实从本质上来说我们也不知道，因为还没有到时间，十年之后我们再来开一次会议，在那个点总结这个事情。
本质上来讲，架构的演进这件事情一定不会停止，但是会发展到哪里确实很难预料得到，不过未来十年的架构原理一定不会变化。
未来十年架构长什么样我们很难估计，但这十年当中的架构思路一定不会变化，就是基于更多的计算机的技术，了解更多的技术，然后对技术更加深入，用更新更深入的技术去反思今天的架构，让它发展到下一代，更多地用技术去考虑商业，更多地考虑业务逻辑，然后用技术的方式去解决它，这件事情肯定是不会变的。
Q：任务急，时间短，怎么做架构？王晓波：刚才我们在讲的过程当中也有讲到，架构设计一定是天时地利人和，也就是整个背景都很重要。比如老板觉得不应该花太长时间，因为需要解决商业的问题，直接给我怼代码，那这个时候架构师怎么办？
刚开始我自己在做架构师的时候其实对这件事情非常反感，因为我觉得任何一个技术，任何一个系统都应该好好设计，然后再去动手。
随着时间的推移，我发现这件事情真的要重新考虑一下。因为对于商业来说，明天就是商业最后期限，如果明天不去抢占这个市场，可能这件事情就不用做了。好好做架构这件事情应该是认真对技术负责，认真观察商业，然后确定商业的逻辑。
那么是不是我们应该去赶一下时间？还是去赶一下技术？当然，在这种情况下你自己的判断不一定是正确的，毕竟是一个技术人员，最强的一项就是技术，可能你的老板是一个商人，可能他对商业的敏感度更大一点，这件事情应该去听老板的，但也并不代表我们真的是要直接去怼代码，符合条件的基础上我们对这些东西之后的技术债要记下来，然后在后面把它还掉，可能这就是一个相对来说比较可以接受的结果。
毕竟技术人员在这件事情上永远是矛盾，就是当时间和技术发生冲突的时候选择哪一个，但是从更成熟的考虑来说，对于商业思路的服从可能需要更大一点，因为能够真正解决生存的问题，因为代码本身不印钱，但是解决生存的问题之后一定要把这个技术债还掉。
Q：架构师都需要什么技术素养？马文霜：我觉得架构师首先应该是一个程序员，这个大家应该都认同。不是说做架构师只会做架构不会写代码，架构师应该都是从程序员成长起来的，或者团队已经没有人了，现在架构要落地的时候你能上。
我觉得要先能写代码，整个技术栈从底层到上层，比如底层操作系统的原理、内核、实现，然后再到上层的网络，数据库的设计、数据库的优化，应该说我们做程序员的过程当中都会涉及到的。
再往上就是一些分布式、大数据的系统，网络通信的框架，加上 RPC 的框架，其实都是非常有必要去掌握的，还有消息中间件等。
另外，现在比较流行的云原生和容器技术，这些都是需要去掌握的。架构师主要的能力是在解决问题，当你的团队遇到问题的时候，无论是技术问题还是业务问题，或者是其它的一些团队的合作相关的问题，架构师都应该能够上，冲在前面。
技术上面能够有点子出来，打开团队思路，能够让团队去尝试解决问题，我觉得这是架构师技术的素养。
Q：自己搭的系统，没用户怎么暴露问题？马文霜：先前我建议同学自己去搭系统，自己去练手，没有用户的话你就做你系统的用户，可以做很多的机器人测试客户端出来，往你的系统发请求，这些都是可以的。
我们都有很多的测试工具可以用起来，跟真实系统还是有差别的。但是这给你系统带来的流量压力，测试你系统的可用性，这些都是可以的。
Q：想要成为架构师应该着重培养形成哪些竞争力？马文霜：这里我从另外一个角度去说，前面说了架构师技术的素养，解决问题的能力，我觉得另外一个角度的话就是架构师不是一个人在战斗，而是带着一群人在解决某一个业务的问题。
这个过程当中需要让你的团队有战斗力，这是你的竞争力。带领团队解决业务问题，对外的话你怎么说服你的兄弟团队接受你的方案，怎么去说服老板去给你投相应的资源，让你完成这个项目，其实这些都是一些软实力，我觉得也都非常重要。
Q：三位老师还招人吗？ 王超：期待行业技术伙伴们的加入，一起为新居住产业贡献力量。欢迎投放简历 surr@ke.com
王晓波：我们常年在招各路优秀的程序员，就是广义的程序员，架构师、运维、测试，包括产品经理全部在招。