豆瓣的基础架构

　　在豆瓣，不管是做产物照旧做平台的工程师，手艺实力都比力强，一个项目应该从哪个部门提倡，并不是看这个使命的难度，而是看它是公共的照旧营业特有的。有些项目纵然未来可能会成为公共的，但一最先只是一个产物线需要，那么它也会从产物线提倡。好比豆瓣的短信服务，最最先是产物线有需求，以是这些服务都是由他们提倡完成的，平台这边主要卖力提供建设服务的架构，好比DoubanService，告诉他们一个服务怎样去写、怎样去部署、怎样去对用户开放。短信服务厥后成为许多产物线都在使用的服务，同时这个系统自己也越来越成熟，那么它逐渐就被转移到SA团队来举行维护。

　　焦点系统组做过的项目，包罗适才提到的DPark、BeansDB，另有MooseFS这些二次开发的，另有搜索服务、信息推送的长毗连服务等，大巨细小差不多有十几个。有些项目处于维护状态，以是需要的人不是那么多。

　　跟豆瓣其他工程团队一样，平台部也强制各人做code review。这对于焦点系统来说很主要的一点在于，code review是一个知识共享的历程：我们人少项目多，以是许多项目都是一小我私家做主力，很容易就酿成其他人不知道你这个项目详细是什么情形，而强制code review就可以实现一种公然透明的状态，让各人都相识每个项目在做什么。

　　在平台部，由于你做的所有工具都市影响到全公司，测试显然很主要，我们还做了另一件事来举行质量保证，那就是一个项目由谁来主导上线，谁就要卖力这个项目的故障响应——所有运维、调整系统等SA的事情，你这个第一卖力人都要到场。你做的工具的优劣会影响到自己晚上能不能睡好觉，以是各人就会比力审慎。灰度上线也是我们这边的通用做法。

　　平台部另有一点跟产物线纷歧样的是，平台部没有产物司理，以是你的事情偏向更多是自己去找的，每小我私家自己发现问题的能力更主要。我们每个月都市问各人，你这个月想要解决什么问题？若是偏向各人一致认可，那就去做。

　　最后，对于新手艺的引入上，豆瓣整体是比力偏激进的，我们勉励各人去看看新的手艺。固然我们也不会看到新的就上，这内里有一些限制：一个是比力主要的服务若是要上新的手艺，一定要有乐成案例，且乐成案例有跟我们量级差不多的规模，这样可以降低风险；另一个是对于引入的新手艺一定要吃透——大部门引入的手艺一定是要做二次开发的，以是拿进来的手艺你必须保证能完全明白它的代码结构，出了问题能修，能去掉自己无法掌控的工具。这也是为什么豆瓣不太可能在主要的地方引入Java的缘故原由，除非别无选择，我们一样平常都是Python、C和Go。

 2/2   首页 上一页 1 2