Algorithm

Remove Duplicates from Sorted Array

Use a two-pointer approach.

Review

初识微服务

https://martinfowler.com/articles/microservices.html



好的程序员都有洁癖（clean code），都是收纳高手（容器，微服务）。

分布式系统的发展

来自《分布式架构》陈皓 左耳听风专栏。

Tips

接下来我将在Tips里面总结所学的Linux知识。

下图来自刘超，《趣谈Linux操作系统》，《02-学习路径：爬过这六个陡坡，你就能对Linux了如指掌》，极客时间APP。

Share

一下是我整理的容器技术发展历程。内容来自：张磊，《深入剖析Kubernetes》，极客时间APP。



2013年以前的软件打包上云过程非常痛苦。

2013年，云计算技术，已经从当初虚无缥缈的概念蜕变成了实实在在的虚拟机和账单。AWS和OpenStack如日中天、盛极一时。在当时，主流用户的普遍用法，就是租一批 AWS 或者 OpenStack 的虚拟机，然后像以前管理物理服务器那样，用脚本或者手工的方式在这些机器上部署应用。可见，这并不是很好的 “上云” 体验。

而以 Cloud Foundry 为代表的 PaaS 开源项目的出现，就是当时解决这个问题的一个最佳方案，可以实现一键部署到云上。上云非常方便。

但前提是用户需要先将应用打包。而事实上，像 Cloud Foundry 这样的 PaaS 项目，最核心的组件就是一套应用的打包和分发机制。

可偏偏就是这个打包功能，却成了日后不断遭到用户诟病的一个“软肋”。

出现这个问题的根本原因是，用户必须为每种语言、每种框架，甚至每个版本的应用维护一个打好的包。这个打包过程，没有任何章法可循，更麻烦的是，明明在本地运行得好好的应用，却需要做很多修改和配置工作才能在 PaaS 里运行起来。而这些修改和配置，并没有什么经验可以借鉴，基本上得靠不断试错，直到你摸清楚了本地应用和远端 PaaS 匹配的“脾气”才能够搞定。最后结局就是，确实是能一键部署了，但是为了实现这个一键部署，用户为每个应用打包的工作可谓一波三折，费尽心机。



Docker镜像解决了打包的痛点。

同样在2013年，一个名为dotCloud的公司决定开源自己的容器项目Docker。这个决定在当时根本没人在乎。“容器”这个概念从来就不是什么新鲜的东西，也不是 Docker 公司发明的。事实上，Cloud Foundry就使用了容器的概念实现了把多个用户的应用互不干涉地在虚拟机里批量地、自动地运行起来的目的。容器也只是Cloud Foundry项目中最底层、最没人关注的那一部分。而 Docker 项目，实际上跟 Cloud Foundry 的容器并没有太大不同。

正所谓“差不多就差远了”、“A small difference will make a big difference.”偏偏就是这剩下的一小部分不一样的功能，成了 Docker 项目接下来“呼风唤雨”的不二法宝。

这个功能，就是 Docker 镜像。而Docker 镜像解决的，恰恰就是打包这个根本性的问题。所谓 Docker 镜像，其实就是一个压缩包。这个压缩包里打包了应用运行所需要的整个操作系统（也就是这个应用运行所需要的所有依赖），从而保证了本地环境和云端环境的高度一致，避免了用户通过“试错”来匹配两种不同运行环境之间差异的痛苦过程。



Docker迅速崛起。

那么，有了 Docker 镜像这个利器，当时的PaaS开源项目里最核心的打包系统一下子就没了用武之地，最让用户抓狂的打包过程也随之消失了。相比之下，在当今的互联网里，Docker 镜像需要的操作系统文件和目录，可谓唾手可得。

结果就是，短短几个月，Docker 项目就迅速崛起了。它的崛起速度如此之快，以至于 Cloud Foundry 以及所有的 PaaS 社区还没来得及成为它的竞争对手，就直接被宣告出局了。

Docker 项目在短时间内迅速崛起的三个重要原因：

1.       Docker 镜像解决了应用打包和发布这一困扰运维人员多年的技术难题

2.       Docker 容器同开发者之间有着与生俱来的密切关系；它第一次把一个纯后端的技术概念，通过非常友好的设计和封装，交到了最广大的开发者群体手里。

3.       PaaS 概念已经深入人心的完美契机。

一时之间，“容器化”成为了基础设施领域最炙手可热的关键词，一个以“容器”为中心的、全新的云计算市场，正呼之欲出。“PaaS”的定义已经全然不是 Cloud Foundry 描述的那个样子，而是变成了一套以 Docker 容器为技术核心，以 Docker 镜像为打包标准的、全新的“容器化”思路。

dotCloud公司凭借着Docker项目，从一家默默无闻的创业公司，一跃成为云计算领域的近十年难得一见的技术明星。该公司也在2013年底，正式改名为Docker公司。



Docker Swarm，Mesos，Kubernetes“三国鼎立”。

Docker 项目其实是一个只能用来创建和启停容器的小工具。但用户们最终要部署的，还是他们的网站、服务、数据库，甚至是云计算业务。这就意味着，只有那些能够为用户提供平台层能力的工具，才会真正成为开发者们关心和愿意付费的产品。

虽然Docker 项目是容器生态的事实标准，它所维护的 Docker 社区也足够庞大。可是，一旦这场斗争被转移到容器之上的平台层，或者说 PaaS 层，Docker 公司的竞争优势便立刻捉襟见肘了。

在此后的2014-2015年间，具有平台层能力的产品层出不穷，各大厂商群雄并起。

Docker 公司开始实施平台化战略，在 2014 年 12 月发布了 Swarm项目来对外提供集群管理功能。Swarm 擅长的是跟 Docker 生态的无缝集成，所谓“Docker Native”。

Mesosphere公司利用在Mesos项目中积累的超大规模集群管理经验，发布了一个名为 Marathon 的项目，并很快就成为了 Docker Swarm 的一个有力竞争对手。Mesos 擅长的则是大规模集群的调度与管理。

Google、RedHat 等开源基础设施领域玩家们，共同牵头发起了一个名为 CNCF（Cloud Native Computing Foundation）的基金会，并推出了Kubernetes项目。这个基金会的目的其实很容易理解：它希望，以 Kubernetes 项目为基础，建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区，来对抗以 Docker 公司为核心的容器商业生态。

Kubernetes并不是几个工程师突然“拍脑袋”想出来的东西，而是 Google 公司在容器化基础设施领域多年来实践经验的沉淀与升华。这中“超前”的设计思想，让 Kubernetes 项目能够从一开始就避免同 Swarm 和 Mesos 社区同质化，并很快取得了在容器编排领域取得足够大的竞争优势。RedHat 是世界上为数不多的、能真正理解开源社区运作和项目研发真谛的合作伙伴。它把这些先进的思想通过技术手段在开源社区落地，并培育出一个认同这些理念的生态。

至此，在容器编排领域，开启了Kubernetes 项目、Docker 公司和 Mesos 社区“三国鼎立”的局面。



Kubernetes成为容器编排领域的事实标准。

不过没过多久，容器生态的格局就发生了变化。

首先出局的是Mesos。Mesos 社区与容器技术的关系，更像是“借势”，而不是这个领域真正的参与者和领导者。这个事实，加上它所属的 Apache 社区固有的封闭性，导致了 Mesos 社区虽然技术最为成熟，却在容器编排领域鲜有创新。

于是，竞争主要在CNCF社区和Docker公司之间展开。

Docker公司意识到了 Swarm 项目目前唯一的竞争优势，就是跟 Docker 项目的无缝集成。那么，如何让这种优势最大化呢？在 2016 年，Docker 公司宣布了一个震惊所有人的计划：放弃现有的 Swarm 项目，将容器编排和集群管理功能全部内置到 Docker 项目当中。

而 Kubernetes 的应对策略则是反其道而行之，开始在整个社区推进“民主化”架构，即：从 API 到容器运行时的每一层，Kubernetes 项目都为开发者暴露出了可以扩展的插件机制，鼓励用户通过代码的方式介入 Kubernetes 项目的每一个阶段。

可见，Docker 公司最后选择的对抗方式，是将开源项目与商业产品紧密绑定，打造了一个极端封闭的技术生态。而这，其实违背了 Docker 项目与开发者保持亲密关系的初衷。

相比之下，Kubernetes 社区鼓励二次创新，在 2016 年之后得到了空前的发展，不同于之前局限于“打包、发布”这样的 PaaS 化路线，这一次容器社区的繁荣，是一次完全以 Kubernetes 项目为核心的“百家争鸣”。它以一种更加温和的方式，承接了 Docker 项目的未尽事业，即：以开发者为核心，构建一个相对民主和开放的容器生态。

2017 年 10 月，Docker 公司出人意料地宣布，将在自己的主打产品 Docker 企业版中内置 Kubernetes 项目，这标志着持续了近两年之久的“编排之争”至此落下帷幕。