TiledMap简单使用

  categories:资料  author:

tiled map是一款开源免费的游戏地图编辑开发工具,可以帮助您开发游戏的内容。软件最主要的功能便是编辑游戏中各种形式的瓷砖地图,侧重于一般的灵活性,同时保持直观,并支持图素、层次和对象等通用概念。tiled map支持快速的编辑游戏地图,使用方面也是非常的简单,不管是新手还是老手,都可轻松的进行编辑,软件里面还内置了大量的游戏地图模块,免费的提供给大家进行使用,是游戏开发人员快速开发游戏一大利器。

使用教程

1、创建新文件 ,然后写入自己的地图大小,和块大小。这里所谓的地图大家可以想象成自己游戏中的地图大小,tiled中将地图分为一个一个块,每一个块大小相同,所有的块拼接成一张地图

2、选择一张背景图片加入到该项目,直接将一张图片拖入到右边的“图块”中

3、接下来把图块中的图片全部选中拖入到左边的窗口中,可以贴很多张因为刚开始我们创建的项目图片大小是6400的高度

4、接下来创建地图中的对象,也就是所谓的敌军飞机,首先在地图中创建一个图层,然后再图层中画方框,或者圆形来代表敌军飞机,选中图层,然后选择矩形图标,你就可以在地图中画矩形对象了。

5、都完成后,基本页面就做好了,接下来就是代码的输入了

—-

官网下载地址

http://www.mapeditor.org/

官方文档

http://doc.mapeditor.org/

参考的文章

http://blog.csdn.net/zhy_cheng/article/details/8308609

http://blog.csdn.net/zhy_cheng/article/details/8316277

http://blog.csdn.net/zhy_cheng/article/details/8363028

关东升  http://blog.csdn.net/tonny_guan/article/details/39324041
泰然网1 http://www.taikr.com/article/1924
泰然网2 http://www.tairan.com/archives/7122/
Github  https://github.com/chukong/cocos-docs/blob/master/tutorial/framework/native/how-to-make-a-tile-based-game-with-cocos2d/part1/zh.md

图片素材网址 http://www.2gei.com/rpg-marker/map/pn3/

 

示例:

一》打开TiledMap,新建地图:
块大小可结合图片资源来设置,地图大小结合块大小和像素大小来设置。

新建完成后如下,右边默认图层名字为块层1,可更改图层的名字:

图层定义:

用于分隔不同作用的地图元素以方便管理和实现层叠显示。举例跑酷的场景中可以将地面、背景建筑、碰撞物体等分层放置,对于背景只是用来增加画面效果不会用于判断碰撞等事件,墙壁等瓦片图如果不能充满整个图块就会造成颜色不协调(同一个图块位置无法放置两种不同的瓦片图),所以层的出现解决了这个棘手的问题,保证了背景可以存在上面又能用墙壁等瓦片图遮挡显示一部分图片。 图层主要放置不会改变的图片,如地面或墙壁等

二》导入图块资源:

三》图块层布局:… 阅读全文

cocos2d-js引擎的工作原理和文件的调用顺序

  categories:资料  author:

Cocos2d-js可以实现在网页上运行高性能的2D游戏,实现原理是通过HTML5的canvas标签,该引擎采用Javascript编写,并且有自己的一些语法,因为没有成熟的IDE,一般建立工程是通过WebStorm手动创建文件与文件夹,实现将引擎跑起来,下面详解一下运行过程。

首先,用户最先访问到的是index.html页面,在index.html中引入引擎的启动文件CCBoot.js和自己编写的游戏的启动文件main.js。除此之外,还需要在工程的根目录下写一个project.json,来描述工程,引擎会自动读入这个文件,确定工程的类型、功能设置、引入的模块、自己的js文件列表等。

一般是将cocos2d的引擎拷贝到自己的工程目录下,使用frameworks/cocos2d-html5这个目录下的引擎文件。

下面的流程图说明了cocos2d的基本工作流程:

下面我们以frameworks/cocos2d-html5/template为例分析一下这个工程。

工程的运行结果为在屏幕上显示Hello、屏幕分辨率、Logo等内容。

首先分析一下index.html这个文件。

[html] view plaincopyprint?
  1. <!DOCTYPE html>
  2. <html>
  3. <head>
  4.     <meta charset=“utf-8″>
  5.     <title>Cocos2d-html5 Hello World test</title>
  6.     <link rel=“icon”
阅读全文

数人云架构师:微服务体系中的K8S&Mesos调度与服务发现

  categories:资料  author:

9月10日在K8S GeekGathering Meetup上,数人云架构师保珠做了关于《K8S&mesos之我见》的主题分享,分别介绍了Kubernetes和Mesos对微服务的支撑,以下是本次分享的实录——

本次主要分享主要有以下五个方面:
– 容器的价值
– 微服务体系建设
– Kubernetes对微服务的支撑
– Mesos对微服务的支撑
– 总结

关于容器大家可能已经理解或者正在实践使用,所以今天会讲一下容器的价值方面内容,然后是目前比较火的微服务相关:将单体应用解构成微服务后它到底是一个怎样的概念,而后是Kubernetes和Mesos在微服务方面的支撑,最后是基于以上做一个总结。

容器的价值

Markdown

首先来思考一些问题:

  • Docker现在已经是容器界的事实标准,原因是什么?
  • Docker和VM各自都有什么优势?

2013年,Docker就已经在国内进行发展,2015年本人首次接触Docker是在客户现场进行生产应用部署,后来在和客户分享交流中,被问及的比较多的一点是Docker和VM究竟有什么区别,以及各自的价值是什么?Docker如此之火,难道就是因为轻量化、隔离性安全性以及秒级启动这些原因吗?这些特性VM也可以通过变通的方式做到,那么Docker的价值到底是什么?

请带着这些问题,继续往下看。

微服务体系建设

Markdown

试想下,目前比较火的微服务是不是和Docker或者说容器的经历很相似?为什么现在大家要用微服务,它都为我们带来了什么?单体应用时用的MVC架构,金融业会把应用切分成七层,接入层、服务层等等,微服务是否还要按照这种分层架构,用了它到底是简单了,还是复杂了,是不是用了Spring Cloud、Dubbo即是微服务了?

随着应用规模的膨胀导致运维规模线性增长,如何解决:有了微服务的概念后,应用可以按照业务模块做切分,做了微服务化切割够,一个小团队去管理开发一个服务,但随之而来的问题是,以前10个系统,5个运维就可以完成任务,使用微服务后可能会变成每个系统有几十个服务,部署的复杂度、团队之间的沟通协调、线上问题追踪,版本控制这些问题需要一些解决办法。

微服务的所有服务之间都是平等的关系,每个服务内部还可以遵循之前的分层架构。

当把系统做了模块化切分后,用Spring Cloud或者Dubbo框架去构建系统,虽然感觉上这就属于微服务的范畴,但随着对于这个体系的了解,其实会发现还远远不够。

〓 微服务体系建设

Markdown

为什么说微服务不是一个简单的框架而是一个体系,因为一个框架并不能解决微服务给我们带来的所有问题,如前面所提到的,其实还有很多,下面是在项目中遇到的一些体系方面建设的罗列,供以参考:

服务化框架:要解决的是服务之间调用的多通讯协议支持,数据交互的数据结构支持。

服务注册和发现:完成服务切分后,服务之间完成解耦,通过服务注册中心对服务统一管理,调用端去调用。

统一配置管理:不同环境如开发、生产、测试等环境的配置肯定不同,如果没有做出相应的改变,那么后续带来的修改以及升级问题是不可想象的。

API网关:服务被拉平后,身份验证、监控、负载均衡、缓存、请求分片与管理、静态相应处理。

监控报警阅读全文

StatefulSet: Kubernetes 中对有状态应用的运行和伸缩

  categories:资料  author:

在最新发布的 Kubernetes 1.5 我们将过去的 PetSet 功能升级到了 Beta 版本,并重新命名为StatefulSet。除了依照社区民意改了名字之外,这一 API 对象并没有太大变化,不过我们在向集合里部署 Pod 的过程中加入了“每索引最多一个”的语义。有了顺序部署、顺序终结、唯一网络名称以及持久稳定的存储,我们认为,对于大量的有状态容器化负载,我们已经具备了一定的支持能力。我们并不是宣称这一功能已经完全完成,但是我们相信他已经处于一个可用状态,并且我们会在推动其正式发布的过程中保持其兼容性。

StatefulSet 的采用时机

在 Kubernetes 中,Deployment 和 ReplicaSets 都是运行无状态应用的有效手段。但这两种方式对于有状态应用来说就不太合适了。StatefulSet 的目的就是给为数众多的有状态负载提供正确的控制器支持。然而需要注意的是,不一定所有的有存储应用都是适合移植到 Kubernetes 上的,在移植存储层和编排框架之前,需要回答以下几个问题。

应用是否可以使用远程存储?

目前,我们推荐用远程存储来使用 StatefulSets,就要对因为网络造成的存储性能损失有一个准备:即使是专门优化的实例,也无法同本地加载的 SSD 相提并论。你的云中的网络存储,能够满足 SLA 要求么?如果答案是肯定的,那么利用 StatefulSet 运行这些应用,就能够获得自动化的优势。如果应用所在的 Node 发生故障,包含应用的 Pod 会调度到其他 Node 上,在这之后会重新加载他的网络存储以及其中的数据。

这些应用是否有伸缩需求?

阅读全文

cocos creator入门

  categories:资料  author:

前面的话

  Cocos Creator 是一个完整的游戏开发解决方案,包括了 cocos2d-x 引擎的 JavaScript 实现,以及快速开发游戏所需要的各种图形界面工具。Cocos Creator 的编辑器完全为引擎定制打造,包含从设计、开发、预览、调试到发布的整个工作流所需的全功能,该编辑器提供面向设计和开发的两种工作流,提供简单顺畅的分工合作方式。Cocos Creator 目前支持发布游戏到 Web、Android 和 iOS,真正实现一次开发,全平台运行。Cocos Creator 是以内容创作为核心的游戏开发工具,在 Cocos2d-x 基础上实现了彻底脚本化、组件化和数据驱动等特点。本文将详细介绍cocos creator 入门知识

 

工作流程

cocos creator的流程如下所示

1

【创建或导入资源】

将图片、声音等资源拖拽到编辑器的资源管理器面板中,即可完成资源导入

此外,也可以在编辑器中直接创建场景、预制、动画、脚本、粒子等各类资源

【建造场景内容】

项目中有了一些基本资源后,就可以开始搭建场景了,场景是游戏内容最基本的组织方式,也是向玩家展示游戏的基本形态

通过场景编辑器将添加各类节点,负责展示游戏的美术音效资源,并作为后续交互功能的承载

【添加组件脚本,实现交互功能】

可以为场景中的节点挂载各种内置组件和自定义脚本组件,来实现游戏逻辑的运行和交互,包括从最基本的动画播放、按钮响应,到驱动整个游戏逻辑的主循环脚本和玩家角色的控制

几乎所有游戏逻辑功能都是通过挂载脚本到场景中的节点来实现的

【一键预览和发布】

搭建场景和开发功能的过程中,可以随时点击预览来查看当前场景的运行效果。使用手机扫描二维码,可以立即在手机上预览游戏

当开发告一段落时,通过构建发布面板可以一键发布游戏到包括桌面、手机、Web 等多个平台

 

安装和启动

阅读全文

Web架构之缓存应用——DNS与浏览器缓存

  categories:资料  author:

WEB浏览器缓存介绍

合理的利用WEB浏览器缓存WEB服务器上面的图片,css,js等静态文件。对于运维工程师来说这样,既提高了用户体验,又降低了网站的请求压力和带宽。浏览器缓存是对于用户和运维人员是一个双赢。

本文主要介绍浏览器DNS缓存和浏览器缓存协商,缓存刷新,缓存过期等知识。

浏览器DNS缓存

据统计,DNS解析时间一般是20-120毫秒,浏览器有两种方法可以缓存DNS解析结果,提高用户体验。

DNS预获取:指的是用户在请求某一个链接之前,浏览器先尝试解析该链接的域名,然后将其进行缓存。

下面是京东网的案例,在用户解析图片域名之前浏览器DNS会预解析这些DNS,然后缓存,这样用户在访问京东图片的时候就不需要DNS解析了。

image004

浏览器DNS缓存:浏览器在进行正常DNS解析的情况下,会把解析的IP地址缓存下来,大部分浏览器都有这种功能和DNS无关是浏览器自身的机制。

以谷歌浏览器为例:输入chrome://net-internals/#dns可以查看到谷歌浏览器的DNS缓存,当用户请求的域名在浏览器缓存列表的时候会从中取出IP地址,而不是找DNS服务器解析,这样可以提高DNS解析的效率,谷歌浏览器DNS解析默认过期时间是1分钟。

image006

浏览器缓存协商介绍

上面介绍了浏览器DNS缓存,那么浏览器能否缓存显示的内容呢?答案是可以的。我们知道,浏览器本质上就是一个http的代码,它帮助用户发送http请求给web服务器,然后web服务器响应请求(也就是返回数据给浏览器),然后浏览器进行本地的渲染和展示,那么浏览器能否把web服务器返回的图片,css,js等资源缓存呢?那么在下次访问这些资源的时候就可以直接读取缓存提高访问速度了。

Web服务器想缓存一些数据到浏览器上面,但是浏览器并不知道那些数据需要缓存,而且这些数据需要缓存多久,那么这个时候浏览器就需要和web服务器进行对话,我们就把浏览器和web服务器之间的对话称为缓存协商。

浏览器缓存协商Last-Modified

我们知道,我们的网页文件存放在硬盘上面有三个修改时间,分别是Access访问时间。Modify修改时间。Change状态改变时间,可以通过stat命令查看。

image008

那么默认情况下,我们的web服务器会通过stat系统调用,获取静态文件在硬盘上的最后修改时间,而且在响应http请求的时候,会自动在http响应头添加自动修改时间,浏览器获取到这个头部之后会把这个数据缓存下来,以后如果在请求这个静态文件,会询问web服务器请求的静态文件最后修改时间是否发生变化,如果没有发生变化,web服务器会返回304状态码,浏览器看到304就直到静态文件没有发生改变,就会从缓存中获取数据,这样就不会产生实际的数据传输。

首次请求:WEB服务器资源,WEB服务器返回状态码200,并且在响应头添加Last-Modified标签,标明文件的最后修改时间,这个时候WEB浏览器就会把这个静态文件缓存下来。

image010

再次请求:web服务器返回304状态码,表示文件没有发生改变,浏览器从缓存中返回数据。

image012

我们知道浏览器可以缓存数据,但是我们如何查看浏览器缓存的数据呢?以谷歌浏览器为例,查看浏览器缓存数据。

(1)在Chrome浏览器的地址栏输入Chrome:Version查看Chrome浏览器保存文件的位置。

(2)在Windows资源管理器,打开这个目录就可以看到一个Cache的目录,谷歌浏览器的缓存文件就是存放在这里。

image014

如何缓存动态内容?

如果是动态程序需要使用Last-Modified缓存,需要在程序中添加Last-Modified响应头,当用户请求动态文件文件的时候,返回这个头部,但是我们通常很少这样干。

浏览器缓存协商Etag

WEB服务器会给每个静态服务器打一个标签也有人称为指纹,总之就是一个唯一的标识符。浏览器第一次访问WEB服务器上面的静态文件,WEB服务器会把这个静态文件的标签发送给浏览器,浏览器下次再访问WEB服务器的时候就会带着这个标签,如果WEB服务器上面的静态文件没有被修改,那么WEB服务器和浏览器之间的标签就是一样的,这样浏览器就不会请求WEB服务器这个静态资源了。

image016

浏览器缓存协商expires

Mod_expires允许通过apache配置文件控制http的“Expires”和”cache-Control“头内容,这个模块控制服务器应答时的expires头内容和cache-Control头的max-age指令。有效期可以设置为相当源文件的最后修改时刻或者客户端的访问时刻。

这些HTTP头向客户端表明了内容的有效性和持久性。如果客户端本地有缓存,则内容就可以从缓存(除非已经过期),而不是从服务器读取,然后客户端会检查缓存中的副本,查看是否过期或者失效,已决定是否从新服务器获得内容更新。

image018

浏览器缓存协商Cache-Control

在使用expires这种基于时间的缓存协商,如果服务器和用户浏览器的时间不一致怎么办?http协议就在这个基础上增加了一个响应头cache-control,其中有一个属性max-age表示这个文件多长时间过期,这个时间是基于浏览器本地时间,而不是服务器时间,这样就解决了浏览器和WEB服务器时间不一致的情况。

image020

浏览器缓存刷新

(1)在地址栏中输入网址后按回车键或点击转到按钮

浏览器以最少的请求来获取网页的数据,浏览器会对所有没有过期的内容直接使用本地缓存,从而减少了对浏览器的请求。所以,Expires,max-age标记只对这种方式有效。

(2)按F5或浏览器刷新按钮

浏览器会在请求中附加必要的缓存协商,但不允许浏览器直接使用本地缓存,它能够让Modified、ETag发挥效果,但是对expires无效。

(3)按Ctrl+F5或按Ctrl并点击刷新按钮

这种方式就是强制刷新,总会发起一个全新的请求,不使用任何缓存

浏览器缓存过期

第一种方法:给js文件或css的请求带个参数,每次更新项目的时候也更新参数,这样就可以了。

第二种方法:修改文件名,每次请求的时候都是请求这个新的文件。

转载请注明:西门飞冰的博客-专注于Linux运维 … 阅读全文

九种浏览器端缓存机制知多少

  categories:资料  author:

浏览器缓存(Browser Caching)是浏览器端保存数据用于快速读取或避免重复资源请求的优化机制,有效的缓存使用可以避免重复的网络请求和浏览器快速地读取本地数据,整体上加速网页展示给用户。浏览器端缓存的机制种类较多,总体归纳为九种,这里详细分析下这九种缓存机制的原理和使用场景。打开浏览器的调试模式->resources左侧就有浏览器的8种缓存机制。

一、http缓存

http缓存是基于HTTP协议的浏览器文件级缓存机制。即针对文件的重复请求情况下,浏览器可以根据协议头判断从服务器端请求文件还是从本地读取文件,chrome控制台下的Frames即展示的是浏览器的http文件级缓存。以下是浏览器缓存的整个机制流程。主要是针对重复的http请求,在有缓存的情况下判断过程主要分3步:

  • 判断expires,如果未过期,直接读取http缓存文件,不发http请求,否则进入下一步
  • 判断是否含有etag,有则带上if-none-match发送请求,未修改返回304,修改返回200,否则进入下一步
  • 判断是否含有last-modified,有则带上if-modified-since发送请求,无效返回200,有效返回304,否则直接向服务器请求

如果通过etag和last-modified判断,即使返回304有至少有一次http请求,只不过返回的是304的返回内容,而不是文件内容。所以合理设计实现expires参数可以减少较多的浏览器请求。

二、websql

websql这种方式只有较新的chrome浏览器支持,并以一个独立规范形式出现,主要有以下特点

  • Web Sql 数据库API 实际上不是HTML5规范的组成部分;
  • 在HTML5之前就已经存在了,是单独的规范;
  • 它是将数据以数据库的形式存储在客户端,根据需求去读取;
  • 跟Storage的区别是: Storage和Cookie都是以键值对的形式存在的;
  • Web Sql 更方便于检索,允许sql语句查询;
  • 让浏览器实现小型数据库存储功能;
  • 这个数据库是集成在浏览器里面的,目前主流浏览器基本都已支持;

websql API主要包含三个核心方法:

  • openDatabase : 这个方法使用现有数据库或创建新数据库创建数据库对象。
  • transaction : 这个方法允许我们根据情况控制事务提交或回滚。
  • executeSql : 这个方法用于执行真实的SQL查询。

openDatabase方法可以打开已经存在的数据库,不存在则创建

	var db = openDatabase(
阅读全文

Zookeeper连接客户端总结

  categories:资料  author:

Zookeeper原生API

Apache Zookeeper原生API,的缺点:

  1. 由于设置和获取路径节点的数据都是字节序列,所以自己去处理序列化。
  2. 同时事件注册是一次性的,如果需要持续监听一个节点,必须在监听器捕捉一个事件后,重新注册。
  3. 无法创建父路径不存在的路径。
  4. 删除操作,只能删除节点下没有子节点的路径。
    客户端为 @see org.apache.zookeeper.ZooKeeper,观察者为 @see org.apache.zookeeper.Watcher

ZK的节点有5种操作权限: CREATE、READ、WRITE、DELETE、ADMIN 也就是 增、删、改、查、管理权限,这5种权限简写为crwda(即:每个单词的首字符缩写) 注:这5种权限中,delete是指对子节点的删除权限,其它4种权限指对自身节点的操作权限

身份的认证有4种方式:

  1. world:默认方式,相当于全世界都能访问
  2. auth:代表已经认证通过的用户(cli中可以通过addauth digest user:pwd 来添加当前上下文中的授权用户)
  3. digest:即用户名:密码这种方式认证,这也是业务系统中最常用的
  4. ip:使用Ip地址认证 一般使用digest方式。

设置访问控制: 方式一:(推荐)

  1. 增加一个认证用户
    addauth digest 用户名:密码明文
    eg. addauth digest user:password
    
  2. 设置权限 setAcl
阅读全文

Kubernetes(K8s)容器设计模式实践案例 – 分散收集模式

  categories:资料  author:

《Kubernetes与云原生应用》专栏是InfoQ向轻元科技首席架构师王昕约稿的系列文章。本专栏包含8篇内容,将会从介绍和分析Kubernetes系统以及云原生应用 入手,逐步推出基于Kubernetes的容器设计模式实践案例,希望对计划应用Kubernetes的朋友有所帮助。本文是该专栏的第七篇。

  1. Kubernetes系统架构与设计理念
  2. 云原生应用的设计理念与挑战
  3. Kubernetes与云原生应用的容器设计模式
  4. Kubernetes容器设计模式实践案例-单节点多容器模式
  5. Kubernetes容器设计模式实践案例-多节点选举模式
  6. Kubernetes容器设计模式实践案例-工作队列模式
  7. Kubernetes容器设计模式实践案例-分散收集模式
  8. 云原生应用的容器设计模式综述与展望

Kubernetes与容器设计模式

目前Kubernetes社区推出的容器设计模式主要分为三大类:

第一类,单容器管理模式;

第二类,单节点多容器模式;

第三类,多节点多容器模式;

一类比一类更复杂。根据复杂性的不同,本系列文章给出不同篇幅的实践案例介绍。云计算跟分布式系统是一个事物的两种解读:云计算是面子,分布式系统是里子。云计算给用户刻画出的是方便的、弹性的、自动化的随时随地可以得到的信息处理服务;而后台,需要云平台背后的研发和运维工程师创建维护好一个复杂的分布式系统。

本系列文章所推出的容器设计模式,旨在将分布式系统,特别是将分布式应用模式化,简化分布式系统的创建和维护。本文将介绍容器设计模式的最后一种,分散收集模式。这是最复杂的一种,但也是最具通用意义的一种模式。分散收集模式先将服务扇出到多个微服务实例上做独立处理,再将所有处理结果扇入到一个逻辑根微服实例上作合并,以此来完成对一个复杂问题的处理;这和数学和计算机算法中的分治法非常相似。这一模式对利用k8s平台运行分布式系统有普遍应用价值。

分散收集模式

分散收集模式利用分布式系统弹性计算能力的容器设计模式。在这一模式中,计算服务的使用者,即服务的客户端,将初始计算请求发送给一个“根计算节点”。根计算节点对计算任务做出分割,将任务分割成大量的小计算任务,然后将小计算任务分配给大量计算服务器进行分布式平行计算 。每个计算服务器都计算初始计算任务的一小块,将计算结果返回给根计算节点。根计算节点将所有计算结果合并起来,组成一个针对初始计算任务的一个统一的结果,返回给申请计算任务的客户端。

这一系统中的分布式服务器非常适合用容器技术来实现,具体到K8s系统中,就是一个K8s的Pod;具体到Docker系统中,就是一个Docker容器。利用容器快速部署启动和运行时开销特别小的特点,任务可以被分到很多小服务器上并行处理,这些容器形成的小服务器跟其他任务共同使用基础设施计算节点的能力。

一个典型的分散收集模式的分布式系统如图Fig01所示。根节点接受到来自客户端的服务请求,将服务请求分配给不同的业务模块分散处理,处理结果收集到根节点,经过一定的汇聚合并运算,产生一个合并的结果交付给客户端。

 

Fig01 分散收集模式示意图

 

本文中案例的代码 本文中使用的代码在Github仓库:https://github.com/xwangqingyuan/metaparticle 本文中使用的代码主要以metapaticle项目为基础:https://github.com/brendandburns/metaparticle 本文作者在此基础上增加了用于演示scatter gather容器模式的案例,在https://github.com/xwangqingyuan/metaparticle/tree/master/examples目录下。

分布式计算模式项目Metapaticle

Metapaticle项目的目的在开发并展示一种基础设施即代码的编程模式,力图将基础设施管理逻辑和功能运算逻辑以同一种语言实现在同一短小精干的程序中。

在分布式计算系统中,不仅功能性计算的逻辑是重要的,对计算系统的逻辑拓扑结构的控制也是重要的。大家可以想象,依靠流行大数据分析框架Hadoop MapReduce,Spark,Storm和Flink等进行分布式大数据运算,代码中往往包含逻辑拓扑结构的逻辑。

在以往的分布式计算特别是云计算体系中,大多将基础设施管理的逻辑由配置文件和自动化运维工具来配置,而功能运算逻辑由通用的编程语言来控制。这一模式也比较符合过去基础设施管理逻辑和功能运算逻辑的特点

在过去,基础设施相对固定,变化较小,因此用来管理它的配置文件和自动化运维工具不需要支持太强大的动态逻辑功能;另一方面,过去大多数编程语言的抽象度和表达能力较底层,以命令式的编程范式为主;因此,功能运算逻辑和基础设施管理逻辑相距较远。即便如此,当开发人员开始运维自己的软件系统时,不可避免地将同时用两种语言分别管理基础设施和功能运算逻辑,往往给开发人员带来不舒服的感觉。

随着云计算特别是容器技术的流行,计算机系统的基础设施越来越动态,人们对基础设施管理控制的逻辑控能力要求越来越大。同时,随着计算机语言的发展,函数式编程,声明式语言越来越收到开发人员的熟悉;人们越来越倾向于使用高抽象度的、高表达力的函数式编程模式甚至声明式语言来快速地实现功能逻辑,使得很多应用功能逻辑的代码看上去越来越简单得像“配置文件”。这样,对基础设施管理逻辑控制能力的需求和对功能运算逻辑控制能力的需求似乎越来越接近了。

在这种背景下,metaparticle项目被设计用来探索将基础设施管理逻辑和功能运算逻辑以同一种编程语言来实现的模式。正像我们提到的,随着云计算和容器的发展,基础设施管理逻辑和功能运算逻辑越来越融合成一个整体的分布式计算任务。Metaparticle谋求的正是用同一种语言搞定一个整体的计算任务。

目前metaparticle主要支持javascript语言,主要是利用它的简单性和它对函数式编程的支持。当然,按照metaparticle的设计思想,未来Python,Scala,Swift这些较高级的语言都可是用来实现metaparticle的模式。Metaparticle的设计思想在于用同一种语言完成同一个分布式计算任务,但是并不会谋求限制到某一种特定语言。

Metaparticle项目还很初级,主要对我们的帮助还是试验和启发作用。Metaparticle支持3种分布式系统的服务模式:分散收集模式(Scatter/Gather)、分片模式(Shard)和水平扩展模式(Spread)。其中分散收集模式是更具通用性的一种模式,正好也是本系列文章中准备介绍的最后一种容器设计模式,也是最复杂的一种设计模式。本文中针对分散收集模式的演示案例,以metaparticle为基础,先要通过nodejs的包管理工具安装metaparticle模块,然后通过node来试验本文中的案例。

安装Metaparticle

阅读全文



快乐成长 每天进步一点点      京ICP备18032580号-1