云计算深入浅出聊Docker解读Microservices

Posted 2021-04-21 产业智能官

深入浅出聊Docker

Docker是什么?

Docker是一个工具，能把应用打包部署于container里，这里可以把container看做是一个简易版的 Linux 环境和运行在其中的应用程序，每个container运行一个application。它诞生于 2013 年初，最初是 dotCloud公司内部的一个业余项目，创始人是Solomon Hykes。

Docker自开源后受到广泛的关注和讨论，Redhat已经在其 RHEL6.5 中明确支持Docker；Google也在其PaaS产品中广泛应用。Docker项目的目标是实现轻量级的操作系统虚拟化解决方案。 现在Docker已经从一个工具转化成平台，小生态圈。

Docker的优势有哪些？

以前企业部署软件会购买真正的服务器，这种模式的资源利用率很低。后来出现了云端的虚拟服务器，比如AWS，提高了一定的资源利用率，但是不同阶段的应用环境可能不同。

Docker对这些有很大的优化，比如：

1. Docker 容器可以实现秒级启动

2. 容器除了运行其中应用外，基本不消耗额外的系统资源，使得应用的性能很高，系统的开销很小。传统虚拟机方式运行10个不同的应用就要起10个虚拟机，而Docker只需要启动10个隔离的应用即可。

下图是传统虚拟化方式和Docker的不同。Docker本质上是一种虚拟化的技术，不是虚拟机。Docker是在操作系统层面上实现虚拟化，直接复用本地主机的操作系统，而传统方式则是在硬件层面实现。在传统模式下，Guest OS会占用大量空间，而且不同的应用会需要不同的虚拟机。在Docker中只有一个OS，各种application运行在一个OS上。

*Hypervisor是一种虚拟化的技术

具体来说，Docker的优势包括：

1. Faster developer onboarding

2. No vendor lockin

3. Eliminate environment inconsistencies

4. Ship applications faster

5. Scale quickly

6. Easily remediate issues

   
   

Play with Docker container

下载安装完Docker后，可以尝试使用以下命令来运行一个聊天软件。

docker run -d -p 3000:3000 unclebarney/chit-chat

这个命令的含义是启动Docker容器。-d表示在后台启动。-p表示做端口的映射，把容器里的3000端口映射到宿主机上的3000。使用的镜像为unclebarney/chit-chat。

这个命令有两部分操作：

1. 从Dockerhub（所有镜像存储的地方）下载此镜像，大概5到30秒（取决于带宽）

2. 根据镜像启动container，并运行node server

Docker image

Docker image（镜像）是container的基础。所有container都是从image构建的。
Docker 运行容器前需要本地存在对应的镜像，如果镜像不存在本地，Docker 会从镜像仓库下载（默认是 Docker Hub 公共注册服务器中的仓库）。

从下图可以看出image的具体含义

Docker每个运行的实例由最上层的container和下面的多层镜像构成。Docker使用Union FS（union filesystem）将这些不同镜像整合在一起。通常Union FS有两个用途, 一方面可以实现不借助LVM、RAID将多个disk挂到同一个目录下；另一个更常用的就是将一个只读的分支和一个可写的分支联合在一起，Live CD正是基于此方法可以允许在镜像不变的基础上允许用户在其上进行一些写操作。

镜像的每一层都有以下这些信息：

1. 这一层的meta data，以JSON的形式存储

2. image filessystem changeset

3. image ID，比如：74fe38d11401

镜像有两种构建方式：

1. 启动一个最基础的容器，在里面运行一些命令，像git一样把这些命令commit，形成自己的镜像。

2. 引用一个base image，再加上一些需要的指令。这些指令存在一个文件中，叫Dockerfile。

以下是Dockerfile的例子，是刚才提到的聊天软件的镜像的生成方式。

# 引用mhart/alpine-node这个镜像
# Dockerfile中第一个命令必须是FROM命令
FROM mhart/alpine-node:base
# 将Dockerfile所在文件夹中的内容添加到Docker镜像中
# 第一个点指的是Dockerfile所在的目录
# 第二个点指的是Docker镜像中的当前目录
ADD . .
# 为这个镜像暴露3000端口
EXPOSE 3000
# 运行node命令。值得注意的是在构建镜像的时候这个命令不会执行
# 而是在真正基于这个镜像启动了容器时才会执行这个命令
CMD [“node”, “index.js”]

More Explanation

如果传统方式做一个聊天软件。首先底层有个Linux系统，上层有个node.js，再上面有source code。user通过3000端口连接。假设Google需要这个应用，那么需要将整个程序package打包过去。最简单的打包方式是从Linux系统到source code都打包。虽然最主要的部分是source code，但是不能只打包它。如果另外有用户（Google 2）需要这个应用，还是要把整个系统打包。

如果使用Docker，这两个服务（service 1，service 2）的Linux，node.js是一样的，但是它们的source code不同。如果将它们分层，比如Linux系统部分叫image 1， Node.js部分叫image 2，Service 1的source code叫image 3，Service 2的source code叫image 4。这样可以把image 1，2，3给Google1，而把image1,2,4给Google 2。image 1，2是可以复用的。

如果image 1，2，3里都有file 0。image3会使得image 1和2里的file 0隐藏（如同覆盖）。从上层往下层看，如果拥有相同文件名，下层文件隐藏。

Docker中下层的文件都是只读的，只在最上方有可读写层。应用可以对可读写层进行修改。

Namespace

Docker运用Linux系统里的namespace（命名空间）技术实现最上层应用之间的分离。拥有相同namespace的进程拥有相同的资源。拥有不同namespace的进程拥有的资源相互独立。每个容器都有自己单独的名字空间，运行在其中的应用都像是在独立的操作系统中运行一样。名字空间保证了容器之间彼此互不影响。

Cgroups

Docker运用Cgroups（控制组）进行资源限制。它是 Linux 内核的一个特性，主要用来对共享资源进行隔离、限制、审计等。只有能控制分配到容器的资源，才能避免多个容器同时运行时对系统资源的竞争。控制组技术最早是由Google的程序员提出。

Docker Components

下图是Docker的构成

Docker采用了C/S架构，包括客户端和服务端。 Docker daemon作为服务端接受来自客户的请求，并处理这些请求（创建、运行、分发容器）。 客户端和服务端既可以运行在一个机器上，也可通过socket或者RESTful API来进行通信。Docker daemon一般在宿主主机后台运行，等待接收来自客户端的消息。 Docker客户端则为用户提供一系列可执行命令，用户用这些命令跟 Docker daemon交互。

Docker daemon包括两部分：

1. 一个轻量级服务器，接收来自客户端的消息，为用户提供一系列可执行命令

2. 一个engine，负责调度请求，是一个总入口，管理容器的生存周期

Docker registry是存储镜像的一个仓库。它与daemon沟通，处理从客户端发送来的镜像相关的请求。可以使用public的registry或者private的。

Docker在本地安装时还有一个功能是graphdb。graphdb是一个基于SQLite的一个小数据库。能够管理本地Docker镜像和它们之间的关系。当创建新的container时，或是下载某个镜像时，Docker会先查找原有的镜像，复用可用资源。

Docker driver允许用户定制Docker运行的环境。它包括三类：

1. graph driver：存储相关

2. network driver：网络相关

3. exec driver：运行环境相关

一个container可以没有IP。在network driver里一个选项设为none，可以实现。

RunC

runC是一个抽象层，它介于Docker driver和Linux kernel之间。运用它可以调用很多linux内核的功能，包括namespace，cgroups，capabilities，filessystem access controls。

Open source

Docker不被任何运营商锁定，不被任何公司垄断。Docker项目已经加入了Linux基金会，遵从了 Apache 2.0协议，项目代码在GitHub上进行维护。

---

解读Microservices

现在很多人都在谈论Microservices，但是每当我们努力探究的时候，似乎里面没有任何新东西，每个人都在讨论，却没有人知道如何去做。那现在我们来看一看Microservices到底是什么。

从开发的角度来看

从开发的角度来说，Microservices对应胖服务，下图中左边是胖服务，右边是Microservices微服务。胖服务里面往往把所有服务都放在一起来开发，强调了模块之间的相互牵连，也就是所谓的“牵一发而动全身”。而右边的微服务则相对独立，能够使用不同的语言来进行开发。

 

从部署的角度来看

在部署的时候可以看到，胖服务在每个机器里面都需要把所有模块包含在里面，所以整个胖服务之间都是一样的。而在微服务里，我们可以把每个模块和每个服务部署在多个机器上，而每个机器上甚至可以部署多个一样的服务

 

 

Microservices是一个新概念吗？

那Microservices到底是一个新的概念吗？肯定不是。从service-oriented architecture角度来看，实际上它就是一种面向服务的设计。因此，我们的Microservices微服务只是SOA小小的子集。那我们是在不断地创造新概念来满足虚荣心吗？实际上，很多时候我们会有很多花哨的成分在里面，但对于微服务来说，它选择了面向服务这一个子集，也就是说在这个子集里它有一些独到之处。

 

 

Microservices的趋势

那这些独到之处有哪些呢？我们可能很难定义出微服务到底是什么，但我们可以从下面七个趋势中看一看微服务到底带给我们什么

• 组件是服务

• 基于需求模块的团队

• 弱化管道强调终端

• 分散管理

• 部署自动化

• 为失败设计

• 进化的设计

 

趋势一  

组件是服务，我们想要了解组件是什么，组件其实是一些相互独立，能够相互替代并且能够独立升级的东西。举个例子，我们有笔记本，有显示器，有鼠标，有键盘，这些放在一起组成了工作套装，它是能够相互替代的，因为笔记本和显示器都可以替代成别的东西。那什么叫独立升级呢？比如说把我的显示器从20寸升级到24寸，这就是一种独立升级。

 

那再看一看怎么实现组件呢？

 

实际上有两种方式，左边是基于Library库函数的方式。它的核心往往是一种语法调用，比如函数或者类的写法。而右边是基于服务的方式，那它的方式往往是进程间的通信，如今http之类的基于web的通信已经越来越成为我们一个实时标准了。

 

 

右侧有什么好处呢？比如说某个库升级了，需要依赖于Java8，而其它旧的库需要依赖于Java7，那左边基于库的方式就很难实现，因为它们往往需要依赖同一个版本。而基于右边微服务的方式就很容易实现。实际上再结合现在Docker越来越火的趋势，在不同的Docker里打装上不同的Java运行版本就很容易实现。

趋势二  

基于需求模块的团队这个看起来很抽象，传统来说，团队里面的分工就是UI团队，Server团队，DBA团队，但我们如果基于微服务拆解以后就会发现，这群人负责Order,另群人负责做Shipping，还有一群人负责做类目Catalog，所以不同的人群可以组合在一起实现一个小团队。像很多创业公司都是这样做的，就会拆成这样的情况。

 

趋势三  

弱化管道强调终端什么叫弱化管道呢？其实传统的方式我们也能把服务都连在一起，但这些服务中间连接的集合体往往会做很多事情，比如check一些消息，判断怎么路由以及大家真正的连接等各种复杂情况，都需要给中间键来解决 。而如今随着大家的通讯方式越来越简单，我们可以在每一个单独的模块上把负责通讯的机制放里面，比如说都是基于HTTP的服务或者是基于REST的服务，这样大家通过很简单的方式就可以实现通讯，就不会有很重的管道概念存在。

趋势四 

分散管理这很容易了解，我们左侧一群人，他们都要访问底层数据，这些胖的数据都放在一起，所以需要通过统一的方式来访问。而右侧大家可以拆解开，不同的服务访问不同的数据库，不同的数据文件，因而能够实现很好的效果。实际上我们用微服务也很容易，因为微服务带来另外一个现象，就是我们现在的数据库也在拆解，比如基于图的数据库，基于文档的数据库，基于KeyValue数据库。他们分别适用于不同的场景，所以我们完全可以通过一种微服务的方式把大家拆解开，不同的服务只访问自己的数据，上面再搭一层kafka把大家连到一起。

 

 

趋势五 

部署自动化现在我们开发完一个程序以后，如果用Docker我们可以持续在系统上不断的部署上去。Docker不仅提供了一整套工具来做，而且可以同时运行很多的实例，我们可以实现这些实例的部分升级，这也是我们持续部署自动化的一个概念。

 

趋势六 

为失败设计这个是非常好玩的，假设我们只有10台机器，每台机器的成功率是99%，那么加在一起成功率就是90%，但如果有100台服务机器，我们成功率就变成了0.37，所以失败一定会出现。0.99^10=0.900.99^100=0.37因此很多人为了保证系统的健壮，会制造出很多虚拟坏人把机器全部破坏，看你的鲁棒性。因此我们在设计的时候一定会想如果这个东西崩溃掉怎么办，因此很多时候无状态服务也成为一个流行的趋势。趋势七  进化的设计

在微服务里面我们可以不断的优化我们的结构，因为它们之间相互独立，所以大家可以做一种基于进化的设计方式。

 

那我们再做一个简单的比较，到底胖服务和微服务之间有什么优点和缺点呢？

 

1. 开发来说，胖服务更简单。因为在开发时虽然微服务看起来架构简单，但需要处理通讯，沟通，数据一致性等很多问题，所以其实开发更难，这也是为什么绝大多数人首先用的都是胖服务而不是微服务。

2. 持续部署上，微服务有很大的优势，因为它能够一个模块一个模块单独升级，而不需要升级全部。

3. 数据一致性来说，必然是胖服务好。因为胖服务的数据在一起，所以大家通过统一的管道来访问，因此数据不容易出问题。在微服务里面，数据往往存在多个副本，会有多个访问源，那我们就会出现各种冲突或者写之类的问题。

4. 微服务的数据可用性很高。因为大家独立保存自己的一份，或者服务之间各种互相替换，很多情况下数据即使出现一些小故障也能够带伤运行，如同人体一样。

5. 对于重构来说，实际上胖服务更容易重构。为什么呢？因为微服务中每个启动的服务相对固定，内部是包容在一起的，因此要想进行大的调整，会发现这个服务需要全部调整。对于胖服务来说，只要可能调整内部就行，对于外部往往是透明的。

6. 维护上来看，微服务会更方便。因为模块升级，修改等只管自己就可以，不用管其他。

7. 哪个服务支持更多的平台呢？答案还是微服务。因为能够支持不同语言，每个平台都是相互独立的，中间有个统一的交流语言就好。

 

说了这么多，我们应该用微服务吗？实际上微服务和胖服务很像一个中心控制的集权式国家以及自由浪漫的经济主义，他们并不是好与不好。从国家的创建来说，实际从国家的创立的初期，往往需要一个集权的力量控制所有，这就是胖服务；当国家建立起来以后，长期发展经济上行就需要微服务来帮助大家有活性，能够成长起来。所以早期经常用胖服务，晚期经常用微服务。当然，很多就希望一个完美的方案，是不是微服务能够解决所有问题呢？一开始用微服务就行了吗？这其实是一个幻想，大家不要想这么多，还是老老实实从胖服务做起。所以我们经常会说，仰望星空，脚踏实地。碰到任何一个设计，千万不要认为它是万能药，可以解决所有问题。出现big data，出现function program这类词之后，我们往往都会产生各种各样的想法，但最终都幻灭。

做一个总结：

• Microservices是一群通过HTTP沟通的独立自治的需求模块

• 迷信Microservices是痛苦的源泉

• 仰望星空，脚踏实地

 

资料：

视频 Microservices • Martin Fowler

博客http://martinfowler.com/articles/microservices.html

---

老辈SOA，火的微服务，新生代服务网格（Service Mesh）

全民学编程

SOA 全称是：Service Oriented Architecture，“面向服务的架构”。

说SOA，必然要说ESB，ESB 的存在是为了集成基于不同协议的不同服务，ESB 做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通。

SOA 所要解决的核心问题是：

• 系统间的集成：站在系统的角度来看，首先要解决各个系统间的通信问题。目的是将原先系统间散乱、无规划的网状结构，梳理成规整、可治理的星形结构，这步的实现往往需要引入一些概念和规范。比如 ESB、以及技术规范、服务管理规范；这一步解决的核心问题是【有序】。

• 系统的服务化：站在功能的角度，需要把业务逻辑抽象成可复用、可组装的服务，从而通过服务的编排实现业务的快速再生。目的是要把原先固有的业务功能抽象设计为通用的业务服务、实现业务逻辑的快速复用；这步要解决的核心问题是【复用】。

• 业务的服务化：站在企业的角度，要把企业职能抽象成可复用、可组装的服务，就要把原先职能化的企业架构转变为服务化的企业架构，以便进一步提升企业的对外服务的能力。“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。而本步骤，则是以业务驱动把一个业务单元封装成一项服务。要解决的核心问题是 【高效】

微服务（Microservices）架构

微服务不再强调传统 SOA 架构里面比较重的 ESB 企业服务总线，同时以 SOA 的思想进入到单个业务系统内部实现真正的组件化。原单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应用或组件服务。

服务的特征：

• 通过服务实现组件化

• 按业务能力来划分服务和开发团队

• 去中心化

• 基础设施自动化(DevOps、自动化部署)

服务注册发现和负载均衡是微服务架构在技术上的根本问题，解决的办法是采用代理 Proxy。根据代理在架构上的位置不同，服务发现代理一般有三种模式：

• 模式一：集中式代理

• 模式二：客户端嵌入式代理

• 模式三：主机独立进程代理

服务网格（Service Mesh）架构

ServiceMesh 本质上就是模式三中主机独立进程代理，它结合了模式一和模式二的优势。

号称是下一代微服务，不知道生产环境用的多不，有人探路没有。所以没有趋于成熟的东西，生产环境慎用。

服务网格的特征：

• 应用程序间通讯的中间层

• 轻量级网络代理

• 应用程序无感知

• 解耦应用程序的重试/超时、监控、追踪和服务发现

以上是参考网上文章和个人理解，理解有误的地方请多多指教。

参考

SOA&微服务&服务网格&高可用

http://www.cnblogs.com/wade-luffy/p/9293090.html

微服务架构设计

https://www.cnblogs.com/wintersun/p/6219259.html

Service Mesh 及其主流开源实现解析

http://blog.51cto.com/brucewang/2144039?from=groupmessage

工业互联网

---

产业智能官  AI-CPS

加入知识星球“产业智能研究院”：先进产业OT（工艺+自动化+机器人+新能源+精益）技术和新一代信息IT技术（云计算+大数据+物联网+区块链+人工智能）深度融合，在场景中构建状态感知-实时分析-自主决策-精准执行-学习提升的机器智能认知计算系统；实现产业转型升级、DT驱动业务、价值创新创造的产业互联生态链。

版权声明：产业智能官（ID：AI-CPS）推荐的文章，除非确实无法确认，我们都会注明作者和来源，涉权烦请联系协商解决，联系、投稿邮箱：[e-mail]。