架构师接龙:百度架构师侯震宇VS. 百姓网技术总监潘晓良

主持人:冯大辉,现任丁香园 (http://www.dxy.cn)网站CTO。曾历任支付宝架构师、数据库团队负责人等职。

 

侯震宇:在编程模型上,您认为如何能够更好地利用多核以及多机环境?

 

潘晓良:我是把它分成两个问题来看的:一个是多核问题,另一个是多机问题。

 

对于多核问题,我是一个实用主义者,真的不想在上面有所投入。我把多核环境认为是操作系统应该完成的事情,相信微软和Linux的那些内核朋友们都 在为此而努力,因为他们是专家。但看着几个核的资源分布严重不均,一颗累死,十一颗闲死,资源实在太浪费了,怎么办?让系统工程师来搞定吧,就是多跑几个 进程,最简单的例子就是一个机器上起多个Memcached、多个Search、多个MySQL,既然操作系统无法把一个进程很好地分到多个核上去,那么 我们就用人为的方式来做一些,这虽然不能彻底解决多核效率的问题,但是至少缓解了一点。而且据我所知,很多公司都是这么做的。

 

对于多机环境,按我的理解,问题只有一个,就是数据访问必须是共享的,对于一个Pool中的Web服务器,它不能使用Session,也不能把数据 放到本地文件中,因为不知道下一次访问会不会命中自己,包括本地缓存,随着Pool中服务器数量的增加,命中率随之下降。虽然以上的问题可以通过负载均衡 的固定Session方式或者URL映射的方式来做,但是它可能造成服务器的压力分配不均,后面带来的问题可能更多。所以我们的方式就是禁止直接使用 Session等本地资源,使用上面一层的虚拟对象,由虚拟对象来控制数据访问,而使用共享的Cache来实现Session的基本功能。

 
 

侯震宇:在纯代码层面上,您的团队是否有规范以确保大范围的代码组织结构是统一的。比如有项目的lib、include目录和基础库等。你们是否实现了一个统一的编码编译环境?有什么困难?

 

潘晓良:对于百姓网来说,因为我们只有一个产品,基本上还没有多项目的问题,但是我想这个问题的关键还是在编码规范上,在于代码的质量和不断增长的代码数量之间的矛盾的问题。关于这个我们做了以下几个事情。

 

由Developer们讨论出来的编码规范。规范的事情是这么写也对,那么写也对,但就是要争取大多数一致,所以我们的规范是Developer们一起讨论出来的。

 

标明代码责任人。以前我们的代码是按照模块划分的,但是人会换模块,后来就会多出来很多无主代码,这些无人维护的代码,不仅容易出现Bug,而且增加了阅读成本,所以必须清理掉。

 

每日上线的时候把每个人的代码数量统计发出来。我们认为代码的少就是多,每个人有责任控制自己代码的数量,是多是少大家都要看见。

 

每周固定时间Pair Programming。代码质量的重要性大家都知道,但是给予的时间却不多,我们有固定时间段用于Pair,一来可以加强开发人员沟通,二来可以提高代码质量。

 

给实习生一个平台。实习生很有Passion,而且有很多自己的想法和独特的视角,其实他们在学校里面学了很多东西,只是缺乏应用,我们的实习生可以访问所有代码、修改任何一行代码,只要稍加指导,他可以做任何他愿意做的功能。

 

统一的编码编译环境非常重要,必须实现。互联网软件开发依赖的环境很多,数据库、搜索、缓存、定时脚本、消息队列、Web服务器等多种服务,要是自 己搭建肯定是事倍功半,一人发几台机器都不行,不仅资源浪费,而且环境不同,也会带来很多意想不到的Bug。我们在实现了统一环境之后,每个人都只需要用 一个笔记本开发就可以了,既节省了资源,也极大地方便了Pair Programming,方便了工具的统一和思想的交流,也方便实习生的学习和融入。

 

实施统一编码环境的障碍肯定不是技术,最大的困难还是人,首先需要团队的Leader支持,其次需要有好的方法分步骤实现。开发人员都会认为自己的 习惯很好,不愿意改变,所以只能先小范围尝试,让愿意改变的一部分人先满意,培养他们的幸福感,然后他们就会去影响其他人,再来几次Pair以后,就慢慢 都被同化了。

 
 

侯震宇:在大规模机器集群上,你们如何实现程序发布上线、配置的管理以及程序和机器的监控和健康检查?

 

潘晓良:百姓网是每日发布产品的,只要是工作日就会有版本发布,但我们不是从第一天就是这样的,我们是从每周发布一次,到每周发布两次,到现在每天 发布一次的,整体来说,每天发布让我们的迭代周期缩短,加快了产品更新的速度,但是也会带来很大的问题,比如Bug增加等问题。每日上线其实对我们来说是 一个很大的挑战,有很多工作需要做。

 

自动化打包。百姓网是使用PHP开发的,可能有人说不需要Build,但是打包过程可以做很多事情,压缩、去注释、代码统计等很多工作都是在这个时候完成的。

 

自动化测试。这个过程非常关键,必须通过所有的Unit Test和重要流程的测试之后才能发布,如果出现重要流程失败,则需要找相关开发人员找到问题,然后重新打包,这是基于打包全自动、够快的前提的。

 

部署上线。那个时候就是一个按钮的工作了,当然这个时候最重要的就是确认上线中是否有问题,即使再详细的测试,也不能保证线上环境能够顺利,所以上 线之后我们就要关注关键功能是否有问题,我们有一个Rollback的标准,达到这个标准则必须Rollback,如果达不到这个标准,则直接在线上进行 Hot Fix。

 

关于配置的管理,也存在于版本控制工具中,比如叫config.online.php,在自动化打包的时候,会被命名为config.inc.php,通常情况下,线上环境配置是不需要更改的,而在配置更改的时候,只需要修改它就可以了。

 

关于程序和环境监控的问题,我们基本上采用Cacti、Nagios这样的主动和被动监控工具,但是它们都是在系统级别上,除非是程序导致系统压力 有巨大变化的状况,程序中的问题就不能被发现,所以我们还有程序级别上的监控,最主要的是监控错误日志,主要是PHP错误,如果有错误,那么开发人员很快 就能收到邮件,可以及时修复。

 
 

侯震宇:在目前国内的网络环境下,一个分布式系统是否需要考虑多机房问题?如果需要,主要考虑哪些问题?

 

潘晓良:关于多机房,我觉得完全取决于业务需求,即访问速度是否影响了业务,如果影响了,那么南北机房应该是最有效的方式,但是我觉得这里面的成本 还是很高的,一个机房变成两个机房,就如同是一台Web变成两台Web,对于系统架构的影响比较大。百姓网是经历的这样的过程的,我们考虑多机房是完全基 于业务发展的需要,不过多机房也没有那么可怕,就是要多付出一些成本。

 

硬件维护成本。通常都是异地,有人驻扎还稍好,无人驻扎,正常的机器维护都会成问题,我们的解决方案就是使用刀片服务器,虽然硬件成本上升了,但是少了人员维护成本。

 

可用性风险。我不知道有多少公司会让两个机房有相同的承载能力,能够以一个机房之力承载所有请求,因为那意味着大量冗余,所以肯定是各自承担一部分 的压力,但是宕机的风险却加倍了,而且还引入了另外一个风险,就是机房之间通信的风险,网络的延时可能会对业务造成很大影响,如何消除延时或减小网络延时 对于业务的影响就是最关键的一点。

 

开发、部署、调试的成本。代码部分会产生一些修改以支持多机房,部署的时候两边都要走,即使是自动化发布,也需要写脚本,特别是调试的时候,更加需要知道是哪个机房的问题,我们曾经遇到过只有一个机房出Bug的情况,调试的时候等于说是增加了一种因素。

 

多机房看似只是多了一个机房,但是对于运维来说,很多工作就变得复杂很多了。

 
 

侯震宇:对于机器选型问题,是为不同的大型专有系统(如分布式存储)专门配置的机器,还是统一采购同一类型的机器将不同的系统共享一个物理集群?这两种方法有什么优缺点?如何选择?

 

潘晓良:不同类型的机器的好处是度身定制,物尽其用,比如存储的机器的硬盘大,缓存的机器内存大,Web机器可能就用最小的硬盘等,虽然看起来很 美,但是不灵活、不通用,多出来的大硬盘机器,其他地方用不到,反过来小内存的机器又不能给缓存的机器用,特别是在做系统调整的时候,很多机器因为不合适 而不能用了,反而容易造成资源浪费。

 

相同型号就是完全反过来,它有明显的好处——通用,放在哪里都能用,但是问题就是可能对于某些特殊应用不是很适用,做存储的话硬盘小了点,而做Web服务器可能硬盘又大了点。

 

对于这个问题,百姓网通常还是会选择用一种型号,然后再对不同类型的服务器去升级硬盘或者内存,而CPU等核心的内容基本上一致,这样就既能保留通 用性,又有一些灵活性。不过我们还是会在一些特殊应用上采购一些特殊机器设备,比如数据仓库,它们对于容量和计算的需求就会超过正常的机器的范围,可能就 有一些特殊的要求,我觉得这里面还是一个平衡的艺术。

 

不过我们觉得这种灵活性还是相对的,因为机器的升级速度太快了,通常1~2年就有一种新升级型号,之前的内存硬盘都有可能很难买,或者价格很高,这时候就宁可选择新型号,而把旧型号放到一些非关键应用上。

 

以上是我们在使用过程中的一些感想体会,不能说放到哪里都准确,欢迎技术朋友们发邮件过来指正,我的邮箱是 panxiaoliang@baixing.com。另外,我们也非常欢迎喜欢互联网的技术人员或者同学来百姓网工作实习,我们的职位发布在 http://jobs.baixing.com/。

Leave a Reply

Your email address will not be published.