响应银监会十三五规划之拥抱容器系列(一):微服务化

宁静胡同 发表了文章 • 0 个评论 • 490 次浏览 • 2016-07-21 11:50 • 来自相关话题

中国银监会7月15日就《中国银行业信息科技“十三五”发展规划监管指导意见(征求意见稿)》(以下简称指导意见)公开征求意见。从提升信息科技治理水平,深化科技创新,推进互联网、大数据、云计算新技术应用等方面入手,指出健全产品研发管理机制,加强信息安全管理,提升信息科技风险管理水平,推进科技开发协作等方面重点工作任务。

指导意见同时指出,银行业应该适应互联网环境下计算资源弹性变化和快速部署等需求,开展云计算架构规划,制定云计算应用策略。探索构建私有云平台,采用成熟度高、开放性强的计算虚拟化、容器虚拟化、分布式存储、网络虚拟化等技术,建立资源池,形成资源弹性供给、灵活调度和动态计量的私有云平台。探索建立银行业金融公共服务行业云,构建私有云与行业云相结合的混合云应用。同步开展应用架构规划,构建与云计算基础设施相适应的应用架构,自主设计或推动应用开发商实施应用架构改造,并降低应用与基础架构的耦合度。稳步实施架构迁移,到“十三五”末期,面向互联网场景的主要信息系统尽可能迁移至云计算架构平台。

银行业拥抱云计算已经是必然趋势,而容器则是其中的关键技术。数人云推出了传统金融业Docker实践系列组图与文章,将一一为大家展现传统金融业的转型过程中的技术细节与实践心得,欢迎大家持续关注。







数人金融容器云

作为基于Docker的最轻量级PaaS平台,数人金融容器云致力于打造金融领域专属的云原生应用平台,实现秒级启停,帮助客户及时响应高并发等新型业务需求;同时,借助容器技术,使应用的交付变得标准,极大地消除技术部署的局限性,提高客户产品的交付及运维效率;数人金融容器云平台自身具备高可用能力,以最大程度保证对工作集群不间断管控,工作集群内的各组件也具备高可用特性,进一步保障了客户的容器化应用安全、可靠、稳定运行;提供从主机网络到应用容器实例的多级实时监控和告警机制,极大降低了金融IT运维风险。

目前,数人云在金融领域已有多家合作客户,帮助金融客户在互联网+时代下构建开放业务新形态,从平台转型、产品创新、服务交付等层面推进金融业信息化变革,激发创新活力。


  查看全部
中国银监会7月15日就《中国银行业信息科技“十三五”发展规划监管指导意见(征求意见稿)》(以下简称指导意见)公开征求意见。从提升信息科技治理水平,深化科技创新,推进互联网、大数据、云计算新技术应用等方面入手,指出健全产品研发管理机制,加强信息安全管理,提升信息科技风险管理水平,推进科技开发协作等方面重点工作任务。

指导意见同时指出,银行业应该适应互联网环境下计算资源弹性变化和快速部署等需求,开展云计算架构规划,制定云计算应用策略。探索构建私有云平台,采用成熟度高、开放性强的计算虚拟化、容器虚拟化、分布式存储、网络虚拟化等技术,建立资源池,形成资源弹性供给、灵活调度和动态计量的私有云平台。探索建立银行业金融公共服务行业云,构建私有云与行业云相结合的混合云应用。同步开展应用架构规划,构建与云计算基础设施相适应的应用架构,自主设计或推动应用开发商实施应用架构改造,并降低应用与基础架构的耦合度。稳步实施架构迁移,到“十三五”末期,面向互联网场景的主要信息系统尽可能迁移至云计算架构平台。

银行业拥抱云计算已经是必然趋势,而容器则是其中的关键技术。数人云推出了传统金融业Docker实践系列组图与文章,将一一为大家展现传统金融业的转型过程中的技术细节与实践心得,欢迎大家持续关注。


654082800374343878.png


数人金融容器云

作为基于Docker的最轻量级PaaS平台,数人金融容器云致力于打造金融领域专属的云原生应用平台,实现秒级启停,帮助客户及时响应高并发等新型业务需求;同时,借助容器技术,使应用的交付变得标准,极大地消除技术部署的局限性,提高客户产品的交付及运维效率;数人金融容器云平台自身具备高可用能力,以最大程度保证对工作集群不间断管控,工作集群内的各组件也具备高可用特性,进一步保障了客户的容器化应用安全、可靠、稳定运行;提供从主机网络到应用容器实例的多级实时监控和告警机制,极大降低了金融IT运维风险。

目前,数人云在金融领域已有多家合作客户,帮助金融客户在互联网+时代下构建开放业务新形态,从平台转型、产品创新、服务交付等层面推进金融业信息化变革,激发创新活力。


 

Docker 1.12实践:Docker Service、Stack与分布式应用捆绑包

宁静胡同 发表了文章 • 0 个评论 • 934 次浏览 • 2016-07-13 15:10 • 来自相关话题

在本文中数人云将带大家了解如何利用Docker Compose创建一套分布式应用捆绑包,并将其作为Docker Stack在Docker Swarm Mode中进行部署。


Docker 1.12的首套候选发行版于三周之前公布,而近期又有更多新功能计划被添加至该版本当中。


下面首先来看各项新的功能特性:
内置编排机制:通常来讲,应用利用一个Docker Compose文件进行定义。此定义由多个被部署在不同主机上的容器共同构成。这种作法除了能够避免单点故障(简称SPOF)之外,也能够让应用具备弹性。目前包括Docker Swarm、Kubernetes以及Mesos在内的多种编排框架都允许大家对此类应用进行编排。不过现在我们又有了新的选择——Docker Engine如今迎来了内置编排机制。更多细节内容将在后文中进行说明。Service:现在大家可以利用docker service create 命令轻松创建一项复制且分布式的负载均衡服务。该应用可实现“理想状态”,例如运行三套Couchbase容器,并具备自我修复能力。Docker引擎能够确保必要容器数量始终运行于集群当中。如果某容器发生故障,那么另一容器将旋即启动。如果某台节点发生故障,则该节点上的容器会在另一节点上启动。稍后我们将详细说明其作用。零配置安全性: Docker 1.12采用相互验证TLS,能够对swarm当中各节点间的通信内容进行验证、授权与加密。更多详尽内容将在后文中进行讨论。

Docker Stack与分布式应用捆绑包:分布式应用捆绑包,或者简称DAB,是一种多服务可分发镜像格式。在后文中我们会进一步讨论。


截至目前,大家已经可以选定一个Dockerfile,并利用docker build命令由此创建镜像。使用docker run命令则可启动容器。这条命令亦能够轻松同时启动多套容器。另外,大家也可以使用Docker Compose文件并利用docker-compose scale命令对容器进行规模扩展。









镜像属于单一容器的一种便携式格式。而Docker 1.12当中新推出的分布式应用捆绑包,或者简称DAB,则属于一种新的概念,其专门面向多套容器的迁移需求。每个捆绑包都可作为stack在运行时中进行部署。









感兴趣的朋友可以前往docker.com/dab了解更多与DAB相关的内容。为了简单起见,在这里我们利用类比来进行说明:


kerfile -> 镜像 -> 容器

Docker Compose -> 分布式应用捆绑包 -> Docker Stack

下面我们使用一个Docker Compose文件来创建DAB,并将其作为Docker Stack加以部署。


需要强调的是,这项实验性功能仅存在于1.12-RC2版本当中。


利用Docker Compose创建一个分布式应用捆绑包


Docker Compose CLI添加了一条新的bundle命令。下面来看其具体说明:docker-compose bundle --help
Generate a Docker bundle from the Compose file.

Local images will be pushed to a Docker registry, and remote images
will be pulled to fetch an image digest.

Usage: bundle [options]

Options:
-o, --output PATH Path to write the bundle file to.
Defaults to "<project name>.dsb".
现在,让我们选取一条Docker Compose定义并以此为基础创建DAB。以下为我们的Docker Compose定义内容:version: "2"
services:
db:
container_name: "db"
image: arungupta/oreilly-couchbase:latest
ports:
- 8091:8091
- 8092:8092
- 8093:8093
- 11210:11210
web:
image: arungupta/oreilly-wildfly:latest
depends_on:
- db
environment:
- COUCHBASE_URI=db
ports:
- 8080:8080

此Compose文件会启动WildFly与Couchbase服务器。其中WildFly服务器中已经预部署了一款Java EE应用,且接入Couchbase服务器并允许利用REST API执行CRUD操作。该文件的源代码来自:github.com/arun-gupta/oreilly-docker-book/blob/master/hello-javaee/docker-compose.yml。利用它生成一个应用捆绑包:docker-compose bundle
WARNING: Unsupported key 'depends_on' in services.web - ignoring
WARNING: Unsupported key 'container_name' in services.db - ignoring
Wrote bundle to hellojavaee.dsb


depends_on只负责创建两项服务之间的依赖性,并以特定顺序对二者进行启动。这能确保Docker容器首先启动,而运行在其中的应用则需要更长时间才能启动完成。因此,此属性只在一定程度上解决了这一问题。


container_name能够为该容器提供一个特定名称。对特定容器名称的依赖性为紧密耦合,且不允许我们对该容器进行规模伸缩。因此这里我们暂时忽略这两条警告。此命令会利用Compose项目名(也就是其目录名称)生成一个文件。因此在本示例中,生成的文件名为hellojavaee.dsb。此文件的扩展名在RC3中则为.dab。此生成的应用捆绑包内容如下所示:{
"services": {
"db": {
"Image": "arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c",
"Networks": [
"default"
],
"Ports": [
{
"Port": 8091,
"Protocol": "tcp"
},
{
"Port": 8092,
"Protocol": "tcp"
},
{
"Port": 8093,
"Protocol": "tcp"
},
{
"Port": 11210,
"Protocol": "tcp"
}
]
},
"web": {
"Env": [
"COUCHBASE_URI=db"
],
"Image": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914",
"Networks": [
"default"
],
"Ports": [
{
"Port": 8080,
"Protocol": "tcp"
}
]
}
},
"version": "0.1"
}


此文件为包含在应用内的各项服务提供完整的描述。当然,未来我们应该可以使用其它容器格式,例如Rkt或者VM等形式。不过就目前来讲,其还仅支持Docker这一种格式。


在Docker中进行Swarm Mode初始化


正如之前所提到,目前“理想状态”由Docker Swarm负责保持。而其现在已经被纳入Docker Engine当中。在本篇文章中,我们使用新增的一条命令,即docker swarm:docker swarm --help

Usage: docker swarm COMMAND

Manage Docker Swarm

Options:
--help Print usage

Commands:
init Initialize a Swarm
join Join a Swarm as a node and/or manager
update Update the Swarm
leave Leave a Swarm
inspect Inspect the Swarm

Run 'docker swarm COMMAND --help' for more information on a command.
在Docker Engine中对一个Swarm节点(作为工作节点)进行初始化:docker swarm init
Swarm initialized: current node (ek9p1k8r8ox7iiua5c247skci) is now a manager.

关于该节点的更多细节信息可利用docker swarm inspect命令进行查看。docker swarm inspect
[
{
"ID": "1rcvu7m9mv2c8hiaijr7an9zk",
"Version": {
"Index": 1895
},
"CreatedAt": "2016-07-01T23:52:38.074748177Z",
"UpdatedAt": "2016-07-02T04:54:32.79093117Z",
"Spec": {
"Name": "default",
"AcceptancePolicy":{
"Policies": [
{
"Role": "worker",
"Autoaccept": true
},
{
"Role": "manager",
"Autoaccept":false
}
]
},
"Orchestration": {
"TaskHistoryRetentionLimit":10
},
"Raft": {
"SnapshotInterval": 10000,
"LogEntriesForSlowFollowers":500,
"HeartbeatTick":1,
"ElectionTick":3
},
"Dispatcher": {
"HeartbeatPeriod": 5000000000
},
"CAConfig": {
"NodeCertExpiry": 7776000000000000
}
}
}
]
从输出结果中可以看到,该节点只属于工作节点而非管理节点。如果在单节点集群当中,这样的设置并无不妥。不过在多节点集群当中,则应至少存在一个管理节点。


部署Docker Stack


利用docker deploy命令创建一个stack:docker deploy -f hellojavaee.dsb hellojavaee
Loading bundle from hellojavaee.dsb
Creating network hellojavaee_default
Creating service hellojavaee_db
Creating service hellojavaee_web
下面来看各服务列表:docker service ls
ID NAME REPLICAS IMAGE COMMAND
2g8kmrimztes hellojavaee_web 1/1 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914
46xhlb15cc60 hellojavaee_db 1/1 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c

在输出结果中,我们可以看到正在运行的两项服务,分别为WildFly与Couchbase。 Service概念同样新增于Docker 1.12版本,其负责为我们提供“理想状态”,而具体实现则由Docker Engine负责。使用docker ps命令显示当前正在运行的容器列表:CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
622756277f40 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c "/entrypoint.sh /opt/" 3 seconds ago Up 1 seconds 8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp hellojavaee_db.1.19enwdt6i5m853m5675tx3z29
abf8703ed713 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 3 seconds ago Up 1 seconds 8080/tcp hellojavaee_web.1.70piloz6j4zt06co8htzisgyl

WildFly容器会在Couchbase容器启动并运行之前先行启动。这意味着Java EE应用会尝试接入Couchbase服务器但发生失败。因此,该应用将永远无法成功完成引导。


自我修复Docker Service


Docker Service负责保持应用的“理想状态”。在本示例中,我们的理想状态是确保特定服务有且只有一套容器与之对应且持续运行。如果我们移除该容器,而非服务,则该服务会自动重启容器。使用以下命令移除容器:docker rm -f abf8703ed713

请注意,这里之所以要使用-f,是因为该容器已经处于运行状态。Docker 1.12自我修复机制会介入并自动重启此容器。现在再次打开运行容器列表:CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
db483ac27e41 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 1 seconds ago Up Less than a second 8080/tcp hellojavaee_web.1.ddvwdmojjysf46d4n3x4g8uv4
622756277f40 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c "/entrypoint.sh /opt/" 26 seconds ago Up 25 seconds 8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp hellojavaee_db.1.19enwdt6i5m853m5675tx3z29
结果显示新容器已经启动完成。检查WildFly服务:docker service inspect hellojavaee_web
[
{
"ID": "54otfi6dc9bis7z6gc6ubynwc",
"Version": {
"Index": 328
},
"CreatedAt": "2016-07-02T01:36:35.735767569Z",
"UpdatedAt": "2016-07-02T01:36:35.739240775Z",
"Spec": {
"Name": "hellojavaee_web",
"Labels": {
"com.docker.stack.namespace": "hellojavaee"
},
"TaskTemplate": {
"ContainerSpec": {
"Image": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914",
"Env": [
"COUCHBASE_URI=db"
]
}
},
"Mode": {
"Replicated": {
"Replicas": 1
}
},
"Networks": [
{
"Target": "epw57lz7txtfchmbf6u0cimis",
"Aliases": [
"web"
]
}
],
"EndpointSpec": {
"Mode": "vip",
"Ports": [
{
"Protocol": "tcp",
"TargetPort": 8080
}
]
}
},
"Endpoint": {
"Spec": {},
"Ports": [
{
"Protocol": "tcp",
"TargetPort": 8080,
"PublishedPort": 30004
}
],
"VirtualIPs": [
{
"NetworkID": "9lpz688ir3pzexubkcb828ikg",
"Addr": "10.255.0.5/16"
},
{
"NetworkID": "epw57lz7txtfchmbf6u0cimis",
"Addr": "10.0.0.4/24"
}
]
}
}
]




Swarm会将随机端口分配给该服务,我们也可以利用docker service update命令进行手动更新。在本示例中,容器的端口8080被映射至主机上的端口30004。



进行应用验证


下面检查该应用是否已经成功部署:curl http://localhost:30004/books/resources/book
[{"books":0}]


为该应用添加新的book:curl -v \
> -H "Content-Type: application/json" \
> -X POST -d '{
> "isbn": "978-1-4919-1889-0",
> "name": "Minecraft Modding with Forge",
> "cost": 29.99
> }' \
> http://localhost:30004/books/resources/book
* Trying ::1...
* Connected to localhost (::1) port 30004 (#0)
> POST /books/resources/book HTTP/1.1
> Host: localhost:30004
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 92
>
* upload completely sent off: 92 out of 92 bytes
< HTTP/1.1 200 OK
< Connection: keep-alive
< X-Powered-By: Undertow/1
< Server: WildFly/10
< Content-Type: application/octet-stream
< Content-Length: 88
< Date: Sat, 02 Jul 2016 01:39:49 GMT
<
* Connection #0 to host localhost left intact
{"name":"Minecraft Mhttp://localhost:30004/books/r ... ot%3B}



再次验证该book:curl http://localhost:30004/books/resources/book
[{"books":{"name":"Minecraft Modding with Forge","cost":29.99,"id":"1","isbn":"978-1-4919-1889-0"}}, {"books":1}]
欲了解更多与此Java应用相关的信息,请访问github.com/arun-gupta/oreilly-docker-book/tree/master/hello-javaee。 查看全部
在本文中数人云将带大家了解如何利用Docker Compose创建一套分布式应用捆绑包,并将其作为Docker Stack在Docker Swarm Mode中进行部署。


Docker 1.12的首套候选发行版于三周之前公布,而近期又有更多新功能计划被添加至该版本当中。


下面首先来看各项新的功能特性:
  • 内置编排机制:通常来讲,应用利用一个Docker Compose文件进行定义。此定义由多个被部署在不同主机上的容器共同构成。这种作法除了能够避免单点故障(简称SPOF)之外,也能够让应用具备弹性。目前包括Docker Swarm、Kubernetes以及Mesos在内的多种编排框架都允许大家对此类应用进行编排。不过现在我们又有了新的选择——Docker Engine如今迎来了内置编排机制。更多细节内容将在后文中进行说明。
  • Service:现在大家可以利用docker service create 命令轻松创建一项复制且分布式的负载均衡服务。该应用可实现“理想状态”,例如运行三套Couchbase容器,并具备自我修复能力。Docker引擎能够确保必要容器数量始终运行于集群当中。如果某容器发生故障,那么另一容器将旋即启动。如果某台节点发生故障,则该节点上的容器会在另一节点上启动。稍后我们将详细说明其作用。
  • 零配置安全性: Docker 1.12采用相互验证TLS,能够对swarm当中各节点间的通信内容进行验证、授权与加密。更多详尽内容将在后文中进行讨论。


Docker Stack与分布式应用捆绑包:分布式应用捆绑包,或者简称DAB,是一种多服务可分发镜像格式。在后文中我们会进一步讨论。


截至目前,大家已经可以选定一个Dockerfile,并利用docker build命令由此创建镜像。使用docker run命令则可启动容器。这条命令亦能够轻松同时启动多套容器。另外,大家也可以使用Docker Compose文件并利用docker-compose scale命令对容器进行规模扩展。



1.png



镜像属于单一容器的一种便携式格式。而Docker 1.12当中新推出的分布式应用捆绑包,或者简称DAB,则属于一种新的概念,其专门面向多套容器的迁移需求。每个捆绑包都可作为stack在运行时中进行部署。


2.png




感兴趣的朋友可以前往docker.com/dab了解更多与DAB相关的内容。为了简单起见,在这里我们利用类比来进行说明:


kerfile -> 镜像 -> 容器

Docker Compose -> 分布式应用捆绑包 -> Docker Stack

下面我们使用一个Docker Compose文件来创建DAB,并将其作为Docker Stack加以部署。


需要强调的是,这项实验性功能仅存在于1.12-RC2版本当中。


利用Docker Compose创建一个分布式应用捆绑包


Docker Compose CLI添加了一条新的bundle命令。下面来看其具体说明:
docker-compose bundle --help
Generate a Docker bundle from the Compose file.

Local images will be pushed to a Docker registry, and remote images
will be pulled to fetch an image digest.

Usage: bundle [options]

Options:
-o, --output PATH Path to write the bundle file to.
Defaults to "<project name>.dsb".

现在,让我们选取一条Docker Compose定义并以此为基础创建DAB。以下为我们的Docker Compose定义内容:
version: "2"
services:
db:
container_name: "db"
image: arungupta/oreilly-couchbase:latest
ports:
- 8091:8091
- 8092:8092
- 8093:8093
- 11210:11210
web:
image: arungupta/oreilly-wildfly:latest
depends_on:
- db
environment:
- COUCHBASE_URI=db
ports:
- 8080:8080


此Compose文件会启动WildFly与Couchbase服务器。其中WildFly服务器中已经预部署了一款Java EE应用,且接入Couchbase服务器并允许利用REST API执行CRUD操作。该文件的源代码来自:github.com/arun-gupta/oreilly-docker-book/blob/master/hello-javaee/docker-compose.yml。利用它生成一个应用捆绑包:
docker-compose bundle
WARNING: Unsupported key 'depends_on' in services.web - ignoring
WARNING: Unsupported key 'container_name' in services.db - ignoring
Wrote bundle to hellojavaee.dsb


depends_on只负责创建两项服务之间的依赖性,并以特定顺序对二者进行启动。这能确保Docker容器首先启动,而运行在其中的应用则需要更长时间才能启动完成。因此,此属性只在一定程度上解决了这一问题。


container_name能够为该容器提供一个特定名称。对特定容器名称的依赖性为紧密耦合,且不允许我们对该容器进行规模伸缩。因此这里我们暂时忽略这两条警告。此命令会利用Compose项目名(也就是其目录名称)生成一个文件。因此在本示例中,生成的文件名为hellojavaee.dsb。此文件的扩展名在RC3中则为.dab。此生成的应用捆绑包内容如下所示:
{
"services": {
"db": {
"Image": "arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c",
"Networks": [
"default"
],
"Ports": [
{
"Port": 8091,
"Protocol": "tcp"
},
{
"Port": 8092,
"Protocol": "tcp"
},
{
"Port": 8093,
"Protocol": "tcp"
},
{
"Port": 11210,
"Protocol": "tcp"
}
]
},
"web": {
"Env": [
"COUCHBASE_URI=db"
],
"Image": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914",
"Networks": [
"default"
],
"Ports": [
{
"Port": 8080,
"Protocol": "tcp"
}
]
}
},
"version": "0.1"
}


此文件为包含在应用内的各项服务提供完整的描述。当然,未来我们应该可以使用其它容器格式,例如Rkt或者VM等形式。不过就目前来讲,其还仅支持Docker这一种格式。


在Docker中进行Swarm Mode初始化


正如之前所提到,目前“理想状态”由Docker Swarm负责保持。而其现在已经被纳入Docker Engine当中。在本篇文章中,我们使用新增的一条命令,即docker swarm:
docker swarm --help

Usage: docker swarm COMMAND

Manage Docker Swarm

Options:
--help Print usage

Commands:
init Initialize a Swarm
join Join a Swarm as a node and/or manager
update Update the Swarm
leave Leave a Swarm
inspect Inspect the Swarm

Run 'docker swarm COMMAND --help' for more information on a command.

在Docker Engine中对一个Swarm节点(作为工作节点)进行初始化:
docker swarm init
Swarm initialized: current node (ek9p1k8r8ox7iiua5c247skci) is now a manager.


关于该节点的更多细节信息可利用docker swarm inspect命令进行查看。
docker swarm inspect
[
{
"ID": "1rcvu7m9mv2c8hiaijr7an9zk",
"Version": {
"Index": 1895
},
"CreatedAt": "2016-07-01T23:52:38.074748177Z",
"UpdatedAt": "2016-07-02T04:54:32.79093117Z",
"Spec": {
"Name": "default",
"AcceptancePolicy":{
"Policies": [
{
"Role": "worker",
"Autoaccept": true
},
{
"Role": "manager",
"Autoaccept":false
}
]
},
"Orchestration": {
"TaskHistoryRetentionLimit":10
},
"Raft": {
"SnapshotInterval": 10000,
"LogEntriesForSlowFollowers":500,
"HeartbeatTick":1,
"ElectionTick":3
},
"Dispatcher": {
"HeartbeatPeriod": 5000000000
},
"CAConfig": {
"NodeCertExpiry": 7776000000000000
}
}
}
]

从输出结果中可以看到,该节点只属于工作节点而非管理节点。如果在单节点集群当中,这样的设置并无不妥。不过在多节点集群当中,则应至少存在一个管理节点。


部署Docker Stack


利用docker deploy命令创建一个stack:
docker deploy -f hellojavaee.dsb hellojavaee
Loading bundle from hellojavaee.dsb
Creating network hellojavaee_default
Creating service hellojavaee_db
Creating service hellojavaee_web

下面来看各服务列表:
docker service ls
ID NAME REPLICAS IMAGE COMMAND
2g8kmrimztes hellojavaee_web 1/1 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914
46xhlb15cc60 hellojavaee_db 1/1 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c


在输出结果中,我们可以看到正在运行的两项服务,分别为WildFly与Couchbase。 Service概念同样新增于Docker 1.12版本,其负责为我们提供“理想状态”,而具体实现则由Docker Engine负责。使用docker ps命令显示当前正在运行的容器列表:
CONTAINER ID        IMAGE                                                                                                 COMMAND                  CREATED             STATUS              PORTS                                                        NAMES
622756277f40 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c "/entrypoint.sh /opt/" 3 seconds ago Up 1 seconds 8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp hellojavaee_db.1.19enwdt6i5m853m5675tx3z29
abf8703ed713 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 3 seconds ago Up 1 seconds 8080/tcp hellojavaee_web.1.70piloz6j4zt06co8htzisgyl


WildFly容器会在Couchbase容器启动并运行之前先行启动。这意味着Java EE应用会尝试接入Couchbase服务器但发生失败。因此,该应用将永远无法成功完成引导。


自我修复Docker Service


Docker Service负责保持应用的“理想状态”。在本示例中,我们的理想状态是确保特定服务有且只有一套容器与之对应且持续运行。如果我们移除该容器,而非服务,则该服务会自动重启容器。使用以下命令移除容器:
docker rm -f abf8703ed713


请注意,这里之所以要使用-f,是因为该容器已经处于运行状态。Docker 1.12自我修复机制会介入并自动重启此容器。现在再次打开运行容器列表:
CONTAINER ID        IMAGE                                                                                                 COMMAND                  CREATED             STATUS                  PORTS                                                        NAMES
db483ac27e41 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 1 seconds ago Up Less than a second 8080/tcp hellojavaee_web.1.ddvwdmojjysf46d4n3x4g8uv4
622756277f40 arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c "/entrypoint.sh /opt/" 26 seconds ago Up 25 seconds 8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp hellojavaee_db.1.19enwdt6i5m853m5675tx3z29

结果显示新容器已经启动完成。检查WildFly服务:
docker service inspect hellojavaee_web
[
{
"ID": "54otfi6dc9bis7z6gc6ubynwc",
"Version": {
"Index": 328
},
"CreatedAt": "2016-07-02T01:36:35.735767569Z",
"UpdatedAt": "2016-07-02T01:36:35.739240775Z",
"Spec": {
"Name": "hellojavaee_web",
"Labels": {
"com.docker.stack.namespace": "hellojavaee"
},
"TaskTemplate": {
"ContainerSpec": {
"Image": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914",
"Env": [
"COUCHBASE_URI=db"
]
}
},
"Mode": {
"Replicated": {
"Replicas": 1
}
},
"Networks": [
{
"Target": "epw57lz7txtfchmbf6u0cimis",
"Aliases": [
"web"
]
}
],
"EndpointSpec": {
"Mode": "vip",
"Ports": [
{
"Protocol": "tcp",
"TargetPort": 8080
}
]
}
},
"Endpoint": {
"Spec": {},
"Ports": [
{
"Protocol": "tcp",
"TargetPort": 8080,
"PublishedPort": 30004
}
],
"VirtualIPs": [
{
"NetworkID": "9lpz688ir3pzexubkcb828ikg",
"Addr": "10.255.0.5/16"
},
{
"NetworkID": "epw57lz7txtfchmbf6u0cimis",
"Addr": "10.0.0.4/24"
}
]
}
}
]




Swarm会将随机端口分配给该服务,我们也可以利用docker service update命令进行手动更新。在本示例中,容器的端口8080被映射至主机上的端口30004。



进行应用验证


下面检查该应用是否已经成功部署:
curl http://localhost:30004/books/resources/book
[{"books":0}]


为该应用添加新的book:
curl -v \
> -H "Content-Type: application/json" \
> -X POST -d '{
> "isbn": "978-1-4919-1889-0",
> "name": "Minecraft Modding with Forge",
> "cost": 29.99
> }' \
> http://localhost:30004/books/resources/book
* Trying ::1...
* Connected to localhost (::1) port 30004 (#0)
> POST /books/resources/book HTTP/1.1
> Host: localhost:30004
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 92
>
* upload completely sent off: 92 out of 92 bytes
< HTTP/1.1 200 OK
< Connection: keep-alive
< X-Powered-By: Undertow/1
< Server: WildFly/10
< Content-Type: application/octet-stream
< Content-Length: 88
< Date: Sat, 02 Jul 2016 01:39:49 GMT
<
* Connection #0 to host localhost left intact
{"name":"Minecraft Mhttp://localhost:30004/books/r ... ot%3B}




再次验证该book:
curl http://localhost:30004/books/resources/book
[{"books":{"name":"Minecraft Modding with Forge","cost":29.99,"id":"1","isbn":"978-1-4919-1889-0"}}, {"books":1}]

欲了解更多与此Java应用相关的信息,请访问github.com/arun-gupta/oreilly-docker-book/tree/master/hello-javaee。

中国开源云联盟容器工作组第一次会议召开

宁静胡同 发表了文章 • 0 个评论 • 512 次浏览 • 2016-07-08 16:24 • 来自相关话题

7月7日,中国开源云联盟WG11容器工作组第一次会议在京召开,会议的主题为“容器技术与标准交流会”。此次会议由中国电子技术标准化研究院主办,参与方包括中国开源云联盟容器工作组组长单位数人云,副组长单位CNTV,以及Hyper,去哪儿网,VMware,Intel,中国移动。







中国开源云联盟容器工作组第一次会议召开


会议上,参会单位首先围绕容器生态圈展开了讨论,数人云CTO肖德时和Hyper CTO王旭对容器生态圈以及容器发展趋势进行了分享,吕晓旭分享了去哪儿网使用Mesos+Docker技术在集群、日志收集等场景下的应用情况;张海宁分享了VMware针对容器研究情况,包括容器和虚拟化技术融合的研究以及纯容器数据中心的研究情况;杨剑浩分享了中国移动研究院容器技术在CRM等方面的应用情况;何钦钦分享了CNTV使用容器技术实现快速交付和资源回收的应用案例。此外,参会专家还针对容器在应用情况面临的问题和遇到的挑战展开了讨论。最后,中国电子技术标准化研究院高级工程师陈志峰介绍了我国云计算综合标准化指南、标准体系框架以及云计算标准化白皮书情况,为实现容器领域开展标准化工作提供借鉴。

后续容器工作组将开展我国容器应用和标准化白皮书的编制工作,白皮书编制工作的开展将有利于推动容器技术在国内的落地,并为建立符合中国本地化特征的容器标准奠定基础。


相关背景


中国开源云联盟由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟。作为领先的云计算创新技术实践者,数人云一直致力于推动开源技术的发展,并荣膺联盟挂靠中国电子技术标准化研究院后的首批成员单位。目前,联盟下设工作组工作范围从OpenStack逐渐向开源云计算生态圈的其他技术方向延伸,涉及我国云计算领域较热点的发展趋势,如混合云研究、千节点部署、Ceph开源技术、桌面云技术、容器技术等;同时,部分技术方向已开始探索标准化工作,开展开源标准研究,以及与国家标准、国际标准的配套方式的研究。


5月31日,中国开源云联盟2016年第一次理事会在京召开,会上中国开源云联盟Mesos工作组正式成立,为更好地推进容器及相关技术在中国的落地与实践,Mesos工作组现已正式更名为容器工作组。中国开源云联盟容器工作组旨在推动容器技术在国内的落地,提升容器技术在开源社区的贡献比例,并建立顺应国际技术发展趋势、符合中国本地化特征的容器标准体系。


关于数人云


数人云创始团队来自谷歌、红帽和惠普,在今年3月初公司完成A轮融资,由云启资本领投,思科、策源以及唯猎跟投。作为领先的云计算创新技术实践者,数人云致力于打造最轻量化的PaaS平台,将应用弹性做到极致。基于Docker + Mesos,数人云实现一站式的微服务架构集群系统,最大化地帮助客户实现应用业务在云端的快速部署,解决从客户到云资源的最后一公里。 查看全部
7月7日,中国开源云联盟WG11容器工作组第一次会议在京召开,会议的主题为“容器技术与标准交流会”。此次会议由中国电子技术标准化研究院主办,参与方包括中国开源云联盟容器工作组组长单位数人云,副组长单位CNTV,以及Hyper,去哪儿网,VMware,Intel,中国移动。


685425922798165313.jpg11_.jpg


中国开源云联盟容器工作组第一次会议召开


会议上,参会单位首先围绕容器生态圈展开了讨论,数人云CTO肖德时和Hyper CTO王旭对容器生态圈以及容器发展趋势进行了分享,吕晓旭分享了去哪儿网使用Mesos+Docker技术在集群、日志收集等场景下的应用情况;张海宁分享了VMware针对容器研究情况,包括容器和虚拟化技术融合的研究以及纯容器数据中心的研究情况;杨剑浩分享了中国移动研究院容器技术在CRM等方面的应用情况;何钦钦分享了CNTV使用容器技术实现快速交付和资源回收的应用案例。此外,参会专家还针对容器在应用情况面临的问题和遇到的挑战展开了讨论。最后,中国电子技术标准化研究院高级工程师陈志峰介绍了我国云计算综合标准化指南、标准体系框架以及云计算标准化白皮书情况,为实现容器领域开展标准化工作提供借鉴。

后续容器工作组将开展我国容器应用和标准化白皮书的编制工作,白皮书编制工作的开展将有利于推动容器技术在国内的落地,并为建立符合中国本地化特征的容器标准奠定基础。


相关背景


中国开源云联盟由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟。作为领先的云计算创新技术实践者,数人云一直致力于推动开源技术的发展,并荣膺联盟挂靠中国电子技术标准化研究院后的首批成员单位。目前,联盟下设工作组工作范围从OpenStack逐渐向开源云计算生态圈的其他技术方向延伸,涉及我国云计算领域较热点的发展趋势,如混合云研究、千节点部署、Ceph开源技术、桌面云技术、容器技术等;同时,部分技术方向已开始探索标准化工作,开展开源标准研究,以及与国家标准、国际标准的配套方式的研究。


5月31日,中国开源云联盟2016年第一次理事会在京召开,会上中国开源云联盟Mesos工作组正式成立,为更好地推进容器及相关技术在中国的落地与实践,Mesos工作组现已正式更名为容器工作组。中国开源云联盟容器工作组旨在推动容器技术在国内的落地,提升容器技术在开源社区的贡献比例,并建立顺应国际技术发展趋势、符合中国本地化特征的容器标准体系。


关于数人云


数人云创始团队来自谷歌、红帽和惠普,在今年3月初公司完成A轮融资,由云启资本领投,思科、策源以及唯猎跟投。作为领先的云计算创新技术实践者,数人云致力于打造最轻量化的PaaS平台,将应用弹性做到极致。基于Docker + Mesos,数人云实现一站式的微服务架构集群系统,最大化地帮助客户实现应用业务在云端的快速部署,解决从客户到云资源的最后一公里。

数人云 | 一场属于 Docker&Mesos 的夏日欢乐颂

宁静胡同 发表了文章 • 0 个评论 • 620 次浏览 • 2016-07-04 11:42 • 来自相关话题

上次畅谈容器技术的诗和远方还是 4 月份的春天, 如今,夏天已悄然而至。 在西雅图刚结束的 “DockerCon 2016” 大会上, Swarm 原生编排备受推崇, 有人不禁担心 Mesos 将何去何从? 7月份, 
让我们来一场属于 Docker&Mesos 的欢乐颂, 愉快地探讨一下这个“严肃”的话题:)

号外,论如何优雅的将开源技术进行到底, 中国开源云联盟成立了 WG11—容器工作组, 如果你是容器实践老司机, 欢迎加入开源云联盟, 现缺 2 枚副组长,点击 此处自荐

这次,我们邀请了......

Timothy Chen,硅谷 Mesos 专家【确认中】

分布式系统专家,专注于容器化和大数据框架。他是 Apache Drill 和 Apache Mesos 项目的 PMC/ 贡献者,对 Spark、Kafka 和 Docker 等开源项目亦有贡献。Tim 还有 Halo 上的大数据服务、CloudFoundry (PaaS) 和搜索引擎方面的经验。

《CNTV 容器技术探索与实践》 【已确认】

张航源,CNTV 技术中心-高级工程师

2009年加入CNTV,主要负责CNTV容器化的探索和平台搭建,存储平台的架构和运维,以及ELK平台的建设等工作。

《Containerizer Modularization Proposal for Mesos》【已确认】

黄浩松,Engineer @ Shopee

负责公司自动化运维平台建设。 业余时间在 Apache Mesos / Apache Hadoop / Apache HBase 打酱油。

《思科微服务管理框架 Mantl》【已确认】

谢军,思科大中华区解决方案和产品团队首席架构师

负责思科大中华区下一代数据中心和云体系架构及市场推广,专注混合云/微服务架构/分布式存储等。

议程,是这样安排的......

13:30 - 14:00 签到 
14:00 - 14:15 开场 
14:15 - 14:55 《CNTV容器技术探索与实践》张航源 
14:55 - 15:35 《Containerizer Modularization Proposal for Mesos》黄浩松 
15:35 - 16:15 Timothy Chen 
16:15 - 16:55 《思科微服务管理框架 Mantl》谢军 
16:55 - 17:10 《老肖有话说》肖德时

时间:7月23日 14:00 - 17:10 地点:P2 联合创业办公社—中关村 e 世界 A 座 B2

活动行报名链接:http://t.cn/R5QjqdF 查看全部
MESOS_5.jpg

上次畅谈容器技术的诗和远方还是 4 月份的春天, 如今,夏天已悄然而至。 在西雅图刚结束的 “DockerCon 2016” 大会上, Swarm 原生编排备受推崇, 有人不禁担心 Mesos 将何去何从? 7月份, 
让我们来一场属于 Docker&Mesos 的欢乐颂, 愉快地探讨一下这个“严肃”的话题:)

号外,论如何优雅的将开源技术进行到底, 中国开源云联盟成立了 WG11—容器工作组, 如果你是容器实践老司机, 欢迎加入开源云联盟, 现缺 2 枚副组长,点击 此处自荐

这次,我们邀请了......

Timothy Chen,硅谷 Mesos 专家【确认中】

分布式系统专家,专注于容器化和大数据框架。他是 Apache Drill 和 Apache Mesos 项目的 PMC/ 贡献者,对 Spark、Kafka 和 Docker 等开源项目亦有贡献。Tim 还有 Halo 上的大数据服务、CloudFoundry (PaaS) 和搜索引擎方面的经验。

《CNTV 容器技术探索与实践》 【已确认】

张航源,CNTV 技术中心-高级工程师

2009年加入CNTV,主要负责CNTV容器化的探索和平台搭建,存储平台的架构和运维,以及ELK平台的建设等工作。

《Containerizer Modularization Proposal for Mesos》【已确认】

黄浩松,Engineer @ Shopee

负责公司自动化运维平台建设。 业余时间在 Apache Mesos / Apache Hadoop / Apache HBase 打酱油。

《思科微服务管理框架 Mantl》【已确认】

谢军,思科大中华区解决方案和产品团队首席架构师

负责思科大中华区下一代数据中心和云体系架构及市场推广,专注混合云/微服务架构/分布式存储等。

议程,是这样安排的......

13:30 - 14:00 签到 
14:00 - 14:15 开场 
14:15 - 14:55 《CNTV容器技术探索与实践》张航源 
14:55 - 15:35 《Containerizer Modularization Proposal for Mesos》黄浩松 
15:35 - 16:15 Timothy Chen 
16:15 - 16:55 《思科微服务管理框架 Mantl》谢军 
16:55 - 17:10 《老肖有话说》肖德时

时间:7月23日 14:00 - 17:10 地点:P2 联合创业办公社—中关村 e 世界 A 座 B2

活动行报名链接:http://t.cn/R5QjqdF

微服务转型绕不开的坑——日志记录这样做就对了

宁静胡同 发表了文章 • 0 个评论 • 895 次浏览 • 2016-06-29 10:17 • 来自相关话题

在如今企业纷纷转型微服务的过程中,微服务架构中日志记录的重要性时常会被忽略。本文作者十分关注微服务日志记录,提出了独到的观点,并与大家分享关于微服务日志记录的各种技巧的最佳实践。 

微服务架构是一种软件架构类型,着重于利用大量细分组件进行应用开发,其中每个组件都负责整体业务中的一小部分。这些组件彼此独立,支持在自己的进程之上,且能够相互通信以实现业务目标。


为什么要关注日志记录?


很多企业都开始将整体型应用拆分为微服务形式。而在拆分大型应用时,我们需要建立松散耦合的模块,从而保证其便于测试并降低变更风险。另外,这些模块亦可独立部署以实现横向规模扩展。然而,这也会带来一些初看并不严重,但长远影响极其重大的问题——其中的典型代表就是日志记录。


日志记录存在于一切应用当中,无论其属于整体还是微服务架构。关键在于,当我们将应用拆分为微服务形式时,我们需要投入大量时间来思考业务边界并找寻最理想的应用逻辑拆分方式——但很少有人会对日志记录给予应有的重视。


当然,大家可能会问:日志记录的方式一直没有变化过,为什么现在倒成了需要关注的问题?


理由在于,整体应用内的事务追踪往往比较困难,有时候我们只能依靠日志记录来理解当前状况。另外,当业务逻辑运行在多项服务中时,监控与日志记录的难度也会相应增加。这意味着如果我们没有明智地规划出微服务记录机制,那么最终可能根本无法理解应用的当前运行状态。


正因为如此,我想与大家分享我的个人经验以及作为软件开发者积累到的一点心得。近年来我一直在使用微服务方案,希望大家能够在读完本文后意识到日志记录的重要性与实现难点。


心得一——设立应用实例标识符


在使用微服务时,整套体系往往会同一时间运行同一组件的多个实例。最重要的就是在日志条目中设立实例标识符,从而区分各条目的具体来源。其ID的具体生成方式其实并不重要,只要保证惟一即可,这样我们才能借此回溯到特定服务器/容器以及生成该条目的应用处。在微服务架构中,大家可以利用服务注册表轻松为每项服务分配惟一的标识符。


心得二——坚持使用UTC时间


这项心得不仅适用于微服务架构,在其它场景下也同样值得坚持。任何使用过分布式应用程序——或者组件分散在各处——的朋友,都会意识到各组件使用不同时区进行计时有多么令人头痛。而在微服务架构中,以本地时间记录的日志条目会带来更严重的问题。如果大家确实需要使用本地时间,请在日志条目中以字段形式添加时区,从而简化信息的检索方式。但更重要的是一定要为UTC时间设立时区,并利用它在聚合工具内进行信息排序。

下面来看示例日志信息:







第一部分是由一项运行在新西兰的服务所生成。第二部分则由运行在巴西的服务生成。由于我们使用本地日期,因此由巴西服务生成的信息会早于新西兰信息——但其实际生成时间却恰恰相反。


现在,让我们看看使用UTC时间与时区后的示例信息:








现在两条信息已经得到正确的时间排序,如果大家希望了解信息的本地生成时间,则可将其由UTC转换为特定时区。


心得三——生成请求标识符


在将业务逻辑拆分为多个不同组件时,我们的逻辑最终需要由一个或者多个组件构成。而在追踪这些事务时,我们往往很难对其加以识别。因此,大家应当为每个事务生成一个惟一标识符,并利用其关联事件以及追踪各项事务。


想象一下,如果我们需要利用以下请求序列在某电子商务网站上购买产品:

 





那么我们对于操作的分组方法,显然取决于事务的实际定义(毕竟其也能够进行嵌套)。最重要的是确保在事务开端,我们为其创建一个能够传递下去的标识符,并借此在事务结束之前全程记录日志条目。


一般来讲,我倾向于使用人工生成的ID来区分自己的事务。大家也可以使用user_id或者session_id处理与用户相关的事务。而在进行结算与支付时,大家可以使用order_id来追踪结算与付款操作。不过其前提是大家已经进行了用户登录,或者创建了拥有order_id的订单——但实际情况往往并非如此。在使用手动ID时,大家可以将事务ID从业务逻辑流中解耦出来。


另外需要注意的是,这些ID需要拥有足够的信息以对系统中的各项事务进行区分。有时候事务识别符可能在日志条目中体现为一整套字段组合。


心得四——利用聚合工具进行日志分组


如果大家没有对来自全部微服务的日志条目进行聚合,那么以上提到的心得将毫无意义。要实现这一目标,我们需要使用一款能够轻松实现条目分组与查询的工具。我个人使用ELK堆栈,其效果相当出色。如果大家之前没听过ELK,这里可以稍微解释几句。ELK是三款应用的集合体,由此构成的完整解决方案能够调度日志条目、实现条目存储与索引,而后对信息进行聚合与可视化处理。


我们可以利用ELK对应用程序日志进行多种规模伸缩与分发处理,但这里就不讲太多了。感兴趣的朋友可以查看Logz.io博客上的Logstash教程,其中提到了多项相关使用技巧。另外,我们也可以使用Logz.io等企业服务处理日志基础设施的设置与维护工作,从而确保自己的微服务体系采用最理想的日志记录实践方案。


总结

这篇文章的目的是向大家强调在微服务架构中重视日志记录的必要性,同时分享一些在实际应用当中积累到的最佳实践。但这仅仅是个开始,相信大家能够采用多种其它方式解决日志记录难题。

文章来源:Logz.io  作者  Lucas Saldanha 查看全部

在如今企业纷纷转型微服务的过程中,微服务架构中日志记录的重要性时常会被忽略。本文作者十分关注微服务日志记录,提出了独到的观点,并与大家分享关于微服务日志记录的各种技巧的最佳实践。 

微服务架构是一种软件架构类型,着重于利用大量细分组件进行应用开发,其中每个组件都负责整体业务中的一小部分。这些组件彼此独立,支持在自己的进程之上,且能够相互通信以实现业务目标。


为什么要关注日志记录?


很多企业都开始将整体型应用拆分为微服务形式。而在拆分大型应用时,我们需要建立松散耦合的模块,从而保证其便于测试并降低变更风险。另外,这些模块亦可独立部署以实现横向规模扩展。然而,这也会带来一些初看并不严重,但长远影响极其重大的问题——其中的典型代表就是日志记录。


日志记录存在于一切应用当中,无论其属于整体还是微服务架构。关键在于,当我们将应用拆分为微服务形式时,我们需要投入大量时间来思考业务边界并找寻最理想的应用逻辑拆分方式——但很少有人会对日志记录给予应有的重视。


当然,大家可能会问:日志记录的方式一直没有变化过,为什么现在倒成了需要关注的问题?


理由在于,整体应用内的事务追踪往往比较困难,有时候我们只能依靠日志记录来理解当前状况。另外,当业务逻辑运行在多项服务中时,监控与日志记录的难度也会相应增加。这意味着如果我们没有明智地规划出微服务记录机制,那么最终可能根本无法理解应用的当前运行状态。


正因为如此,我想与大家分享我的个人经验以及作为软件开发者积累到的一点心得。近年来我一直在使用微服务方案,希望大家能够在读完本文后意识到日志记录的重要性与实现难点。


心得一——设立应用实例标识符


在使用微服务时,整套体系往往会同一时间运行同一组件的多个实例。最重要的就是在日志条目中设立实例标识符,从而区分各条目的具体来源。其ID的具体生成方式其实并不重要,只要保证惟一即可,这样我们才能借此回溯到特定服务器/容器以及生成该条目的应用处。在微服务架构中,大家可以利用服务注册表轻松为每项服务分配惟一的标识符。


心得二——坚持使用UTC时间


这项心得不仅适用于微服务架构,在其它场景下也同样值得坚持。任何使用过分布式应用程序——或者组件分散在各处——的朋友,都会意识到各组件使用不同时区进行计时有多么令人头痛。而在微服务架构中,以本地时间记录的日志条目会带来更严重的问题。如果大家确实需要使用本地时间,请在日志条目中以字段形式添加时区,从而简化信息的检索方式。但更重要的是一定要为UTC时间设立时区,并利用它在聚合工具内进行信息排序。

下面来看示例日志信息:


1.PNG


第一部分是由一项运行在新西兰的服务所生成。第二部分则由运行在巴西的服务生成。由于我们使用本地日期,因此由巴西服务生成的信息会早于新西兰信息——但其实际生成时间却恰恰相反。


现在,让我们看看使用UTC时间与时区后的示例信息:


2.PNG



现在两条信息已经得到正确的时间排序,如果大家希望了解信息的本地生成时间,则可将其由UTC转换为特定时区。


心得三——生成请求标识符


在将业务逻辑拆分为多个不同组件时,我们的逻辑最终需要由一个或者多个组件构成。而在追踪这些事务时,我们往往很难对其加以识别。因此,大家应当为每个事务生成一个惟一标识符,并利用其关联事件以及追踪各项事务。


想象一下,如果我们需要利用以下请求序列在某电子商务网站上购买产品:

 
3.png


那么我们对于操作的分组方法,显然取决于事务的实际定义(毕竟其也能够进行嵌套)。最重要的是确保在事务开端,我们为其创建一个能够传递下去的标识符,并借此在事务结束之前全程记录日志条目。


一般来讲,我倾向于使用人工生成的ID来区分自己的事务。大家也可以使用user_id或者session_id处理与用户相关的事务。而在进行结算与支付时,大家可以使用order_id来追踪结算与付款操作。不过其前提是大家已经进行了用户登录,或者创建了拥有order_id的订单——但实际情况往往并非如此。在使用手动ID时,大家可以将事务ID从业务逻辑流中解耦出来。


另外需要注意的是,这些ID需要拥有足够的信息以对系统中的各项事务进行区分。有时候事务识别符可能在日志条目中体现为一整套字段组合。


心得四——利用聚合工具进行日志分组


如果大家没有对来自全部微服务的日志条目进行聚合,那么以上提到的心得将毫无意义。要实现这一目标,我们需要使用一款能够轻松实现条目分组与查询的工具。我个人使用ELK堆栈,其效果相当出色。如果大家之前没听过ELK,这里可以稍微解释几句。ELK是三款应用的集合体,由此构成的完整解决方案能够调度日志条目、实现条目存储与索引,而后对信息进行聚合与可视化处理。


我们可以利用ELK对应用程序日志进行多种规模伸缩与分发处理,但这里就不讲太多了。感兴趣的朋友可以查看Logz.io博客上的Logstash教程,其中提到了多项相关使用技巧。另外,我们也可以使用Logz.io等企业服务处理日志基础设施的设置与维护工作,从而确保自己的微服务体系采用最理想的日志记录实践方案。


总结

这篇文章的目的是向大家强调在微服务架构中重视日志记录的必要性,同时分享一些在实际应用当中积累到的最佳实践。但这仅仅是个开始,相信大家能够采用多种其它方式解决日志记录难题。

文章来源:Logz.io  作者  Lucas Saldanha

关于Docker 1.12中的最新功能,你需要了解这些

宁静胡同 发表了文章 • 0 个评论 • 628 次浏览 • 2016-06-28 10:46 • 来自相关话题

DockerCon已然落幕,留下了无数激动人心的声音。随着Docker1.12版本的发布,众多新功能新提升的出现,无疑将对Docker为中心的生态圈产生不小的影响。今天小数与大家看一看新版本对于存储层面都有哪些影响——



新版本的发布对存储层面来说,最值得关注的自然是分卷驱动器支持能力的强化。这些变更不仅能够使我们对分卷进行标记,从而明确其属于本地抑或全局可访问对象,同时也能够提供与可用分卷相关的驱动器具体信息。另外,1.12版本中还出现了众多提升及修复机制。很明显,部分变更将帮助Docker Swarm更好地完成规模化使命,甚至可以说这一规模化发展思路正是本届DockerCon大会的主旨所在。


值得关注的变化


支持分卷范围(本地/全局)#22077


虽然这一变更谈不到什么飞跃,但如今使用docker分卷(例如swarm)的各服务已经能够将可用分卷识别为本地(特定主机)或全局(全部主机)。过去,当我们在swarm管理器中运行“docker volume ls”时,所有可用于全部swarm代理的全局分卷都会在各主机上被分别列出。这使得我们很难据此构建起可扩展的Docker Swarm集群。现在,新的调整让我们得以轻松区分全局分卷与本地分卷。








支持分卷状态 #21006


过去,每个Docker分卷只包含分卷名称、驱动器名称、安装位置以及基本标签(如果使用)等信息。








而在1.12版本中,我们能够获取更多来自驱动器的各分卷细节信息(嵌套于Status下)。








其它变化


支持ZFS分卷大小 #21946


在1.12版本之前,我们无法强制指定ZFS分卷的大小,但现在已经可以通过“-storage-opts”实现。


支持利用BTRFS实现磁盘配额 #19651


如果利用BTRFS取代devicemapper作为默认docker文件系统,我们将能够为各独立docker容器设置最大大小或容量配额。


分卷名称/驱动器过滤 #21015


新版本提供的增强过滤机制适用于“docker volume”命令/api请求。这意味着我们可以获取更为具体的特定分卷名称信息,或者可由特定分卷驱动器访问的全部分卷。


为分卷安装/卸载请求匹配惟一ID #21015


当分卷安装/卸载请求被发送至分卷驱动器时,系统会同时生成一条惟一ID以确保驱动器对各请求加以追踪。如此一来,分卷驱动器就能够更好地识别安装与卸载请求。


SELinux用户迎来小幅修复 #17262


如果大家在自己的docker主机上使用SELinux,则#17262能够修复将本地目录附加至新容器时z/Z权限选项的使用方式。在原有版本中,由于新容器中不存在启动所需要的文件夹,因此直接附加会导致失败。


本文源自:EMC {code},作者 Chris Duchesne 查看全部
DockerCon已然落幕,留下了无数激动人心的声音。随着Docker1.12版本的发布,众多新功能新提升的出现,无疑将对Docker为中心的生态圈产生不小的影响。今天小数与大家看一看新版本对于存储层面都有哪些影响——



新版本的发布对存储层面来说,最值得关注的自然是分卷驱动器支持能力的强化。这些变更不仅能够使我们对分卷进行标记,从而明确其属于本地抑或全局可访问对象,同时也能够提供与可用分卷相关的驱动器具体信息。另外,1.12版本中还出现了众多提升及修复机制。很明显,部分变更将帮助Docker Swarm更好地完成规模化使命,甚至可以说这一规模化发展思路正是本届DockerCon大会的主旨所在。


值得关注的变化


支持分卷范围(本地/全局)#22077


虽然这一变更谈不到什么飞跃,但如今使用docker分卷(例如swarm)的各服务已经能够将可用分卷识别为本地(特定主机)或全局(全部主机)。过去,当我们在swarm管理器中运行“docker volume ls”时,所有可用于全部swarm代理的全局分卷都会在各主机上被分别列出。这使得我们很难据此构建起可扩展的Docker Swarm集群。现在,新的调整让我们得以轻松区分全局分卷与本地分卷。


1.png



支持分卷状态 #21006


过去,每个Docker分卷只包含分卷名称、驱动器名称、安装位置以及基本标签(如果使用)等信息。



2.png


而在1.12版本中,我们能够获取更多来自驱动器的各分卷细节信息(嵌套于Status下)。


3.png



其它变化


支持ZFS分卷大小 #21946


在1.12版本之前,我们无法强制指定ZFS分卷的大小,但现在已经可以通过“-storage-opts”实现。


支持利用BTRFS实现磁盘配额 #19651


如果利用BTRFS取代devicemapper作为默认docker文件系统,我们将能够为各独立docker容器设置最大大小或容量配额。


分卷名称/驱动器过滤 #21015


新版本提供的增强过滤机制适用于“docker volume”命令/api请求。这意味着我们可以获取更为具体的特定分卷名称信息,或者可由特定分卷驱动器访问的全部分卷。


为分卷安装/卸载请求匹配惟一ID #21015


当分卷安装/卸载请求被发送至分卷驱动器时,系统会同时生成一条惟一ID以确保驱动器对各请求加以追踪。如此一来,分卷驱动器就能够更好地识别安装与卸载请求。


SELinux用户迎来小幅修复 #17262


如果大家在自己的docker主机上使用SELinux,则#17262能够修复将本地目录附加至新容器时z/Z权限选项的使用方式。在原有版本中,由于新容器中不存在启动所需要的文件夹,因此直接附加会导致失败。


本文源自:EMC {code},作者 Chris Duchesne

智能运维 | 如何做好持续集成——Jenkins on Mesos 实践

宁静胡同 发表了文章 • 0 个评论 • 1347 次浏览 • 2016-06-24 11:18 • 来自相关话题

今天小数给大家带来的又是十足的干货:当运维遇到云计算,当Docker遇到Mesos和Jenkins,会擦出怎样的火花呢?且看来自数人云运维工程师金烨的演讲实录分享——


持续集成的价值

首先讲一下持续集成的优势。过去公司做测试可能需要十几、二十几个组件,集成一次往往要一两个小时,费力费时,而且复杂容易出错,而一旦配置出错的话耗时会更久。因此,一次集成测试一周才会做一次,测出Bug要到下一周才能更新,再做测试,这个周期会非常漫长。而持续集成的意义就在于减少风险,和重复的过程,最终提高工作效率。

Docker

Docker是现在非常火的一门技术,使用Docker首先解决的是环境的问题。因为开发环境和运维的部署环境千奇百怪,依赖的环境和包各不一样。其次,Docker是可以实现更快速地交付和部署,只要写一个Dockerfile,把服务打成一个镜像,然后再迁移到各种服务器上就行了,部署的过程也非常方便,服务器只要有Docker的环境就可以运行。因为是内核级虚拟化解决方案,Docker利用的额外资源很少,同时,它的更新管理也非常容易,只需要把Dockerfile修改一两行,其他的服务器则不需要做改动,也不需要下载其它的安装依赖包,打好Docker镜像直接就可以部署镜像、直接运行。这些都是它的优势。

Mesos






Apache Mesos是一款开源集群管理软件。Mesos经过了Facebook,Twitter这些大型公司的万台主机验证,在国内,爱奇艺、去哪网,小米网等公司也拥有大规模的Mesos集群应用。Mesos实现了两级调度架构,可以管理多种类型的应用程序。第一级调度是Master的守护进程,管理Mesos集群中所有节点上运行的Slave守护进程。集群由物理服务器或虚拟服务器组成,用于运行应用程序的任务,比如Hadoop和MPI作业。第二级调度由被称作Framework的“组件”组成。Framework包括调度器(Scheduler)和执行器(Executor)进程,其中每个节点上都会运行执行器。Mesos能和不同类型的Framework通信,每种Framework由相应的应用集群管理。图中只展示了Hadoop和MPI两种类型,其它类型的应用程序也有相应的Framework。Mesos支持多种Framework,比如说Hadoop,Spark,Storm等等,各类型的Framework在它上面都可以运行。

Marathon

Marathon是Mesosphere为Mesos生态圈打造的一个轻量级管理服务APP框架,它可以用RESTful API方便地进行操作。

Marathon 协调应用和Frameworks

下图是在Marathon上发布各种的服务,它们都可以通过Marathon发到Mesos的集群资源中。






扩展和故障恢复

例如我们发了三个服务,分别是有一个节点的,三个节点的和五个节点的。

我们想拓展这些服务的话,可以调用Marathon的API进行扩展,秒级扩展到下图。

如果有一台主机宕掉了, Marathon会均匀地把服务迁移到其他的机器上,选择资源有空余的机器进行迁移。这样能就保证服务是动态的调度,保证服务的高可用,并且这些都是它内部自行处理的,不需要手动干预。

Jenkins

介绍

Jenkins是Java开发的一种持续集成的工具,我们在它的基础上做了一些重复的工作,比如版本发布、测试代码,以及调用外部接口。Jenkins支持很多插件,可以很方便地选择使用适合自己团队的插件工具。

问题

Jenkins为我们提供了便利,当然Jenkins本身也有它自己的问题,比如传统的Jenkins是单点的,任务大多是需要排队的,如果每个任务都自己建一套Jenkins的话,资源会非常浪费。为了解决这些问题,我们引入了Jenkins On Mesos。

Jenkins On Mesos

Jenkins 分为Master 节点和Slave 节点,Master 进行调度,Slave节点负责负责执行Job任务。

Jenkins master






首先我们把Jenkins的Master通过Marathon发布,Marathon 去调用 Mesos Master,之后Mesos Master再去Slave节点起Jenkins的Master。这个机制保证了Jenkins Master的高可用,Marathon会监控Jenkins Master的健康状态,当Jenkins Master出现崩溃挂掉,Marathon会自动再启动一个Jenkins Master的任务。Jenkins Master使用Mesos整个大的资源池,Mesos的资源池是一个资源共享的状态,资源利用率也会更高一些。

Jenkins Slave






Jenkins Master做的是调度,Jenkins Slave则是真正执行构建任务的地方。Jenkins Master会在Mesos Master上注册一个它自己的Framework,如果有任务需要构建的话,Jenkins Master 会通知 Jenkins Framework 调用 Mesos Master构建一个任务。之后Mesos Master 再调用 Mesos Slave去起一个Jenkins Slave的节点去构建任务,它是实时的,用户资源可能被分配到各个机器上,在不同的机器上并行存在。此外,Jenkins还具备动态调度功能,也就是说,当任务运行完后一定时间,资源会再返还给Mesos,实现合理地利用整个集群的资源,提高集群的资源利用率。

Mesos 整体流程






这张图是Mesos整体的调度流程。第一步,它的集群有三个Mesos Slave节点资源,资源上报到Mesos Master,Mesos Master收集到这些资源之后把这些资源再提供给Marathon,Marathon如果要发任务,它确认一个Offer1,Offer1足够任务来运行,就拒绝其他的Offer,并把这个任务发送给Mesos Master,之后Mesos Master去找Slave1起Marathon的任务。这是Marathon的任务启动过程。Mesos本身可以和多框架进行通信,Jenkins Master要跑一个任务,Mesos Master同样提供资源给Jenkins,提供的资源包括了Marathon 任务使用剩下的资源,比如Task1 确认的 Offer1没有用完和没有使用的资源,Mesos也会它提供给Jenkins。而Jenkins也会选择,比如Jenkins选择了Offer3,拒绝了其他的Offer,把Jenksin的任务再通过Mesos Master去Mesos Slave中起起来。

Jenkins On Mesos Docker化

Jenkins部署起来非常麻烦,需要安装各种依赖,如果代码是从Git上下载的,那么还需要安装一些Git包。而动态调度需要每台机器上都装这些依赖,为了解决这种问题,我们把服务全部进行了Docker化,主机上只需要有Docker环境就可以运行我们的服务。

遇到的坑

进行Docker化之后就会面临Docker化的问题,因为Docker和 Mesos都是比较新的技术,我们遇到了很多坑,也需要去解决。

我们遇到的第一个问题是Jenkinson Mesos需要调度Mesos的Lib库,如果Docker化之后是隔离的,就调不到Mesos Lib。

第二个问题是Docker化的数据,因为Jenkins是没有数据库的,数据都是存在本地的JENKINS_HOME目录中,如果Jenkins Master挂掉之后,相应的数据就没有了。

第三个问题是Jenkins需要升级,插件也需要升级,而镜像本身没办法自动升级。

解决

为了解决这些问题,首先我们将Mesos打成一个基础镜像,在这个基础镜像上安装Jenkins的服务制作成一个Jenkins的镜像,这样就可以调用Mesos的Lib库文件了。

第二是数据备份,我们在Jenkins上安装了一个插件,就是SCM Sync Configuration Plugin 这个插件,它会同步数据到Github。如果这个Jenkins Master挂掉了,迁移到另外一台主机上,它会从Github上面把数据克隆下来,数据是不会丢失的。此外,如果插件出了故障,或者因为网络问题导致Github访问不了,我们把JENKINS HOME目录挂在主机上进行备份,进行恢复的时候也会很方便。用以上这两点来保证数据的完整性。

第三对于Jenkins升级或其插件的升级,我们现在的做法是把它重新打一个镜像,重新在Mararhton发布Jenkins Master。

Jenkins Slave On Docker 工作流程






首先Jenkins Master如果要构建一个Job,让Mesos Slave起一个Jenkins Slave这样的容器,容器里面是没有Docker环境的,因为容器里面再装一个Docker环境就太重了。我们现在的做法是把Jenkins Slave用到的命令挂载,其中包括 /usr/bin/docker /var/lib/docker /sys/fs/cgroup /var/run/docker.sock ,这样在容器内部就可以操作主机上的Docker环境,Jenkins Slave 可以在容器内部进行一些Docker Build,Docker Run,Docker Push等工作。

Jenkins Job List






这是我们运维平台一些Job List,左下角是Mesos各个Slave的节点,每一个节点上都有任务,这些任务都是并行的。因为我们的服务模块比较多,可能一个模块一天提交十几次,这么多的模块在一天提交几十次或者上百次的情况也出现过。手动更新、构建的话是非常难做到的。现在,做成Jenkins 分布式执行Job的模式,一天构建几百上千次也没有问题,它会把构建的任务均匀的分布在主机资源里。

数人云运维平台持续集成实践






这是数人云运维平台的持续集成实践。首先讲几个组件,比如Github,它是存储代码的,第二个组件是我们自己开发了的一个Configserver的API,第三个组件是Jenkins和Marathon。第四个组件是我们的私有Registry,是Docker的一个存储镜像的镜像仓库。最右下角是CDN,安装包传送到达的地方。

首先Jenkins触发任务,Jenkins调用Configserver提供的API,这个API就去Github上获取最新代码的Tag,并对比现有的已经更新过的Tag。如果不需要更新,这个任务就完成了,结束了。如果需要更新的话,就进行第三步,把从Github拉的代码放到Configserver上,Jenkins Slave的节点会从Configserver去拉取代码到Slave的容器之中。把代码下载之后再去Pull一个我们编译环境的镜像,然后再用这个镜像去编译我们的代码。比如编译出来一个二进制代码,我们把这个二进制重新打一个运行时的镜像。这个Runtime镜像打好之后我们再使用Docker Push把它推到私有的Registry,镜像Push到Registry后,就可以发布到各种的环境,比如说Dev Demo生产环境,调用Marathon API直接发布就可以了。同样在Jenkins Slave,推完镜像之后就可以去调用。这样一个整体构建镜像再部署的任务就构建完成了。

如果有一些安装包,比如我们的Agent包,它不需要发布Marathon,需要上传到CDN,也是在Jenkins Slave 中执行的。

配置管理

问题

因为我们引入了Docker,而且是分布式动态调度的,传统的配置工具如Ansible、Puppet 、SaltStack都已经不适用了,没办法去管理Docker内部的东西。这些配置文件修改起来非常麻烦。

配置中心一期






讲一下如何进行配置的更新。首先我们做了一个配置中心的一期,把镜像嵌入自己的脚本,这个脚本实现的功能就是 根据传入的ENV CONFIG_SERVER和 SERVICE ,访问 Configserver的API,API返回的数据就是这个服务需要下载的配置文件的列表,以及它需要下载到哪个目录底下。Configserver也非常简单,起一个Nginx,去Vim手动修改。容器一重启,就会自动拉这些配置文件,把配置进行更新。

一期的问题

一期完成之后,因为是多种环境,如Dev Demo环境、预生产环境、生产环境等等,虽然把这些配置都在Configserver上集中配置,但还需要手动修改这些配置。手动修改容易出错,例如Dev更新了一个服务,可能过了一周才会更新到生产环境。那个时候再去修改生产就很容易出错,导致无法运行。此外,如果配置发生了Bug需要回滚,手动修改也是不合适的。

配置中心二期






为了解决这些问题,我们做了ConfigCenter的二期。其中有我们自己开发的一个运维平台,以及Github和Gitlab。Github是个存储项目的代码,Gitlab是用了存储配置模板和最终配置文件的。我们用Jenkins把它们整体的串起来,我们的第一个工作是把所有的配置文件抽象化,各种环境的文件抽象出来一个模板,放在Gitlab上。它的数据是放在数据库里面,这样组合起来是一个完整的配置文件。各个环境的值是不一样的。 我们的运维平台触发Jenkins,Jenkins去调度我们的ConfigCenter API,它传入两个参数,一个是需要更新的环境,第二个是更新哪个服务。之后API去做对比,从数据库去读现有的配置文件的模板Tag,再去读新模板的Tag进行对比。如果这个文件需要更新,把它从数据库拉过来,数据做匹配,渲染成我们最终的配置文件,再传到Gitlab上。剩下的通过Jenkins 触发 Configserver去调Gitlab下载最新的配置文件到Configserver服务器,Jenkins再去调用Marathon去重启服务,服务就会成功更新配置文件。

这里有两个需要注意的点,一方面模板需要更新,另一方面值要更新,这是两种模式。模板更新是所有的流程都要走一遍,如果模板没有更新,只是值更新的话,我们只需要在运维平台上做修改。修改的同时它会做一个标记,说明这个服务配置文件是需要更新的,之后就会生成一个最新的配置继续下面的操作。如果这两个都不需要更新的话就返回,不再操作。

今天的分享就到此为止,谢谢大家。

  查看全部


今天小数给大家带来的又是十足的干货:当运维遇到云计算,当Docker遇到Mesos和Jenkins,会擦出怎样的火花呢?且看来自数人云运维工程师金烨的演讲实录分享——



持续集成的价值

首先讲一下持续集成的优势。过去公司做测试可能需要十几、二十几个组件,集成一次往往要一两个小时,费力费时,而且复杂容易出错,而一旦配置出错的话耗时会更久。因此,一次集成测试一周才会做一次,测出Bug要到下一周才能更新,再做测试,这个周期会非常漫长。而持续集成的意义就在于减少风险,和重复的过程,最终提高工作效率。

Docker

Docker是现在非常火的一门技术,使用Docker首先解决的是环境的问题。因为开发环境和运维的部署环境千奇百怪,依赖的环境和包各不一样。其次,Docker是可以实现更快速地交付和部署,只要写一个Dockerfile,把服务打成一个镜像,然后再迁移到各种服务器上就行了,部署的过程也非常方便,服务器只要有Docker的环境就可以运行。因为是内核级虚拟化解决方案,Docker利用的额外资源很少,同时,它的更新管理也非常容易,只需要把Dockerfile修改一两行,其他的服务器则不需要做改动,也不需要下载其它的安装依赖包,打好Docker镜像直接就可以部署镜像、直接运行。这些都是它的优势。

Mesos

mesos1.jpg


Apache Mesos是一款开源集群管理软件。Mesos经过了Facebook,Twitter这些大型公司的万台主机验证,在国内,爱奇艺、去哪网,小米网等公司也拥有大规模的Mesos集群应用。Mesos实现了两级调度架构,可以管理多种类型的应用程序。第一级调度是Master的守护进程,管理Mesos集群中所有节点上运行的Slave守护进程。集群由物理服务器或虚拟服务器组成,用于运行应用程序的任务,比如Hadoop和MPI作业。第二级调度由被称作Framework的“组件”组成。Framework包括调度器(Scheduler)和执行器(Executor)进程,其中每个节点上都会运行执行器。Mesos能和不同类型的Framework通信,每种Framework由相应的应用集群管理。图中只展示了Hadoop和MPI两种类型,其它类型的应用程序也有相应的Framework。Mesos支持多种Framework,比如说Hadoop,Spark,Storm等等,各类型的Framework在它上面都可以运行。

Marathon

Marathon是Mesosphere为Mesos生态圈打造的一个轻量级管理服务APP框架,它可以用RESTful API方便地进行操作。

Marathon 协调应用和Frameworks

下图是在Marathon上发布各种的服务,它们都可以通过Marathon发到Mesos的集群资源中。

marathon1.png


扩展和故障恢复

例如我们发了三个服务,分别是有一个节点的,三个节点的和五个节点的。

我们想拓展这些服务的话,可以调用Marathon的API进行扩展,秒级扩展到下图。

如果有一台主机宕掉了, Marathon会均匀地把服务迁移到其他的机器上,选择资源有空余的机器进行迁移。这样能就保证服务是动态的调度,保证服务的高可用,并且这些都是它内部自行处理的,不需要手动干预。

Jenkins

介绍

Jenkins是Java开发的一种持续集成的工具,我们在它的基础上做了一些重复的工作,比如版本发布、测试代码,以及调用外部接口。Jenkins支持很多插件,可以很方便地选择使用适合自己团队的插件工具。

问题

Jenkins为我们提供了便利,当然Jenkins本身也有它自己的问题,比如传统的Jenkins是单点的,任务大多是需要排队的,如果每个任务都自己建一套Jenkins的话,资源会非常浪费。为了解决这些问题,我们引入了Jenkins On Mesos。

Jenkins On Mesos

Jenkins 分为Master 节点和Slave 节点,Master 进行调度,Slave节点负责负责执行Job任务。

Jenkins master

jenkins_master.png


首先我们把Jenkins的Master通过Marathon发布,Marathon 去调用 Mesos Master,之后Mesos Master再去Slave节点起Jenkins的Master。这个机制保证了Jenkins Master的高可用,Marathon会监控Jenkins Master的健康状态,当Jenkins Master出现崩溃挂掉,Marathon会自动再启动一个Jenkins Master的任务。Jenkins Master使用Mesos整个大的资源池,Mesos的资源池是一个资源共享的状态,资源利用率也会更高一些。

Jenkins Slave

jenkins_slave.png


Jenkins Master做的是调度,Jenkins Slave则是真正执行构建任务的地方。Jenkins Master会在Mesos Master上注册一个它自己的Framework,如果有任务需要构建的话,Jenkins Master 会通知 Jenkins Framework 调用 Mesos Master构建一个任务。之后Mesos Master 再调用 Mesos Slave去起一个Jenkins Slave的节点去构建任务,它是实时的,用户资源可能被分配到各个机器上,在不同的机器上并行存在。此外,Jenkins还具备动态调度功能,也就是说,当任务运行完后一定时间,资源会再返还给Mesos,实现合理地利用整个集群的资源,提高集群的资源利用率。

Mesos 整体流程

jenkins_on_mesos.png


这张图是Mesos整体的调度流程。第一步,它的集群有三个Mesos Slave节点资源,资源上报到Mesos Master,Mesos Master收集到这些资源之后把这些资源再提供给Marathon,Marathon如果要发任务,它确认一个Offer1,Offer1足够任务来运行,就拒绝其他的Offer,并把这个任务发送给Mesos Master,之后Mesos Master去找Slave1起Marathon的任务。这是Marathon的任务启动过程。Mesos本身可以和多框架进行通信,Jenkins Master要跑一个任务,Mesos Master同样提供资源给Jenkins,提供的资源包括了Marathon 任务使用剩下的资源,比如Task1 确认的 Offer1没有用完和没有使用的资源,Mesos也会它提供给Jenkins。而Jenkins也会选择,比如Jenkins选择了Offer3,拒绝了其他的Offer,把Jenksin的任务再通过Mesos Master去Mesos Slave中起起来。

Jenkins On Mesos Docker化

Jenkins部署起来非常麻烦,需要安装各种依赖,如果代码是从Git上下载的,那么还需要安装一些Git包。而动态调度需要每台机器上都装这些依赖,为了解决这种问题,我们把服务全部进行了Docker化,主机上只需要有Docker环境就可以运行我们的服务。

遇到的坑

进行Docker化之后就会面临Docker化的问题,因为Docker和 Mesos都是比较新的技术,我们遇到了很多坑,也需要去解决。

我们遇到的第一个问题是Jenkinson Mesos需要调度Mesos的Lib库,如果Docker化之后是隔离的,就调不到Mesos Lib。

第二个问题是Docker化的数据,因为Jenkins是没有数据库的,数据都是存在本地的JENKINS_HOME目录中,如果Jenkins Master挂掉之后,相应的数据就没有了。

第三个问题是Jenkins需要升级,插件也需要升级,而镜像本身没办法自动升级。

解决

为了解决这些问题,首先我们将Mesos打成一个基础镜像,在这个基础镜像上安装Jenkins的服务制作成一个Jenkins的镜像,这样就可以调用Mesos的Lib库文件了。

第二是数据备份,我们在Jenkins上安装了一个插件,就是SCM Sync Configuration Plugin 这个插件,它会同步数据到Github。如果这个Jenkins Master挂掉了,迁移到另外一台主机上,它会从Github上面把数据克隆下来,数据是不会丢失的。此外,如果插件出了故障,或者因为网络问题导致Github访问不了,我们把JENKINS HOME目录挂在主机上进行备份,进行恢复的时候也会很方便。用以上这两点来保证数据的完整性。

第三对于Jenkins升级或其插件的升级,我们现在的做法是把它重新打一个镜像,重新在Mararhton发布Jenkins Master。

Jenkins Slave On Docker 工作流程

jenkins_slave_docker.png


首先Jenkins Master如果要构建一个Job,让Mesos Slave起一个Jenkins Slave这样的容器,容器里面是没有Docker环境的,因为容器里面再装一个Docker环境就太重了。我们现在的做法是把Jenkins Slave用到的命令挂载,其中包括 /usr/bin/docker /var/lib/docker /sys/fs/cgroup /var/run/docker.sock ,这样在容器内部就可以操作主机上的Docker环境,Jenkins Slave 可以在容器内部进行一些Docker Build,Docker Run,Docker Push等工作。

Jenkins Job List

jenkins_job_list.png


这是我们运维平台一些Job List,左下角是Mesos各个Slave的节点,每一个节点上都有任务,这些任务都是并行的。因为我们的服务模块比较多,可能一个模块一天提交十几次,这么多的模块在一天提交几十次或者上百次的情况也出现过。手动更新、构建的话是非常难做到的。现在,做成Jenkins 分布式执行Job的模式,一天构建几百上千次也没有问题,它会把构建的任务均匀的分布在主机资源里。

数人云运维平台持续集成实践

sryci.png


这是数人云运维平台的持续集成实践。首先讲几个组件,比如Github,它是存储代码的,第二个组件是我们自己开发了的一个Configserver的API,第三个组件是Jenkins和Marathon。第四个组件是我们的私有Registry,是Docker的一个存储镜像的镜像仓库。最右下角是CDN,安装包传送到达的地方。

首先Jenkins触发任务,Jenkins调用Configserver提供的API,这个API就去Github上获取最新代码的Tag,并对比现有的已经更新过的Tag。如果不需要更新,这个任务就完成了,结束了。如果需要更新的话,就进行第三步,把从Github拉的代码放到Configserver上,Jenkins Slave的节点会从Configserver去拉取代码到Slave的容器之中。把代码下载之后再去Pull一个我们编译环境的镜像,然后再用这个镜像去编译我们的代码。比如编译出来一个二进制代码,我们把这个二进制重新打一个运行时的镜像。这个Runtime镜像打好之后我们再使用Docker Push把它推到私有的Registry,镜像Push到Registry后,就可以发布到各种的环境,比如说Dev Demo生产环境,调用Marathon API直接发布就可以了。同样在Jenkins Slave,推完镜像之后就可以去调用。这样一个整体构建镜像再部署的任务就构建完成了。

如果有一些安装包,比如我们的Agent包,它不需要发布Marathon,需要上传到CDN,也是在Jenkins Slave 中执行的。

配置管理

问题

因为我们引入了Docker,而且是分布式动态调度的,传统的配置工具如Ansible、Puppet 、SaltStack都已经不适用了,没办法去管理Docker内部的东西。这些配置文件修改起来非常麻烦。

配置中心一期

cfgcenter1.png


讲一下如何进行配置的更新。首先我们做了一个配置中心的一期,把镜像嵌入自己的脚本,这个脚本实现的功能就是 根据传入的ENV CONFIG_SERVER和 SERVICE ,访问 Configserver的API,API返回的数据就是这个服务需要下载的配置文件的列表,以及它需要下载到哪个目录底下。Configserver也非常简单,起一个Nginx,去Vim手动修改。容器一重启,就会自动拉这些配置文件,把配置进行更新。

一期的问题

一期完成之后,因为是多种环境,如Dev Demo环境、预生产环境、生产环境等等,虽然把这些配置都在Configserver上集中配置,但还需要手动修改这些配置。手动修改容易出错,例如Dev更新了一个服务,可能过了一周才会更新到生产环境。那个时候再去修改生产就很容易出错,导致无法运行。此外,如果配置发生了Bug需要回滚,手动修改也是不合适的。

配置中心二期

cfgcenter2.png


为了解决这些问题,我们做了ConfigCenter的二期。其中有我们自己开发的一个运维平台,以及Github和Gitlab。Github是个存储项目的代码,Gitlab是用了存储配置模板和最终配置文件的。我们用Jenkins把它们整体的串起来,我们的第一个工作是把所有的配置文件抽象化,各种环境的文件抽象出来一个模板,放在Gitlab上。它的数据是放在数据库里面,这样组合起来是一个完整的配置文件。各个环境的值是不一样的。 我们的运维平台触发Jenkins,Jenkins去调度我们的ConfigCenter API,它传入两个参数,一个是需要更新的环境,第二个是更新哪个服务。之后API去做对比,从数据库去读现有的配置文件的模板Tag,再去读新模板的Tag进行对比。如果这个文件需要更新,把它从数据库拉过来,数据做匹配,渲染成我们最终的配置文件,再传到Gitlab上。剩下的通过Jenkins 触发 Configserver去调Gitlab下载最新的配置文件到Configserver服务器,Jenkins再去调用Marathon去重启服务,服务就会成功更新配置文件。

这里有两个需要注意的点,一方面模板需要更新,另一方面值要更新,这是两种模式。模板更新是所有的流程都要走一遍,如果模板没有更新,只是值更新的话,我们只需要在运维平台上做修改。修改的同时它会做一个标记,说明这个服务配置文件是需要更新的,之后就会生成一个最新的配置继续下面的操作。如果这两个都不需要更新的话就返回,不再操作。

今天的分享就到此为止,谢谢大家。

 

Docker Swarm系列第二部:重新调度Redis

宁静胡同 发表了文章 • 0 个评论 • 623 次浏览 • 2016-06-16 10:48 • 来自相关话题

欢迎回来,我们继续本系列的第二篇教程。今天我们将主要关注[Redis](http://shurenyun.com),希望大家还记得第一部分的主要内容——了解如何安装我们将要使用的环境。

传送门: Docker Swarm系列第一部:利用Flocker部署多节点Cassandra集群

在发生节点故障时利用Swarm对Redis服务器进行重新调度

如果大家认真阅读了第一部分,应该记得我们在Swarm部署中使用了--experimental标记。其中包括Swarm 1.1.0中的一项功能——在节点故障时对容器进行重新调度。

今天,我们将关注如何部署Redis容器并测试当前实验性重新调度功能的当前状态。

注意:重新调度尚处于实验阶段,其中存在bug。我们将在示例过程中的对应位置提醒大家可能出现的bug。

如果大家希望在Swarm主机发生故障时对容器进行重新调度,则需要在容器部署中使用特定标记。作为可行方案之一,我们可以使用以下标记:--restart=always -e reschedule:on-node-failure或者类似于-l 'com.docker.swarm.reschedule-policy=["on-node-failure"]'的标签。以下示例将使用环境变量方法。

首先,我们使用重新调度标记与由Flocker管理的分卷进行Redis容器部署。








接下来,利用SSH接入Docker主机内的Redis容器运行位置,并查看Redis始终使用的appendonly.aof文件内容。该文件应当位于Flocker分卷中,作为容器起始点存在且不包含任何数据。








然后接入Redis服务器并添加一些键/值对。而后,再次查看appendonly.aof文件内容以确保Redis以正确方式存储数据。








在Flocker分卷中查看数据以验证Redis正确运行。








测试故障转移

现在我们将测试故障转移场景,确保我们的Flocker分卷能够将存储在Redis中的数据正确迁移至Swarm重新调度容器的新Docker主机上。

要实现这一目标,我们在Swarm管理器中指定Docker,并利用docker events命令监控各项事件。

要开始测试,首先在运行有Redis容器的Docker主机上运行shutdown -h now以模拟节点故障。大家应该看到与该节点及容器相关的各项事件。

这些事件在告知我们,该容器及其资源由于遭遇故障(包括网络与分卷)需要被移除、断开连接或者卸载。我们看到的事件如下:

Container Kill
Container Die
Network Disconnect
Swarm Engine Disconnect
Volume Unmount
Container Stop  








在Docker主机关闭一段时间之后,大家应该会最终看到故障容器正在进行重新调度(即重新创建)。在这里需要提醒的是,在测试中我们发现Swarm 1.1.3版本中仍然存在问题,即其仍然会在被创建在新Docker主机上的容器中运行 Start 。

大家应该会在查看到Create事件记录的同时发现docker events,而后者的作用是对容器重建以及Flocker分卷移动进行初始化。

我们发现,大家可能需要在重新调度完成后,在新主机上手动Start该容器。

注意:容器创建过程中存在一些问题,但在测试中我们并未在容器启动时发现问题。

此事件代表着我们的容器已经经过重新调度并自动创建于新的Docker主机之上。请注意,最新信息中的IP地址发生了变化,这是因为容器被调度到了新的Docker主机中。








回顾

下面来看流程回顾:









如果我们对Swarm运行docker ps,则会看到该Redis容器为Created。在这种情况下,我们可以手动进行启动,而Redis也将恢复并运行在新节点上。

 








下面接入该Redis服务器以确保我们添加的数据仍然存在。







数据仍然存在!不过考虑到重新调度情况,我们不建议大家直接使用这些数据。

在测试当中,大部分用户反映容器能够在新节点上正常启动。但也确实有部分用户指出重新调度机制并未生效,或者是在Docker主机恢复后出现了两套容器。无论如何,工作当中显然还存在着问题,而社区的作用也正在于此——帮助测试、报告并修复这些问题,从而确保其运行效果更为可靠。 查看全部
欢迎回来,我们继续本系列的第二篇教程。今天我们将主要关注[Redis](http://shurenyun.com),希望大家还记得第一部分的主要内容——了解如何安装我们将要使用的环境。

传送门: Docker Swarm系列第一部:利用Flocker部署多节点Cassandra集群

在发生节点故障时利用Swarm对Redis服务器进行重新调度

如果大家认真阅读了第一部分,应该记得我们在Swarm部署中使用了--experimental标记。其中包括Swarm 1.1.0中的一项功能——在节点故障时对容器进行重新调度。

今天,我们将关注如何部署Redis容器并测试当前实验性重新调度功能的当前状态。

注意:重新调度尚处于实验阶段,其中存在bug。我们将在示例过程中的对应位置提醒大家可能出现的bug。

如果大家希望在Swarm主机发生故障时对容器进行重新调度,则需要在容器部署中使用特定标记。作为可行方案之一,我们可以使用以下标记:--restart=always -e reschedule:on-node-failure或者类似于-l 'com.docker.swarm.reschedule-policy=["on-node-failure"]'的标签。以下示例将使用环境变量方法。

首先,我们使用重新调度标记与由Flocker管理的分卷进行Redis容器部署。


1.PNG



接下来,利用SSH接入Docker主机内的Redis容器运行位置,并查看Redis始终使用的appendonly.aof文件内容。该文件应当位于Flocker分卷中,作为容器起始点存在且不包含任何数据。


2.PNG



然后接入Redis服务器并添加一些键/值对。而后,再次查看appendonly.aof文件内容以确保Redis以正确方式存储数据。


3.PNG



在Flocker分卷中查看数据以验证Redis正确运行。


4.PNG



测试故障转移

现在我们将测试故障转移场景,确保我们的Flocker分卷能够将存储在Redis中的数据正确迁移至Swarm重新调度容器的新Docker主机上。

要实现这一目标,我们在Swarm管理器中指定Docker,并利用docker events命令监控各项事件。

要开始测试,首先在运行有Redis容器的Docker主机上运行shutdown -h now以模拟节点故障。大家应该看到与该节点及容器相关的各项事件。

这些事件在告知我们,该容器及其资源由于遭遇故障(包括网络与分卷)需要被移除、断开连接或者卸载。我们看到的事件如下:

Container Kill
Container Die
Network Disconnect
Swarm Engine Disconnect
Volume Unmount
Container Stop  


55.jpg



在Docker主机关闭一段时间之后,大家应该会最终看到故障容器正在进行重新调度(即重新创建)。在这里需要提醒的是,在测试中我们发现Swarm 1.1.3版本中仍然存在问题,即其仍然会在被创建在新Docker主机上的容器中运行 Start 。

大家应该会在查看到Create事件记录的同时发现docker events,而后者的作用是对容器重建以及Flocker分卷移动进行初始化。

我们发现,大家可能需要在重新调度完成后,在新主机上手动Start该容器。

注意:容器创建过程中存在一些问题,但在测试中我们并未在容器启动时发现问题。

此事件代表着我们的容器已经经过重新调度并自动创建于新的Docker主机之上。请注意,最新信息中的IP地址发生了变化,这是因为容器被调度到了新的Docker主机中。


6.PNG



回顾

下面来看流程回顾:


00.jpg




如果我们对Swarm运行docker ps,则会看到该Redis容器为Created。在这种情况下,我们可以手动进行启动,而Redis也将恢复并运行在新节点上。

 

7.PNG




下面接入该Redis服务器以确保我们添加的数据仍然存在。

8.PNG



数据仍然存在!不过考虑到重新调度情况,我们不建议大家直接使用这些数据。

在测试当中,大部分用户反映容器能够在新节点上正常启动。但也确实有部分用户指出重新调度机制并未生效,或者是在Docker主机恢复后出现了两套容器。无论如何,工作当中显然还存在着问题,而社区的作用也正在于此——帮助测试、报告并修复这些问题,从而确保其运行效果更为可靠。

圆桌论坛实录 | 从容器生态圈解析容器之热现象

宁静胡同 发表了文章 • 0 个评论 • 379 次浏览 • 2016-06-08 15:33 • 来自相关话题

5月26日,数人云产品战略发布会在北京万达索菲特酒店举行,发布会最后一个环节圆桌论坛可谓大咖云集,小数为大家在第一时间带来了实录分享,快来感受下容器生态圈的激情碰撞吧——






主持人:谢乐冰 数人云COO

圆桌嘉宾:

王雷 央视网(CNTV)运维总监

刘少壮 环信联合创始人&CTO

华琨 UCloud 联合创始人&COO

王瑞琳 EasyStack联合创始人&COO

张峻 VMware 中国先进技术中心主任

陈昱 云启资本 VP

EasyStack:物理机、虚拟机和容器的兼容整合

谢乐冰:各位好,今天我们讲讲干货。第一位我想有请EasyStack的王总回答,容器在2015年变成了和OpenStack一样火的技术,前一阵的奥斯汀OpenStack大会上也有很多关于容器的议题。我的第一个问题是,您认为对于一个完整的数据中心操作系统来说,用物理机跑原生Docker与通过OpenStack跑Docker有什么区别?

王瑞琳:今年的奥斯汀OpenStack峰会做了一次OpenStack用户调查,根据调查结果,在OpenStack用户关注的技术里,容器技术排在首位。你提的这个问题排在第三位,它们是客户最关注三大问题中的两个。

我认为OpenStack跟容器技术解决的是不同的问题,容器解决的是应用的高并发管理、CI/CD、快速发布,也就是说,它是更面向应用的。然而,OpenStack是要解决的是云数据中心层面的问题。从云数据中心的两个维度去看,第一它向下加强各种硬件的管理,向上支持数据中心各种业务场景。所以从这两点上看,OpenStack更多的是面向基础设施,而容器则是面向应用的,这两个技术本身互不矛盾,这也是为什么OpenStack峰会对容器的关注已经持续很多年,在去年东京的峰会上容器也是OpenStack整个峰会的热点之一。

最近两届的OpenStack峰会对容器的关注点也越来越多地集中在容器和OpenStack集成的应用场景实现上,刚刚Mesos国外的专家也谈到,Mesos也好、Kubernetes也好,它们要管理越来越多不同类型的容器。同样,OpenStack在数据中心控制层面也要解决不同场景的应用,一般来说大家谈到OpenStack对于容器的支持,大多集中在虚拟机上。但是作为数据中心的总控,OpenStack要管理的对象除了虚拟机,也有容器,还有物理机。OpenStack有一个主件叫Ironic,它可以管理裸机,并在上面部署容器。所以OpenStack和容器技术并不是矛盾体,它们是兼容并整合的关系。

VMware:容器与虚拟化在一起会更好

谢乐冰:对于一个完整的数据中心操作系统来说,IaaS负责基础架构层面的服务,PaaS则偏重应用层面。第二个问题是我们与客户沟通过程中经常遇到的一个问题,也就是说,我们是不是把容器当成虚拟机在使用。VMware有一个非常完整的支撑容器的基础架构,可以非常好地把容器当作虚拟机。而现在IaaS和PaaS之间的界限越来越模糊,从长期来看,作为一个全球领先的IaaS厂商,VMware认为,IaaS是否也有可能进入schedule调度,甚至进入微服务这个层面?

张峻:刚刚主持人提到一点,容器作为虚拟机是可以的,但是现在在微服务化场景下把容器当成虚拟机使用并不合适。因为我们希望它能够切得更小,然后每一个微服务都通过容器来实现。容器跟虚拟化是解决不同问题的,从这一点来看与OpenStack有相似之处,我认为虚拟化解决的一个重大问题是隔离和安全的问题,而容器则解决的是快速交付的问题。所以它们并不矛盾,只是解决的问题分别在IaaS和PaaS两个层次上。所以我的想法是虚拟化和容器技术在一起会更好,因为它们是解决不同的问题,在一起的好处是同时解决了容器技术潜在的安全性和隔离性的问题。众所周知,容器都是基于共享内核的,是有一定程度上的安全问题,因为容器潜在的特性是共享的。所以,想要同时兼具安全性并做到快速交付,就可以在下层使用虚拟机,并在它的上面搭容器。所以基于这样的想法,不管用户之前是否使用vSphere,我们都有很好的产品解决方案去应对各种业务场景。

同时在虚拟机上面搭建容器的另一个好处是从运维方面,大家可以把容器和虚拟机在统一的管理平台上一同进行管理,把所有未容器化的应用与现在已经容器化的应用统一管理起来,大大提高便利性。同时也可以应用一些虚拟化比较成熟的技术,包括容器的HA、容器的热迁移,现在也都具备一些初步的方案。但是企业需要的是成熟的方案,比如说数人云选择了Mesos技术,而不是Kubernetes,就是因为Mesos相对来说更为成熟。对于企业来说,成熟稳定是非常重要的,因而用虚拟化成熟的下层IaaS解决方案再加上上层的容器技术的便利快捷,是一个非常好的组合。

UCloud:自然过渡的混合云时代

谢乐冰:在我们接触的企业中,互联网公司的大部分应用还处于云就绪状态,云原生应用还不是特别多。在这种情况下,我们认为IaaS可以解决底层网络和存储的大部分问题,可以帮助企业平滑上云。我们在给客户做方案的过程中意识到,未来向公有云延伸非常需要协同的能力,如今,容器技术越来越被认为是一种云端应用交付的标准手段,UCloud是国内领先的公有云公司,华琨总您认为容器技术会给公有云带来怎样的新机遇?

华琨:就像前面嘉宾说的,Docker是面向应用的、一种非常灵活的场景,我非常认同张总所说的,应该把容器和虚拟化技术结合在一起。有越来越多的用户找到我们,表示非常想在公有云上使用容器,这样做面临以下几个问题:首先是便利性,VM与IaaS的关系更密切,VM有一个好处就是管理起来很方便,同时它也很符合广大工程师的使用习惯。但是现在,大家的兴趣点和很多的应用场景都在Docker上,那么首当其冲要去解决的就是管理上的便利性,需要解决外网访问的问题,并结合VM的隔离安全性。

另外,容器技术还需要结合IaaS的其它优势。公有云厂商在资源的管理调度上做了大量工作,在资源的提供上具有很大的优势。我们很早就在VM层面实现了热迁移,可以在业务无感知的情况下把一个VM迁移到另外一个位置上。同样的技术我们也可以应用到Docker上,包括向其他产品提供负载均衡,在Docker环境下,这也是一个非常典型的场景。如何将这两个技术进行结合,让整体的可视化管理做的更好,这些都是公有云厂商擅长的领域。我们想把它们更好的结合起来,让广大的用户可以不用去关注底层技术细节。当然,原理的学习是一回事,实践起来的话还是会有很多的门槛,而这些都可以通过公有云的一些专业技术去实现。我们希望让用户更多地去享受Docker技术所带来的应用场景的便利性,这是我们想去做的一件非常重要的事情。

谢乐冰:华总,您认为混合云的时代会在什么时候到来呢,现在已经有一些什么样的实例?

华琨:我们认为,混合云的混合有很多种,包括公有云和私有云的混合,物理机和虚拟机的混合,甚至是IaaS和PaaS的混合。在我们看来,这些都已经有很多的应用场景了,其中,我们在五年前就推出了物理机和虚拟机的混合,并受到了用户的欢迎,有一些用户出于使用习惯或者设备的限制选择了混合云,我们为他们提供了一个兼容的方案。整个云计算的发展也是这样的一个过程,用户需要慢慢地接受,因而有很多的应用场景在兼容。实际上,公有云厂商也在做更多的兼容过渡方案,去匹配这当中五到十年的各种应用场景的过渡。公有云和私有云的结合推动打通了各种层面的VPC,这是非常实用的,我觉得这也是非常合理的。尤其在中国,很多的场景都需要混合云来解决,否则问题就会僵持不下。我想这种混合,在未来会越来越多地体现在IaaS跟PaaS融合的方面。

CNTV:企业级客户对容器的需求和探索

谢乐冰:刚才三位是我们的IaaS合作伙伴,我们看到不管是单独用PaaS,或者IaaS+PaaS,最后的目标都是让客户不用再去特别关心底层实现,而是说哪一种方案最能达到目标就选哪种。下面我们会有几个比较难的话题,这个话题落到使用者身上——CNTV的王总身上,CNTV是一个既代表互联网,又跨广电的企业,在容器和相应的PaaS技术落地过程中,我们都有哪些应用场景,碰到了哪些问题?例如这个流程需不需要变化,软件代码需不需要更改等等?

王雷:刚才几位嘉宾是属于这个行业的从业人员,我是属于使用者,属于企业用户。CNTV的中文名字叫中国网络电视台,另外一个名称叫央视网。我们其实是两个牌子,都属于中央电视台的网络传播中心,同时也是中央电视台的新媒体传播机构。从归属上大家可以看到,既然是中央电视台的新媒体传播机构,同时也是国家重点新闻网站,所以我们对安全性的要求非常高。而且每年伴随央视很多的重大的活动,包括每年的春晚、即将召开的今年的欧洲杯、奥运会,我们都会在新媒体层面大力地进行宣传报道。

我们虽然是一个比较偏向于传统媒体的新媒体公司,但是我们对整个行业、新技术非常关注。自从Docker诞生,我们一直都很关注,但是因为Docker那时不够成熟,所以我们基本上还属于观望。从去年我们开始测试Docker平台,经过大概一年多的测试,我们也发现了一些现阶段的需求,比如CI/CD。我是负责公司运维平台的,运维和开发是一对矛盾体,开发者有要求,但我们公司对运维和保障的要求更高。在使用Docker一段时间之后,我们发现开发和运维之间不像以前那么矛盾,通过CI/CD让大家看到这个东西其实是非常好用的。

另外,我们更关注的问题集中在很多的重大活动、重大赛事上,包括春晚这种传统活动。所以我们对弹性,对支撑能力的要求是非常高的。因为在重大活动期间,突发访问可能一下子会增加到平常的十倍、甚至百倍,Docker的弹性和快速扩展满足了我们的需求。通过一段时间的测试,我们现在基本上已经确定会把一些前端的业务逐渐往Docker上转移。现在我们接口层的一些业务,包括一些传统服务已经在Docker上运行,效果非常好,同时我们也在测试在Docker上跑Hadoop,但是这涉及到很多缓存层、中间层的系统,可能我们还要更慎重一些。

我认为现在Docker还有很多不完善的地方,包括监控层面还有安全层面,也包括刚才海外的Mesos专家说的整个调试方面的一些问题,这些我们都是很关注的。比如我的集群上跑了很多业务,但是哪个容器出现问题了导致这个平台的效率变得非常低下,能否及时发现问题并把它踢出去,是我们所关注的。但是这种技术确实已经在很多方面对我们有所帮助,所以我们选择逐渐容器化。因为从另外一个层面来说,做好容器化的同时,我们也在用大量的虚拟化技术,它使我们整个企业可以节省更多的硬件设备开销,更多地地提高资源使用率,这个也是每个企业都希望的。

谢乐冰:还有一个小问题,过去我认为虚拟化是非常简单的事情,但是实际上我发现各个企业也是做了一些相应的流程,甚至也有一些软件技术层面的改造工作,您预计未来容器+PaaS对于开发部门来说会有什么样的变化?

王雷:我认为这是一个趋势,很多新技术改变了人们的观念和操作方式,只有不断地适应才能更好地做好本职的工作。不管是对个人还是对于企业,只要能提高效率,能有更大的产能,大家都是十分乐意的。有很多的业务的改变需要很长时间,我认为从新业务上我们可能会从架构层面就开始规划,可以容器化的就直接做这样的改变。

环信:IT服务商的企业定制与术业专攻

谢乐冰:我们与客户沟通的时候,大家会经常问一个问题,你们是一家做容器的公司,那么,什么是容器的公司?只说是做容器的公司就像说自己是一家做JAVA的公司一样,等于什么都没有说。做容器的公司要解决的是,容器在生产环境上的大规模运行,并给企业提供上云的最佳实践,这才叫一个做容器的公司。不管是做IaaS还是做PaaS的公司,我们做的所有事情实际上都是一起帮助企业的整个IT架构向云端迁移。下面一个话题谈到怎么挣钱这个问题,环信是行业内领先的PaaS公司,是一家为数不多能从互联网公司身上赚到IT服务费的公司。为互联网提供IT服务是一个非常难的事情,不管是互联网公司还是大中型企业都涉及到一个定制问题,一定程度上大家认为定制是非常合理的,因为每个企业的流程是不一样的。所以我想请问一下刘总,你们是如何解决这个问题的?

刘少壮:环信是这样考虑定制这个事情的,首先我们做的产品是即时通讯云和移动客服。我们的目标是PaaS和SaaS的方向,这个选择决定了我们不会做太多的定制。但是做企业服务,尤其是像做移动互联网企业的企业服务,每一家企业都有不同的业务流程和业务需求。比如说我们的移动客服,或者说往更下层的容器技术,再比如说数人云提供的PaaS平台服务,或者是像UCloud提供的IaaS服务,都要满足企业各种不同的需求。

从环信的角度来讲,第一,要通过我们的产品设计和技术手段来保证系统的开放性,同时要更加灵活地提供所有的API和SDK,在系统设计之初就把所有的使用范围都考虑到。第二,我们确实是有所为有所不为,因为一家公司不可能把所有的事情都做完。我们也在往上游发展众多的合作伙伴,开创一个生态圈,往下游联合合作伙伴一起为客户服务。比如前一段我们提供的红包功能,就是环信和其他公司一起合作完成的。再往上层,我们接到很多定制各种企业客户端和微信客户端的要求,但是我们拒绝了。因为我认为一个企业要有所为有所不为,并且要专注,这也是我们一直关注数人云的原因。因为现在术业有专攻成为了一个趋势,每个公司都应该专注各自的领域服务好自己的客户。

谢乐冰:从这个角度我们也有同样的想法,我认为PaaS或者是IaaS的核心就是API,第一我们会专注于我们的核心API,同时开放出好的的API,希望合作伙伴能够通过我们的核心API来实现一些定制。现在很多甲方都有自己的开发能力,又有非常强烈的开发意愿,希望自己能够在这一波开源的大潮中能够获得更多的自主性,所以这也是一种有效的解决方法。

刘少壮:确实如此,比如我们一直在和数人云接触,打算以后逐步推进与数人云的合作,用数人云的服务来替换我们当前底层的服务,同时我们也在积极推进跟UCloud的合作。为什么说我们能做企业服务赚移动互联网公司的钱?因为我们能够给移动互联网公司解决他们的痛点问题。比如我们之前每一家客户都是自己做聊天功能,但是这些企业并没有意识到他们自己做的聊天系统可能有丢消息、延迟大、乱序等各种问题。他们发现了很多问题无法解决,而且其中很多甚至没有意识到这些问题。

从环信自身的角度来说,好一点的是我们意识到了,我们用的云平台包括我们整个的运维架构和运维技术,需要像数人云、Mesos、Docker等等这样的底层技术来支持我们更好的发展。我们不可能把所有的都做了,我们也是想把自身所有的力量,投入到我们自己更擅长的PaaS IM领域和移动客服功能上。我们不想投入太多的精力在其他地方,比如自己建一个物理机房,我们很早就讨论过这个问题,有的同事跟我说,建一个物理机房能够省掉四分之一、甚至三分之一的费用。但是我认为对一个创业公司来说,人是更宝贵的,如果有别的更专业的公司提供服务,就应该去选择更专业的人来做。

资方:关注开源技术,期待行业独角兽

谢乐冰:最后的一个圆桌话题回到行业,行业的趋势问题一般都是由投资人来回答。我们看到2014年下半年产生了五家到六家的容器创业公司,我们数人云也是其中之一。一个非常好的消息是这五到六家,出乎意料地都活到了现在,并且都拿到了A轮融资,这是市场对大家的认可。我们请陈总从投资的角度谈一下整个容器行业的发展趋势。

陈昱:我希望容器这个行业能够更加规范化。其实Docker代表着一类资本非常关注的事物就是开源技术。资本非常喜欢开源技术,因为它技术优秀,能够解决实际问题,并且有活跃的社区还有广泛的应用群体。容器是这一类技术里面非常好的代表,这项技术在实际落地的过程中有很多的问题。企业虽然能够免费获得技术,但是在落地的时候,他们可能并没有人力精力去用好这项技术,企业其实是非常需要像数人云这样的技术公司给他们提供一个企业级的解决方案,提供相应的培训和后续的支持。只有这样,优秀的开源技术才能够实现落地。

而像数人云这样的公司也能够通过这样的商业模式变现,最终实现成长。但是这类软件不会是一家独大的状况,而会是百花齐放。就像Docker一样,国内就有五六家不错的Docker公司,以Hadoop为例,在美国我们同样也能看到有很多家公司,他们每一家都有数千个客户,每年有上亿美元的营收,在资本市场表现非常好,Docker也是类似的。他们能运营良好的原因,第一是市场庞大,没有一家公司能够服务所有的客户;第二是在整个构架里面,各个公司从产品从技术和销售策略上都有一定的差异化,就像数人云选择的是Docker加Mesos,而其他竞争对手可能选择的是切入一体机的解决方案,或者提供一个Container as a Service服务这样的一个路线,最终大家都能够在资本市场上取到不错的表现。既然像Hadoop这种技术可以产生好几家独角兽公司,那么Docker一样在中国也可以产生独角兽公司,我希望数人云就是其中的一家。

谢乐冰:不管是做IaaS、PaaS还是大数据,我们希望所有做开源商业化技术的公司都能够竞争合作,一起推动整个时代向一个分布式云端的架构前进,谢谢大家。 查看全部
5月26日,数人云产品战略发布会在北京万达索菲特酒店举行,发布会最后一个环节圆桌论坛可谓大咖云集,小数为大家在第一时间带来了实录分享,快来感受下容器生态圈的激情碰撞吧——

520952144917949177.jpg


主持人:谢乐冰 数人云COO

圆桌嘉宾:

王雷 央视网(CNTV)运维总监

刘少壮 环信联合创始人&CTO

华琨 UCloud 联合创始人&COO

王瑞琳 EasyStack联合创始人&COO

张峻 VMware 中国先进技术中心主任

陈昱 云启资本 VP

EasyStack:物理机、虚拟机和容器的兼容整合

谢乐冰:各位好,今天我们讲讲干货。第一位我想有请EasyStack的王总回答,容器在2015年变成了和OpenStack一样火的技术,前一阵的奥斯汀OpenStack大会上也有很多关于容器的议题。我的第一个问题是,您认为对于一个完整的数据中心操作系统来说,用物理机跑原生Docker与通过OpenStack跑Docker有什么区别?

王瑞琳:今年的奥斯汀OpenStack峰会做了一次OpenStack用户调查,根据调查结果,在OpenStack用户关注的技术里,容器技术排在首位。你提的这个问题排在第三位,它们是客户最关注三大问题中的两个。

我认为OpenStack跟容器技术解决的是不同的问题,容器解决的是应用的高并发管理、CI/CD、快速发布,也就是说,它是更面向应用的。然而,OpenStack是要解决的是云数据中心层面的问题。从云数据中心的两个维度去看,第一它向下加强各种硬件的管理,向上支持数据中心各种业务场景。所以从这两点上看,OpenStack更多的是面向基础设施,而容器则是面向应用的,这两个技术本身互不矛盾,这也是为什么OpenStack峰会对容器的关注已经持续很多年,在去年东京的峰会上容器也是OpenStack整个峰会的热点之一。

最近两届的OpenStack峰会对容器的关注点也越来越多地集中在容器和OpenStack集成的应用场景实现上,刚刚Mesos国外的专家也谈到,Mesos也好、Kubernetes也好,它们要管理越来越多不同类型的容器。同样,OpenStack在数据中心控制层面也要解决不同场景的应用,一般来说大家谈到OpenStack对于容器的支持,大多集中在虚拟机上。但是作为数据中心的总控,OpenStack要管理的对象除了虚拟机,也有容器,还有物理机。OpenStack有一个主件叫Ironic,它可以管理裸机,并在上面部署容器。所以OpenStack和容器技术并不是矛盾体,它们是兼容并整合的关系。

VMware:容器与虚拟化在一起会更好

谢乐冰:对于一个完整的数据中心操作系统来说,IaaS负责基础架构层面的服务,PaaS则偏重应用层面。第二个问题是我们与客户沟通过程中经常遇到的一个问题,也就是说,我们是不是把容器当成虚拟机在使用。VMware有一个非常完整的支撑容器的基础架构,可以非常好地把容器当作虚拟机。而现在IaaS和PaaS之间的界限越来越模糊,从长期来看,作为一个全球领先的IaaS厂商,VMware认为,IaaS是否也有可能进入schedule调度,甚至进入微服务这个层面?

张峻:刚刚主持人提到一点,容器作为虚拟机是可以的,但是现在在微服务化场景下把容器当成虚拟机使用并不合适。因为我们希望它能够切得更小,然后每一个微服务都通过容器来实现。容器跟虚拟化是解决不同问题的,从这一点来看与OpenStack有相似之处,我认为虚拟化解决的一个重大问题是隔离和安全的问题,而容器则解决的是快速交付的问题。所以它们并不矛盾,只是解决的问题分别在IaaS和PaaS两个层次上。所以我的想法是虚拟化和容器技术在一起会更好,因为它们是解决不同的问题,在一起的好处是同时解决了容器技术潜在的安全性和隔离性的问题。众所周知,容器都是基于共享内核的,是有一定程度上的安全问题,因为容器潜在的特性是共享的。所以,想要同时兼具安全性并做到快速交付,就可以在下层使用虚拟机,并在它的上面搭容器。所以基于这样的想法,不管用户之前是否使用vSphere,我们都有很好的产品解决方案去应对各种业务场景。

同时在虚拟机上面搭建容器的另一个好处是从运维方面,大家可以把容器和虚拟机在统一的管理平台上一同进行管理,把所有未容器化的应用与现在已经容器化的应用统一管理起来,大大提高便利性。同时也可以应用一些虚拟化比较成熟的技术,包括容器的HA、容器的热迁移,现在也都具备一些初步的方案。但是企业需要的是成熟的方案,比如说数人云选择了Mesos技术,而不是Kubernetes,就是因为Mesos相对来说更为成熟。对于企业来说,成熟稳定是非常重要的,因而用虚拟化成熟的下层IaaS解决方案再加上上层的容器技术的便利快捷,是一个非常好的组合。

UCloud:自然过渡的混合云时代

谢乐冰:在我们接触的企业中,互联网公司的大部分应用还处于云就绪状态,云原生应用还不是特别多。在这种情况下,我们认为IaaS可以解决底层网络和存储的大部分问题,可以帮助企业平滑上云。我们在给客户做方案的过程中意识到,未来向公有云延伸非常需要协同的能力,如今,容器技术越来越被认为是一种云端应用交付的标准手段,UCloud是国内领先的公有云公司,华琨总您认为容器技术会给公有云带来怎样的新机遇?

华琨:就像前面嘉宾说的,Docker是面向应用的、一种非常灵活的场景,我非常认同张总所说的,应该把容器和虚拟化技术结合在一起。有越来越多的用户找到我们,表示非常想在公有云上使用容器,这样做面临以下几个问题:首先是便利性,VM与IaaS的关系更密切,VM有一个好处就是管理起来很方便,同时它也很符合广大工程师的使用习惯。但是现在,大家的兴趣点和很多的应用场景都在Docker上,那么首当其冲要去解决的就是管理上的便利性,需要解决外网访问的问题,并结合VM的隔离安全性。

另外,容器技术还需要结合IaaS的其它优势。公有云厂商在资源的管理调度上做了大量工作,在资源的提供上具有很大的优势。我们很早就在VM层面实现了热迁移,可以在业务无感知的情况下把一个VM迁移到另外一个位置上。同样的技术我们也可以应用到Docker上,包括向其他产品提供负载均衡,在Docker环境下,这也是一个非常典型的场景。如何将这两个技术进行结合,让整体的可视化管理做的更好,这些都是公有云厂商擅长的领域。我们想把它们更好的结合起来,让广大的用户可以不用去关注底层技术细节。当然,原理的学习是一回事,实践起来的话还是会有很多的门槛,而这些都可以通过公有云的一些专业技术去实现。我们希望让用户更多地去享受Docker技术所带来的应用场景的便利性,这是我们想去做的一件非常重要的事情。

谢乐冰:华总,您认为混合云的时代会在什么时候到来呢,现在已经有一些什么样的实例?

华琨:我们认为,混合云的混合有很多种,包括公有云和私有云的混合,物理机和虚拟机的混合,甚至是IaaS和PaaS的混合。在我们看来,这些都已经有很多的应用场景了,其中,我们在五年前就推出了物理机和虚拟机的混合,并受到了用户的欢迎,有一些用户出于使用习惯或者设备的限制选择了混合云,我们为他们提供了一个兼容的方案。整个云计算的发展也是这样的一个过程,用户需要慢慢地接受,因而有很多的应用场景在兼容。实际上,公有云厂商也在做更多的兼容过渡方案,去匹配这当中五到十年的各种应用场景的过渡。公有云和私有云的结合推动打通了各种层面的VPC,这是非常实用的,我觉得这也是非常合理的。尤其在中国,很多的场景都需要混合云来解决,否则问题就会僵持不下。我想这种混合,在未来会越来越多地体现在IaaS跟PaaS融合的方面。

CNTV:企业级客户对容器的需求和探索

谢乐冰:刚才三位是我们的IaaS合作伙伴,我们看到不管是单独用PaaS,或者IaaS+PaaS,最后的目标都是让客户不用再去特别关心底层实现,而是说哪一种方案最能达到目标就选哪种。下面我们会有几个比较难的话题,这个话题落到使用者身上——CNTV的王总身上,CNTV是一个既代表互联网,又跨广电的企业,在容器和相应的PaaS技术落地过程中,我们都有哪些应用场景,碰到了哪些问题?例如这个流程需不需要变化,软件代码需不需要更改等等?

王雷:刚才几位嘉宾是属于这个行业的从业人员,我是属于使用者,属于企业用户。CNTV的中文名字叫中国网络电视台,另外一个名称叫央视网。我们其实是两个牌子,都属于中央电视台的网络传播中心,同时也是中央电视台的新媒体传播机构。从归属上大家可以看到,既然是中央电视台的新媒体传播机构,同时也是国家重点新闻网站,所以我们对安全性的要求非常高。而且每年伴随央视很多的重大的活动,包括每年的春晚、即将召开的今年的欧洲杯、奥运会,我们都会在新媒体层面大力地进行宣传报道。

我们虽然是一个比较偏向于传统媒体的新媒体公司,但是我们对整个行业、新技术非常关注。自从Docker诞生,我们一直都很关注,但是因为Docker那时不够成熟,所以我们基本上还属于观望。从去年我们开始测试Docker平台,经过大概一年多的测试,我们也发现了一些现阶段的需求,比如CI/CD。我是负责公司运维平台的,运维和开发是一对矛盾体,开发者有要求,但我们公司对运维和保障的要求更高。在使用Docker一段时间之后,我们发现开发和运维之间不像以前那么矛盾,通过CI/CD让大家看到这个东西其实是非常好用的。

另外,我们更关注的问题集中在很多的重大活动、重大赛事上,包括春晚这种传统活动。所以我们对弹性,对支撑能力的要求是非常高的。因为在重大活动期间,突发访问可能一下子会增加到平常的十倍、甚至百倍,Docker的弹性和快速扩展满足了我们的需求。通过一段时间的测试,我们现在基本上已经确定会把一些前端的业务逐渐往Docker上转移。现在我们接口层的一些业务,包括一些传统服务已经在Docker上运行,效果非常好,同时我们也在测试在Docker上跑Hadoop,但是这涉及到很多缓存层、中间层的系统,可能我们还要更慎重一些。

我认为现在Docker还有很多不完善的地方,包括监控层面还有安全层面,也包括刚才海外的Mesos专家说的整个调试方面的一些问题,这些我们都是很关注的。比如我的集群上跑了很多业务,但是哪个容器出现问题了导致这个平台的效率变得非常低下,能否及时发现问题并把它踢出去,是我们所关注的。但是这种技术确实已经在很多方面对我们有所帮助,所以我们选择逐渐容器化。因为从另外一个层面来说,做好容器化的同时,我们也在用大量的虚拟化技术,它使我们整个企业可以节省更多的硬件设备开销,更多地地提高资源使用率,这个也是每个企业都希望的。

谢乐冰:还有一个小问题,过去我认为虚拟化是非常简单的事情,但是实际上我发现各个企业也是做了一些相应的流程,甚至也有一些软件技术层面的改造工作,您预计未来容器+PaaS对于开发部门来说会有什么样的变化?

王雷:我认为这是一个趋势,很多新技术改变了人们的观念和操作方式,只有不断地适应才能更好地做好本职的工作。不管是对个人还是对于企业,只要能提高效率,能有更大的产能,大家都是十分乐意的。有很多的业务的改变需要很长时间,我认为从新业务上我们可能会从架构层面就开始规划,可以容器化的就直接做这样的改变。

环信:IT服务商的企业定制与术业专攻

谢乐冰:我们与客户沟通的时候,大家会经常问一个问题,你们是一家做容器的公司,那么,什么是容器的公司?只说是做容器的公司就像说自己是一家做JAVA的公司一样,等于什么都没有说。做容器的公司要解决的是,容器在生产环境上的大规模运行,并给企业提供上云的最佳实践,这才叫一个做容器的公司。不管是做IaaS还是做PaaS的公司,我们做的所有事情实际上都是一起帮助企业的整个IT架构向云端迁移。下面一个话题谈到怎么挣钱这个问题,环信是行业内领先的PaaS公司,是一家为数不多能从互联网公司身上赚到IT服务费的公司。为互联网提供IT服务是一个非常难的事情,不管是互联网公司还是大中型企业都涉及到一个定制问题,一定程度上大家认为定制是非常合理的,因为每个企业的流程是不一样的。所以我想请问一下刘总,你们是如何解决这个问题的?

刘少壮:环信是这样考虑定制这个事情的,首先我们做的产品是即时通讯云和移动客服。我们的目标是PaaS和SaaS的方向,这个选择决定了我们不会做太多的定制。但是做企业服务,尤其是像做移动互联网企业的企业服务,每一家企业都有不同的业务流程和业务需求。比如说我们的移动客服,或者说往更下层的容器技术,再比如说数人云提供的PaaS平台服务,或者是像UCloud提供的IaaS服务,都要满足企业各种不同的需求。

从环信的角度来讲,第一,要通过我们的产品设计和技术手段来保证系统的开放性,同时要更加灵活地提供所有的API和SDK,在系统设计之初就把所有的使用范围都考虑到。第二,我们确实是有所为有所不为,因为一家公司不可能把所有的事情都做完。我们也在往上游发展众多的合作伙伴,开创一个生态圈,往下游联合合作伙伴一起为客户服务。比如前一段我们提供的红包功能,就是环信和其他公司一起合作完成的。再往上层,我们接到很多定制各种企业客户端和微信客户端的要求,但是我们拒绝了。因为我认为一个企业要有所为有所不为,并且要专注,这也是我们一直关注数人云的原因。因为现在术业有专攻成为了一个趋势,每个公司都应该专注各自的领域服务好自己的客户。

谢乐冰:从这个角度我们也有同样的想法,我认为PaaS或者是IaaS的核心就是API,第一我们会专注于我们的核心API,同时开放出好的的API,希望合作伙伴能够通过我们的核心API来实现一些定制。现在很多甲方都有自己的开发能力,又有非常强烈的开发意愿,希望自己能够在这一波开源的大潮中能够获得更多的自主性,所以这也是一种有效的解决方法。

刘少壮:确实如此,比如我们一直在和数人云接触,打算以后逐步推进与数人云的合作,用数人云的服务来替换我们当前底层的服务,同时我们也在积极推进跟UCloud的合作。为什么说我们能做企业服务赚移动互联网公司的钱?因为我们能够给移动互联网公司解决他们的痛点问题。比如我们之前每一家客户都是自己做聊天功能,但是这些企业并没有意识到他们自己做的聊天系统可能有丢消息、延迟大、乱序等各种问题。他们发现了很多问题无法解决,而且其中很多甚至没有意识到这些问题。

从环信自身的角度来说,好一点的是我们意识到了,我们用的云平台包括我们整个的运维架构和运维技术,需要像数人云、Mesos、Docker等等这样的底层技术来支持我们更好的发展。我们不可能把所有的都做了,我们也是想把自身所有的力量,投入到我们自己更擅长的PaaS IM领域和移动客服功能上。我们不想投入太多的精力在其他地方,比如自己建一个物理机房,我们很早就讨论过这个问题,有的同事跟我说,建一个物理机房能够省掉四分之一、甚至三分之一的费用。但是我认为对一个创业公司来说,人是更宝贵的,如果有别的更专业的公司提供服务,就应该去选择更专业的人来做。

资方:关注开源技术,期待行业独角兽

谢乐冰:最后的一个圆桌话题回到行业,行业的趋势问题一般都是由投资人来回答。我们看到2014年下半年产生了五家到六家的容器创业公司,我们数人云也是其中之一。一个非常好的消息是这五到六家,出乎意料地都活到了现在,并且都拿到了A轮融资,这是市场对大家的认可。我们请陈总从投资的角度谈一下整个容器行业的发展趋势。

陈昱:我希望容器这个行业能够更加规范化。其实Docker代表着一类资本非常关注的事物就是开源技术。资本非常喜欢开源技术,因为它技术优秀,能够解决实际问题,并且有活跃的社区还有广泛的应用群体。容器是这一类技术里面非常好的代表,这项技术在实际落地的过程中有很多的问题。企业虽然能够免费获得技术,但是在落地的时候,他们可能并没有人力精力去用好这项技术,企业其实是非常需要像数人云这样的技术公司给他们提供一个企业级的解决方案,提供相应的培训和后续的支持。只有这样,优秀的开源技术才能够实现落地。

而像数人云这样的公司也能够通过这样的商业模式变现,最终实现成长。但是这类软件不会是一家独大的状况,而会是百花齐放。就像Docker一样,国内就有五六家不错的Docker公司,以Hadoop为例,在美国我们同样也能看到有很多家公司,他们每一家都有数千个客户,每年有上亿美元的营收,在资本市场表现非常好,Docker也是类似的。他们能运营良好的原因,第一是市场庞大,没有一家公司能够服务所有的客户;第二是在整个构架里面,各个公司从产品从技术和销售策略上都有一定的差异化,就像数人云选择的是Docker加Mesos,而其他竞争对手可能选择的是切入一体机的解决方案,或者提供一个Container as a Service服务这样的一个路线,最终大家都能够在资本市场上取到不错的表现。既然像Hadoop这种技术可以产生好几家独角兽公司,那么Docker一样在中国也可以产生独角兽公司,我希望数人云就是其中的一家。

谢乐冰:不管是做IaaS、PaaS还是大数据,我们希望所有做开源商业化技术的公司都能够竞争合作,一起推动整个时代向一个分布式云端的架构前进,谢谢大家。

新瓶装旧酒?从微服务同步REST的天然缺陷说起

宁静胡同 发表了文章 • 0 个评论 • 498 次浏览 • 2016-05-10 20:17 • 来自相关话题

今天小数给大家带来的干货来自国外一个小组会议上的分享。目前,大部分微服务架构都会使用REST协议以实现不同服务之间的通信,但是它却有天然的缺陷——怎样的缺陷?如何解决?请看下文。

最近,Lightbend技术负责人James Roper在纽约Java特别兴趣小组会议上分享了一个观点:

现在许多人正着手将传统的整体式应用拆分成微服务集合,但如果这些微服务组件都通过REST(即表述性状态转移)实现彼此通信,那么它依然只是一款整体式的应用程序。








Roper表示自己是异步通信的铁杆支持者——Lightbend(前身为Typesafe)推出的一套名为Lagom的Scala微服务平台正好是基于异步通信所打造。

何谓异步通信

这里提到的“异步通信”与我们常说的“异步I/O”并不是一回事。异步I/O的实质在于避免因等待进程线程完成而导致的操作停止。而作为微服务中的重要组成部分,异步通信则旨在设计出一套系统,其中某项服务的执行无需等待另一项任务的完成。

“使用异步通信,如果用户向某项服务提出一条请求,而该服务又需要向另一服务发出请求,那么前一服务的通信无需受阻即可向用户直接返回响应,”Roper解释称。

REST的固有缺陷

目前,大部分微服务架构都会使用REST协议以实现不同服务之间的通信(取代对象调用)。尽管REST较其它常规方式(例如基于XML的SOAP)更为简单,但其同步特性仍然成为固有缺陷——换言之,它天然拥有同步属性,而非异步。

“当客户端发出一条请求,服务器则发出一条响应,”Roper这样形容REST的工作原理。






一项服务发生故障,即会导致操作整体瘫痪。

面向用户的服务通常包含大量以同步方式通信的微服务,这意味着各微服务彼此依赖。这种处理方式在各服务皆能正常运转时并不会带来什么麻烦,然而一旦某项服务发生故障,即会引发不可阻挡的故障链并导致最终用户面临拒绝服务状况。

同样的,如果某项微服务速度缓慢,则响应时间也会被同时拖累。

使用REST等同步通信机制,Roper指出,“从技术角度讲,我们仍然相当于构建了一款整体式方案。无论各组件是否被拆分为独立服务,系统本身还是会像整体应用那样高度关联。”

异步通信来填坑

而在异步通信中,各服务间仍然彼此依赖,但不再因相互等待结果而导致响应速度缓慢。因此,如果一项服务发生故障,其不会影响到其它服务,瓶颈与单点故障问题也将不复存在。

利用基于Java的一套类Twitter服务演示,Roper解释了如何通过多种方式实现代码中的异步调用。方法之一在于确保每项微服务都在信息更新时对其进行发布,而非等待其它微服务针对该信息提出请求。通过这种办法,假设通讯服务需要一份用户的“好友”列表,则可使用由“好友”相关微服务提供的最新信息,而非直接指向该服务发出请求。

来自异步通信的挑战

Roper坦言,异步通信带来的最大挑战在于如何确保最终用户始终能够获得最新信息。很多社交网络都会使用最终一致性机制,并不保证每位用户都能够获得最新版本信息。

另外,REST调用由于极易实现而使用户产生了稳定的使用习惯。一位与会者提到,需要经过大量编码工作才能实现异步通信。

实时REST调用应该被取代吗?
Roper指出,像Apache Kafka这样的软件能够自动处理异步服务中的低级细节,“如果使用简单的REST调用,大家的服务有可能瘫痪。而通过这种方式,情况就不会那么糟糕。” 查看全部
今天小数给大家带来的干货来自国外一个小组会议上的分享。目前,大部分微服务架构都会使用REST协议以实现不同服务之间的通信,但是它却有天然的缺陷——怎样的缺陷?如何解决?请看下文。

最近,Lightbend技术负责人James Roper在纽约Java特别兴趣小组会议上分享了一个观点:

现在许多人正着手将传统的整体式应用拆分成微服务集合,但如果这些微服务组件都通过REST(即表述性状态转移)实现彼此通信,那么它依然只是一款整体式的应用程序。


2.png



Roper表示自己是异步通信的铁杆支持者——Lightbend(前身为Typesafe)推出的一套名为Lagom的Scala微服务平台正好是基于异步通信所打造。

何谓异步通信

这里提到的“异步通信”与我们常说的“异步I/O”并不是一回事。异步I/O的实质在于避免因等待进程线程完成而导致的操作停止。而作为微服务中的重要组成部分,异步通信则旨在设计出一套系统,其中某项服务的执行无需等待另一项任务的完成。

“使用异步通信,如果用户向某项服务提出一条请求,而该服务又需要向另一服务发出请求,那么前一服务的通信无需受阻即可向用户直接返回响应,”Roper解释称。

REST的固有缺陷

目前,大部分微服务架构都会使用REST协议以实现不同服务之间的通信(取代对象调用)。尽管REST较其它常规方式(例如基于XML的SOAP)更为简单,但其同步特性仍然成为固有缺陷——换言之,它天然拥有同步属性,而非异步。

“当客户端发出一条请求,服务器则发出一条响应,”Roper这样形容REST的工作原理。

3.png


一项服务发生故障,即会导致操作整体瘫痪。

面向用户的服务通常包含大量以同步方式通信的微服务,这意味着各微服务彼此依赖。这种处理方式在各服务皆能正常运转时并不会带来什么麻烦,然而一旦某项服务发生故障,即会引发不可阻挡的故障链并导致最终用户面临拒绝服务状况。

同样的,如果某项微服务速度缓慢,则响应时间也会被同时拖累。

使用REST等同步通信机制,Roper指出,“从技术角度讲,我们仍然相当于构建了一款整体式方案。无论各组件是否被拆分为独立服务,系统本身还是会像整体应用那样高度关联。”

异步通信来填坑

而在异步通信中,各服务间仍然彼此依赖,但不再因相互等待结果而导致响应速度缓慢。因此,如果一项服务发生故障,其不会影响到其它服务,瓶颈与单点故障问题也将不复存在。

利用基于Java的一套类Twitter服务演示,Roper解释了如何通过多种方式实现代码中的异步调用。方法之一在于确保每项微服务都在信息更新时对其进行发布,而非等待其它微服务针对该信息提出请求。通过这种办法,假设通讯服务需要一份用户的“好友”列表,则可使用由“好友”相关微服务提供的最新信息,而非直接指向该服务发出请求。

来自异步通信的挑战

Roper坦言,异步通信带来的最大挑战在于如何确保最终用户始终能够获得最新信息。很多社交网络都会使用最终一致性机制,并不保证每位用户都能够获得最新版本信息。

另外,REST调用由于极易实现而使用户产生了稳定的使用习惯。一位与会者提到,需要经过大量编码工作才能实现异步通信。

实时REST调用应该被取代吗?
Roper指出,像Apache Kafka这样的软件能够自动处理异步服务中的低级细节,“如果使用简单的REST调用,大家的服务有可能瘫痪。而通过这种方式,情况就不会那么糟糕。”