硬核观察 | 外媒呼吁美国不要打压中国智能电话
外媒呼吁美国不要打压中国智能电话在美国，消费者购买的手机主要是 iPhone 和三星手机。而这些产品往往也是在中国生产的。但是由于美国的政策，中国的华为、OPPO、小米等手机在美国的市场受到了打压，而与此同时，这些中国手机在欧洲、中东和非洲拥有大量的用户群。外媒 ZDnet 对中国智能手机取得的技术优势表示了欣赏，比如 Oppo 在其 Find X3 Pro 屏幕上的显示屏不仅引入了 120Hz 刷新频率，而且还引入了精确的 10 位色彩表现，以及一个“微透镜”。在叹息美国消费者不能享受到这些新产品的同时，作者也认为华为和中兴的情况对多个方面都是不幸的，因为不能使用这些价格较低且极具竞争力的产品的不仅仅是消费者，还有那些试图在更多农村地区建设 5G 网络的运营商。从全球化到对抗，受伤的不仅仅是中国人民。AWS 可以帮你清理糟糕的 Python 代码，但是要收费AWS 表示，其自动代码审查工具 CodeGuru 可以通过检测难以发现的缺陷来提高源代码质量，已经更新了对 Python 编程语言的支持。该服务使用 AWS 的机器学习算法来寻找应用程序开发过程中的错误，目前支持 Python 和 Java。在这个版本中，CodeGuru 增加了代码可维护性和输入验证的检测器，同时改进了资源泄漏的检测器。CodeGuru 定价是根据仓库的大小按代码行数计算的。前 10 万行代码的费用是每月 10 美元。每增加 10 万行代码，每月费用为 30 美元。所以，代码写的烂不要紧，只要花点钱就行了。以后估计连烂代码也没得写了，AI 就可以帮你写好了。曾经的容器编排三巨头 Mesos 项目落幕4 月 7 日，Apache 基金会宣布开始投票，准备将 Mesos 项目移至 Attic 下。Mesos 项目起源于 Google 的数据中心资源管理系统 Borg，曾经解决了 Twitter 面临的可伸缩性和性能上的挑战。但是在后来的容器编排系统之战中，Mesos 和 Docker Swarm 不敌谷歌的 Kubernetes，纷纷落败。Mesos 落败的原因有很多，无论是技术、战略还是大公司的倾轧，总之，短短不到十年，曾经红极一时的 Mesos 落下了帷幕。
人们经常用 x 相对于 y 这样的术语来考虑问题，但是它并不是一个技术对另一个技术的问题。Ben Hindman 在这里解释了 Mesos 是如何对另外一种技术进行补充的。Mesos 的起源可以追溯到 2009 年，当时，Ben Hindman 还是加州大学伯克利分校研究并行编程的博士生。他们在 128 核的芯片上做大规模的并行计算，以尝试去解决多个问题，比如怎么让软件和库在这些芯片上运行更高效。他与同学们讨论能否借鉴并行处理和多线程的思想，并将它们应用到集群管理上。Hindman 说 “最初，我们专注于大数据” 。那时，大数据非常热门，而 Hadoop 就是其中的一个热门技术。“我们发现，人们在集群上运行像 Hadoop 这样的程序与运行多线程应用及并行应用很相似。”Hindman 说。但是，它们的效率并不高，因此，他们开始去思考，如何通过集群管理和资源管理让它们运行的更好。“我们查看了那个时期很多的各种技术” Hindman 回忆道。然后，Hindman 和他的同事们决定去采用一种全新的方法。“我们决定对资源管理创建一个低级的抽象，然后在此之上运行调度服务和做其它的事情。” Hindman 说，“基本上，这就是 Mesos 的本质 —— 将资源管理部分从调度部分中分离出来。”他成功了，并且 Mesos 从那时开始强大了起来。将项目呈献给 Apache这个项目发起于 2009 年。在 2010 年时，团队决定将这个项目捐献给 Apache 软件基金会（ASF）。它在 Apache 孵化，并于 2013 年成为顶级项目（TLP）。为什么 Mesos 社区选择 Apache 软件基金会有很多的原因，比如，Apache 许可证，以及基金会已经拥有了一个充满活力的其它此类项目的社区。与影响力也有关系。许多在 Mesos 上工作的人也参与了 Apache，并且许多人也致力于像 Hadoop 这样的项目。同时，来自 Mesos 社区的许多人也致力于其它大数据项目，比如 Spark。这种交叉工作使得这三个项目 —— Hadoop、Mesos，以及 Spark —— 成为 ASF 的项目。与商业也有关系。许多公司对 Mesos 很感兴趣，并且开发者希望它能由一个中立的机构来维护它，而不是让它成为一个私有项目。谁在用 Mesos？更好的问题应该是，谁不在用 Mesos？从 Apple 到 Netflix 每个都在用 Mesos。但是，Mesos 也面临任何技术在早期所面对的挑战。“最初，我要说服人们，这是一个很有趣的新技术。它叫做‘容器’，因为它不需要使用虚拟机” Hindman 说。从那以后，这个行业发生了许多变化，现在，只要与别人聊到基础设施，必然是从”容器“开始的 —— 感谢 Docker 所做出的工作。今天再也不需要做说服工作了，而在 Mesos 出现的早期，前面提到的像 Apple、Netflix，以及 PayPal 这样的公司。他们已经知道了容器替代虚拟机给他们带来的技术优势。“这些公司在容器成为一种现象之前，已经明白了容器的价值所在”， Hindman 说。可以在这些公司中看到，他们有大量的容器而不是虚拟机。他们所做的全部工作只是去管理和运行这些容器，并且他们欣然接受了 Mesos。在 Mesos 早期就使用它的公司有 Apple、Netflix、PayPal、Yelp、OpenTable 和 Groupon。“大多数组织使用 Mesos 来运行各种服务” Hindman 说，“但也有些公司用它做一些非常有趣的事情，比如，数据处理、数据流、分析任务和应用程序。“这些公司采用 Mesos 的其中一个原因是，资源管理层之间有一个明晰的界线。当公司运营容器的时候，Mesos 为他们提供了很好的灵活性。“我们尝试使用 Mesos 去做的一件事情是去创建一个层，以让使用者享受到我们的层带来的好处，当然也可以在它之上创建任何他们想要的东西，” Hindman 说。 “我认为这对一些像 Netflix 和 Apple 这样的大公司非常有用。”但是，并不是每个公司都是技术型的公司；不是每个公司都有或者应该有这种专长。为帮助这样的组织，Hindman 联合创建了 Mesosphere 去围绕 Mesos 提供服务和解决方案。“我们最终决定，为这样的组织去构建 DC/OS，它不需要技术专长或者不想把时间花费在像构建这样的事情上。”Mesos vs. Kubernetes?人们经常用 x 相对于 y 这样的术语来考虑问题，但是它并不是一个技术对另一个技术的问题。大多数的技术在一些领域总是重叠的，并且它们可以是互补的。“我不喜欢将所有的这些东西都看做是竞争者。我认为它们中的一些与另一个在工作中是互补的，” Hindman 说。“事实上，名字 Mesos 表示它处于 ‘中间’；它是一种中间的操作系统”， Hindman 说，“我们有一个容器调度器的概念，它能够运行在像 Mesos 这样的东西之上。当 Kubernetes 刚出现的时候，我们实际上在 Mesos 的生态系统中接受了它，并将它看做是在 Mesos 上的 DC/OS 中运行容器的另一种方式。”Mesos 也复活了一个名为 Marathon（一个用于 Mesos 和 DC/OS 的容器编排器）的项目，它成为了 Mesos 生态系统中最重要的成员。但是，Marathon 确实无法与 Kubernetes 相比较。“Kubernetes 比 Marathon 做的更多，因此，你不能将它们简单地相互交换，” Hindman 说，“与此同时，我们在 Mesos 中做了许多 Kubernetes 中没有的东西。因此，这些技术之间是互补的。”不要将这些技术视为相互之间是敌对的关系，它们应该被看做是对行业有益的技术。它们不是技术上的重复；它们是多样化的。据 Hindman 说，“对于开源领域的终端用户来说，这可能会让他们很困惑，因为他们很难去知道哪个技术适用于哪种任务，但这是这个被称之为开源的本质所在。“这只是意味着有更多的选择，并且每个都是赢家。via: https://www.linux.com/blog/2018/6/mesos-and-kubernetes-its-not-competition作者：Swapnil Bhartiya 选题：lujun9972 译者：qhwdw 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
Docker、Kubernetes 和 Apache Mesos 对比中的一些误区
有无数的文章、讨论、以及很多社区喋喋不休地比较 Docker、Kubernetes 和 Mesos。如果你只是听信了只言片语，你可能会认为这三个开源项目正为了称霸容器界而殊死搏斗。你可能还相信从他们中选出一个如宗教信仰般神圣——真正的信徒会忠于他们的信仰，而且会烧死那些敢于考虑替代方案的异教徒。那都是废话。虽然所有这三种技术都使得使用容器来部署、管理和伸缩应用成为可能，但实际上它们各自解决了不同的问题，并且根植于迥异的上下文环境中。事实上，这三种被广泛采用的工具链，都是有差别的。让我们重新审视每个项目的原始任务、技术架构，以及它们是如何相互补充和交互的，而不是纠结于比较这些快速迭代的技术之间重叠的特性。让我们从 Docker 开始……Docker 公司，始于名为 dotCloud 的平台即服务（PaaS）供应商。dotCloud 团队发现，在许多应用和客户之间管理依赖和二进制文件时需要付出大量的工作。因此他们将 Linux 的 cgroups 和 namespace 的一些功能合并成一个单一且易于使用的软件包，以便于应用程序可以一致地运行在任何基础设施上。这个软件包就是所谓的 Docker 镜像，它提供了如下的功能：将应用程序和依赖库封装在一个软件包（即 Docker 镜像）中，因此应用可以被一致地部署在各个环境上；提供类似 Git 的语义，例如 docker push，docker commit 等命令让应用开发者可以快速接受这门新的技术，并将其融入到现有的工作流中；定义 Docker 镜像为不可变的层，支持不可变的基础设施。新提交的变更被分别保存为只读层，让复用镜像和追踪变更记录变得十分简单。层还通过只传输更新而不是整个镜像来节省磁盘空间和网络流量；通过实例化不可变的镜像和读写层来运行 Docker 容器，读写层可以临时地存储运行时变更，从而轻松部署和扩展应用程序的多个实例。Docker 变得越来越受欢迎，开发者们开始从在笔记本电脑上运行容器转而在生产环境中运行容器。跨多个机器之间协调这些容器需要额外的工具，这称之为 容器编排 container orchestration 。有趣的是，第一个支持 Docker 镜像的容器编排工具（2014 年 6月）是 Apache Mesos 的 Marathon（后面会有详细介绍) 。那年，Docker 的创始人兼首席技术官 Solomon Hykes 将 Mesos 推荐为“生产集群的黄金标准”。不久之后，除了 Mesos 的 Marathon 之外，还出现了许多的容器编排技术：Nomad、Kubernetes，不出所料还有 Docker Swarm （它如今是 Docker 引擎的一部分）。随着 Docker 开始商业化其开源的文件格式（LCTT 译注：指 Docker 镜像的 dockerfile 文件格式），该公司还开始引入工具来完善其核心的 Docker 文件格式和运行时引擎，包括：为公开存储 Docker 镜像的而生的 Docker hub；存储私有镜像的 Docker 仓库（Docker registry）；Docker cloud，用于构建和运行容器的管理性服务；Docker 数据中心作为一种商业产品体现了许多 Docker 技术；来源: www.docker.comDocker 将软件及其依赖关系封装在一个软件包中的洞察力改变了软件行业的游戏规则，正如 mp3 的出现重塑了音乐行业一般。Docker 文件格式成为行业标准，领先的容器技术供应商（包括 Docker、Google、Pivotal、Mesosphere 等) 组建了 云计算基金会 Cloud Native Computing Foundation (CNCF) 和 开放容器推进联盟 Open Container Initiative (OCI)。如今，CNCF 和 OCI 旨在确保容器技术之间的互操性和标准化接口，并确保使用任何工具构建的任何 Docker 容器都可以在任何运行时或基础架构上运行。进入 KubernetesGoogle 很早就认识到了 Docker 的潜力，并试图在 Google Cloud Platform （GCP）上提供容器编排“即服务”。 Google 在容器方面拥有丰富的经验（是他们在 Linux 中引入了 cgroups），但现有的内部容器和 Borg 等分布式计算工具直接与其基础架构相耦合。所以，Google 没有使用原有系统的任何代码，而是从头开始设计 Kubernetes （K8S）来编排 Docker 容器。 Kubernetes 于 2015 年 2 月发布，其目标和考虑如下：为应用程序开发人员提供编排 Docker 容器的强大工具，而无需与底层基础设施交互；提供标准部署接口和原语，以实现云端一致的应用部署体验和 API;基于模块化 API 核心，允许供应商围绕 Kubernetes 的核心技术集成其系统。2016 年 3 月，Google 将 Kubernetes 捐赠给了 CNCF，并且直到今天仍然是该项目的主要贡献者（其次是Redhat，CoreOS 等）。来源: wikipediaKubernetes 对应用程序开发人员非常有吸引力，因为它减轻了对基础架构和运营团队的依赖程度。供应商也喜欢 Kubernetes，因为它提供了一个容易的方式来拥抱容器化运动，并为客户部署自己的 Kubernetes（这仍然是一个值得重视的挑战）提供商业解决方案。 Kubernetes 也是有吸引力的，因为它是 CNCF 旗下的开源项目，与 Docker Swarm 相反，Docker Swarm 尽管是开源的，但是被 Docker 公司紧紧地掌控着。Kubernetes 的核心优势是为应用程序开发人员提供了用于编排无状态 Docker 容器的强大工具。 虽然有多个扩大项目范围的提议，以提供更多的功能（例如分析和有状态数据服务），但这些提议仍处于非常早期的阶段，它们能取得多大的成功还有待观察。Apache MesosApache Mesos 始于 加州大学伯克利分校 UC Berkeley 的下一代容器集群管理器项目，并应用了从云计算级别的分布式基础架构（如 Google 的 Borg 和 Facebook 的 Tupperware）中习得的经验和教训。 虽然 Borg 和 Tupperware 具有单一的架构，并且是与物理基础架构紧密结合的闭源专有技术，但 Mesos 推出了一种模块化架构，一种开源的开发方法，旨在完全独立于基础架构。Mesos 迅速被 Twitter、Apple（Siri 中）、Yelp、Uber、Netflix 和许多领先的技术公司采用，支持从微服务、大数据和实时分析到弹性扩展的一切。作为集群管理器，Mesos 被设计用来解决一系列不同的挑战：将数据中心资源抽象为单个池来简化资源分配，同时在私有云或公有云中提供一致的应用和运维体验；在相同的基础架构上协调多个工作负载，如分析、无状态微服务、分布式数据服务和传统应用程序，以提高利用率，降低成本和台面空间;为应用程序特定的任务（如部署、自我修复、扩展和升级），自动执行第二天的操作；提供高度可用的容错基础设施；提供持久的可扩展性来运行新的应用程序和技术，而无需修改集群管理器或其上构建的任何现有应用程序；弹性扩展可以将应用程序和底层基础设施从少量扩展到数十到数万个节点。Mesos 独有的独立管理各种工作负载的能力 —— 包括 Java 这样的传统应用程序、无状态 Docker 微服务、批处理作业、实时分析和有状态的分布式数据服务。Mesos 广泛的工作负载覆盖来自于其两级架构，从而实现了“应用感知”调度。通过将应用程序特定的操作逻辑封装在“Mesos 框架”（类似于操作中的运行手册）中来实现应用程序感知调度。资源管理器 Mesos Master 提供了这些框架基础架构的部分，同时保持隔离。这种方法允许每个工作负载都有自己的专门构建的应用程序调度程序，可以了解其部署、扩展和升级的特定操作要求。应用程序调度程序也是独立开发、管理和更新的，这让 Mesos 拥有高度可扩展的能力，支持新的工作负载或随着时间的推移而增加更多的操作功能。举一个团队如何管理应用软件升级的例子。无状态应用程序可以从“蓝/绿”部署方案中受益；当新版本的应用运行起来时，原先旧版本的软件依然还正常运转着，然后当旧应用被销毁时流量将会切换到新的应用上。但是升级数据工作负载例如 HDFS 或者 Cassandra 要求节点停机一次，此时需要持久化本地数据卷以防止数据丢失，并且按照特定的顺序执行原位升级，在升级之前和升级完成之后，都要在每一个节点类型上执行特定的检查和命令。任何这些步骤都是应用程序或服务特定的，甚至可能是版本特定的。这让使用常规容器编排调度程序来管理数据服务变得非常困难。Mesos 以每一个工作负载所需的特定方式管理各种工作负载，使得许多公司将 Mesos 作为一个统一的平台，将微服务和数据服务结合在一起。数据密集型应用程序的通用参考架构是 “SMACK 家族”（LCTT 译注：SMACK 即 Spark、Mesos、Akka、Cassandra、Kafka)。是时候搞清楚这些了请注意，我们尚未对 Apache Mesos 的容器编排有任何描述。所以为什么人们会自动地将 Mesos 和容器编排联系起来呢？容器编排是可以在 Mesos 的模块化架构上运行的工作负载的一个例子，它是通过一个专门的编排“框架”来完成的，这个框架就 Marathon，一个构建于 Mesos 之上的工具。 Marathon 最初是为了在 cgroup 容器中编排应用归档（如 JAR、tarball、ZIP 文件）而开发的，是 2014 年最先支持 Docker 容器的编排工具之一。所以当人们将 Docker 和 Kubernetes 与 Mesos 进行比较时，他们实际上是将 Kubernetes 和 Docker Swarm 与在 Mesos 上运行的 Marathon 进行比较。为什么搞清楚这一点很重要？ 因为 Mesos 坦率地讲并不在乎它上面运行了什么。 Mesos 可以在共享的基础设施上弹性地为 Java 应用服务器提供集群服务、Docker 容器编排、Jenkins 持续集成任务、Apache Spark 分析、Apache Kafka 流，以及更多其他的服务。Mesos 甚至可以运行 Kubernetes 或者其他的容器编排工具，即使公共的集成目前还不可用。来源: Apache Mesos 2016 调查问卷Mesos 的另一个考虑因素（也是为什么它对许多企业架构师来说如此有吸引力）是运行关键任务工作负载的成熟度。 Mesos 已经在大规模生产环境下（成千上万台服务器）运行了超过 7 年的时间，这就是为什么它比市场上许多其他的容器技术更具有生产上的可行性和扩展上的可靠性。我所说的这些什么意思？总而言之，所有这三种技术都与 Docker 容器有关，可以让你在容器编排上实现应用程序的可移植性和扩展性。那么你在它们之间如何选择呢？ 归根到底是为工作选择合适的工具（也可能是为不同的工作选择不同的工具）。如果您是一个应用开发人员，正在寻找现代化的方式来构建和打包你的应用程序，或者想加速你的微服务计划，Docker 容器和开发工具就是最好的选择。如果你们是一个开发人员或者 DevOps 的团队，并希望构建一个专门用于 Docker 容器编排的系统，而且愿意花时间折腾集成解决方案与底层基础设施（或依靠公共云基础架构，如 Google 容器引擎（GCE）或 Azure 容器服务（ACS）），Kubernetes 是一个可以考虑的好技术。如果你们想要建立一个运行多个关键任务工作负载的可靠平台，包括 Docker 容器、传统应用程序（例如 Java）和分布式数据服务（例如 Spark、Kafka、Cassandra、Elastic），并希望所有这些可依移植到云端提供商或者数据中心，那么 Mesos（或我们自己的 Mesos 发行版，Mesosphere DC/OS）更适合你们的需求。无论您选择什么，您都将拥抱一套可以更有效地利用服务器资源的工具，简化应用程序的可移植性，并提高开发人员的敏捷性。你的选择真的不会有错。via: https://mesosphere.com/blog/docker-vs-kubernetes-vs-apache-mesos/作者：Amr Abdelrazik 译者：rieonke 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
鲜为人知的 Apache Mesos 项目帮助 Mesosphere 公司得到了千万美元投资
Mesosphere，一家试图围绕鲜为人知的 Apache Mesos 项目开展商业活动的公司，刚刚从 Andreessen Horowitz 那里获得了 1000 万美元投资。以下是为什么这个项目能够吸引如此巨款的原因。事实上 Mesos 这款自动扩放软件已经出现了五年了。据 Mesosphere 的CEO及联合创始人 Florian Leibert 所述，Mesos 已经在 Twitter 内已经管理了超过 50,000 个以上的CPU。此外， EBay, AirBnB, Netflix 还有 HubSpot 也是这款软件的使用者。当那些互联网巨头发现 Mesos 的时候，这项技术却并不为大多数企业所知。但它确实可以满足一些公司在他们内部的数据中心上应用公共云的一些技术的需求。Mesos 管理集群机器，根据需要自动扩放应用。它在每台机器上只依赖很少的软件，它由一个主调度程序协调。据 Leibert 所说，其CPU 占用为 0 并且几乎不消耗任何内存。在其工作的每台机器上的该软件会向调度程序报告关于虚拟机或者服务器的容量信息，接着调度程序向目标机器分派任务。“如果一项任务终断并且没有返回任何结果，主调度程序知道如何重新调度它和它所用的资源在哪里。” Mesosphere 的资深副总裁 Matt Trifiro 说。Mesos 能自动扩放一系列的任务，包括 Hadoop 数据库，Ruby on Rails 节点，以及 Cassandra 。使用 Mesos 使得 Hubspot 削减了一半的 AWS(Amazon Web Services) 的费用支出，Liebert 说道。这是因为 Mesos 能够在目标机器之间有效地分配作业量的原因。然而，Mesos 更有可能应用到那些试图真正地在内部创建一个类 AWS 环境的企业，一位来自 451 Research 的分析员 Jay Lyman 说。AWS 提供一些自动扩放工具，但大多数公司对于在公共云基础设施上运行所有东西还是感到不安。与此同时，他们并不想着反对他们的开发者采用 AWS 那样的公共云中可用的优异性能。他们希望他们的私有云能集成这些可用的优点。“如你所见，类似 AWS 风格的界面风格，与监控、命令、操控以及稳定性相融合，” Liebert 继续说道。Mesos 既可以在一个私有云上也可以在 AWS 上运行，向企业提供最有效率地使用其内部云的方法，并在需要扩放时自动切换到 AWS 去。但是，从另外的方面说 Mesos 也是有一些缺点的。它并不能运行任何 Windows 操作系统或者比较古老的应用比如说 SAP 软件。不过，Lyman 说，“假如一个团队拥有长时期使用云的经历，他们大概早就对 Linux 操作系统情有独钟了。”在将来，Mesosphere 能够支持 Windows 操作系统是很有可能的。最初，像 Puppet 和 Chef 这样的技术也只支持 Linux 操作系统，Lyman 表示。“这只是早期 Mesosphere 的特性。现在它还是不太成熟，” 他又说道。Mesosphere 正瞄向大部分使用现代编程技术构建了越来越多的运行于 Linux 的应用的企业，以及 Twitter 和 Netflix 这种在初创时还没有 Mesos 类似技术的第一代 Web 2.0 公司。“这是早期两类最常见的客户概况，” Trifiro 说。年终之前，Mesosphere 希望发布包含文档的商业产品，通过技术支持与颁发许可证来获得营收。Mesosphere 已开发一款名为 Marathon 的大规模扩放编制工具，并且支持 Docker 集成。它现在免费提供打包好的 Mesos 发行版，希望以此占有未来的市场。Mesosphere 同时也正在为少数早期的顾客工作。它帮助 HubSpot 实施有关 Mesos 的搭建。Mesosphere 在这个领域并不唯一。Rightscale，Scalr 以及现在归 Dell 所有的 Enstratius，全都提供了一些各种版本的扩放或云管理技术。Mesosphere 强调说，Mesos 及其公司自己开发的技术在单独机器中创建服务器集群方面的表现远胜于市场上的其他同类软件。来自 Andreessen 的新投资一定会帮助 Meos 获得更大的动力。via: http://thenewstack.io/little-known-apache-mesos-project-helps-mesosphere-raise-10m-from-andreessen/译者：SteveArcher 校对： wxy本文由 LCTT 原创翻译，Linux中国 荣誉推出