前言 我们每天都在使用网络，面对这个看不见也摸不着的东西，你有没有思考过他的背后发生了什么吗？
相信很多人第一次接触网络是通过一个叫「网站」的东西，那网站又究竟是什么？
影视剧里经过出现的通过 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 里的衣柜。...
想追女神？先学 Synchronized 吧
在之前的《从找对象到多线程》一文中我曾介绍了一些和多线程有关的知识，而谈到多线程，就一定离不开「锁」这个名词。在 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 就很不开心了，对他来说这就是一种「悲观锁」。...
接口调度者—— API 网关
背景 我们知道在微服务架构风格中，一个大应用被拆分成为了多个小的服务系统提供出来，这些小的服务他们自成体系，也就是说这些小系统可以拥有自己的数据库，框架甚至语言等，这些小系统通常以提供 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 提供的反向代理的功能是一样的，后面我们也会对其进行一个比较。...
你的系统可用性 5 个 9 了吗？
又是一年放榜日，众多考生满怀期待的点开招生网，结果输了信息才发现根本没办法查询——查询人数太多了，直接把系统打挂了！
这个时候，还没翻身的码农闰土被问到一个直击心灵的问题：这个系统可用性达到了多少个 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...
【译】如何创建一个可复用的网页爬虫
原文地址：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....
云计算之 Anything As a Service
这年头，不管什么应用，仿佛“上云“都成了标配，感觉拥抱了“云”，应用的逼格都上升了。那真的是这样的吗？
是的，的确是这样。 云计算是一种按照需求通过 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 软件即服务 如下图所示：...
DO,VO,DTO 你知道吗？
作为后端最常用的编程语言之一，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 的用处。...
