系统结构的选择

最近在帮公司整理系统结构,原来的系统采用thrift消息打通各个节点“奇经八脉”,但是这种网状的系统结构维护起来非常复杂,虽然thrift是个好东西,但是梳理好系统的交互和关系比用什么工具更加重要。

首先,这里说的系统结构指的是系统的模块以及功能的划分,各个模块存在的形态(独立的节点还是类库)。有一点我们应该时刻提醒自己——不要设法用一种系统结构去解决所有问题,这会让自己陷入无止尽的循环中。那么系统结构到底有哪些呢?我目前接触到的有——C/S结构,心型结构,树状结构,网状结构,用得最多的当属C/S结构。

C/S结构的系统是非常简单直接的,做过网络编程的程序员能够很容易的搭建起来。其特点通俗一点来说就是:客户端所有信息都从服务器拿,所有信息都向服务器上报,另外客户端还会接收服务的通知。举个具体的例子,我想用一个web来管理流媒体服务器,另外还有多个客户端APP可以访问这个流媒体服务器上媒体流。这里使用C/S结构是最好不过的了,web服务作为后台管理,可以对流媒体服务器进行管理和操作,可以为客户端提供登录,媒体信息推送,以及客户端之间的消息交互等。客户端则根据web服务提供的信息向流媒体服务器取流。这里我们并没有让客户端直接向流媒体服务器获取流的信息,而是通过web服务下发,好处是第一,让管理配置工作有专门的模块处理,让流媒体服务器做好自己流分发的事情;第二,web服务做后台管理有着天生的优势(数据库访问接口,MVC框架,工程管理……);第三,以后加入其他服务模块可以参考流媒体服务器的做法,接口可以重用。这种结构非常适合中小型系统,作为初期系统原型,而开发和维护只需要JAVA程序员1枚,C/C++程序员1枚,客户端开发另计。

心型结构,是以某一个节点或者一个集群(对外表现为一个节点)为中心,其他节点通过该中心节点与其他节点进行交互,而中心节点仅仅作为一个中转,本身并不保存这些消息。这种结构与C/S结构很像,消息都是通过某一节点,不同在于心型结构是要在自身隐形,就像我们打电话一样,我们并不知道我们的电话线路经过了多个节点,只要知道对方的电话号码就能够与对方通信。使用这种结构的系统,一般都具有多个相同或者不同功能的节点,各个节点之间彼此需要频繁的通讯,所以通过一个中心节点进行路由是一个方便的选择。在我做过的系统中,核心网产品曾经使用过这种结构。核心网的网关使用的是一种ATCA的硬件架构,我们的产品中有主控板和业务板(接口板)组成,这是个非常复杂的产品,心型的消息框架为应用提供了板卡之间通讯的能力。

树状结构,其实是一种跨系统的解决方案,比如:一个用户从一个系统漫游到另一个系统,一种方式就是在这两个系统之上再构建一个节点,用户同步这个用户的数据。

网状结构,我工作这么久没有使用过,见过其他人用过,但个人觉得用的并不好。

后两种系统结构,我还需要时间去多了解一下,现在不能做过多评述。

 

对redis用法的思考

redis是基于key-value的消息框架也可以作为缓存,数据库来使用。在最近的几个项目中,我都想把redis加进去,作为消息框架使用,但是每次都因为种种原因最后放弃了。在这里简单做个备忘吧。

A项目是一个tomcat+C的架构,前端使用了strut2。现有架构中使用了thrift作为消息框架,每个模块自己定义消息来进行交互。如果引入redis的话,除了可以使用现成的消息框架(包括消息订阅与发布功能,这在thrift中得自己定义)以外,更重要的是各个模块的消息交互可以保持一种统一规则,而且还可以可借助redis的tools方便调试。但是在现有框架下引入redis显得有点冗余,因为前端已经使用了strut2这种重量级的WEB框架,不可避免的,我们需要添加一些业务对象来做redis接口的适配,而这个适配层其实自己就可以作为缓存而存在。

B项目中,我想引入redis保存server的client实例,这样UI显示部分可以直接从redis获取实时信息。但最后,我认为还是server自己管理上下文简单些,一是写个list加个lock很省事;二是,把list上报给UI也用不了几行代码。因此没有必要,再多引入一个节点。那么如果要用redis的话,应该怎么用才合适呢?

首先,我认为UI部分应该承担比以前更多的工作,为了避免引入适配层,在web后台应该使用通用的方法来处理redis的请求与返回,比如使用json格式来传递消息,甚至在UI部分可以直接使用redis的语义,这用后台可以直接透穿给redis。这种方法可以极大的减少web后台原来的工作(想想strut2中,写的那些个action)。而C程序中,也应该直接面对redis来编码,虽然自身的context还得不能避免,但是至少统一了与上层的消息接口。

这里只是想把redis作为消息框架使用,其缓存功能,我暂时还用不到。

零配置

关于零配置,最早我是在2010年做WLAN的时候了解到的。当时运营商的规范里面要求瘦AP架构下,AP要能够零配置启动。一个概念我当时第一感觉就是——简单,易维护。后续的VIS 2.0设计里面也沿用了这种集中式配置+客户端零配置的做法。最近在做RS重构,对这种架构有了更深一层的认识。

RS里,配置管理是一个非常重要的部分,另一块,就是media gateway。这里主要考虑media gateway的配置如何实现,由于media gateway很多库都是c/c++实现的,而且对效率比较敏感,所以用c/c++是顺理成章的事情。它的配置,其实非常简单,用1,2个table就可以满足需要,那么到底放在自己这块用c/c++实现呢,还是放到统一的配置管理服务上实现呢?

假如media gateway是一个单独的小产品,我们当然希望越简单越好,让media gateway自己保存配置。但是当它作为整个RS系统的一部分的时候,我们不得不从整体来考虑,这时候将配置管理部分抽离出来让一个平台来解决这些公共的功能才是最合理的做法。另一方面,让平台来做还可以借助第三方工具,一来提高了效率,二来而不用担心media gateway的代码过于臃肿。举个例子,系统平滑升级,我们需要考虑数据结构发生变化的时候,如何将现有数据迁移到新的结构中。这其实在JAVA中,比如hibernate,已经有很多工具/方法可以解决这种问题,我们甚至都不需要自己写SQL语句。但是在C/C++中实现这种功能,就会有点繁琐,甚至会影响性能和稳定性。

最后总结下一下,单独的小产品,自己管理配置最好不过。对于大系统而言,由平台统一管理才是王道。

智能硬件云平台

因为想把家的NAS接到互联网上去,这样在任何地方都可以访问到家里的文档。之前使用过VPN的方式来解决,自己在NAS装了客户端,在阿里云上装了PPTP,对于我这种技术宅来说够用了,但是对一般人来说还是略显繁琐,于是就有了想提供这种云平台服务的想法,未曾想已经有很多人想到了。类似的平台有:

萤石云,为家庭和小微企业用户提供可视化安全为基础的关爱、沟通、分享服务。
可接入摄像机,录像机,路由器,报警器,视频盒,云储存服务收费。这是国内安防NO1海康威视的提供云服务,主要配合他已有的产品,打造一个家庭安全的概念,主要靠自己的民用级产品盈利,云存储不知道有多少人会用,因为本地可以存储,除了一些微型企业如便利店,大部分人应该不会花每个月十几块钱把视频备份到云服务器上去。

Qsync Central Station,是QNAP的产品,有了Qsync,NAS就变成了超大空间的安全档案同步中心!可以从手机及平板装置将拍好的照片上传到NAS,即可在其他已连结至NAS的桌机、笔电或是移动设备观赏。 对于时常需要移动作业的人士,通过Qsync来管理文件,可以随时从各个装置取得最新的档案。首先买个NAS就好几千块了,提供个同步功能算是跟上时代步伐吧。

智能硬件相关的有xlink,yeelink,乐维,IoTgo,一套完整的智能硬件开发需要以下几个方面:设备硬件、设备软件、云端服务器和手机APP,使用mqtt或者coap协议。这些云平台可以缩短智能硬件作坊的开发周期,让他们专注的做硬件部分的事情,通过简单的步骤就可以把硬件与互联网连接,而APP,云服务器都由平台免费提供,其中IoTgo是真正开源的平台,代码可以在github找到,用户可自己搭建一个云服务器。这些智能硬件平台,基本上靠定制化或者推自己的demo产品赚钱,规模不大比较适合发烧友。

微信也提供智能硬件接入服务,真是鹅厂真是不给小企业一点活路啊。

综合来看萤石云的模式是最值得创业者借鉴的,因为够专注,而智能硬件相关平台的问题主要是做得大而全的话,做不过BAT;做得小而精的话,用户没有培养起来, 养不活团队,所以这个市场还得等机会。想靠互联网赚点钱真不容易,只能想想办法把互联网的东西企业化,赚点系统集成的钱。

备份一下几个link:

  • http://www.xlink.cn/index.html
  • http://www.yeelink.net/
  • http://www.lewei50.com/
  • https://github.com/itead/IoTgo

 

 

HTML5的几个关键技术

传统的WEB技术,基于request-response,因为用户的主要行为是在不同的网页之间跳转。随着网页应用越来越广泛,用户越来越接受这种简单,不需要任何安装步骤就可以享受到的服务,由此也给WEB技术带来了新的需求和挑战——交互式体验。

最早的WEB开发采用轮询的方式来实现服务器向客户端消息的推送,但是这种方式效率太低,用户体验也不好。HTML5的几项关键技术如:websocket,Sever-Sent Events则很好的解决了交互的问题,而canvas和SVG则很好的解决了图形展现的问题。

那么现在问题来了,什么应用是单页面应用,而且非常适合使用WEB去替换传统的桌面应用的呢?本来我一开始就想到聊天类的应用,但是我估计80%的这类应用会推荐你下载他们的桌面版本。qnap的客户端是纯HTML的设计,不提供PC客户端,但是提供了移动客户端。我猜测这是想通过WEB解决为不同PC操作系统开发的麻烦,而在移动客户端上WEB与原生的APP相比并没有那么多的灵活性。对于创业初期的开发者来说,business是第一位的,此时使用WEB这种简单易用的技术来节省大笔研发费用也是不错的选择。

此外,对于WEB开发单页面应用来说,还有一个非常不幸的实事,那就是用户会习惯性的把网页关闭。比如,我用chrome浏览完网页时,会关闭整个窗口,而不会一个个的TAB关闭,这时很难注意到是不是有个TAB还在处理些什么事情。

关于全栈工程师(full stack developer)

原文:http://www.kuqin.com/shuoit/20140704/341000.html

这差不多是我看过的吐槽全栈工程师最犀利的文章了,其实自己默默做“full stack”已经好多年了,这些年中午吃饭差不多是最晚的一个,而且也没有睡午觉的习惯,都在想着工作上的事情,有时候甚至回到家也情不自禁的查查资料,同事常说老板请我是最值的了,一个人干10个人的活。开始我也不怎么觉得,总觉得是自己的兴趣爱好,时间长了,我发现我也时常抱怨xxx没有人做,人手不够什么的,最后都自己上了。这么打工法,其实最合适给自己打工,怎么做都是为了自己的事业嘛。什么时候才能给自己正名呢,难道非得创业不可?

几个WEB前端框架

WEB 前端框架大多基于JS,最近草草看了一些文章,主要是想选择一个WEB前端技术/框架,可以满足长期需求。PS:框架也好工具也好,我这里不想咬文嚼字了。其实每个框架都是自己的长处和短处,关键还得结合自身的情况。对于上面几种框架我就总结一下适合的场景吧。

  1. ExtJS,比较适合需要完整的前端技术解决方案的情况,因为他提供了包括表格,表单,菜单等丰富的UI元素,MVC框架。
  2. AngularJS,MVC框架,但是UI依靠bootstrap等第三方组件,比较适合CRUD,SAP(单页面应用)的应用,比如后台管理。
  3. ReactJS,将UI组件化,可以看成是UI的小工具,与backbone配合使用,简单快捷。

现在只接触了一段时间AngularJS,对其他框架还没有什么体会,但我相信技术是相通,也没有一种框架可以通吃所有。所以果断先用AngularJS在后台管理上试试水吧。