Note

Docker 引擎(Docker Engine), 顾名思意，是 Docker 的核心. 它为 Docker 提供动力, 并承担所有繁重的工作. 本文将深入探讨这一关键组件的内部运作, 以便了解 Docker 在内核下是如何工作的. The Evolution of the Docker Engine | Docker 引擎的演进 Docker 最初是一个巨大的单体(monolith), 所有代码都塞在同一个项目里. 对于 dotCloud来说, 这种方式一开始是可行的. 实际上, 这个方向运作得非常好, 以至于他们放弃了其他服务、把所有赌注都押在 Docker 上, 甚至把公司重命名为 Docker, Inc. 一开始, Docker 是一个又大又混乱的单体应用. 随着时间推移, Docker, Inc. 发现这种做法不可持续, 他们需要把系统拆分出来: 各个部分可以独立成长 更容易升级某些部分 - 可以替换旧组件而不影响整体 让社区更容易参与贡献 - 更小的组件意味着更多人能参与进来 更易跨平台 - 他们想要 Docker 在每个平台上运行, 而不只是 Linux 拆分的第一步是把客户端 client 剥离出来. 把客户端从大应用中抽出, 赋予它新职责: 把用户命令翻译成 Docker 引擎能理解的指令(也就是原来单体里"内核部分"的接口) 此时, Docker 引擎主要有两部分: ...

The Docker Story - Part1: Docker History docCloud - 也就是开发 Docker 的公司, 最初是一家 PaaS(平台即服务)公司, 他们在 PaaS 领域并没有太大的成功, 但他们构建了一个可以无缝管理客户系统与架构的工具: Docker. 2013 年, 他们决定放弃 PaaS 服务, 将全部精力投入到 Docker 这款产品上. Containers 容器 Docker 公司并没有发明容器这个概念. 实际上, 容器的概念已经演进了十多年, 很多参与者都做出了贡献, Linux 基金会和 Google 是推动整个生态走向成熟的重要力量. 假如你在运营一家公司, 希望将应用上线, 以前需要做的事大概是: 购买一台服务器 安装所有必要的应用和依赖 配置环境以匹配你的开发设置 部署应用 把服务器对外开放 看起来很简单, 但实际操作会很复杂: 要手动跟踪并更新每个依赖和配置 如果出问题, 需要手动去修复 基础设施团队需要估算服务器规格(内存、CPU 等) — 为了防止流量高峰崩溃, 通常会配置更高的规格(过度配置) 那台高配服务器大多数时间只是闲置着, 做最少量的工作 不能轻易扩展或在同一服务器上运行多个应用, 因为每个应用都需要独立的运行环境 总之, 非常混乱 后来出现了虚拟机(VM), 情况有了改善. 使用 VM 可以: 在同一台服务器上运行多个隔离的环境 为 VM 做快照并在不同服务器间复用 不再重复重复地搭建环境，这是一个很大的进步 但 VM 也有缺点: ...

Redis 的有序集和(ordered set)同时具有"有序"和"集和"两种性质, 这种结构中每个元素都由一个成员和一个与成员相关联的分值组成, 其中成员与字符串方式存储, 而分值以64位双精度浮点数格式存储. 例如下面一个记录薪水的集和: 成员 分值 “perter” 3500 “bob” 3800 “jack” 4500 “tom” 5000 “mary” 5500 与集和一样, 有序集和中的元素都是唯一的, 同时, 成员将按照分值大小进行排序. 有序集和分值除了可以是数字外, 还可以是字符串 “+inf” 或者 “-inf”, 这两个特殊值分别表示无穷大和无穷小. 虽然有序集和的成员不可相同, 但是分值可以是相同的, 当两个或多个成员拥有相同的分值时，Redis 将按照这些成员在字典序中的大小对其进行排列. 有序集合是Redis提供的所有数据结构中最为灵活的一种, 它可以以多种不同的方式获取数据, 比如根据成员获取分值、根据分值获取成员、根据成员的排名获取成员、根据指定的分值范围获取多个成员等. ZADD: 添加或更新成员 ZADD sorted_set socre number [score number ...] 默认情况下, ZADD 命令将返回成功添加的新成员数量作为返回值, 对于更新操作会返回0(未添加新成员). 使用 XX | NX 选项来显示地指示命令 只更新 或 只添加操作 ZADD sorted [XX|NX] socre member [socre member ...] 若要返回所有被修改的成员数量(新添加 + 更新数量), 可使用 CH 选项 ZADD sorted_set [CH] socre number [score number ...] 复杂度: O(M * log(N)) 其中 M 为给定成员数量, N 为有序集和的成员数量 ...

Redis 的集和 set 键允许用户将任意多个不同的元素存储到集和中, 既可以是文本数据, 也可以是二进制数据. 其与列表有以下两个明显的区别: 列表可以存储重复元素, 而集和只存储非重复元素 列表以有序方式存储元素, 而集和则以无序方式存储元素 下面介绍结合键的各个命令 Set 集和 SADD: 将元素添加到集和 SADD set element [element ...] 返回成功添加的新元素数量作为返回值, 由于集和不存储相同元素, 所以会自动忽略重复的元素 SREM: 从集和中移出元素 SREM set element [element ...] 返回被移除的元素数量, 同样的, 不存在的元素会被忽略 SMOVE: 将元素从一个集和移动到另一个集和 SMOVE source target element 移动操作成功时返回1, 若不存在于源集和, 返回0. 如果 source 的元素不存在, 则返回0表示失败. 如果 target 的元素已存在, 则会覆盖该元素. 从结果来看, 并不会导致 target 中元素变化, 但是会导致 source 中的该元素消失. SMEMBERS: 获取集和包含的所有元素 SMEMBERS set 由于集和是无序的, 且 SMEMBERS 命令不会进行任何排序操作, 所以根据元素添加的顺序不同, 含相同元素的集和执行该命令结果可能不同. SCARD: 获取集和包含的元素数量 SCARD set SISMEMBER: 检查给定元素是否存在于集和 ...

List 列表 Redis 的列表是一种线性的有序结构, 可以按照元素被推入列表的顺序来存储元素, 这些元素即可以是文字顺序, 也可以是二进制顺序, 且元素可重复出现. LPUSH: 将元素推入列表左端 LPUSH list item [item item ...] LPUSH 命令会返回当前元素数量 RPUSH: 将元素推入列表右端 RPUSH list item [item item ...] LPUSHX, RPUSHX: 只对已存在的列表执行推入操作 上面两条命令, 在列表不存在的情况下, 会自动创建空列表, 并将元素推入列表中. 且上面命令每次只能推入一个元素 LPOP: 弹出列表最左端的元素, 并返回被移出的元素 POP list 空列表 POP 会返回空值 (nil) RPOP: 弹出列表最右端的元素 RPOP list RPOPLPUSH: 将列表右端弹出的元素推入列表左端 RPOPLPUSH source target source 和 target 可以是相同列表, 也可以是不同列表. 但不能为空列表, 否则会返回空(nil) 示例: 先入先出队列 许多电商网站都会在节日时推出一些秒杀活动, 这些活动会放出数量有限的商品供用户抢购, 秒杀系统的一个特点就是短时间内会有大量用户进行相同的购买操作, 如果使用事务或者锁去实现秒杀程序, 那么会因为锁和事务的重试性而导致性能低下, 并且由于重试的存在, 成功购买商品的用户可能并不是最早购买操作的用户, 因此这种秒杀系统并不公平. 解决方法之一就是把用户的购买操作都放入先进先出队列里面, 然后以队列的方式处理用户购买操作, 这样的程序就可以不使用锁或者事务实现秒杀系统, 且更加公平. ...

散列 Redis 散列键 hash key 会将一个键和一个散列在数据库里关联起来, 散列中可以存任意多个字段 field. 与字符串一样, 散列字段和值既可以是文本数据, 也可以是二进制数据. HSET: 为字段设置值 HEST hash field value 若已给定的字段是否已经存在与散列中, 该设置为一次更新操作, 覆盖旧值后返回0. 相反, 则为一次创建操作, 命令将在散列里面关联起给定的字段和值, 然后返回1. HSETNX: 只在字段不存在的情况下设置值 HSETNX hash field value HSETNX 命令在字段不存在且成功设置值时, 返回1. 字段已存在并设置值未成功时, 返回0. HGET: 获取字段的值 HGET hash field 若查找的不存在的散列或字段, 则会返回空(nil) 示例: 短网址生成 为了给用户提供更多空间, 并记录用户在网站上的链接点击行为, 大部分社交网站都会将用户输入的网址转换为短网址. 当用户点击段网址时, 后台就会进行数据统计, 并引导用户跳转到原地址. 创建短网址本质上就是, 要创建出短网址ID与目标网址之间的映射, 并让用户访问短网址时, 根据短网址的ID映射记录中找出与之相对应的目标网址. 短网址 ID 目标网址 RqRRz8n http://redisdoc.com/geo/index.html RUwtQBx http://item.jd.com/117910607.html HINCRBY: 对字段存储的整数值执行加法或减法操作 HINCRBY hash field increment 与字符串 INCRBY 命令一样, 如果散列字段里面存储着能够被 Redis 解释为整数的数字, 那么用户就可以使用 HINCRBY 命令为该字段的值加上指定的整数增量. 该命令执行成功后, 将返回字段当前的值为命令的结果. 若要执行减法操作, increment 传入负数即可. ...

本篇文章基于 REST api 介绍HTTP请求方法、HTTP响应码和API数据载荷, 是之前介绍 REST 那篇文章的延伸 HTTP Status Codes 1xx group: Signals that an operation is in progress 2xx group: Signals that a request was successfully processed 3xx group: Signals that a resource has been moved to a new location 4xx group: Signals that someting was wrong with the request 5xx group: Signals that there was an error while processing the request 在之前文章中, 定义的 HTTP status code 如下: POST /orders: 201 (Created) - 资源成功创建 GET /orders: 200 (OK) - 请求成功处理 GET /orders/{order_id}: 200 (OK) - 请求成功处理 PUT /orders/{order_id}: 200 (OK) - 资源成功更新 DELETE /orders/{order_id}: 204 (No Content) - 请求被成功处理, 但是没有响应内容, 对比其他方法, DELETE 请求不需要 payload 来删除资源 POST /orders/{order_id}/chanel: 200 (OK) - 取消成功, 由于并不创建任何资源, 故返回200 POST /orders/{orders\id}/pay: 200 (OK) - 支付成功, 同样由于未创建资源, 返回200 上面全是成功的响应, 下面介绍错误响应 ...

介绍Redis中的字符串键 字符串 字符串建是 Redis 最基本的键值对类型, 这种类型的键值对会在数据库中把单独的一个值关联起来, 被关联的键和值可以为文本, 也可以是图片, 视屏, 音频等二进制数据. SET: 为字符串键设置值 O(1) SET key value ```Redis SET number "10086" > OK SET book "Redis in action" > OK ``` 对于已经存在的 key, 再次赋值会覆盖原值, 若不想覆盖后面添加参数 NX, 相反, 默认 XX 允许覆盖 ```Redis SET key "10086" NX > (nil) SET key "10086" XX > OK ``` GET: 获取字符串键的值 O(1) GET key ```Redis GET number > "10086" ``` 对于不存在的值, 返回空 ```Redis GET key_new > (nil) ``` GETSET: 获取旧值并更新值 O(1) ...

这篇文章延续之前微服务的内容, 将介绍关于 REST API 的以下几个方面: REST API 的设计原则 Richardson maturity model (RMM) 如何帮助理解 REST 的优势和设计原则 REST API 中资源(resource)和端点(endpoints)设计的概念 表达性状态转移 representational state transfer (REST) 描述了一种通过网络进行通信的应用程序架构风格. 最初, REST 的概念包含了一组用于设计分布式、可扩展 Web 应用的约束条件. 随着时间推移, 出现了更为细致的协议和规范, 为 REST API 的设计提供了明确的指导方针. 如今, REST 已经成为构建 Web API 的最流行选择. 下面将继续在 CoffeeMesh 项目上, 设计相关订单 API. What is REST? REST 由 Roy Fielding 在他的博士论文 “Architectural Styles and the Design of Network-based Software Atchitecture” (PhD diss. University of California,Irvine,2000,p. 109) 中创造. ...

What are microservices ? 什么是微服务? 微服务可以有多种不同的定义方式, 具体取决于希望强调微服务架构的哪个方面, 不同作者会给出略有不同但相关的定义 Sam Newman, 微服务领域最有影响力的作者之一, 给出了一个极简的定义: “Microservices are small, autonomous services that work together.” 这个定义强调了这样一个事实: 微服务是彼此独立运行的应用程序, 但它们可以协作完成任务. 该定义还强调微服务是 “small (小的)”, 这里的 small 并不是指微服务代码量的大小, 而是指微服务具有狭窄且定义清晰的职责范围, 符合单一职责原则(Single Responsibility Principle) —— 即“只做一件事，并把它做好”. James Lewis 和 Martin Fowler 撰写的一篇开创性文章提供了一个更详细的定义, 他们将微服务定义为一种架构风格(architectural style) “an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API” ...