• 为什么看起来简单的服务,却需要大量顶尖高手来开发?


    文章转载自「开发者圆桌」一个关于开发者入门、进阶、踩坑的微信公众号

    拿google、百度的搜索服务举例来说,就是提供一个输入框, 提供一个按钮,用户在输入框里输入关键字,按了按钮以后,可以搜索出相应结果。

    拿淘宝、京东这类电商服务来说,无非就是搜索商品、选择商品、购买下单这几个简单的功能。

    但是,就是这样简单的功能,却需要大量顶尖高手才能开发出来,为什么?

    拿淘宝这类电商来说

    搜索商品

     

    如果你有几千条商品,完全可以用select * from tableXX where title like %XX%这样的操作来搞定。但是,当你有10000000000(一百亿)条商品的时候,任何一个数据库都无法存放了,请问你怎么搜索?这里需要用到分布式的数据存储方案,另外这个搜索也不可能直接从数据库里来取数据,必然要用到搜索引擎(简单来说搜索引擎更快)。

    好,能搜出商品了,是否大功告成可以啵一个了呢?早着呢,谁家的商品出现在第一页?这里需要用到巨复杂的排序算法。要是再根据你的购买行为做一些个性化的推荐,这够一帮牛叉的算法工程师奋斗终生了。

    商品详情

    就是搜索完毕,看到你感兴趣的,点击查看商品的页面,这个页面有商品的属性、详细描述、评价、卖家信息等等,这个页面的每天展示次数在30亿以上,同样的道理,如果你做一个网站每天有10个人访问,你丝毫感觉不到服务器的压力,但是30亿,要解决的问题就多了去了。

    首先,这些请求不能直接压到数据库上,任何单机或分布式的数据库,承受30亿每天的压力,都将崩溃到完全没有幸福感,这种情况下要用到的技术就是大规模的分布式缓存,所有的卖家信息、评价信息、商品描述都是从缓存里面来取到的,甚至更加极致的一点“商品的浏览量”这个信息,每打开页面一次都要刷新,你猜能够从缓存里面来取吗?淘宝做到了,整个商品的详情都在缓存里面。


    商品图片

     

    一个商品有5个图片,商品描述里面有更多图片,你猜淘宝有多少张图片要存储?100亿以上。这么多图片要是在你的硬盘里面,你怎么去查找其中的一张?要是你的同学想拷贝你的图片,你需要他准备多少块硬盘?你需要配置多少大的带宽?你们的网卡是否能够承受?你需要多长时间拷贝给他?这样的规模,很不幸市面上已经没有任何商业的解决方案,最终我们必须自己来开发一套存储系统,如果你听说过google的GFS,我们跟他类似,叫TFS。顺便说一下,腾讯也有这样的一套,也叫TFS。

    广告系统

    淘宝上有很多广告,什么,你不知道?那说明淘宝的广告做的还不错,居然很多人不认为它是广告,卖家怎么出价去买淘宝的广告位?广告怎么展示?怎么查看广告效果?这又是一套算法精奇的系统。

    BOSS系统

    淘宝的工作人员怎么去管理这么庞大的一个系统,例如某时刻突然宣布某位作家的作品全部从淘宝消失,从数据库到搜索引擎到广告系统,里面的相关数据在几分钟内全部消失,这又需要一个牛叉的后台支撑系统。

    运维体系

    支持这么庞大的一个网站,你猜需要多少台服务器?几千台?那是零头。这么多服务器,上面部署什么操作系统,操作系统的内核能否优化?Java虚拟机能否优化?通信模块有没有榨取性能的空间?软件怎么部署上去?出了问题怎么回滚?你装过操作系统吧,优化过吧,被360坑过没,崩溃过没?这里面又有很多门道。

    不再多写了,除了上面提到的这些,还有很多很多需要做的技术,当然并不是这些东西有多么高不可攀,任何复杂的庞大的东西都是从小到大做起来的,里面需要牛叉到不行的大犇,也需要充满好奇心的菜鸟。

    看看排序这点事儿

     

    我有 20 个整数,一把全装进内存,调用个 sort,完事了。我有 2GB 那么多的整数,一把全装进内存……嗯嗯,如果机器不那么破,勉强也完事吧。

    那我现在有 200GB 那么多的整数……看你丫的怎么装内存,哈哈哈哈哈哈!

    吓尿了吧!?写外排序?你写啊!It's only the beginning!很多人可是连内存里的快排都写不出的哦~

    好,现在有 200GB 的整数,排个序吧……呃,给你 10 台机器吧。这 200GB 的整数,如何分配?这 10 台机器之间如何通讯?没错,我不止坑了你去写外排序,我还得坑你去玩网络编程。

    假设每一台机器上的数据都已经完全排好,如何多快好省地把各自排序好的结果 merge 在一起?如何设计有效的 merge 逻辑减少 10 台机器之间的网络IO。

    别以为 10 台机器不需要维护,万一在排序的时候其中一台机器挂了,怎么办?具体包括但不限于:他在挂之前有响应其他机器发给他的 request 吗?他在挂之前自身的任务完成了多少了?假设这台机器在挂的时候正在跟隔壁的机器互相传输数据肿么办?

    如果数据不是 200GB,而是 2TB,2PB……,排序简单么?简单。但是给很多数字排序就不简单了。

    技术优化的经济效益

    当你有一百亿件商品要检索的时候,一台计算机的计算能力肯定是不够用的。于是Facebook,淘宝就需要建一个大车间,里面装满了各种性能强劲的电脑来做计算。这些电脑能耗是多少?Google有3亿瓦,Facebook 6000万瓦。其实这些能源有很多都在CPU空转的时候被浪费了。假如有一种方法能让数据中心的能耗降低10%,你愿意花多少钱配多少人员去研究这个方法?

    问题规模大到一定级别,任何微小的改进都能带来巨大的回报。但是这样的改进往往不是那么容易做到,所以这样“简单”的网站需要大量高手来开发。

    行动的误区

     

    看到这里你可能觉得优秀的开发者就是写出更优的算法,正要摩拳擦掌去征服高深的xx算法,这样的理解是非常片面的,像google这种看起来简单的服务却需要大量顶尖高手来开发的产品并不算多,大部分是不需要大量顶尖高手参与的复杂的功能性的产品。

    任何复杂的庞大的东西都是从小到大做起来的,不要一上来就要求这样那样的算法,很多开源的组件或者工具已经非常优秀,拿来应用是个不错的选择,解决当前面临的问题才是正道。

    「小公司没有发展前途,各种工作比较杂,没有高手带领,而大公司通常只让你做模块,你根本接触不到核心,那算法优化方面怎么提高?自学?」这些问题很多开发者都会遇到。

    在之前的文章「什么才是真正的编程能力?」中我们讨论过计算机科学有两类根本问题。一类是理论:算法,数据结构,复杂度,机器学习,模式识别,等等等。一类是系统:操作系统,网络系统,分布式系统,存储系统,游戏引擎,等等等等。

    这两类工作没有孰优孰劣的问题,如果不能应用到现实中,即使算法再强大,也没有任何意义。同理,你要为用户提供好用的服务,如果没有好的算法支持,提供的服务可能会大打折扣,它们是相互依存相互制约的。理论也好,系统也罢归根到底是要解决现实问题或者改变不尽人意的现状。

    怎么选择,理论?系统?

     

    个人因素

     

    从个人擅长的点出发,如果你沟通能力较强,擅长现实业务与虚拟数字产品的映射,需求分析、功能设计等等,但是不太擅长复杂的算法分析,完全没问题,你更适合系统而非算法研究。

    如果你自身沟通能力较弱,逻辑思维较强,数学不错,工科科班出身,同时自己非常喜欢研究算法,那么你可以去阿里或谷歌这类科技公司应聘算法工程师或者数据结构工程师岗位。

    环境因素

    人总会受到环境的制约,你所处公司的业务方向2B还是2C都会影响你接触的技术或者工作岗位,当然现在的人才流动性很大,可以在流动中弥补自己的不足。

    小公司,大公司也会不同,小公司更多的要求综合应用能力,大公司分工非常明确,更多的要求深入能力。

    国内很少是根据个人兴趣进行技术研究,更多的是注重现实收益,所以即便是算法工程师岗位,大部分是对已有算法的应用和改进,对开源产品的应用和微调,而非从头研究新的算法或者算法工具。这也就是为什么Hadoop等技术源于国外而不是国内的原因。

    当然,国内的技术起步较晚也是一个不争的事实,开源做的也不够好,相信未来会更好,这需要一个不断发展的过程。

    互相转换

     

    当然,人是可以去改变自己的,一生不可能只从事一个方面的工作,关键看你的职业规划。

    从事系统研发工作也是一种不错的积累,培养自己把现实问题映射为虚拟数字产品的能力,系统研发遇到瓶颈,你可能会转向算法等理论研发工作;同样算法等理论研发工作也是要以现实存在的问题作为出发点,不然就是本末倒置。

    最后的话

    看起来简单的服务并不简单,越是简单的服务工作越艰巨;算法研究与系统研究统一于对现实问题的解决,两者相互依存,而非谁优谁劣。

    这些是我的一点浅见,希望可以帮助站在十字路口的你。

  • 相关阅读:
    iOS之CALayer属性简介
    iOS之UIGraphics.h方法简介
    iOS之CGcontext.h方法和属性简介
    iOS之CATiledLayer的属性简介和使用
    iOS之CATextLayer属性简介
    iOS之CAScrollLayer属性简介和使用
    iOS之CAReplicatorLayer属性简介和使用
    iOS之CAGradientLayer属性简介和使用
    iOS之CAShapeLayer属性简介
    iOS之UIBezierPath贝塞尔曲线属性简介
  • 原文地址:https://www.cnblogs.com/helloworld114/p/6510501.html
Copyright © 2020-2023  润新知