2016年9月22日-23日，由CSDN重磅打造的将在杭州举行。大会前夕，百度网页搜索架构部架构师郑然接受了CSDN专访，谈及了对架构的理解、SOFA（Service Oriented Flyweight Architecture）的前世今生，以及技术人提升之道。
百度网页搜索架构部架构师 郑然
嘉宾介绍：
郑然于2009年加入百度网页搜索部，在百度网页搜索部工作的7年时间里，一直从事百度搜索引擎的架构研发工作，先后负责过百度搜索引擎的大规模索引构建工作，大数据离线平台架构工作。近几年来一直从事着大规模服务治理相关工作，包括支撑大规模服务变更的PaaS系统，保障百度搜索引擎99。995%可靠性的高可用架构和中间件，以及百度搜索引擎容量规划和评估等。
专访正文
CSDN：请先和大家介绍下您和目前所从事的工作，以及关注哪些技术领域？
郑然：我自从2009年加入百度以来，一直在网页搜索部从事搜索引擎架构相关的工作。 从最开始的大规模分布式索引建库系统到离线泛建库大数据分析架构相关的工作。近几年一直从事大规模服务治理技术的研发工作，设计并实施了轻量级的接口化和组件化的微服务开发平台SOFA；带领团队对支撑百度搜索引擎海量服务部署和变更的PaaS平台——Eden进行了一系列重构和优化（日前在业内技术大会上分享过Eden，Slides参见：）；现阶段，我们把服务治理拆分成效率提升，高可用架构和容量优化三个大方向，系统化的解决服务治理面临的问题，构建搜索引擎的私有云平台。
我个人对于高可用架构、云计算、容器和微服务、服务治理、DevOps等技术领域非常感兴趣，也希望和大家进一步交流。
CSDN：：作为一名资深架构师，能否谈下您对架构的理解？
郑然：这个问题有点大，我理解架构的本质是为了业务服务的，解决不了业务问题的架构毫无用处。但是往往业务问题是复杂的，同时已有架构和系统都会或多或少的存在技术债务（我猜大多数情况下技术债务还不少）。所以我觉得对于一个架构师来说，选择正确的时间，使用正确的技术，选择解决哪些问题，最终能给业务带来什么价值，是需要经过深思熟虑的。一方面要能满足业务需求，解决业务问题，另一方面又要偿还技术债务，让系统向着理想目标前进，这其实需要很多折中和权衡，即使在架构设计过程中也往往是一个折中的过程。不过恰巧是这一点，让我觉得这正是吸引我一直从事架构相关工作的原因。
CSDN：有人觉得架构师是个很高大上的职业，您觉得作为一名架构师，需要具备哪些能力？
郑然：我一直工作在一线，从“硬件”和“软件”两方面谈：
架构的设计要求具备很强的抽象能力。对于复杂系统，大到能设计整体架构，对于核心技术做出正确的技术选型和技术判断，小到能清楚的知道API的接口设计和实现逻辑，做到当团队只有一个人的时候，也能开发出来，区别就是时间长短而已。这要求架构师具备丰富的技术储备，需要在工作过程中不断总结和归纳，同时开阔技术视野，取长补短。这些都需要时间的积累，不是一日之功， 没有捷径可走。
CSDN：您在百度网页搜索部工作了7年，能够分享下近年来百度搜索引擎的挑战？
郑然：百度搜索引擎其实一直在不断更新，只不过可能每天只提升一点点，影响一小部分query，大家感受不那么明显，是一个从量变到质变的过程。百度一直以“让人们最平等便捷的获取信息，找到所求”为使命，随着移动互联网的发展以及信息量的不断膨胀，用户找到信息的难度更大了。所以从2016年开始百度正在从多个维度全面打造“新搜索”，让搜索结果多样化全方位的满足用户请求，同时不断完善内容生态，促进优质内容在百度全平台的承载。这就意味着百度搜索引擎的算法复杂度和数据计算存储量的大幅提升，给搜索引擎的算法和架构带来了巨大的挑战。
CSDN：这次在SDCC 2016（杭州）架构峰会上，您主要分享SOFA（Service Oriented Flyweight Architecture）这一轻量级的面向服务的开发框架，可否介绍下SOFA的前世今生？
郑然：先澄清一下， sofa-pbrpc和我要分享的SOFA是完全不同的。以我们的反作弊服务为例，反作弊服务需要根据网页的HTML计算和解析出上千个特征，然后在经过几百个策略，最后得出反作弊的结果。这上千个特征存在错综复杂的依赖关系，策略与策略之间也存在着严格的顺序要求。随着算法的越发复杂，有些特征或者策略的计算需要消耗的资源会越来越大， 这时候大家想到的办法一定是对服务进行拆分了。如果没有SOFA，这样的拆分过程相当于做一次重构的工作量，而且对反作弊效果来说是没有正向收益的，做算法的同学最不愿意做这种事情。所以能否灵活的进行拆分，就是提升研发效果的关键了。使用SOFA技术以后，修改几行配置就可以实现拆分了；另外反作弊服务中有些特征和策略的计算逻辑，可能其他服务或者产品线也同样需求，比如切词，提取title、content、anchor等，那么如果能非常方便的实现代码共享，也势必大幅提升研发效率。所以在这种情形下，我们设计和实现了SOFA这一接口化和组件化的开发平台。
在2013年SOFA完成的第一个版本中，我们已经实现了RPC的功能并且性能十分优异，考虑到当时距离SOFA成型还有相对较长的时间，同时部门内一些偏向基础架构的系统（比如百度开源的tera分布式表格系统）仅仅有RPC的需求，所以我们把SOFA中RPC的代码剥离出来，适配了protobuf，于是乎就有了sofa-pbrpc这个项目了。
可以说RPC只是SOFA的冰山一角， 我希望通过本次SDCC的分享，给大家揭秘整个SOFA平台。不过由于SOFA依赖了一些公司的库以及人力问题，还没有开源出来，但是我个人认为整个SOFA的设计思想还是非常先进的，所以决定在本次SDCC上为大家介绍SOFA，希望能给大家带来一点点启发。
CSDN：SOFA目前有哪些最佳实践？
**郑然：**SOFA自身具备接口化和RPC的能力，所以适用于所有应用RPC的场合。同时得益于SOFA接口化和组件化的设计思想，更适合于构建带有复杂业务逻辑的服务模块。不知道大家有没有遇到过这样的场景，比如我想使用切词功能，于是我从公司的代码库中反复搜索，终于找到了代码路径。Checkout下来之后，首先阅读头文件，看过复杂的结构体声明和函数定义以后，准备写一个demo程序做实验。代码写完编译好之后，发现缺少切词词典，于是乎从公司的wiki上反复搜索，终于找到对应的接口RD，我们从一个FTP地址下载了切词词典。然后运行demo，词典加载失败，联系接口RD发现词典版本和代码版本不匹配，于是重新下载对应版本的切词词典，终于demo运行通过了。下一步当然是把切词的逻辑添加到线上的模块了。代码写完并且添加好编译依赖之后，发现编译不通过，原来切词库依赖的一个库和当前模块冲突了，打平之后发现当前开发的模块又编译不通过了……这时候如果运气好的话，经过反复实验，可以找到一个编译通过的版本; 运气不好的话，那只能修改相应的代码了，真是一如好闷深似海啊! 烧香拜佛之后，终于编译通过了，运行之后程序如果core了，这还算好的，如果运行之后得出的结果不对， 那才叫一个叫天天不应叫地地不灵呢。
遗憾的是，我们的搜索服务中存在很多这样的模块。我们的反作弊服务和页面解析服务都是包含复杂的特征提取和算法模块，这些模块随着算法复杂度的提升，需要的CPU和内存会不断提升。如果说编译依赖冲突的问题还可以通过一些艰苦卓绝的工作解决，那么资源需求达到一定程度之后，就必须进行服务拆分了。没有使用SOFA之前，这样的拆分是非常复杂的，不仅仅研发周期长，对服务的效果又起不到提升的作用研发过程需要反复的测试功能和效果的评估，给算法的研发同学带来的极大的痛苦。SOFA的接口化和组件化的设计思想，可以大大简化上述过程。组件的符号隔离机制，确保组件之间不同版本的库并存; 接口化和组件化的能力使得我们仅仅通过修改配置，就可以完成服务拆分工作; 而且不同的组件可以采用不同的编程语言， 进一步加速组件的研发效率。SOFA上线以后， 先后支持了公司包括网页搜索，自然语言处理，深度学习研究院，机器翻译等十几个的产品线，构建了上百个服务，使用SOFA的研发人员接近200人。
CSDN：微服务目前受到广大互联网公司的热捧，您如何评价这一现象？
郑然：可能很多朋友看到微服务带来的可扩展、松耦合、研发和迭代效率提升等优点， 都有蠢蠢欲动的感觉。微服务背后隐藏着一座冰山，我们看到的往往是浮出水面的华丽的部分，而水下作为微服务的底座，需要包含日志的汇总和分析、服务注册和发现、部署和升级、资源管理、CI/CD流水线、服务依赖关系管理、调用链跟踪框架、灰度发布、蓝绿部署、容量评估和规划等技术，如果公司对这些基础设施缺乏积累，那么引入微服务架构我觉得会是一场噩梦。当然这些基础设施的发展也很迅速，开源社区也非常活跃，大大降低了建设这些基础设施的门槛。
CSDN：您作为技术人员，擅长太多，包括：流式索引构建系统&离线计算平台架构&PaaS&服务治理&高可用架构&DevOps等，可否分享下您学习新知识或技能的方法？以及在日常生活中你是通过哪些方式来提升个人技能的？
郑然：对于我来说，我特别享受学习的过程。我一直坚持每天7:30到公司，吃过早饭之后读一个小时的早报。早报的内容大部分是来自各个微信公众号和自媒体，把其中认为好的文章记录下来，这样组织了一个《分布式技术一周技术动态》的小专栏，每周为大家推送。 这个小专栏持续了一年半了，总共推送了上千篇技术文章，我个人的知识面也得到了很大的扩展。我也一直坚持组织团队和部门的技术分享会，我一个人的力量毕竟是有限的，我希望所有人都养成学习的习惯，当然我也可以从大家的分享中更快速的获取知识。
不过如果需要系统的学习，还是需要看书的，公司提供了图书馆制度，每个人每个季度都有一定的额度购买图书。
我的日常工作主要包括系统设计方案评审，项目过程中疑难问题的解决，需求和方案的讨论， code review。我喜欢编码，如果一段时间不写代码，就感觉心里不踏实，我的代码量在部门内排名还是比较靠前的。除此之外，我还需要给自己预留学习和思考的时间，这里的学习不是像读早报那样泛泛的学习，需要一定的系统学习，比如读一本书，学习一个开源或者公司内部的系统，学习设计方案等。思考的时间也特别重要，我需要保证我做出的技术决策大部分是对的，我需要保证整体技术方向不会出现偏差，我需要保证每个同学都有足够的成长空间， 这些都需要深入思考。
