谈谈技术研发的简单可依赖

Uifhjvv

简单可依赖，这是百度公司的文化。

曾经遇到某个老百度人，在挖人的时候跟人讲到『我们创始人是百度老人，都是04年前后进百度的，所以公司文化和氛围上都是很简单可依赖的』。

作为一家以技术为导向的互联网公司的企业文化，简单可依赖，在我看来，最起码对于技术研发这个领域而言，还是有多借鉴和遵循的价值的。

架构的简单可依赖

- ~* ?0 g5 E; r5 k* d) I) y

有个项目，涉及数据采集传输、实时计算、批处理、还有数据存储。在接手这个项目大概一年的时候，随着团队从十几个人慢慢的流失到就剩下我自己和实习生同学做整个后端项目的研发与维护。

$ d: [+ {/ P% \( R# j0 Q/ d

原来十几个人做的东西，因为人力和人员的拆分，每个人或者每几个人负责其中的数据流向的一环或者一块，进而组合成整个完整的数据流。比如，除了采集传输之外，进入到实时计算环节，先分了两块，上游做基础的数据解包以及做简单建模，基于流式计算平台来做；下游用生产者消费者模式，基于PHP常驻进程+redis队列和ssdb存储来实现二次模型计算，模型在这里会加很多feature，然后入Elasticsearch【下称es】存储库。然后下一份数据流程，批处理，则是基于PHP定时任务，先从es里load数据到内存，然后做一系列的计算、清洗、聚合之类的工作，产出的结果存储到MySQL。读者可以自己在这里脑补一下数据流程图。

数据流程被分了三段，中间夹杂着两层存储。因为以前做存储选型的时候，技术调研不到位的问题，导致全部数据依赖的存储，选择了两个：ssdb存原始数据，es存模型数据，因为之前调研的时候得出的结论是es写入性能太低，实际上是因为只调研了最简单的单条索引的情况，并没有调研批量索引bulk的性能。

9 d& j: ^4 \- y8 F: J" b

这么长的数据链路，导致的问题是，其中每一个环节出现问题，都会导致整个数据流的中断或者延迟。由于运维的问题，经常导致PHP进程僵死，或者ssdb挂掉的情况。并且，由于整套系统中存在非常多的IO和计算瓶颈，导致整个系统资源使用率、吞吐率都不高。对接用户的时候，往往每对接一个业务线，可能需要花费至少一天的时间。

: ]; P% r* l: i! Z( Y: V2 R1 ?

听到这，你觉得，这套架构，简单吗？可依赖吗？
3 @( M* \; a+ j4 j6 ?  ]& u

1 ^: g1 y1 ?" m4 e3 {

有问题需要解决，解决要考虑现状：人少，链路长，存储多。怎么用较少的人力cover这么一大坨充满坑而且乱七八糟的项目?我们解决的方案：把所有的数据流环节，基于流式计算平台重写，重写技术之后整个计算层，只有一些流式计算平台上的算子。因为从原有的经验来看，流式计算平台上原有的算子是非常稳定的，不怎容易出问题。进而，借助于计算出重写，上面说的两层实时计算之间的redis和ssdb可以拿掉然后整个存储，就只剩下两个，一份主要存储：es，一份meta信息存储：mysql。

整体而言，重构结束之后，架构更简单清晰了，带来的好处是，更稳定了，运维代价和工作量更少了，故障率更低了。简而言之，更可靠了。

. @  y- N7 V/ r% ]1 K; q

做完这个项目有很多反思和总结，比如，不要相信某个软件的官网文档里的测试数据，很多性能数据得自己拿自己的数据模型亲自跑跑测试一下；比如，方案调研要准确负责，不然像上面说的以为es写性能不行然后选用ssdb的例子不会离你太远；比如数据流的环节尽量不要太长，如果能用一套平台一套体系搞定的事情，即便损失一点性能或者其他次要的非业务价值关注的指标和考量，尽量用一套系统搞定等等。总而言之，简单，是技术选型和方案上的简单，带来的收益，就是产出价值的可依赖，包括稳定性，可用性等指标。当然，方案简单了，无论人力成本还是硬件成本，相对也会更低。

) r0 l, i7 u6 t

选型的简单可依赖

, R: [/ b0 V9 ]; i( q  Y9 R4 r, O! I

其实这个方面，在上面的例子里面也有提及到。比如选型和调研的过程中，尽量调研准确，然后能用一种框架或存储就只用一种。但是在这里想说的是另外一个例子，可能这个例子会让你似曾相识，因为很多人都曾经这么做过。

2 t# |& s6 D$ }8 u  W, S

某个项目，内部小平台，遇到了一些稳定性问题。然后在做稳定性提升的过程中，大家想把项目用到的旧版本的PHP升级到更高的版本比如PHP7。其实说到这里，是没有问题的，大家也都同意。但是，升级尝试的过程中发现，用的某种扩展，没法适配PHP7。然后就出现了几种方案，比如，找基础架构组的人帮忙升级这个扩展；自己重写这个扩展；不升级PHP7；或者使用HHVM。这个时候该怎么选择？

" l1 c% h4 [2 I- F: r8 ^0 Z% X2 u) D

首先，如果用PHP7,显然，如何升级一系列扩展是个问题，要么找人帮忙升级，要么自己重写扩展，无论如何，这个方案，都不是一个简单的方案，带来的工作量和项目周期都有些难以承受。主张升级的人的想法是，PHP7是新趋势，如果这次升级成功了后续再升级其他的小版本都比较顺利，也能够紧跟潮流。但是，还有一种选择，就是不升级，但是选择使用跟PHP7性能类似，基础技术团队已经研究了很多年，并且只需要修改一行配置就能让原本PHP7上的代码运行在hhvm上。

主张升级PHP7的人还有一点顾虑，就是据说有些PHP的语法，HHVM其实是不兼容的。但是这一点也有人反驳，因为有人曾经将几万行PHP代码的项目运行在HHVM上，并没有出什么问题。

这个时候该怎么选择？虽然最后我不清楚这个团队选用了怎样的方案，但是，相对而言，使用HHVM比使用PHP7，技术成本上更简单，从操作的复杂性和效果上来看，HHVM可靠性也更高，因为PHP7在升级扩展的过程中会出现什么问题，这个谁也不知道。

这个例子其实还从某个角度辐射出另外一个问题，就是技术人的跟风问题。新技术大家都想尝试，但是自身业务是否有尝试新技术的必要性，这个地方需要一个问号。像是微博之类的项目，升级PHP7能够节省一些计算资源，但是对于一个内部访问量不大的小平台，升级带来的价值是否能够支撑付出的成本和代价呢？这是一个需要权衡的问题。

技术产品的简单可依赖

( v% l1 U* D& L: E6 F, C  T

程序员这个群体里很多人都有一种癖好，就是很多信息的管理喜欢弄成配置文件而不是做一个管理界面，很多信息管理工具喜欢搞成一个shell脚本或者可执行文件而不是提供一个接口或界面。

4 N$ k4 q2 B1 W2 D

举个例子，某个日志采集的系统，提交日志采集规则的方式是，先把采集规则按照一定的格式【格式很难理解，需要看手册】写成配置文件，然后通过一个可执行文件【其实就是封装了一个rpc的client】提交这份配置到一个中心存储上面去。

; S" ]' A5 X) v

这个流程简单吗？配置文件写错了一点点，比如某个格式不对，提交失败或者提交了配置但是采集不了。这样可靠吗?

* v0 E+ F, E  ]

我第一次接手这个项目的时候看了这一坨使用设计顿时觉得脑袋好像顶了是个西瓜。我们接手一段时间之后，遇到用户接入，我们自己都还需要处理一段时间，更不用说，这个系统可以直接让想接入采集的用户自助化配置了。

2 ?8 h" U* A# q1 F9 A- u0 J" s

其实类似这种例子还有很多，尤其是对于一些内部平台，或者项目的一些子系统里面，涉及一些配置信息或者类似meta信息管理的模块，这种情况很常见，最起码我了解过的公司是这样。

有人说，搞成界面化的多麻烦，搞界面化方案上技术上就不是很简单了。其实这也可以引出下面我想说的一点：

简单可依赖首先需要可靠的基础服务

如果一个公司有有成型的稳定可靠的配置管理系统，是不是上面的问题就方便解决了很多呢？借助于这些基础的配置管理服务或系统，技术实现上简单了，技术产品的功能使用上是不是也简单了。用技术产品的时候，学习成本低了，工作和研发效率也就提升上去了。

! @/ u6 e9 t. _! Q& _

但是现实很残酷：很多公司或者团队，包括我个人，也出现过一种情况，就是依赖或者合作的平台或团队做的东西不给力，没法用，甚至影响自身业务的发展，所以主张自己造轮子。这种情况非常常见，尤其是一些基础服务不可靠的时候。带来的问题，除了造轮子带来的成本问题之外，自身造出来的轮子，在技术方案、架构设计、产品功能与价值上，是否也能够满足简单可依赖的准则，也要打个问号。从我接触了解过的一些公司或者团队的情况来看，结果并不乐观。然后，这种情况恶性循环，研发成本浪费严重。甚至出现一种情况，原本基础架构部门的做的服务很烂，很不稳定，功能简单且不可用，但是在一些项目评比甚至职称评定的时候，基础服务部门的人还会出来对新出现的项目大加指责和打压，而不是反思，为什么大家都愿意做一些跟基础服务部门做的事情类似的项目。

  \! K! z. b  }; Y9 _3 J

说道这里不得不说一个例子，就是腾讯收购的那家叫SuperCell的芬兰游戏公司。如果我没有记错的话，这家公司大概是用不到千人的团队规模，做出了大概几百亿美金的公司估值。大家可以搜索一下国内达到几百亿美金市值的公司的团队规模，比如美团好像8000以上了吧，bat都是几万的规模。这家公司是怎么做到的？我想，最起码一点，他们的技术设计上，一定是非常灵活、非常方便扩展并且能够可靠的支撑业务、产品、运营团队去不断试错的。其实，狼厂提倡的平台化、阿里主导的大中台战略，在一定程度上，最起码是技术上，都有主张强化基础服务的意思吧。

简单可依赖这句话所倡导的技术价值取向，归根节点代表了一种以最小的成本和投入来获取最大服务价值的思维。这种技术价值取向和思维，虽然无法让你在跳槽、加薪的时候带来什么额外的薪酬涨幅，同时这里面很多细节可能并不是一个人的尝试实践所能改变，可能需要依赖于一些外部环境或服务，但是，把这种思维落实到自己研发工作的一些细节里面，权衡考虑，或许，慢慢的你会发现，自己并不需要花费那么多时间在加班、追bug、对接客户或者服务客户之类的工作上。而这，才是技术真正的价值和意义。

zzz.dan

人力和人员的拆分，每个人或者每几个人负责其中的数据流向的一环或者一块，进而组合成整个完整的数据流