我上大学时的第一台电脑是微星的一款游戏本，当时买它的原因很简单，性能足够强大，无论是编程等日常任务还是游戏它都可以胜任。现在回想起来，依稀记得它炫酷的灯光、强悍的性能以及用它驰骋虚拟世界的快感。后来年纪渐长，打游戏的热情也逐渐减少，虽然那台电脑仍在家中，但已经落后的性能让我鲜有机会“宠幸”它。再后来，读研之后换了 Mac 后更是没怎么碰过游戏了。 大家都说正经人谁用 Mac 打游戏，一开始我也是这么认为的，毕竟买来就是用来写代码的，可是最近发现的一个有趣玩意让我对这个问题有了新的想法，那就是——云游戏。 云计算？云？ 以下内容摘自百度百科 云游戏是以云计算为基础的游戏方式，在云游戏的运行模式下，所有游戏都在服务器端运行，并将渲染完毕后的游戏画面压缩后通过网络传送给用户。在客户端，用户的游戏设备不需要任何高端处理器和显卡，只需要基本的视频解压能力就可以了。 我将上述内容中一些比较重要的点做了标注，百科在对于云游戏的描述时，第一句就直接阐明了云游戏的基础是云计算，那么「云计算」以及「云」指的是什么？ 云计算（cloud computing），是一种基于互联网的计算方式，通过这种方式，共享的软硬件资源和信息可以按需提供给计算机和其他设备。提供资源的网络被称为“云”。 看完上面一句话有些小伙伴还会不太清楚，我们先来回顾下之前的知识。我在《互联网是如何工作的》这一篇文章中提到：一台又一台的服务器通过“网线”连接在了一起，形成了类似下面这样的结构 👇 众多服务器组成的这种结构被称为“互联网”，而其中每台服务器都被称作“节点”。 事实上这些节点都和你的本机无关但又何你的本机有关。 为什么这么说呢？ 无关的原因是，这些节点所包含的计算能力（CPU、GPU）和存储文件都不是你的。有关的原因是，你可以通过某些方式运用这些能力和文件。 而上述所说的一个个节点便是云计算的核心，即「云」。 大量的水滴漂浮在空中，聚合成云。和我们所说的云很相似，只是这里的云是由大量的数据存储、计算资源和应用程序组成，这便是云计算服务。 「云」其实是一个抽象的概念，并不像服务器有一个具体的实物可以展示，我们可以把「云」理解为一个资源共享池。举个例子就是，我有很多东西，家里放不下了，放到一个特定的地方存着，随时提取。大家都可以访问的就是「公有云」，只有特定的人可以访问的就是「私有云」。 这个“东西”一般是指数据、软件、服务等，而“特定的地方”就是云。所以对于云计算我们也可以简单的理解为：将本地需要进行的计算任务迁移到云端进行。 如今云计算及其产物已经深入我们的生活，我们熟悉的百度网盘、iCloud 还有最近的阿里网盘就是「云存储」，以及本文要介绍的主角「云游戏」也是云计算的产物。 云游戏 云游戏的原理 在现在这个游戏变得越来越流行的时代，人们却被低配设备所限制，比如我，虽然出了很多新游戏，却苦于手头没有一台合适的机器用于玩耍。以往玩游戏我需要配一台游戏主机或者高性能游戏本，少说也要五六千，因为游戏对于计算机性能的要求是非常高的，这些都必须依赖玩家自己的电脑。 但是在云游戏模型中，所有的游戏逻辑和渲染都在服务器端运行，然后再从服务器把压缩的画面传给用户，这样玩家就不需要一台高性能的计算机了，对于设备的要求便也就是基本的视频渲染能力和可靠稳定的网络环境了。 云游戏摆脱了对硬件的依赖。对服务器来说，仅仅需要提高服务器性能而不需要研发新主机；对用户来说，可以得到更高的画质而不用购买高性能的计算机。也就是说，用户可以花一小笔钱租一个更好的计算机来玩各种游戏，就像用机顶盒看电视一样，这意味着玩家可以在计算机硬件，特别是 GPU 上省下一大笔钱。 云游戏需要什么？ 低延时 在解释云游戏的原理时，我们提到了云游戏的游戏逻辑和渲染都是在服务器端进行，然后将画面传送给用户，所以说一台可以高速上网的设备极其重要。如果网速不够快，不够稳定就无法及时接收到高质量的画面。 说到这我们需要介绍一下网络延时，所谓网络延时指一个数据包从用户的计算机发送到网站服务器，然后再立即从网站服务器返回用户计算机的来回时间。通俗的讲，就是数据从电脑这边传到那边往返所用的时间。 以我们现在还在普遍使用的 4G 网络而言，它的延时基本在 30ms ～ 70ms 波动，部分信号不好的地方延时还会更大。这还只是数据传输时的网络延时，如果算上画面编解码的时间，延时达到 100ms 是很容易的事情。 我们知道视频的原理就是每秒播放多张静态画面，画面越多，对于人的观感来说就是视频越流畅。这是因为对于人眼来说，我们的视觉神经是有一个反应速度的，并且对于不同频率的光有不同的暂留时间。其时值约是 1/16 秒，也就是 62.5ms。也就是说，如果网络传输所消耗的延时大于 62.5ms，我们就会觉得画面很不流畅（62.5 是一个理论值，实际情况下这个数值会小于 62.5ms，对延时的要求更苛刻）。 高带宽 现在我们来做一个简单的数学题。 刚才我们说到视频的原理是每秒播放多张静态图像。我们知道图像都是由一个个像素点构成的，对于一张非黑即白的二值图像，不压缩的情况下一个像素只需要 1 个 bit。如果是 256 种状态的灰度图像，不压缩的情况下一个像素需要 8bit（1 字节，256 种状态）。如果用 256 种状态标识屏幕上某种颜色的灰度，而屏幕采用三基色红绿蓝（RGB），不压缩的情况下一个像素需要占用 24bit（3 字节），这个就是常说的 24 位真彩色。 ...

1. 前言 之前看到 M1 芯片出来之后，就想说些什么，结果光写 x86 和 ARM 就写了 4000 多字，考虑到文章篇幅，只得分为上下两篇，上一篇文章发出后有很多人表示非常喜欢，让我赶紧更新，在这里向支持我的读者们表示感谢 🙏。 那么话不多说，这篇我们来聊一聊，这次的芯片到底有何不同，以至于让那么多人说苹果不讲武德。 在这之前我先说明，我只是一个计算机专业的学生，从来就没有自诩自己是什么专家学者，我写博客也只是为了做一些简单的科普，把自己知道的一些知识分享给大家。如果文章中有什么错误的地方，还请各位读者指正。 2. M1 芯片 ≠ CPU 首先，我们要先摆脱一个认知误区，M1 芯片不是一块 CPU，而是一块专为 Mac 设计的 SoC 芯片。CPU 只是 M1 芯片的一个组成部分。 所谓 SoC 芯片，指的是系统级芯片（System on Chip），也称片上芯片，是一个将电脑或其他电子系统集成到单一芯片的集成电路。 SoC 集成的主要包括处理器(CPU，GPU 等)、基带、各种接口控制模块、各种互联总线等，其典型代表为手机芯片。举个例子，CPU 公司将自己的所生产的 CPU 设计卖给其他公司，而其他公司就根据该 CPU 自己添加上所需要的各种外设控制器，这就是 SoC。 所以简单来说：SoC 就是一块集成了 CPU、GPU 等多种结构的芯片。因此，千万不要简单的认为 M1 芯片就是 CPU。 官网有一张图，就很好地说明了 M1 芯片的组成成分。如下图所示，苹果称其为统一内存架构（Unified memory architechture），即通过 Fabric 高速总线将中央处理器、图形处理器、神经网络引擎、缓存、DRAM 内存全部连接在一起。因此，M1 芯片的强大，绝不是靠一个强悍的 CPU 支撑的，而是众多性能强大的部件结合苹果优秀的设计共同努力的成果。 3. 统一内存架构（UMA） 通过上一段内容，我们知道了 M1 芯片的强大光靠一颗强大的 CPU 是不够的，毕竟苹果也没办法突破物理定律，单纯通过设计让 CPU 的性能提升数倍。很明显苹果采用了其他的技巧来弯道超车，而**「统一内存架构」**就是其中之一。 ...

最近这段时间数码圈里最火的莫过于苹果最新推出的三款基于自研芯片 M1 的电脑了，分别是 MacBook Air、13 寸的 MacBook Pro 以及 Mac Mini。其热度也是久居不下，哪怕距离发布会已经过去 10 多天了，却仍然能看见各种评测视频、文章层出不穷。在一些平台搜索 MacBook M1 的相关视频、文章，无一例外都是：Apple 真香、性能起飞、虐杀英特尔等等这类词汇。 最近新出的拆解视频我也有看了一些，可以发现其实新出的 Mac 在模具方面和前几年相比没有什么太大的变化，最大的亮点在于便是其自研的 ARM 芯片 M1 了。 此次的 M1 芯片的出现，带火了另一个名词，ARM 架构。同时也让一个探讨许久的问题又重新浮出水面：ARM 芯片真的会超越 x86 芯片吗？ 本文先不探讨 M1 芯片的设计思路，先来认识学习下两个经常听见但有可能并不太清楚的名词：ARM 与 x86。 ARM 与 x86 随着信息技术的普及，在现在，相信你随便找一个人问他知不知道 CPU 是什么，我想他的答案都会是肯定的。但如果你再问他，知道 CPU 的 x86 架构和 ARM 架构吗，我想一些计算机专业的同学可能都不会太清楚，因此在谈此次苹果的 M1 芯片之前，我们先来聊一聊 ARM 与 x86。 时下「打工人」这个名词很火，而 CPU 就是整个计算机中最勤劳且最核心的打工人。x86 和 ARM 便是 CPU 中两种不同类型的打工人，这两种架构很大一个区别就是指令集。 架构？指令集？ 看到这里你是不是很疑惑，架构到底是什么？指令集又是什么？别急，我们还是以打工人为例，将 CPU 代入该角色来说明。 事实上，CPU 做的事情很简单也最核心，简单来说就是接收指令+运算。CPU 和千千万打工人一样，首先要有正常的工作能力（即执行能力/运算能力），然后又有足够的逻辑能力（能明白做事的顺序），最后还要有一定的理解能力，能听懂别人的话（即指令集），才能正常工作。而把这些集中在一起就构成了所谓的「架构」。你可以将「架构」理解为一套**“工具”、“方法”和“规范”的集合**。 ...

前言 我们每天都在使用网络，面对这个看不见也摸不着的东西，你有没有思考过他的背后发生了什么吗？ 相信很多人第一次接触网络是通过一个叫「网站」的东西，那网站又究竟是什么？ 影视剧里经过出现的通过 IP 地址获取定位，是真的可以实现吗？ 相信你在阅读本文后就会有一个清晰的认知了。 网站？服务器？网络？ 首先我们要理解的是，一个网站只是一堆保存在硬盘上的文件， 就像你的电影、 音乐或图片一样。 然而，网站的唯一的不同之处是： 网站包含一种称为 HTML 的代码。也正是这个叫 HTML 的东西让网站有了好看的皮肤（界面）。 如果你对编程不熟悉，一开始你会很难理解 HTML，因为 HTML 其实是让你的浏览器（Chrome、Safrai、FireFox、IE 等）去**“理解”**的信息，浏览器读得懂这些代码，然后会按照代码的内容展示这些文件。 就和我们对待自己的电脑文件一样，我们会把 HTML 文件存储在硬盘的某个位置， 然后通过浏览器去访问这些 HTML 文件。对于互联网，我们使用特定而功能强大的电脑，我们称之为服务器，所以其实服务器本质上也是一台电脑，它们没有屏幕、鼠标或者键盘，因为它们的主要目的是存储数据，并用它来提供服务。 这就是为什么它们被称作服务器的原因——因为他们用数据服务你。 因此如果想要存储更多的信息，我们有两种解决方案： 增加服务器的容量 增加服务器的数量 显而易见的，一台服务器可以存储的信息是有限的，哪怕是不断增加一台机器的容量也肯定是有上限的。所以，我们可以通过第二种方式以达到**「量变产生质变」**的效果。 于是，一台又一台的服务器通过“网线”连接在了一起，形成了类似下面这样的结构 众多服务器组成的这种结构被称为“互联网”，而其中每台服务器都被称作“节点”，所以「顺着网线来打你」是有理论依据的。 IP 地址？域名？ 那么紧接着，问题就来了。 既然网络是用来存储文件的，对于我这个初次上网的人，我又如何找到我想要的内容呢？ 不着急，我们先来设想一个场景。 闰土家里有几套房子，其中房子 A 被闰土爸妈当作仓库了，一天，妈妈让闰土去房子 A 拿一个家传的盒子 X，说是给未来儿媳妇准备的，房子 A 在 a 市 b 区 c 小区 d 号，并给了侧门钥匙，让他从侧门 C 进去拿，盒子 X 在房子 A 的 2 楼的房间 B 里的衣柜。 我们可以从上述场景中抽象出盒子 X 的位置： ...

在之前的《从找对象到多线程》一文中我曾介绍了一些和多线程有关的知识，而谈到多线程，就一定离不开「锁」这个名词。在 Java 中，锁的使用主要有两种：Synchronized 关键字和 Lock 接口，本文将会换个角度来聊一聊 synchronized 中的锁。 Synchronized 用的锁是存在对象头里的，用来表明当前对象所持有的锁。在 Java SE1.6 之前，Synchronized 是作为重量锁出现的，一旦使用了 synchronized，就一定会阻塞到其他线程。而在 Java SE1.6 后，为了减少获得锁和释放锁带来的性能问题，引入了"偏向锁"和"轻量锁"的概念。由此可以得知，在新的 Java 中，锁一共有 4 种状态：无锁状态、偏向锁状态、轻量锁状态和重量锁状态。这几个状态会随着竞争不断升级且只能升级不能降级，即轻量锁只会升级到重量锁而不会降级到偏向锁。 以上的解释未免太过官方了，我们从一个小例子入手。 我们用女神来表示同步代码块，就好比女神有很多追求者，同步代码块也会被很多线程执行。有一天女神的微博状态变成了「单身」，此时她就处于无锁状态，于是这些追求者纷纷创建了一个名为**「找对象」的线程**，此时对于女神（对象）来说，还没有任何线程来访问她，所以当第一个男生小 A 试图邀请她看电影的时候**（获取锁）**，她会偏向小 A 的邀请，此时她就是处于「偏向锁」状态的。有了这次经历之后，小 A 就知道该怎么邀请女神而不用反复试探了，这就是「可重入锁」，即同一个线程可以多次访问同一代码块。 再后来女神发了一条微博，说今天和这个男生看电影很开心。这条微博被其他男生看见了，大家也都知道了女神这个对象的偏向状态了。可还是有男生小 B 想追女神，此时这两个男生各自「找对象」的线程就在女神这个对象上产生了竞争。 小 B 一直关注女神的微博动态，他心想着，只要小 A 被女神拒绝了，女神就会变成「无锁」状态，自己也就有机会被女神偏向了。女神也知道小 B 在追自己，为了找到最合适的另一半，女神也在暗中观察小 B，有两个竞争者同时竞争，这时候她就处于**「轻量锁」的状态。虽然女神明显更喜欢小 A，但在小 B 心里觉得小 A 除了比自己早点出现外根本不具有和自己竞争的能力，于是不断给女神献殷勤，保持关系，这就叫自旋，**不断的将自己的时间花费在获取锁上，逐渐成为一条舔 🐶。 虽然一开始女神也会偶尔答应小 B 的邀请，但当竞争者越来越多后，小 B 变得疯狂起来，追求逐渐变成了骚扰，女神也逐渐不耐烦起来。最终在小 A 的努力下，女神和小 A 确定了关系，并发了微博告知众人，此时她的状态就升级成为**「重量锁」状态**。这时，除了小 A，其他所有竞争者的「找对象」线程都没有办法再追求女神了。这样做的好处就是赶紧断了那些追求者的念头，让他们可以早日觅得其他良人，不要在一棵树上吊死。 从线程的角度来看，重量锁使除了拥有锁的线程外的其他所有线程都阻塞，这样可以有效防止 CPU 空转，避免造成资源的浪费。 在偏向锁和轻量锁阶段，女神还没有和任何人确定关系，只要给点甜头小 B 等其他追求者都会很开心，这是一种「乐观锁」。而一旦女神和小 A 确定了关系，自身状态升级为重量锁后，小 B 就很不开心了，对他来说这就是一种「悲观锁」。 ...

背景 我们知道在微服务架构风格中，一个大应用被拆分成为了多个小的服务系统提供出来，这些小的服务他们自成体系，也就是说这些小系统可以拥有自己的数据库，框架甚至语言等，这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用。 在《浅入浅出消息队列》这一篇文章中，我提到了消息队列是方便服务与服务之间的通信解耦，如下图所示： 那么这时候问题来了，如果一个外部的应用（浏览器、App）要去访问这个大应用怎么办？ 很简单啊，直接通过 HTTP 请求不就完了？ 问题 真的这么简单吗？我们以淘宝的商品详情页为例： 如上图所示，这个页面包含了视频、库存、商品价格、商品评价等内容，这些数据都来自不同的微服务中，所以没办法像传统单体应用一样依靠数据库的 join 查询来得到最终结果，因此就需要多次调用以检索数据，如下图所示： 这就会引发几个严重的问题： 不同的客户端设备可能需要不同的数据。Web,H5,APP，需要单独写一套 API 多次客户端请求导致用户体验不佳。移动网络相较于服务于服务间的局域网，有更低的带宽和更高的延时，如果可以同时执行请求倒也还好，但如果客户端要按照顺序执行请求，就会让用户体验变得异常糟糕。 缺乏封装导致前后端不协调。过分的拆分 API，会导致客户端和服务端过度耦合，再加上移动端 APP 的新版本迭代到每个手机用户时需要很久，这样会使后端很难更改服务的 API。 这样显然是不好的设计，因此，本期的“天降猛男”就出现了——API 网关。 API 网关 在介绍 API 网关前，我们先来介绍一个设计模式——外观模式。 外观模式（Facade Pattern）它向现有的系统添加一个接口，来隐藏系统的复杂性。类图如下所示： 之所以要在说 API 网关前说一下外观模式，是因为二者的设计理念是类似的。 和外观模式类似，API 网关封装了应用程序的内部架构，并为其客户端提供 API，他还可能具有其他职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。下图展示了客户端、API 网关和服务之间的关系。 所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。其出现也是侧面贯彻了软件工程中**“高内聚，低耦合”**的思想。 核心作用 API 网关负责请求路由、API 组合和协议转换。来自外部客户端的所有 API 请求首先会先转到 API 网关，后者再将请求路由到相应的服务。API 网关使用 API 组合模式处理其他请求，调用多个服务并聚合结果。同时他还可以在客户端友好的协议（例如 HTTP）与客户端不友好的协议之间进行转换。 请求路由 当 API 网关收到请求时，随机会查询路由映射，该映射将指定请求路由到哪个服务。例如，路由映射可以将 HTTP 方法和路径映射到服务的 HTTP URL，这一点和 Nginx 提供的反向代理的功能是一样的，后面我们也会对其进行一个比较。 ...

又是一年放榜日，众多考生满怀期待的点开招生网，结果输了信息才发现根本没办法查询——查询人数太多了，直接把系统打挂了！ 这个时候，还没翻身的码农闰土被问到一个直击心灵的问题：这个系统可用性达到了多少个 9？ 想要回答这个问题，我们得先有些前置知识。 可用性&可靠性 这两个词很相似，我也一直找不到一个很好的定义区分这两个词，直到后来在看分布式系统的时候，看到了一个解释： 可用性被定义为系统的一个属性，它说明系统已准备好，马上就可以使用。换句话说，高度可用的系统在任何给定的时刻都能及时地工作。 可靠性是指系统可以无故障地持续运行，是一个持续的状态。与可用性相反，可靠性是根据时间段而不是任何时刻来进行定义的。 举个例子，想要评估一个舔 🐶，可用性就是你找他的时候能不能找到，而可靠性就是你需要花钱的时候他出手大不大方。一个舔 🐶 如果随叫随到，但是花钱太抠，就是高可用、低可靠；而如果他经常找不到人，但出手很大方，就是低可用、高可靠。 类比到系统时，如果系统在每小时崩溃 1ms，那么它的可用性就超过 99.9999%，但是它还是高度不可靠。与之类似，如果一个系统从来不崩溃，但是每年要停机两星期，那么它是高度可靠的，但是可用性只有 96%。 百度百科对于系统可靠性的解释是：系统可靠性一般是指在规定的时间内和规定的工况下，系统完成规定功能的能力/概率。也就是系统的无故障运行概率。而在我们在评估一个系统的可用性和可靠性时，一般都会说三个 9，四个 9 之类的。这些一般都是说系统的**SLA(Service Level Agreement)**具体是几个「9」，以此，来表示该系统一年中具体宕机的时间。对于这几个 9 的解释，我会放到第三节来详细解释。 不过，在实际交流过程中，大多数人对这两个词的理解还是差不多的。况且咬文嚼字也并非本文的主题，接下来我们来看看可用性的计算方式。 可用性计算 通常我们用 A 表示一个系统的可用性，用以下几个指标来辅助计算： 相关指标 MTBF MTBF,即平均故障间隔时间，英文全称是“Mean Time Between Failure”。是衡量一个产品（尤其是电器产品）的可靠性指标。单位为“小时”。具体来说，是指相邻两次故障之间的平均工作时间，也称为平均故障间隔。 MTTR MTTR，全称是 Mean Time To Repair，即平均修复时间。是指可修复产品的平均修复时间，就是从出现故障到修复中间的这段时间。MTTR 越短表示易恢复性越好。 通过上述公式计算出单个组件的可用性后，我们便可以以此计算出整个系统的可用性，而系统可用性是通过将系统建模为串联和并联的组件来计算的。以下规则用于确定系统是串联的还是并联的： 如果组件的失效导致组合变得不可操作，则认为这两个部件是串联操作的 如果组件的故障导致另一部件接管故障部件的操作，则认为这两部件并行操作 串行可用性 如上图所示，两个组件 X 和 Y，如果有一个出问题导致整个组合都不可用，就认为 X 和 Y 这两个组件是串联的。只有组件 X 和组件 Y 同时可用时，整个组合才可用。由此可见，组合的可用性是这两部分的乘积，公式如下： A = Ax Ay 从上面的等式我们看出，串联系统中，整体组合的可用性，总是低于单个组件的可用性。 对于上面 X 和 Y 两个串联组件，可用性如下： ...

原文地址：How to Create a Reusable Web Scraper 网页爬虫是个非常有趣的玩具。不过不好玩的是，我们需要根据不同网页上的元素不断的调整自己的代码。这就是为什么我要着手实现一个更好的网页爬虫项目——通过该项目可以以最少的更改实现对新网页的爬取。 第一步是将网页爬虫按照逻辑分成每个独立的部分： 页面请求器 页面验证器 模板页面处理器 页面请求器 页面请求器的实现有一些技巧。下载网页时要考虑很多因素。你需要确保你可以随机的使用用户代理，并且不要过于频繁地从同一域中请求。 此外，停下手头的工作去分析为什么网页无法下载是一件出力不讨好的事。尤其是当你的爬虫已经在多个站点运行了好几个小时的情况下。因此，我们会处理一些请求，并将它们保存为文件。 将请求保存到文件中还有另外一个好处。你不必担心一个标签的消失会影响到你的爬虫。如果页面处理器是独立的，并且你已经完成了页面的下载，你还可以根据需要快速且频繁的对其进行处理。如果发现有另一个要抓取的数据元素怎么办？别担心。只需添加一个标签，然后在你已下载的页面上重新运行处理器即可。 以下是一些实际情况下的示例代码： import requests import pickle from random import randint from urllib.parse import urlparse def _random_ua(): ua_list = ["user agent1, user agent2", "user agent3"] random_num = randint(0, len(ua_list)) return ua_list[random_num] def _headers(): return { 'user-agent': _random_ua() } def _save_page(response): uri = urlparse(response.url) filename = uri.netloc + ".pickle" with open(filename, 'wb+') as pickle_file: pickle.dump(response, pickle_file) def download_page(url): response = requests.get(url) _save_page(request) 页面验证器 页面验证器浏览文件并释放请求。它将读取请求的状态码，如果请求代码类似于 408（超时），你可以让它重新排队下载网页。否则，验证器会将文件移动到实际的 web 抓取模块中进行处理。 你还可以收集为什么页面没有下载的数据。也许你请求页面的速度太快而被禁止了。此数据可用于调整你的页面下载器，以便它可以运行尽可能快且错误量最小。 模板页面处理器 终于到这里了。我们要做的第一步是创建数据模型。让我们从 URL 开始，对于每个不同的站点/路径，可能都有不同的提取数据的方法。我们从一个字典开始，就像这样： models = { 'finance.yahoo.com':{}, 'news.yahoo.com'{}, 'bloomberg.com':{} } 在我们的用例中，我们想要提取这些网站的 article 内容。要做到这一点，我们需要创建一个选择器，用于包含所有数据的最小外部元素。举个例子，下面是 finance.yahoo.com 的示例页面: Webpage Sample <div> <a>some link</a> <p>some content</p> <article class="canvas-body"> <h1>Heading</h1> <p>article paragraph 1</p> <p class="ad">Ad Link</p> <p>article paragraph 2</p> <li>list element</li> <li> <a>unrelated link</a> </li> </article> </div> 在上面的代码段中，我们希望定位 article 元素。因此，我们将使用 article 标签和 class 作为标识符，因为这是包含 article 内容的最小元素。 ...

这年头，不管什么应用，仿佛“上云“都成了标配，感觉拥抱了“云”，应用的逼格都上升了。那真的是这样的吗？ 是的，的确是这样。 云计算是一种按照需求通过 Internet 获取计算资源的形态。这些计算资源被包装成为服务，提供给用户。而提供这些服务的主体，我们称之为云服务供应商（Cloud Service Provider）。云服务最主要的有三类，就是本文的三个主角 IaaS、PaaS、SaaS。 那这三个 aaS 到底是个啥？ XaaS 看到这个标题，可能就有人产生疑惑了，那三个 aaS 都不知道是什么，怎么突然又多了一个 XaaS。不急，且听我娓娓道来。 XaaS，即一切皆服务，代表 “X as a service”、“anything as a service”或“everything as a service” 。这一缩写指越来越多地通过互联网提供的服务，而不仅仅指本地或现场服务。云计算的本质就是 XaaS。 XaaS 最常见的例子就是“软件即服务”（Software as a Service，SaaS）、“基础设施即服务”（Infrastructure as a Service，IaaS）和“平台即服务”(platform as a service，PaaS)。 详解 根据所提供服务的不同，云服务可以被分为以下三类／三层： 缩写 全写 注释 IaaS Infrastructure as a Service 基础设施即服务 PaaS Platform as a Service 平台即服务 SaaS Software as a Service 软件即服务 如下图所示： SaaS Software as a Service (SaaS) 又称云应用服务，通过网络为最终用户提供应用服务。绝大多数 SaaS 应用都是直接在浏览器中运行，不需要用户下载安装任何程序。对用户来说，软件的开发、管理、部署都交给了第三方，不需要关心技术问题，可以拿来即用。 比如：电商服务 淘宝 ...

作为后端最常用的编程语言之一，Java 已经有很多年的历史了，在阿里内部，Java 也是使用最广泛的一门语言。在阿里实习的这段时间，规范一词是我感受最深的。没有规矩不成方圆，今天来说一下 Java 中的各种 O(bject)。 为什么会出现这些 O？ 我们知道，这些 O 不管叫什么名字，其本质都还是对象（Object），既然本质都一样，为什么非要给他们套上各种马甲？ 个人认为原因有三： 第一，随着编程工业化的发展，需要有一套合理的体系出现。中国人喜欢造神，外国人喜欢造概念，于是 MVC、MVP、MVVM 等编程模型就出现了，为了搭配这些编程模型的使用，需要对 Object 的功能进行划分，于是我们便看到了这些层出不穷的 Object。当然这里并没有批评这些概念的意思。 其二，我认为在团队协作编码中，一个好的命名方式是可以节约很多时间成本的。就比如getItemById一眼看去就知道是通过 id 获取一个 item 对象，ItemVO一眼看去就知道是前端透出的 json 对应的对象。 其三，如此划分，可以让项目结构更加清楚，不至于出现东一块西一块，对象乱扔的局面。尽可能避免了在多人协作时对象混乱的情况。 总的来说，这一切都是为了让软件编程更加合理、更加规范、更加高效。 有哪些 O？ 这些 O 有很多衍生出的命名，比如 VO、DO、BO，这里我们把常见的 O 列举出来，然后一一解释。 以下内容参考阿里巴巴 Java 开发手册，如果有需要可以在微信公众号「01 二进制」后台回复「Java 开发手册」获得。 DO（ Data Object）：与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。 PO（Persistant Object）：持久对象，一个 PO 的数据结构对应着库中表的结构，表中的一条记录就是一个 PO 对象 DTO（ Data Transfer Object）：数据传输对象，Service 或 Manager 向外传输的对象。 BO（ Business Object）：业务对象。 由 Service 层输出的封装业务逻辑的对象。 AO（ Application Object）：应用对象。 在 Web 层与 Service 层之间抽象的复用对象模型，极为贴近展示层，复用度不高。 VO（ View Object）：显示层对象，通常是 Web 向模板渲染引擎层传输的对象。 POJO（ Plain Ordinary Java Object）：POJO 专指只有 setter/getter/toString 的简单类，包括 DO/DTO/BO/VO 等。 DAO（Data Access Objects）：数据访问对象，和上面那些 O 不同的是，其功能是用于进行数据操作的。通常不会用于描述数据实体。 一下子给出 8 个常见的 O，光看解释大家可能会有些迷糊，接下来我们从下面这张图入手，带大家直观的感受下，这些 O 的用处。 ...