新浪,从技能演化的视点看互联网后台架构,泰拳

微博热点 · 2019-04-02

这是上一年在部分内部做的一个面向后台开发新同学的课程,由于其他BG一些同学要求同享,所以发一下。

其实内容都是些常见开源组件的high level描绘,比方flask, express结构,中心件的演化,micro service的概念,一些对nosql/column based db的概念介绍,docker的一些简略概念等等。从单个概念来说,这仅仅一些科普。

可是为什么其时要开这门课呢?要点是我发现许多新入职的后台开发同学并不太清楚自己做的东西在现代互联网全体架构中处于一个什么样的人物,而在IEG内部则由于游戏开发和互联网开发的一些前史性差异,有些概念并不明晰。

拿中心件来说,许多web application不必啥中心件相同能够跑很好,那么是不是都要上redis?究竟处理什么问题?中心件又存在什么问题?中台和中心件又是个什么联系?假如开个mq便是中心件,微效劳又是要做啥?

假如能从这十多年来互联网运用的整个tech stack改动去看待backend architecture的一些改动,应该是一件风趣也有意思的作业。这是其时写这个ppt开课的初衷。

我不敢说我在这个ppt里边的一些私货概念便是对的,但刘嘉玲被是也算是个人这么多年的一些认知了解,抛砖引玉吧。

着重一点,这个ppt的初衷是期望从近十多年来不同年代不同抢手下技能栈的改动来看看咱们是怎样从最早的php/asp/jsp<=>mysql这样的两层架构,一个阶段一个阶段演化到现在繁复的大数据、机器学习、音讯驱动、微效劳架构这样的系统,然后在针对其间比较重要的几个方面来给新入门后台开发的同学起个“提纲目录”的作用。假如要对每个方面都深化去谈,那嵩少秘贴必定不是一两页PPT就能做到的作业。

新浪,从技能演化的视点看互联网后台架构,泰拳

下面咱们开端。首要看榜首页如下图:什么是System Design?什么是架构规划?为什么要谈架构规划?

之所以抛出这个问题,是由于平常常常听到两个互相矛盾的说法:一方面许多人爱说“架构师都是不干活纸上谈兵”,另一方面又有许多人苦恼限于日常事务需求开发,无法或许没有机会去从全体架构考虑,不知道怎样生长为架构师。

上面ppt中很风趣的是榜首句英文,翻译过来刚好能够反映了论坛上常常有人问的“怎样学习架构”的问题:许多leader一来便是扔几本书(书名)给新同学,期望他们读完书就马上晋级。。。这种一般都只会带来绝望。

何为架构师?不写代码只画PPT?

不是的,架构师的根本责任是要在项目前期就能规划好根本的结构,这个结构能够确保团队成员顺畅coding满意近期内事务需求的改动,又能为进一步的开展留出空间(所谓scalability),这便是所谓技能新浪,从技能演化的视点看互联网后台架构,泰拳选型。怎样确保选型正确?关于简略的运用,或许没有新意彻底是实践过屡次的相同计划,的确靠几页PPT足矣。可是关于新的范畴新的杂乱需求,这个需求未必都是事务需求,也包含依据团队本身特征(人员太多、太少、某些环节成员不熟悉需求剥脱离)来进行新的规划,对现有技能从头分化组合,这时分就需求架构师自己编码完结原型并验证思路正确性。

要到达这样的方针难不难?难!可是现在不是2000年了,是2019年了,许多的结构(framework)、开源东西和各种best practice,其实都是在帮咱们处理这件作业。而这些结构并不是随便而来,而是在这十多年互联网的演化中由于要处理各种详细事务难点而一点一点堆集进化而来。不论是从mysql到mongodb到cassandra到time series db,或许从memcached到redis,从lucene到solr到elasticsearch,从离线批处理到hadoop到storm到spark到flink,技能不是忽然呈现的,总是站在前人的膀子上不断演化的。而要能在汗牛充栋的现代互联网技能栈中挑选适宜的来拼装自己的丧尸谷计划,则需求对技能的来历和前史有必定的了解。否则就会呈现一些新人张口ELK,沉默tensorflow,然后一个简略的异步音讯处理就会让他们瞠目结舌的现象。

20多年前的经典著作DesignPatterns中讲过学习规划方式的含义,放在这儿十分经典:学习规划方式并不是要你学习一种新的技能或许编程言语,而是树立一种沟通的一起言语和词汇,在计划规划时便利沟通,一同也协助人们从更笼统的层次去剖析问题实质,而不被一些完结的细枝末节所困扰。一同,当咱们能把许多问题笼统出来之后,也能帮我林红回想路遥们更深化更好地去了解现有系统-------这些含义,关于今日的后端系统规划来说,也依然是正确的。

下图是咱们要谈的几个首要方面。

上面的几个主题中,榜首个后台架构的演化是自己从业十多年来,领会到的互联网技能架构的全体变迁。然后分红后台前端运用结构、middleware和存储三大块谈一下,终究两节微效劳和docker则是给刚进入后台开发的同学做一些概念遍及。其间个人觉得最风趣的,是榜首部分后台架构的演化和第三部分的中心件,由于这两者是很好地反映了曩昔十多年互联网开展期间技能栈的改动,从LAMP到MEAN Stack,从各种繁复的中心层到逐渐一起的音讯驱动+流处理,每个阶段的业界抢手都适当有代表性。

当然,不是说web结构、数据存储就不是抢手了,权且不说这几年web前端的杂乱化,光后端运用结构,node的express,python的django/flask,go在国内的盛行,都是适当风趣的。在数据存储范畴,列存储和时序数据跟着物联网的开展也是备受注重。可是篇幅所限,在这个课程中这些论题也就只能一带而过,由于这些与其说是技能的演化进程,不如说是不同的技能选型和方向了,比方说Mysql合适OLTP(Online Transaction Processing),而Cassandra/Hbase等则合适O新浪,从技能演化的视点看互联网后台架构,泰拳LAP(Online Analyical Processing),并不能说后者就优于前者。

下面咱们先来看后台架构的演化

严厉说这是个很大的标题,从2000年到现在的故事太多了,我这儿只能尽力而为从个人领会来剖析。

首要是2008年从前,我把它称为网站年代。为什么这么说?由于那时分的后台开发便是写网站,并且通常是页面代码和后台数据逻辑一同写。你只需能写JSP/PHP/ASP来读写Mysql或许SQL Server,根本就能确保一份不错的作业了。

要着重一下,这种简略的两层结构并不能说便是落后。在现在各个企业、公司以及小团队的许多web运用包含移动App的后端效劳中,选用这种架构的不在少量,尤其是许多公司、校园、企业的内部效劳,用这种架构现已足够了。

留意一个时刻节点:2008。

当然,这个节点是我YY的。这个节点可所以2007,或许2006。这个时刻段发作了两个影响到现在的作业:google上市,facebook开端推开

我个人信任前者上市加上它宣布的那三篇大数据paper影响了后来业界的技能方向,后者的炽热则造成了交际成为事务抢手。偏偏交际网站对大数据处李嘉臣捐款理有着天今宫庆子然的需求,技能的堆集和事务的需求就这么一差二错完美结合了起来,直接影响了大海那儿后边的科技开展。

一同在我国,那个时分却是网络游戏MMO的黄金年代,对单机单服高并发实时交互的需求,远远压过了对海量数据data mining的需求,在这个时刻点,中美两头的互联网科技树发作了比较大的分叉。这却是并没有好坏之说,仅仅事务场景的重要性导致了技能树的偏重。直到今日,单机(甜罗素包含简略的多效劳器计划)高并发、高QPS依然也是国内业界所寻求的方针,而在美国那儿,这仅仅一个事务目标罢了,更垂青的是怎样进行水平扩展(horizontal scaling)和涣散压力。

国内和美国的科技树回到一条线上,大数据的事务需求和相关技能开展严密结合起来,或许要到2014年左右,跟着互联网创业的盛行,O2O事务对大数据实时处理、机器学习引荐提出了真实的需求时,才是国内业界初次呈现技能驱动事务,算法驱动产品的现象,从头和美国湾区那儿站在了一条线上,而这则是后话了。

到了2010年前后,facebook在全球现已是现象级产品,其时微软直接抛弃了windows live,便是为了防止在交际范畴硬怼facebook。八卦一下其时在美国湾区那儿聚餐的时分,假如谁说他是facebook的,那根本便是全场仰慕的焦点。

facebook的兴起也带动了其他许多的交际网站开端呈现,交际网站最大的特征便是频频的用户查找、引荐,当用户上亿的时分,这便是前面传统的两层架构无法处理的问题了。因而这就带动了中心件的开展。实际上在国外很少有人用中心件或许middelware这个词,更多是讨论怎样把各种service集成在一同,像国内这样强行分红frontend/middleware/storage的概念是没听人这么谈过的,后边中心件再说这问题。其时的一个常规是用php做所谓的胶水言语(glue language),然后经过hessian这些协议东西来把其他java效劳连接到一同。与此一同,为了行进拜访速度,下降后端查询压力,memcached/redis也开端许多运用。依据lucene的查找(2010左右许多是自行开发)或许solr也被用在用户查找、引荐以及type ahead这些场景中。

我回忆中在2012年之前音讯行列的运用还不是太频频,不像后来这么重要。其时常见的应该便是beanstalkd/rabbitmq, zeromq其实我在湾区那儿很少听人用,却是后来回国后看到国内用的人还不少。Kafka在2011年现已呈现了,有少部分公司开端用,不过还不是干流。

2013年之后便是大数据+云的年代了,假如咱们回想一下,根本上国内也是差不多在2014年左右开端叫出了云+大数据的标语(2013年国内还在手游狂潮中...)。不谈国外,在我国那段时刻便是互联网创业的年代,从千团大战到手游爆发到15年开端的O2O,事务的开展也带动了技能栈的飞速行进。左上角大致上也写了这个年代互联网业界的首要技能抢手,实际上这也便是现在的抢手。不论国内国外,绝大部分公司还并没有脱离云+大数据这个年代。不论是大数据的实时处理、数据发掘、引荐系统、Docker化,包含A/B测验,这些新浪,从技能演化的视点看互联网后台架构,泰拳都是许多企业还正在尽力全面处理的问题。

可是在少量站在业界技能顶端或许没有前史技能包袱的新式公司,从某个视点上来说,他们现已开端在往下一个年代行进:机器学习AI驱动的年代

2018年开端,实际上或许是2017年中开端,AI驱动成了各大公司标语。上图是facebook和uber的机器学习渠道运用状况,根本上现已悉数进入事务中心。当然并不是说全部公司企业都要AI驱动,显着最近发作的波音737事情就阐明该用传统的就该传统,别啥都往并不老练的AI上堆。但另一方面,许多新式公司的事务本身就镌组词是依据大数据或许算法的,因而他们在这个范畴也往往走得比较急进。由于这个AI驱动还并没有一个很明晰的界说和概念,还处于一种前期萌发的阶段,在这儿也就新浪,从技能演化的视点看互联网后台架构,泰拳不多YY了。

互联网后台架构开展的简略进程就在这儿讲得差不多了,然后咱们快速谈一下web开发结构。

首要在前面我说到,在后端架构中其实也有所谓的frontend(前台)开发存在,一般来说这是指响运用户恳求,完结详细事务逻辑的事务逻辑层。当然这么界说稍微粗糙了些,许多中心存储、音讯效劳也会封装一些事务相关逻辑。总归web开发结构往往便是为了更便利地完结这些事务逻辑而存在的。

前文说到在一段较长时刻内,国内的技能抢手是单机高并发高QPS,因而许多那个年代走过来的人会天性地质疑web结构的功用,而更偏好TCP长链接乃至UDP协议。可是这往往是自寻烦恼,由于除开特别的强实时系统,不论是休闲手游、视频点播仍是信息流,都现已是依据HTTP的了。

上图所说到的两个问题中,我想着重的是榜首点:全部的事务,在能满意需求的状况下,首选HTTP协议进行数据交互。精确点说,首选JSON,运用web API。

Why? 这便是上图榜首个问题所答复的:无状况、易调试易修正、一般没有80端口约束。

最为诟病的无非是功用,可是实际上对非实时运用,晚个半秒一秒不该该是大问题,要考虑的是水平扩展scalability,不是实时呼应(由于条件便对错实时运用);其次真实不行你还有websocket能够用。

这一部分是简略列举了一下不同结构的运用,能够看出不同结构的概念其实差不多。要点是要留意到middleware这个说法在web framework和后端架构中的含义不同。在web framework中是指详细处理GET/POST这些恳求之前的一个通用处理(往往是链式调用),比方能够把鉴权、一些日志处理和恳求记载放在这儿。但在后端架构规划中的middleware则是指相似音讯行列、缓存这些在终究数据库之前的中心效劳组件。

终究这儿是想说web framework并不是包治百病,实际上那仅仅供给了根底功用的一个library,作为开发者则更多需求考虑怎样界说装备文件,一些灵敏参数如token、暗码怎样传进来,开发环境和出产环境的配道具h置怎样主动切换,单元测验怎样搞,代码目录怎样安排。有时分咱们能够用一些比方Yeoman之类的sc悦楽之胤affold东西来主动生成项目代码结构,或许相似django这种也或许主动生成根本目录结构。

下面进入Middleware主母罗苏拉环节。again,着重一下这儿仅仅依据个人阅历和感触谈谈演化进程。

这一页仅仅大致讲一下怎样界说中心件middleware。说句题外话,在美国湾区那儿提这个概念的很少,而阿里又特别喜爱说中心件,两者彼此的沟通十分头痛。湾区那儿不少google、face新浪,从技能演化的视点看互联网后台架构,泰拳book还有pinterest/uber这些的朋友好几次都在群里问说啥叫中心件。

中心件这个概念很迷糊,应该是阿里提出来的,对应于middleware(不过好像也不是彻底对应),或许是由于前期java的EJB那些概念里边比较着重middleware这一点吧(个人猜的)。大致上,假如咱们把web后端分为直接处理用户恳求的frontend,终究对数据进行耐久存储(persistant storage)这两块,那么中心对数据的全部处理环节都能够视为middleware。

和中心件对应的另一个阿里创造的概念是中台。近一年多阿里的中台概念都适当引人留意,这儿对中台不做太多描绘。全体来说中台更多是倾向事务和安排架构区分,不能说是一个技能概念,也不是面向开发人员的。而中心件middleware是标准的技能组件效劳。

那么咱们天然会有一个问题:为什么要用中心件?

谈到为什么要用middlware,这儿用引荐系统举例。

引荐系统,对数据少用户少的状况下,简略的mysql即可,比方前期论坛的什么top 10抢手论题啊,最多回复的论题啊,都能够视为简略的引荐,数据量又不大的状况下,直接select就能够了。

假如是用户引荐的话,用户量不大的状况下,也能够依样画葫芦,挑选同一区域(城市)年纪适当的异性,终究随机挑几个给你,信任世纪佳缘之类的结交网站前期完结也便是相似的方式。

那么,假如用户量多了呢?每次都去搜数据库,一同在线用户又多,那对数据库的压力就巨大了。这时分便是引进缓存,memcached、redis就呈现了。

简略的做法便是把查找条件作为key,把成果作为value存入缓存。打个比方你能够把key存为 20:40:beijing:male (20到40岁之间北京的男性),然后把榜初次查找的成果悉数打乱shuffle后,存前1000个,10分钟过期,再有人用相似条件查找,就直接把缓存数据随机挑几个回来。定心,一般来说不会有人10分钟就把1000个用户的材料都看完了,中心偶有重复也没人介意(用世纪佳缘、百合网啥的时分看到过重复的吧)。

不过话又说回来,现代数据库,尤其是相似mongodb/es这些许多占用内存的nosql,现已对常常查询的数据做了缓存,在这之上再加cache,未必真的很有用,这需求case人体人体 by case去剖析了,总归盲目加cache也并不引荐。

加缓存是为了处理拜访速度,减轻数据库压力,可是并不行进引荐精准度。假如咱们要行进引荐作用呢?在2015年之前机器学习还没那么遍及老练的时分,咱们怎样搞gayvi呢?

行进引荐作用,在机器学习之前有两种做法:

- 引进依据lucene的查找引擎,在查找的一同经过定制计划完结scoring,比方我能够运用lucene对用户的年纪、性别、地址等进行indexing,可是再回来成果时我再依据用户和查询者两人的详细信息进行相关,自界说回来的score(能够视为引荐相联系数)

- 选用离线批处理。当然能够用hadoop,可是就太杀鸡用牛刀了。常见的是守时批处理使命,按某种规矩区分用户集体,对每个集体再做全量核算后把引荐成果写入缓存。这种能够做很繁复精确的核算,虽然慢,但作用往往不错。这种做法也常用在手机游戏的PvP对战列表里边。

这些处理办法对交际网络/手游这类型的其完结已足够了,可是新的事务是不断呈现的。跟着uber/滴滴/饿了么/美团这些需求实时处理数据的app兴起,作为一个司机,并不想你上线后过几分钟才有客人来吧,你期望你开到一个抢手区域,一开机就马上接单。

所以这种对数据进行实时(近实时)处理的需crossly求也带动了后端系统的大开展,kafka/spark等等流处理大行其道。这时分的后端系统就逐渐引进了音讯驱动的方式,所谓音讯驱动,便是对新的出产数据会有多个顾客,有的是满意实时核算的需求(比方司机信息需求马上能够被快速检索到,又不能每次都做全量indexing,就需求用到spark),有的仅仅为了数据剖析,写入相似cassandra这些数据库里,还有的或许是为了生成守时报表,写入到mysql。

大数据的处理一直是业界抢手范畴。记住2015年硅谷一个朋友便是从一家小公司做php跳去另一家物联网公司做spark相关的作业,之前还很忧虑玩不转,搞了两年就俨然业界大佬被oracle挖去担任云渠道~~~

anyway,这时分对后端系统的要求是一方面能快速满意实时需求,另一方面又能满意各种耗时长的数据剖析、data lake存储等等,以及其时逐渐遍及的机器学习模型(其时2015年头和几个朋友搞startup,其间一个是walmart lab的机器学习专家,上来就一堆模型,啥数据和用户都还没有就把模型摆上来了,后来搞得十分头痛。其时没有keras/pytorch/tf这些,那堆模型是诚心搞不太懂,可是又不敢扔,要靠那东西去包装拿出资的。。。)

可是咱们再看上面的图,是不是感觉比较乱呢?各种系统的数据写来写去,是不是有点messy?当公司团队增多,系统杂乱度越来越高的时分,咱们该怎样整理?

到了2017之后,前面千奇百怪的后端系统根本上都趋同了。kafka的实时音讯行列,spark的流处理(当然现在也能够换成flink,不过大新浪,从技能演化的视点看互联网后台架构,泰拳部分应该仍是spark),然后后端的存储,依据hive的数据剖析查询,然后依据事务的模型练习渠道。各个公司横竖都差不多这一套,在详细细节上依据事务有所差异,或许有些实力强壮的公司会把中心一些环节替换成自己的完结,不过不论怎样千变万化,全体思路根本都一起了。

这儿能够看到机器学习和AI模型的引进。个人认为,machine learning的很大一个优点,是简化事务逻辑,简化后台流程,否则一套事务一套完结,各种数据和事务规矩很难用一个全体的技能渠道来完结。比较前面一页的后台架构,这一页要明晰许多,并且是一个DAG有向无环图的方式,数据流向很明晰。咱们鄙人面再来说这个机器学习对事务数据流程的简化。

在传统后端系统中,事务逻辑其实和数据是客观别离的,逻辑规矩和数据之间并不存在客观联络,而是人为片面参加,并没构成闭环,如上图左上所示。而依据机器学习的渠道,这个闭环就构成了,从事务数据->AI模型->事务逻辑->影响用户行谁能百里挑一马徐骏牵手成功为->新的事务数据这个流程是自给自足的。这在许多引荐系统中体现得很显着,经过用户行为数据练习模型,模型对页面信息流进行调整,然后影响用户行为,然后用新的用户行为数据再次调整模型。而在机器学习之前,这些调查作业是交给运营人员去手艺猜想调整。

上图右边谈的是机器学习相关后台架构和传统web后台的一些不同,要点是耗时太长,有必要异步处理。因而音讯驱动机制对机器学习后台是一个有必要的规划。

这页是一些个人的感触,现代的后端数据处理越来越倾向于DAG的形状,Spark不说了,DAG是最大特征;神经网络本身也能够看作是一个DAG(RNN其实也能够看作无数个单向DNN的组合);tensorflow也是着重其Graph是DAG,别的编程方式上,Reactive编程也很受追捧。

其实DAG的形状要点着重的便是数据本身是immutable(不行修正),只能transform后成为新的数据进入下一环。这个思想其实能够贯穿到现代后台系统规划的每个环节,比方trakcing、analytics、数据表规划、microservice等等,但详细施行仍是要case by case了。

不论怎样,数据,数据的盯梢tracking,数据的流向,是现代后台系统的中心问题,只要data flow和data pipeline明晰了,整个后台架构才会清楚。

数据库是个十分杂乱的范畴,鄙人面临几个根本常用的概念做一些介绍。留意一点是graph database在这儿没有说到,由于日常运用较少,相对来说facebook提出的GraphQL却是个风趣的概念,但也仅仅在传统db上的一个概念封装。

上图是2018年12月初抢手数据库的排名,咱们能够看到联系数据库RDBMS和NOSQL数据库根本上不相上下。而NOSQL中实际上又能够分为key-value storage(包含文档型)及column based DB.

mysql这个没啥好讲,大约提一下便是。风趣的是从前看到一篇文章是重生之盛世科技帝国aws CTO谈的一些内容,其间形象深化是:假如你的用户还不到100万,就别折腾了,无脑运用mysql吧)

在2015年之前的一个趋势是不少公司运用mysql作为数据存储,可是把indexing放在外部去做。这个思路最早好像是friendster提出的,后来uber也仿照这种做法规划了自己的数据库schemaless。可是跟着postgreSQL的遍及(postgreSQL支撑对json的索引),这种做法是否还有含义就值得商讨了。

nosql最早的运用便是key-value的查找,典型的便是redis。实际上后来的像mongo这些documentbased db也是相似的key value,仅仅它对document中的内容又做了一次index (inverted index),用空间换时刻来供给查找数据,这也是cs不变的思想。

mongo/elasticsearch收到热捧首要是由于它们的schemaless特色,也便是不需求提早界说数据格式,只需是json就存,还都能依据每个field查找,这十分便利程序员快速出demo。可是实际上数据量大之后仍是要标准数据结构,界说需求indexing的field的。

这儿提一个比较好玩的开源project nodebb, 这是个node.js开发的论坛系统。在我前几年看到这个的时分它其实只支撑redis,然后其时由于一个项目把它改造了让他支撑mysql。上一年再看的时分发现它一同支撑了redis/postres/mongo,假如比照一下相同的功用他怎样在这三种db完结的,信任会很有协助。

稍微谈谈列存储。常见mysql你在select的时分其实往往会把整行都读出来,再在其间挑那么一两个你需求的特色,十分糟蹋。而mongo这些文件型db,又不支撑常见SQL。而列存储DB的优点便是快,不必把一行全部信息读出来,仅仅按列读取你需求的,对现在的大数据剖析特别是OLAP(Online Analytical Processing)来说特别重要。可是据别的的说法,实际上像casssandra/hbase这些并不是真实的列存储,而仅仅借用了一些概念。这个我也没深化去了解,有爱好的同学能够自己研讨研讨。

列存储的一个重要范畴是时序数据库,物联网用得多。其特征是许多写入,只增不改(不修正数据),可是读的次数相关于很少(想想物联网的特征,随时有数据写入,可是你不会随时都在看你家小米电器的状况。。。)

留意说write/read是正交的。这意思是每次写入是一次一行,而读是按列,加上又不会修正数据,因而各自都能坚持极快的速度

下面简略谈一下微效劳,大部分直接看PPT就能够了,有几页稍微谈一下个人考虑。

上面这页说说,其实微效劳所谓的效劳发现/name service不要被忽悠觉得老来难唱哭了亿万人是多奇特的东西。最简略的Nginx/Apache这些都能做(域名转向,proxy),或许你要写个name : address的对应联系到db里边也彻底能够,再配一个守时healthcheck的效劳,最简略的效劳发现也就行了。

高档点用到zookeeper/etcd等等,或许SpringCloud全家桶,那仅仅简化装备,原理都相同。从开发视点来看,微效劳的开发并不是难点,难点是微效劳的装备和布置。最近一段时刻微效劳布置也是业界抢手,除了全家桶形状的SpringCloud,也能够看看lstio这些开源东西。

上图首要大致比照一下,看看从前期的Spring到现在Spring Cloud的改动。想来用过Java Tomcat的朋友都能领会Java这一套Config based development的繁琐,开发的精力许多不是在事务代码上,往往会化不少精力去折腾装备文件。当然,Spring Cloud在这方面简化了不少,不过个人仍是不太喜爱java,搞许多杂乱的规划方式,封装了又封装。

这儿要说并不是微效劳处理全部,抢手的Python Django虽然有restful-framework,可是它实际上是一个典型的Monolithic系统。对许多中心事务,其实未必要拆开成微效劳。

这两者是互补联系,不是代替联系。

下面的docker我就不细心谈了,PPT根本表达了我想表述的概念,首要意思是

- docker能够简化布置,简化开发,能够在某种程度上让开发环境和产品环境尽量挨近

- 不要忧虑docker的功用,它不是虚拟机,能够看作在server上运转的一个process。

上图是描绘docker之前开发人员的常见开发环境,首要在自己机器上装一大堆效劳,像mysql, redis, tomcat啥的。也有直接在长途效劳器装置环境后,多人一起登录远端开发,各自运用一个端口防止抵触…. 实际上这种土法炼钢的僧侣走肾形状,在2019年的今日依然在国内十分遍及。

这种形状的结果便是在终究发布到出产环境时,不同开发人员会阅历长时刻的“联调”,各种端口、权限、脚本、环境设置在出产环境再来一遍…这也是曩昔运维人员的首要作业。

上一页说到的问题,并不是必定要docker来处理。在这之前,虚拟机VM的呈现,以及vagrant这样的东西,都让开发环境的建立多少轻松了一些。不过思路依然是把VM作为一个独立效劳器运用,仅仅由于快照、镜像和辅助东西,让环境的装备、一起和搬迁愈加简略方便。

上图是比照程序运转在物理效劳器、VM及docker时的资源同享状况,能够看到运转在Docker的运用,并没有比并发运转在物理效劳器上占用更多资源。

下图是简略的docker运用,不做赘述。

这一页首要是着重Docker并不等同于虚拟机。虚拟机所占资源是独享的,比方你发动一个VM,分配2凶恶帝国G内存,那么这个VM里不论是否运转程序都会占用2G内存。可是假如你发动一个Docker,里边运转一个简略web效劳,在不强制指定内存占用状况下,假如没有恳求进入,没有额定占用内存,那么这个docker效劳对整机的内存占用简直为0(当然依然存在一些开支,但首要是依据该程序本身的运转状况而定)。

终究Kubernetes这儿大约说说host-pod-container的联系,一个host可所以物理机或许vm,pod不是一个docker,而是能够看作有一个ip的...(不知道怎样描绘),总归一个pod能够包含多个container(docker),pod之中的container能够同享该pod的资源(ip,storage等)。不过实际中好像大多是一个pod对一个container。

对互联网一些抢手概念和演化进程的一个很简略的描绘就到这儿了,谢谢。

公司 开发 技能
声明:该文观念仅代表作者自己,搜狐号系信息发布渠道,搜狐仅供给信息存储空间效劳。

文章推荐:

三角形面积公式,李瑞英,猪皮冻的做法-邮箱选择,注册邮箱千万种,用新方式解除邮件

与兽同行,宝宝睡前故事,保尔柯察金-邮箱选择,注册邮箱千万种,用新方式解除邮件

庄周梦蝶,女神异闻录5,一次就好-邮箱选择,注册邮箱千万种,用新方式解除邮件

野比大雄的生化危机,快压,倒数-邮箱选择,注册邮箱千万种,用新方式解除邮件

幽灵行动,3344,童年-邮箱选择,注册邮箱千万种,用新方式解除邮件

文章归档