DNSPod十问58沈剑:为什么创业公司不能做"中台"？

问答时间：2020年9月3日

嘉宾简介：

沈剑：快狗打车CTO，58到家集团技术委员会主席，互联网架构技术专家，技术圈大V号“架构师之路”作者。曾任百度高级工程师，58同城技术委员会主席，高级架构师，技术学院优秀讲师。

主持人简介：

吴洪声(人称:奶罩)：腾讯云中小企业产品中心总经理，DNSPod创始人，洋葱令牌创始人，网络安全专家，域名及DNS技术专家，知名个人站长，中欧国际工商学院校友。

以下为对话原文整理：

第一问

吴洪声：关注你的公众号好些年了，今年又关注了你的视频号。无论是文章还是视频号，而且我看你公众号更文频率也很高，感觉做这些内容挺费时间的，在内容创作与工作时间的平衡，你怎么解决的呢？对于刚工作不久的技术人员来说，最值得去提升的核心能力是什么呢？

沈剑：一天工作10小时，还有14个小时能干其他事情，有人爱好健身，有人爱好学英语，有人爱好打游戏，有人爱好追剧。无所谓创作与工作时间的平衡，我在另外14个小时里干了自己喜欢的事情，仅此而已。

对于技术人员来说，必须要在前3-5年内形成自己的核心竞争力，刚工作不久，不用想太多，掌握工作需要的硬核技术：编程语言，编程工具，设计模式，设计方法等等等等…

第二问

吴洪声：作为一名优秀的架构师、管理者，同时也是一个在科技领域拥有百万粉丝，经营公众号6年之久的成功博主。看到你在很多平台分享了自己的技术经验、管理经验，在这里能谈谈你多年来积累的运营经验吗？要成为一个资深的架构师，都需要经历哪些职业深坑和盲区？

沈剑：写文章，自己本身不太会运营，能有不少粉丝喜欢，我的经验是两点：

（1）坚持

（2）原创有价值的技术文章

成为一名资深的架构师，我的经历，有两点非常重要。

第一：深入业务，任何脱离业务的架构设计都是耍流氓。

有些架构师乐于搜集各个公司的架构图，套用来解决自己公司的架构问题。殊不知，没有一成不变的架构方案，架构是针对业务的，没有一成不变的架构方案，原样照搬只能给自己埋坑。

第二：从单打独斗，到授业解惑。

作为程序员，很多时候都是在单打独斗，所做的事情的结果是可以由自己掌控的。而作为架构师的话，要和一群人一起完成一个系统架构目标，架构师可能没办法去关注所有的细节，你没办法动手去改所有人的代码，你要做的是将自己的知识体系传授给团队内的人，大家一起做出好的系统架构。

第三问

吴洪声：你之前在58，C端业务的高并发情况常见，架构师之路会很锻炼人，现在在快狗做B端业务，感觉高并发业务相对没有那么大的技术要求，你会有失落吗？或者问的狠一点，你的技能会荒废吗？

沈剑：不同的业务，特点不同，对架构的要求不同，挑战不同，架构本来就是用来解决业务问题的，不存在失落和荒废。

58是一个信息平台，业务模式主要是用户发布信息和用户查找信息，其业务模式决定了这是一个流量大、并发量大、数据量大的系统，其架构难度在于几十亿的数据量与访问量。

快狗打车是一个在线下单打车的平台，司机提供服务，用户下单，在线匹配，其业务模式决定了这是一个交易闭环的在线系统，其架构难度在于对数据的实时性、一致性要求会更高。

第四问

吴洪声：对于用户规模可能飞速增长的移动互联网应用来说，面对高可用，大容量，高并发的需求挑战特别大。这里对于企业级DNS解析服务也随之水涨船高，DNSPod作为一家十几年如一日为千万用户提供稳定解析服务的服务商，我知道到58同城也在使用我们的服务，能分享一下使用的体验吗？

沈剑：稳定性不必说。

DNSPod提供的“DNS轮询”能扩展接入层的性能，提供的“智能DNS”能让用户就近访问，有更好的体验。

第五问

吴洪声：如今面向底层DNS的劫持和攻击对整个互联网的影响越来越大，希望你能分享一下对dns安全技术，比如dnssec，doh/dot的一些看法，以及企业应该如何选用安全的dns技术？

沈剑：DNS的解析过程，发生在企业系统外部，很多适合企业都难以控制，这个过程中的安全问题，往往非常棘手。

使用DNS安全升级扩展方案，例如RFC2535中建议的安全认证机制DNSSEC，使用TLS协议加密的DoH与DoT机制，是一些很常见的玩法。

对于企业而言，使用靠谱的DNS服务，是最佳选择。

第六问

吴洪声：你在架构设计上有非常丰富的经验，设计过多款同时在线量巨大的优秀产品；有没有遇到过因为业务爆发而用户数量激增，对现有架构造成严重冲击的情况？有人认为产品初期不需要考虑太复杂的架构，而是应该快速上线持续迭代，你是如何看待架构设计与产品开发周期之间的平衡？

沈剑：架构，是为系统，为产品，为业务服务的，是解决系统，产品，业务中的问题的设计方法论。架构设计不能脱离业务，任何脱离业务的架构设计都是耍流氓：

（1）业务发展早期，对架构的需求是快速尝试，此时架构不要搞得太复杂，为了架构而架构，用成熟的技术方案快速试错，是这个阶段主要考虑的；

（2）业务快速迭代期，对架构的需求是快速迭代，此时架构上的扩展性，是这个阶段主要考虑的；

（3）业务稳定期，流量大，数据量大，对架构的需求是靠谱稳定不出问题，此时架构上的高可用高性能，是这个阶段主要考虑的；

不同的业务阶段，产品与业务的开发周期与迭代速度，对架构的要求是不同的，不可一概而论。

第七问

吴洪声：在10来年的架构师之路里，肯定发生过不少有趣的或者值得纪念分享的案例，都经历了怎样的惨痛经历？又是怎样的破解了难题？能否分享一些案例？

沈剑：快狗打车有一年的促销活动，连续三周的周六都打折，促销力度很大，流量渠道很多，给我们带来了一些技术挑战，第一轮活动上线后，系统挂了。

紧着着，我们立刻着手优化：

入口系统，技术上我们针对性做了cdn优化、缓存优化、静态化优化。

后端系统，还反复进行了压力测试，提前进行了容量规划，并进行了扩容预案，以确保大流量过来后，系统可用性不会受到影响。

当时，我们给自己定的性能指标是，必须抗住10000同时连接，每秒必须处理20000的请求。我们以这个为目标，进行压力测试，不断找到瓶颈，进行优化，继续压测，如此迭代几轮，最终达到目标。

第二轮活动，第三轮活动最终都抗住了，非常有成就感。

第八问

吴洪声：技术管理者往往都在技术一线多年，擅长解决技术问题。但是对于一些优秀的“大牛”，当上升到一定高度后，被赋予了担任战略和管理等方面的工作重任时，会陷入一种“无从着手”的状态，你不仅是一名优秀的技术专家，对于集团技术战略的制定，整体架构的管理也有着丰富经验，在这两个方面你有什么可以和大家分享的见解吗？技术出身的程序员该如何从0开始做好一个管理者？

沈剑：我认为作为团队负责人，要从不同的角度出发，思考时不同身份时自身不同的职责：

从老板的角度出发，我需要带领团队去实现用户目标和公司下达的任务；

从同事的角度出发，我需要带领团队，为队友赋能；

从下属的角度出发，帮助团队去解决当前所遇到的问题以及帮助团队成员成长和提升。

要成为一名合格的管理者，必须多考虑如何帮助团队成长和提升的，以及如何用方法论发现系统中的问题或者发现团队中的问题，帮助团队变得越来越好。

实际上，带领团队与做架构优化，有很多相似的地方。都需要找到当前最痛的问题，并解决它。带团队也是类似的思路，解决团队痛点，团队就能得到提升。

思考、改善痛点和带团队打仗一样，都需要经历现象、分析、行动、结果这 4 个过程。痛点的收集与反馈，往往是自下而上的。

因此，好的管理者，需要多和身边的同学聊聊，看看目前大家都遇到了哪些问题。从问题中找到主要矛盾，再思考它产生的原因、解决问题的方法、如何去实行，以及在实行一段时间之后是否达到了你的预期。

第九问

吴洪声：前几年中台概念炒的很热，不管大公司小公司都纷纷中台战略布局，投入中台的体系建设，业务中台，技术中台，数据中台，用户中台等等，中台概念被广泛定义。但是随着时间推移，最近又出现了很多反对中台化的声音，你是如何理解中台概念的？对于反中台化的声音你是怎么看的？

沈剑：中台有他的可取之处，他代表一种“复用”的架构理念，但并不是所有公司都适合中台。

“小前台，大中台”是很多公司为了快速落地业务，进行的组织变革与系统架构变革。中台的目的是复用：业务复用，组织复用，系统复用。

相对通用的业务，例如：用户，订单，支付，商品，营销等通用的业务模块，非常适合做中台。

初创公司，业务单一的公司，产研团队较小的公司，并不适合中台。中台战略，特别适合有一定规模，有多块业务，或者希望快速进行业务创新尝试的公司。中台战略的落地，能够最大程度的“减少重复建设轮子”。

第十问

吴洪声：今年年初互联网企业微盟上演了狗血大剧，程序员“删库跑路”，凭借一己之力令公司市值蒸发10亿，300万商铺瘫痪。经此一役，如何防止数据丢失保障数据安全更为人所关注。对此你有什么好的建议？

沈剑：保证数据的安全性是，技术侧第一要务，以下两点非常重要：

（1）全量备份，增量备份，定期恢复演练，任何不经过演练的预案都形同虚设；

（2）重要的业务，可以做一个1小时延时从库，以防线上数据误删，能够快速恢复；

第十一问

吴洪声：货运行业普遍认为，同城货运靠烧钱打出的规模化是很难与竞争对手抗衡，精耕细作必然将成为货运市场的生存法则。你作为快狗打车CTO怎么从技术层面出发，通过技术创新，来提升精细化服务？

沈剑：打车系统的核心，就是车货匹配，大数据和人工智能能够做很多工作，提升匹配率，提升完单率的。

初次之外，技术上还能做很多事情，帮助到业务的发展，例如：OCR提升司机认证效率，IVR提升客服接起率，消息通道提升订单推送到达率，算法降低用户不支付的坏账率，等等。

第十二问

吴洪声： 政府春运管理难，百姓春运抢票更难。12306这几年更是承受着这个世界上任何秒杀系统都无法超越的QPS和极限并发。即使在春运这种高并发高复杂度业务场景下，12306都能轻松应对，且服务越发流畅、快捷。你是如何看待他们的技术演进的？他们的演进过程中有哪些是值得中小企业学习的？

沈剑：同样是高并发场景，每类业务的架构挑战不一样：

QQ类业务，用户主要读写自己的数据，数据访问锁冲突较小。

微博类业务，用户的feed主页由别人发布的消息构成，数据读写有一定锁冲突。

12306类业务，并发量很高，几乎所有的读写锁冲突都集中在少量数据上，难度最大。

系统层面，12306这种秒杀类业务，优化方向有两点：

（1）将请求尽量拦截在系统上游，而不要让锁冲突落到数据库。

传统秒杀系统之所以挂，是因为请求都压到了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，访问流量大，下单成功的有效流量小。

（2）充分利用缓存。秒杀买票，这是一个典型的读多写少的业务场景：

车次查询，读，量大；

余票查询，读，量大；

下单和支付，写，量小；

一趟火车2000张票，200w个人同时来买，最多2000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9%，非常适合使用缓存来优化。

第十三问

吴洪声：在我看来，一个优秀的架构师，一定是有前瞻性的。不仅要能够以工程思维全面理解业务需求，来提出当前恰当可行的整体解决方案，方案还需要在可预见的周期内具备一定的扩展性，能保证系统后续的持续易于迭代。正如你所说的：好的架构是不断衍变而来。作为曾经搭建过千万级可用性架构的架构师，能和正在这条路上行走的后辈们分享一些你的经验和这种能力的培养方式吗？

沈剑：道的层面来说：

最好的提升架构能力的方法，就是：不断贴近业务，不断做项目，不断实践，不断解决架构中存在的问题。

架构是一项实践能力，一项解决问题的能力，不是一项ppt的能力。

深入业务，结合业务当前的发展阶段，把握当前业务痛点，用技术，用架构去解决这些问题，在这个过程中，架构能力自然而然能得到提升。

术的层面来说：

不断看代码，看资料，持续的学习。

信息传播如此发达的今天，你很容易在网络上找到相关业务/架构的专家，以及专家们写的文章，经验的积累，和他们交流，和周围的同事交流。

不要想着，一个架构方案，能够解决所有的业务问题。

虚怀若谷，持续学习，持续进步，共勉！

栏目介绍：

大家好，我是吴洪声。

不知不觉，DNSPod十问这个栏目，已经做了第十五期。本来这个栏目叫洪声十问，一期十个问题。然而细心的读者可以发现，问题逐渐变为十一问，十二问。因为在实际采访过程中我发现，十个问题的答案不足以将嘉宾思考上的高度展示给大众。

此外，这个栏目受邀嘉宾的领域也在逐渐的扩大，从域名圈，站长圈到程序员圈，创业者圈。作为有着丰富行业经验的大拿们，他们在这个栏目留下了他们的真知灼见。比如易名中国金小刚说的：“别想着持有对社会有不良影响的域名，这是一个底线。”比如CSDN创始人蒋涛说的：“对于一个技术驱动的公司而言，不断更换新人并不是好事，技术要有一个积累的过程，应该鼓励这些技术人去提升，对技术人员的回报或薪酬、等级要相应地跟管理平行。”

未来我们希望这个栏目的影响力会覆盖更加多元的受众。把更多正确的理念去对外传递。所以也欢迎各位在评论区留下你想看到我对话哪位嘉宾，还有你想问的问题，我们邀请你共同成为“吴洪声十问”栏目的提问者，发声者。（栏目统筹：赵九州责任编辑：张洁胡琼文）

SMB

腾讯云中小企业产品中心

腾讯云中小企业产品中心（简称SMB），作为腾讯云体系中唯一专业服务于8000万中小企业的业务线，致力于为中小微企业提供全面完善贴心的数字化解决方案。产品线覆盖了企业客户从创业起步期、规范治理期、规模化增长期、战略升级期等全生命周期，针对性的解决企业的信息化、数字化、智能化的生产力升级需求。本中心还拥有两大独立腾讯子品牌：DNSPod与Discuz!，在过去15年间，为超过500万企业级客户提供了强大、优质、稳定的IT服务。

SMB团队成员大多都有过创业经历，有获得过知名VC数千万投资的，有被一线互联网巨头以数千万全资收购的，也有开设数十家分公司后技术转型而失败倒闭的，我们成功过，也失败过，我们深知创办企业的难处与痛点，深刻的理解中小企业该如何敏捷起步、规范治理、规模化增长与数字化升级发展，我们会用自己踩坑的经验给出最适合你的答案。

腾讯云中小企业产品中心，助力中小企业数字化升级的好伙伴。