容器技术

在机器人技术和自动化中，控制环是一个控制系统状态的不终止的循环 这是一个控制环的例子："房间里的温度自动调节器" 当你设置了温度，告诉了温度自动调节器你的"期望状态"，房间的实际温度是"当前状态"。通过对设备的开关控制，温度自动调节器让其当前状态无限接近于期望状态。 控制器通过 k8s的apiserver 去监控集群的公共状态，并致力于将当前状态转变为所期望的状态。 中文参考官方： 怎么描述Kubernetes架构控制器的 kubernetes 之Pod控制器（Controller） Controller是kubernetes中用于对Pod进行管理的控制器，通过该控制器可以让Pod始终维持在一个用户原本设定或期望的状态下。如节点宕机或Pod因其他原因死亡，则在其他节点起一个相同的Pod来替代该Pod。 常用的内置控制器类型，它通常与集群API服务器进行交互： ReplicaSet： 是Replication Controller 升级版本，区别是对选择器的支持； Deployments： 管理RS并提供对Pod的更新等功能，建议使用它管理RS，除非自定义更新编排； DaemonSet： 用于确保集群中的每一个节点只运行一个Pod副本，通常用来实现系统级的后台任务； StatefulSets： 通常用来管理有状态应用； Job： 一次性任务执行； Crontab： 定时任务执行；

原文地址： http://xiaorui.cc/?p=1502 问题 docker固定容器ip前提是设置net为none，此情景下所有的网络配置都失效，包括-p端口映射。 目的 使用其他的方法做端口映射，绕过net为none 方法 docker的端口映射并不是在docker技术中实现的，而是通过宿主机的iptables来实现；通过控制网桥来做端口映射，类似路由器中设置路由端口映射。 先检查配置端口映射，iptable设置了什么 执行： docker run -d -p 9000:9000 redis_cluster 9000 root@ubuntu:~# iptables -t nat -L -n Chain PREROUTING (policy ACCEPT) target prot opt source destination DOCKER all -- 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination DOCKER all -- 0.0.0.0/0 !127.0.0.0/8

ref:http://www.infoq.com/cn/presentations/12 ========================Start========== 地址：http://www.infoq.com/cn/presentations/lbs-practice-of-shared-travel 标题：共享出行的 LBS 实践 作者 杨巍 发布于 2016年11月28日 内容：共享出行正在改变着我们的生活，前段时间的共享单车又是一夜之间火爆互联网。其绿色低碳、价格低廉等优势深刻代表了共享出行的新形式，其意在帮助每一位城市人更便捷的完成短途出行。这其中，LBS 至关重要，用户寻车、用车、还车，每一个环节 LBS 都在其中扮演不可替代的角色。高德是如何助力共享单车实现这些场景的，哪些产品在其中发力，实现过程中又会有隐藏哪些能够令人深思的问题？本次演讲将为您解答。 ================================== ========================Start========== 地址：http://www.infoq.com/cn/presentations/core-strengths-and-core-competitiveness-of-rust-language 标题：Rust语言的核心优势和核心竞争力 作者 庄晓立 发布于

什么是云原生 为了解决传统应用升级缓慢、架构臃肿、不能快速迭代、故障不能快速定位、问题无法快速解决等问题，云原生这一概念横空出世。 Pivotal 是云原生应用的提出者，并推出了 Pivotal Cloud Foundry 云原生应用平台和 Spring 开源 Java 开发框架，成为云原生应用架构中先驱者和探路者。 早在 2015 年 Pivotal 公司的 Matt Stine 就写了一本叫做迁移到云原生应用架构的小册子，其中探讨了云原生应用架构的几个主要特征： 符合 12 因素应用 面向微服务架构 自服务敏捷架构 基于 API 的协作 抗脆弱性 后来 Pivotal 对云原生的定义做过几次更新， 最新的 Pivotal 官网上对云原生应用的最新介绍是关注以下四点： 集成 DevOps 持续交付 微服务 容器化 DevOps 是软件开发人员和 IT 运营之间的合作，目标是自动执行软件交付和基础架构更改流程。它创造了一种文化和环境，可在其中快速、频繁且更可靠地构建、测试和发布软件； 持续交付使得单个应用更改在准备就绪后即可发布，而不必等待与其它更改捆绑发布或等待维护窗口期等事件。持续交付让发布行为变得平淡可靠，因此企业可以以更低的风险频繁交付，并更快地获得最终用户的反馈，直到部署成为业务流程和企业竞争力必不可少的组成部分； 微服务是将应用作为小型服务集合进行开发的架构方法

相比于普通的软件的开发速度，容器编排领域的发展速度相当惊人。基于容器的初创公司呈爆发式增长，这个领域的竞争也愈加激烈。这是一个好的开始，但是技术的选择却成为一个难题。在这样的情况下，我们目前关注了Docker和Swarm。 在Apprenda，我们的目标就是提交一个有创意的，稳定的，可以在长时间内比较好维护的编排技术。一个健康的社区有三个关键点。在对技术，社区和不同容器编排工具解决方案进行漫长的商业评估之后，我们选择了Kubernetes。然而，随着其它容器集群管理选项的增加，要重点了解相比于Kubernetes他们分别可以提供什么样的功能进行对比。 Docker即将发布1.12版本，这次的发布直接跟Kubernetes进行竞争。这次的新版本都是在名为SwarmKit的编排系统的基础上建立起来的。Docker Swarm目前增加了一些有趣的新功能，也属于Docker的一部分。比如，Docker CLI增加了一个将Swarm集群实例化的新功能。将Swarm实例化其实也就是创建一个Swarm Manager和CA证书的意思。值得注意的是，这个CA证书可以在不需要外部系统的情况下为Swarm Manager和所有Swarm集群生成证书，同时所有节点之间的交流由TLS来保证安全。这也就意味着不会再有不安全的Swarm集群了。对于创建和使用Swarm的开发者来说，安全已经完全是透明的了。

1.为什么要学习spring？ 1.1设计理念和目标 首先要了解spring的设计理念和目标，可以这么说，spring为开发者提供的是一个 一站式的轻量级应用开发框架 （平台），作为平台，spring抽象了我们 在许多应用开发中遇到的共性问题，同时，作为一个轻量级的应用开发框架，spring和传统的J2EE开发相比，有其自身的特点，通过这些自身的特点 充分体现了它的设计理念： 在java EE的应用开发中，支持POJO和使用JavaBean的开发方式，使应用面向接口开发，充分支持OO（面向对象）的设计方 式 。 比如，在java EE应用开发中，传统的EJB开发需要依赖按照J2EE规范实现的J2EE应用服务器，我们的应用在设计，特别是实现时，往往需要一系列的接口标 准 才能够在应用服务器的环境中得到测试和部署，这种开发方式，使应用在可测试性和部署上都会受到一些影响，spring的设计理念采用了相对EJB而言的 轻量级开发思想，即使用POJO的开发方式，只需要使用简单的java对象或者JavaBean就能进行Java EE开发，这样开发入门，测试，应用部署都得到了简化 另一方面，在我们的应用开发中，往往会涉及复杂的对象耦合关系，如果在java代码中处理这些耦合关系，对代码的维护性和应用扩展性会带来很多不便 而如果使用spring作为应用开发平台，通过使用spring的IOC容器

@[toc] 1. Spring注解的源码分析 1.1 我如何开始分析源码的？ 这一部分可以略过直接看第1.2节 想必程序员都会经过这样一个阶段，当 一门编程语言的语法 已经能够熟练运用。并且它的 流行框架 也能够用到 五分熟 ，程序员就会找进阶的入口，这时候就想到了去了解源码。 作为Java程序员，首先想到的一定是了解Spring源码，但是Spring这个东西庞然大物，从哪里开始都是个问题！这时候我就想起了唐曾那句话：“贫僧从东土大唐而来，往西天取经而去”。真的很羡慕他，知道自己从哪来，还知道自己该往哪去。这样的人已经不多了。那么对Spring源码的剖析该从哪来呢？ 我经历过这几个阶段： 网上看视频（像B站里有很多好的关于spring源码的视频，但是视频有个缺点就是如果忘记了，想复习一遍，没那么容易。） 看网上的博客，这就不用说了。网上的博客五花八门，鱼龙混杂，想要找到一篇适合自己的很不容易。（放弃了） 啃书本，最开始我看的是《Spring源码深度剖析》，但这本书打着Spring5的旗号，讲解xml的内容，作为跟进潮流的程序员表示，我想看关于注解方式的源码解析。然后我又看了《Spring揭秘》《Spirng 技术内幕》等等。没有一本是符合自己的。 黄天不负有心人，最终我还是找到了一本合适的书籍《Spring5 核心原理——手写Spirng 30 个类实战》不得不说

Linux 与 Windows 众所周知，Windows 的应用无法运行在 Linux上，而 Linux 应用也无法运行在 Windows 上。但是，事实上，当 Docker 将容器作为一种显著的打包应用的方法，并且可以在“任意地方”封装它的时候，这里的“任意地方”就已经包含了“Linux”。Windows 也有容器，但是要让所有工作都一起运行还是不太可能的。 但是，今天 Kubernetes1.5 的发布，让 Linux 和 Windows 一起运行的梦想能够实现了。 Kubernetes1.5 （alpha 版本）支持 Windows 服务器容器，跟 Docker 类似，他们共享同一个内核模式；而 Hyper－V 容器的单核模式则为多租户环境提供了更好的隔离（代价是延迟时间更长了）。最终的结果就是，在你创建的这个 Kubernetes 集群上，Linux 节点可以运行 Linux 容器，Windows 节点可以运行 Windows 容器；同时，Linux 节点也可以运行 Windows 容器，Windows 节点也可以运行 Linux 容器，真正实现混合集群。比如，单个 service 允许 Pod 使用 Windows 服务器容器，也允许其它的 Pod 使用 Linux 容器。 虽然 Kubernetes1.5 功能全面，但是也有它的局限性，比如： Kubernetes 是由

相关地址 docker 官网：https://www.docker.com/ 官方文档：https://docs.docker.com/install/linux/docker-ce/centos/ 中文文档：http://www.dockerinfo.net/document docker仓库：https://hub.docker.com/ 阿里云仓库：https://cr.console.aliyun.com/cn-shanghai/instances/repositories docker 介绍 Docker 是基于 Go 语言实现的开源容器项目，一种容器技术，目前已有 80 多个相关开源组 件项目（包括 Containerd Moby Swarm 等），逐渐形成了围 Docker 容器的完整的生态体系 Docker 的构想是要实现“ Build Ship and Run Any App, Anywhere ”，即通过对应用的封 装（ Packaging ）、分发（ Distribution ）、部署（ Deployment ）、运行（ Runtime ）生命周期进行管理，达到应用组件级别的“一次封装 ，到处运行” 这里的应用组件， 既可以是一个 Web 用、一个编译环境，也可以是一套数据库平台服务，甚至是一个操作系统或集群。 实现Devops的工具。 与虚拟机的区别

Spring-理解IOC容器 序言 IoC粗理解 IoC细理解 Spring中IoC的应用 IoC容器 容器的两种表现形式 BeanFactory的IoC实现过程： IoC容器初始化过程 BeanDefinition的定位 BeanDefinition的载入 IoC容器的依赖注入 IoC小结 参考文章： 序言 IoC(Inversion of Control) 控制反转，两种实现： 依赖查找（DL） 依赖注入（DI） IoC包括 依赖查找(DL) 和 依赖注入(DI) ；只不过DL因为有 侵入性 (它需要用户自己去是使用 API 进行查找资源和组装对象)，已经被抛弃。所以现在提到IoC，更多的想到的就是依赖注入(DI)了。 依赖注入(DI)包括Set注入和构造器注入！其实还有一个通过实现接口的方式实现依赖注入，不过不常用，就不说了。 注意：Java 使用 DI 方式实现 IoC 的不止 Spring，包括 Google 的 Guice，还有一个冷门的 PicoContainer（极度轻量，但只提供 IoC）。 如图所示： 但其实 IOC 和DI 相当于一回事，只不过是看待问题的角度不同而已: IOC: Spring 反向控制应用程序需要的资源。 DI: 应用程序依赖Spring为其提供资源。 IOC 是站在Spring 的角度，而DI 是站在应用程序的角度。 如下图所示：