精华内容
下载资源
问答
  • 互联网分层架构的本质,是数据的移动 • 互联网分层架构中,数据的传输格式(协议)与数据在各层次的形态很重要 • 互联网分层架构演进的核心原则与方法:封装与复用
  • 互联网分层结构实现

    千次阅读 2020-07-20 15:15:40
    互联网分层有的七层模型和 的五层模型,本质上实现的功能大同小异,只不过五层模型更加精简一些。这篇博客就是在五层模型的基础上进行分析。 如上图所示,其中每一层都是为了实现不同的功能,为了实现这些功能...

    一、五层模型

    互联网的分层有七层模型和五层模型,本质上实现的功能大同小异,只不过五层模型更加精简一些。这篇博客就是在五层模型的基础上进行分析。

    如上图所示,其中每一层都是为了实现不同的功能,为了实现这些功能,就需要大家(通信双方)都遵守共同的规则,这些规则就是协议。互联网每一层都有很多协议,它们加起来就叫做互联网协议(Intelnet Protocol Suite)。五层模型中,越下面的层,越靠近硬件;越上面的层,越靠近用户。

    二、物理层(Physical Layer)

    物理层是最底下的一层,负责实现的是将电脑之间连接起来的物理实现。比如可以用光缆、电缆、双绞线、无线电波等方式。它主要规定了网络的一些电气特性,作用是负责传送01的电信号

    3.1 定义

    首先我们知道,下一层物理层负责的是传递0和1的电信号,但是单纯的0和1是没有任何意义的,必须为它们规定解读方式:比如多少个电信号算一组?每个信号位代表了什么意义?

    上述就是链接层的功能,它在物理层上方,确定0和1的分组方式,也就是说电脑在物理层收到电信号后,是在链接层将这些0和1信号转换成一个个数据包的格式。当然,它还有其他深层作用,马上会讲。

    3.2 以太网协议

    本来在早期的时候,几乎每家公司都有自己的电信号分组方式。后来逐渐的,一种叫做以太网(Ethernet)的协议,占据了主导地位。

    在以太网协议中规定,一组电信号构成一个数据包,叫做(Frame)。每一帧分成两个部分:帧头(Head)数据(Data)。如下:

    其中,Head 中包含了数据包的一些说明项,比如发送者、接受者、数据类型等等; Data 则是数据包的具体内容。

    Head 的长度,固定为18字节Data 的长度,最短46字节,最长1500字节。因此,整个”帧”最短为64字节,最长为1518字节。如果数据很长,就必须分割成多个帧进行发送。

    3.3 MAC地址

    上面提到,以太网数据包中的 Head ,包含了发送者和接收者的信息。那么,发送者与接受者是如何标识的呢?

    以太网规定,连入网络的所有设备,都必须具有“网卡接口”。数据包必须是从一块网卡,传送到另一块网卡的。网卡具有地址,就是 MAC 地址,可作为接收与发送地址。

    上图为一网卡照片,每块网卡在出厂时,都会拥有一个MAC地址,长度是48个二进制位,通常用12个十六进制数表示。如下

    前6个十六进制是厂商编号后6个是该厂商的网卡流水号。有了MAC地址,就可以定位网卡与数据包的路径了。按理说,每一个 MAC 地址应该是独一无二的。但是事实并不是这样。不过一般情况下,我们很少会遇到两个网卡MAC地址一样的情况(概率很小),如果遇到了,只要两个设备不在一个子网也不会有什么影响。如果遇到了,还在同一个子网中,那么有两种解决方案:

    1. 网卡厂商提供有配置程序,可以直接修改硬件 MAC 地址
    2. 操作系统会提供伪造MAC地址的方式来解决冲突。

    3.4 因特网基于MAC地址的信息传播方式

    在这里需要提前说明一下,链路层的以太网基于 MAC 地址进行通信是只能实现子网内的通信的。即两台电脑需要在一个子网内。

    定义了地址只是第一步,下面一块网卡如何知道另一块网卡的MAC地址呢?

    回答是通过 ARP 协议来解决这个问题的,这个协议建立在网络层协议的基础上,过会儿会在网络层部分进行解释。

    其次我们需要考虑的是就算有了 MAC 地址,系统如何才能把数据包准确送到接收方呢?

    回答是以太网采用了很原始的一种手段,它并不是把数据包准确送到接收方,而是向本网络内所有计算机发送,让每台计算机自己进行判断,自己是否为接收方。

    上图中,1号计算机向2号计算机发送一个数据包,同一个子网络的3号、4号、5号计算机都会收到这个包。它们读取这个包的”标头”,找到接收方的MAC地址,然后与自身的MAC地址相比较,如果两者相同,就接受这个包,做进一步处理,否则就丢弃这个包。这种发送方式就叫做”广播”(broadcasting)。

    3.5 小节

    讲到这里,我们发现,链路层可以将物理层传来的0和1信号转成数据包的格式,并能通过网卡的 MAC 地址,实现一个子网内多台计算机之间的数据传送了。

    四、网络层(Network Layer)

    4.1 网络层的由来

    从上文我们知道,到链路层已经可以实现子网内设备间的通信了,但是不同子网里的设备还不能通信。因为首先我们知道一个子网不可能将所有的设备都包含进去,互联网是一个由无数子网络共同组成的一个巨型网络。

    如图,因此首先需要找到一种方法可以区分两个机器是否属于同一个子网,如果是,那就直接广播方式(上一节中提到的发送方式)发送就可以了。如果不是,就采用路由方式发送(路由方法本博客暂不涉及)。遗憾的是,MAC 地址本身无法做到这一点,因为它只与厂商有关,与所处网络无关

    由此导致了网络层的诞生,它的做法是引入一套新的地址,使得我们能够区分不同的计算机是否属于同一个子网络。这套地址叫做网络地址,简称网址

    于是,网络层的诞生使得每台计算机有了两个地址,一个是 MAC 地址,一个是网络地址。它们之间没有任何联系,MAC 地址绑定在网卡上,网络地址则是管理员分配的,它们只是随机的组合在了一起。

    网络地址帮助我们确定计算机所在的子网络,MAC地址则将数据包送到该子网络中的目标网卡。因此,从逻辑上可以推断,必定是先处理网络地址,然后再处理MAC地址。

    4.2 IP协议

    规定网络地址的协议叫做IP协议。它所定义的地址,被称为IP地址

    目前在我国,广泛采用的是IP协议第四版,简称 IPv4 。这个版本规定,网络地址由32个二进制位组成。

    习惯上,我们会将其分成四段的十进制数表示。从0.0.0.0一直到255.255.255.255

    互联网上每一台计算机都会分配到一个 IP 地址。这个地址分成两个部分,前一部分代表网络后一部分代表主机。比如,IP地址172.16.254.1,这是一个32位的地址,假定它的网络部分是前24位(172.16.254),那么主机部分就是后8位(最后的那个1)。处于同一个子网络的电脑,它们IP地址的网络部分必定是相同的,也就是说172.16.254.2应该与172.16.254.1处在同一个子网络。

    但是,问题在于单单从IP地址,我们无法判断网络部分。还是以172.16.254.1为例,它的网络部分,到底是前24位,还是前16位,甚至前28位,从IP地址上是看不出来的。

    那么,怎样才能从IP地址,判断两台计算机是否属于同一个子网络呢?这就要用到另一个参数子网掩码(subnet mask)

    所谓”子网掩码”,就是表示子网络特征的一个参数。它在形式上等同于IP地址,也是一个32位二进制数字,它的网络部分全部为1,主机部分全部为0。比如,IP地址172.16.254.1,如果已知网络部分是前24位,主机部分是后8位,那么子网络掩码就是11111111.11111111.11111111.00000000,写成十进制就是255.255.255.0。

    知道”子网掩码”,我们就能判断,任意两个IP地址是否处在同一个子网络。方法是将两个IP地址与子网掩码分别进行AND运算(两个数位都为1,运算结果为1,否则为0),然后比较结果是否相同,如果是的话,就表明它们在同一个子网络中,否则就不是。这里网络是分级的,不会出现错误的检测,等到我以后对于这一块理解的更加透彻了,会再专门写一篇博客进行说明。这里只需要理解到这里就足够了。

    比如,已知IP地址172.16.254.1和172.16.254.233的子网掩码都是255.255.255.0,请问它们是否在同一个子网络?两者与子网掩码分别进行AND运算,结果都是172.16.254.0,因此它们在同一个子网络。

    总结一下,IP协议的作用主要有两个,一个是为每一台计算机分配IP地址,另一个是确定哪些地址在同一个子网络。

    有了网络层、链路层、物理层,我们已经可以实现世界上接入互联网上任意两台机器的互联 互通了。

    4.3 IP数据包

    根据IP协议发送的数据,就叫做IP数据包。不难想象,其中必定会包含IP地址信息。前文说过以太网数据包的格式,而IP数据包正是占据了以太网数据包的数据部分。

    这充分体现了互联网分层的优势:上层的变动完全不会影响下层的结构。比如,数据链路层使用了以太网协议网络层即可以使用 IP 协议,即把 IP 数据包塞入以太网数据包的数据部分,也可以使用其他种类的网络层协议替换 IP 协议,即将其他种类的网络层协议数据包塞入以太网数据包的数据部分。

    具体来说,IP 数据包也分为包头与数据两个部分。

    包头部分主要包括版本、长度、IP 地址等信息,数据部分则是 IP 数据包的具体内容。将 IP 数据包放入以太网数据包后,以太网数据包就变成了如下这样。

    IP 数据包的包头部分的长度为20到60字节,整个数据包的总长度最大为65535字节。因此,理论上,一个 IP 数据包的数据部分,最长为65515字节。前面讲过,以太网数据包的数据部分,最长只有1500字节。因此,如果 IP 数据包超过了1500字节,它就需要分割成几个以太网数据包,分开发送了。

    4.4 APR 协议

    讲到这里,我们知道,如果想要实现两台计算机的通信,我们必须同时知道两个地址,一个是对方的 MAC 地址,另一个是对方的 IP 地址。通常情况下,对方的 IP 地址是已知的(一般通过 DNS 协议获得),而 MAC 地址,我们一般通过 APR 协议获得。

    其实这里是分两种情况的,一种情况是,两台机器不在同一个子网络,这时是无法得到对方的 MAC 地址的,只能把数据包发送给网关,让网关去处理。

    另一种情况,两台计算机处于同一个子网络,那么我们就可以使用 APR 协议了,得到对方的 MAC 地址。

    APR 协议(基于 IP 协议)是这么做的,发送一个数据包(包含在以太网数据包中),其中包含它所要查询的主机的 IP 地址,在对方的 MAC 地址一栏填,这表示一个广播地址。即子网络的每个主机收到这个包都要这样做:从中取出 IP 地址,与自身的 IP 地址进行比对。如果两者相同,做出回应,向对方报告自己的 MAC 地址,否则丢弃这个包。

    有了 APR协议之后,我们就可以查询得到子网内任意机器的 MAC 地址了。一般情况下只有第一次通信时才会需要查询,以后会将用过的 MAC 地址缓冲下来,下次直接本地查找缓冲,没有才会广播查询。

    4.5 小节

    有了网络层、链路层、物理层,我们已经可以实现世界上接入互联网上任意两台机器的互联互通了。

    五、传输层

    5.1 传输层的由来

    由上节我们知道,有了网络层、链路层、物理层,我们已经可以实现世界上接入互联网上任意两台机器的互联互通了。但是,同一台主机上有很多程序都需要用到网络,比如,你一边浏览网页,一边与朋友在线聊天。当收到一个数据包时,你需要判断它表示的是网页的内容还是在线聊天的内容。

    于是,传输层诞生了。网络层实现的是主机与主机之间的通信,传输层实现的是程序与程序间的交流。

    在传输层中,表示一个数据包到底供哪个程序使用的参数叫做端口(port)。它的本质更像是使用网卡的程序的编号。每个数据包都发送到主机的特定端口,所以不同程序可以取走自己所需要的数据。

    端口是0到65535之间的一个整数,刚好16个二进制位。其中0到1023端口被系统占用,用户只能选择大于1023的端口。

    网络层定义主机位置,传输层定义端口位置。确定了主机与端口,便能实现程序之间的交流。因此,在 Unix 系统中,把主机+端口叫做套接字(socket)。有了它,便可以进行网络应用程序的开发了。

    下面讲讲两个传输层协议,UDP 协议与 TCP 协议。

    5.2 UDP 协议

    UDP 协议就是在数据包中加入了端口信息,它也是标头+数据的格式,如下:

    其中, Head 部分主要定义了发出端口接收端口Data 部分具体的内容。将整个 UDP 数据包放入 IP 数据包的数据部分,结合前面说的,IP 数据包放进以太网数据包的数据部分,最后整个以太网数据包是这个样子的:

    UDP 数据包十分简单, Head 部分一共只有8个字节,总长度不超过65535字节。

    5.3 TCP 协议

    UDP 协议简单有效,容易实现,但是可靠性差,因为一旦它的数据包发出,无法确定对方能否收到。

    为了解决这个问题,提高网络可靠性, TCP 协议诞生了。这个协议十分复杂,此处可以简单的认为,它是有确认机制的 UDP 协议,即它的每一个数据包发出后,都会收到一个 ACK 响应包。如果一个数据包丢失,就收不到 ACK,发出方就知道有必要重新发送这个数据包了。

    因此,TCP协议能够确保数据不会遗失。它的缺点是过程复杂、实现困难、消耗较多的资源。

    TCP 数据包与 UDP 数据包一样内嵌在 IP 数据包的 Data 部分。 TCP 数据包没有长度限制,理论上可以无限长,但是为了保证网络的效率,通常 TCP 数据包的长度不会超过 IP 数据包的长度,以确保单个 TCP 数据包不必再分割。

    六、应用层

    上节中提到,传输层可以使得应用程序之间进行数据传输。这时,我电脑上的应用程序接收到了数据包,并逐层去掉包头,最后只剩下一个数据部分。应用层的作用就是规定应用程序的数据格式。使得客户端可以将收到的数据包转换成自己想要的格式,并呈现给用户。

    举例来说,通过 TCP/IP 协议,各种各样的程序可以传递数据,比如 Email、WWW、FTP等等。应用层的各种程序协议便规定了电子邮件、网页、 FTP 数据的格式,这些应用程序共同构成了应用层。

    应用层是最高的一层,直接面向用户。它的数据就放在 TCP 数据包的数据部分。因此,最终的以太网数据包是如下格式的。

    七、总结

    上面就是对互联网整个分层结构的解析,总结一下,一台主机在发出一个数据包时需要经历一下步骤:

    1. 应用层将数据信息按照标准的格式(如http报文的格式)组织好,然后向下给到传输层;
    2. 传输层为应用层的数据包添加包头(比如UDP就是端口信息),变成 UDP 数据包格式,向下给到网络层;
    3. 网络层为传输层的数据包添加包头(ip地址等信息),组装成 IP 数据包的格式,向下给到链路层;
    4. 链路层为网络层的数据包添加包头(MAC地址等信息),组装成 以太网数据包的格式,向下给到物理层;
    5. 物理层将以太网数据包转换成0和1电信号,发出去。

     

     

     

     

     

    展开全文
  • 互联网分层架构演进 目录 互联网分层架构本质 互联网分层架构演进 总结 一互联网分层架构本质 典型分层架构 传统三层架构 服务化后四层架构 MVC服务端与客户端 互联网分层架构的本质 数据处理 -> 各层次的形态 数据...
  • 上图是一个典型的互联网分层架构:客户端层:典型调用方是browser或者APP站点应用层:实现核心业务逻辑,从下游获取数据,对上游返回html或者json数据-缓存层:加速访问存储数据-数据库层:固化数据存储 如果实施了...

    640?wx_fmt=png&wxfrom=5&wx_lazy=1

    上图是一个典型的互联网分层架构

    • 客户端层:典型调用方是browser或者APP

    • 站点应用层:实现核心业务逻辑,从下游获取数据,对上游返回html或者json

    • 数据-缓存层:加速访问存储

    • 数据-数据库层:固化数据存储

     如果实施了服务化,这个分层架构图可能是这样:

    640?wx_fmt=png&wxfrom=5&wx_lazy=1

    中间多了一个服务层

     

    640?wx_fmt=png&wxfrom=5&wx_lazy=1

    同一个层次的内部,例如端上的APP,以及web-server,也都有进行MVC分层

    • view层:展现

    • control层:逻辑

    • model层:数据

     

    可以看到,每个工程师骨子里,都潜移默化的实施着分层架构

     

    那么,互联网分层架构的本质究竟是什么呢?

    如果我们仔细思考会发现,不管是跨进程的分层架构,还是进程内的MVC分层,都是一个“数据移动”,然后“被处理”“被呈现”的过程,归根结底一句话:互联网分层架构,是一个数据移动,处理,呈现的过程,其中数据移动是整个过程的核心

     

    0?wx_fmt=png

    如上图所示:

    数据处理和呈现要CPU计算,CPU是固定不动的

    • db/service/web-server都部署在固定的集群上

    • 端上,不管是browser还是APP,也有固定的CPU处理

     

    数据是移动的

    • 跨进程移动:数据从数据库和缓存里,转移到service层,到web-server层,到client层

    • 同进程移动:数据从model层,转移到control层,转移到view层

     

    0?wx_fmt=png

    数据要移动,所以有两个东西很重要:

    • 数据传输的格式

    • 数据在各层次的形态

     先看数据传输的格式,即协议很重要:

    • service与db/cache之间,二进制协议/文本协议是数据传输的载体

    • web-server与service之间,RPC的二进制协议是数据传输的载体

    • client和web-server之间,http协议是数据传输的载体

     再看数据在各层次的形态,以用户数据为例:

    • db层,数据是以“行”为单位存在的row(uid, name, age)

    • cache层,数据是以kv的形式存在的kv(uid -> User)

    • service层,会把row或者kv转化为对程序友好的User对象

    • web-server层,会把对程序友好的User对象转化为对http友好的json对象

    • client层:最终端上拿到的是json对象

     

    结论:互联网分层架构的本质,是数据的移动。

     

    为什么要说这个,这将会引出“分层架构演进”的核心原则与方法:

    • 让上游更高效的获取与处理数据复用

    • 让下游能屏蔽数据的获取细节封装

     

    弄清楚这个原则与方法,再加上一些经验积累,就能回答网友经常在评论中提出的这些问题了:

    • 是否需要引入DAO层,什么时机引入

    • 是否需要服务化,什么时机服务化

    • 是否需要抽取通用中台业务,什么时机抽取

    • 是否需要前后端分离,什么时机分离

    (网友们的这些提问,其实很难回答。在不了解业务发展阶段,业务规模,数据量并发量的情况下,妄下YES或NO的结论,本身就是不负责任的。)

    更具体的分层架构演进细节,下一篇和大家细究。

     总结

    • 互联网分层架构的本质,是数据的移动

    • 互联网分层架构中,数据的传输格式(协议)与数据在各层次的形态很重要

    • 互联网分层架构演进的核心原则与方法:封装与复用

     思考

    哪一个系统的架构,不是“固定CPU,移动数据”而是“固定数据,移动CPU”呢?


    From: https://blog.csdn.net/z50l2o08e2u4aftor9a/article/details/78213211

    展开全文
  • 大型互联网分层架构图

    大型互联网分层架构图

    在这里插入图片描述

    展开全文
  • 互联网分层架构分析.docx
  • 互联网分层教学法应用于高校体育舞蹈教学的实验研究.pdf
  • 互联网分层架构的本质》简述了两个观点: 互联网分层架构的本质,是数据的移动 互联网分层架构演进的核心原则:是让上游更高效的获取与处理数据,让下游能屏蔽数据的获取细节   《分层架构:什么时候抽象...

    互联网分层架构的本质》简述了两个观点:

    • 互联网分层架构的本质是数据的移动

    • 互联网分层架构演进的核心原则:是让上游更高效的获取与处理数据,让下游能屏蔽数据的获取细节

     

    分层架构:什么时候抽象DAO层,什么时候抽象数据服务层》中的观点是:

    • 当手写代码从DB中获取数据,成为通用痛点的时候就应该抽象出DAO,简化数据获取过程,提高数据获取效率,向上游屏蔽底层的复杂性

    • 当业务越来越复杂,垂直拆分的系统越来越多,数据库实施了水平切分,数据层实施了缓存加速之后,底层数据获取复杂性成为通用痛点的时候就应该抽象出数据服务层,简化数据获取过程,提高数据获取效率,向上游屏蔽底层的复杂性

     

    文本将要解答的问题是:

    • 基础数据的访问需要服务化,务层是否需要服务化

    • 如果需要服务化,什么时候服务化

     

    基础数据的访问服务化之后,一个业务系统的后端架构如上:

    • web-server通过RPC接口,从基础数据service获取数据

    • 基础数据service通过DAO,从db/cache获取数据

    • db/cache存储数据

     

    随着时间的推移,系统架构并不会一成不变:

    • 随着业务越来越复杂,业务会不断进行垂直拆分

    • 随着数据越来越复杂,基础数据service也会越来越多

     

    于是系统架构变成了上图这个样子,业务垂直拆分,有若干个基础数据服务:

    • 垂直业务要通过多个RPC接口访问不同的基础数据serviceservice共有是服务化的特征

    • 每个基础数据service访问自己的数据存储,数据私有也是服务化的特征

     

    这个架构图中的依赖关系是不是看上去很别扭?

    • 基础数据service与存储层之前连接关系很清晰

    • 业务web-server层与基础数据service层之间的连接关系错综复杂,变成了蜘蛛网

     

    再举一个更具体的例子,58同城列表页web-server如何获取底层的数据?

    • 首先调用商业基础service,获取商业广告帖子数据,用于顶部置顶/精准的广告帖子展示

    • 再调用搜索基础service,获取自然搜索帖子数据,用于中部自然搜索帖子展示

    • 再调用推荐基础service,获取推荐帖子数据,用于底部推荐帖子展示

    • 再调用用户基础service,获取用户数据,用于右侧用户信息展示

     

    如果只有一个列表页这么写还行,但如果有招聘、房产、二手、二手车、黄页等多个大部分是共性数据,少部分是个性数据的列表页,每次都这么获取数据,就略显低效了,有大量冗余、重复、每次必写的代码。

     

    特别的,不同业务上游列表页都依赖于底层若干相同服务:

    • 一旦一个服务RPC接口有稍许变化,所有上游的系统都需要升级修改

    • 子系统之间很可能出现代码拷贝

    • 一旦拷贝代码,出现一个bug,多个子系统都需要升级修改

     

    如何让数据的获取更加高效快捷呢?

    业务服务化通用业务服务层的抽象势在必行。

     

    通过抽象通用业务服务层,例如58同城“通用列表服务”:

    • web-server,可以通过RPC接口,像调用本地函数一样,调用通用业务service一次性获取所有通用数据

    • 通用业务service,也可以通过多次调用基础数据service提供的RPC接口,分别获取数据,底层数据获取的复杂性,全都屏蔽在了此处 


    是不是连接关系也看起来更清晰?


    这样的好处是:

    • 复杂的从基础服务获取数据代码,只有在通用业务service处写了一次,没有代码拷贝

    • 底层基础数据service接口发生变化,只有通用业务service一处需要升级修改

    • 如果有bug,不管是底层基础数据servicebug,还是通用业务servicebug,都只有一处需要升级修改

    • 业务web-server获取数据更便捷,获取所有数据,只需一个RPC接口调用

     

    结论

    业务越来越复杂,垂直拆分的系统越来越多,基础数据服务越来越多,底层数据获取复杂性成为通用痛点的时候应该抽象出通用业务服务,简化数据获取过程,提高数据获取效率,向上游屏蔽底层的复杂性。

     

    最后再强调两点:

    • 是否需要抽象通用业务服务,和业务复杂性,以及业务发展阶段有关,不可一概而论

    • 需要抽象什么通用业务服务,和具体业务相关

     

    任何脱离业务的架构设计,都是耍流氓


    From:

    https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651960482&idx=1&sn=feb27bdd202093a5e4747f7c043415d1&chksm=bd2d017e8a5a8868888e553a30559cb9eefa93e0a1da557342e1a13127ca67143ea87b721363&scene=21#wechat_redirect


    展开全文
  • 当业务越来越复杂,垂直拆分的系统越来越多,数据库实施了水平切分,数据层实施了缓存加速之后,底层数据获取复杂性成为通用痛点的时候,就应该抽象出数据服务层,简化数据获取过程,提高数据获取效率,向上游屏蔽...
  • 分层抽象,简化数据获取过程,提高数据获取效率,向上游屏蔽底层的复杂性。   最后再强调两点: 是否需要前后端分离,和业务复杂性,以及业务发展阶段有关,不可一概而论 本文...
  • 当业务越来越复杂,端上的产品越来越多,展现层的变化越来越快越来越多,站点层存在大量代码拷贝,数据获取复杂性成为通用痛点的时候,就应该进行前后端分离分层抽象,简化数据获取过程,提高数据获取效率,向上游...
  • 今天问关于老师分布式的概念和高并发的理解,之前由于自己的粗心马虎,一直将这两个概念没搞清楚,刚好今早看到一篇互联网分层架构的本质,觉得讲的十分好,让自己清晰了很多抽象概念。转载分享以待以后学习。上图是...
  • 中国罈荸孜术大学 University of Science and Technology of China 云计算 Cloud Computing 引言 中国鲱学孜术大 University of Science and Technology of China 近年来,云计算已成为业界最热门的研究方向之一几乎...
  • 互联网分层架构的本质,是数据的移动。   互联网分层架构演进的核心原则: 让上游更高效的获取与处理数据,复用 让下游能屏蔽数据的获取细节,封装   这些在上一篇《互联网分层架构的本质》中有详尽的...
  • 互联网分层架构

    2017-01-12 14:13:11
    ELK(ElasticSearch+Logstash+ Kibana)搭建实时日志分析平台, Mysql分布式中间件:Cobar,oneproxy, ElasticSearch类似sphninx,solr docker是一个容器,类似管理进程的一个容器 中间件在数据库层上和应用层之下
  • 本文将体系化总结这天撰写的分层架构设计系列文章。一、总起文章:《互联网分层架构的本质》内容:互联网分层架构的本质互联网分层架构演进的方法论二、数据服务化文章:《分层架构设...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 52,338
精华内容 20,935
关键字:

互联网分层