【技术干货】我们的项目是如何技术选型的

  1. 云栖社区>
  2. 博客>
  3. 正文

【技术干货】我们的项目是如何技术选型的

驻云科技 2016-04-25 16:00:07 浏览6397
展开阅读全文

0d0ac873fe39e8bb3e369b5999fc5ba35bdafe83

本文作者:上海驻云开发总监   陈昂


以下正文:



公司逐渐壮大,团队日趋稳定。作为一名陪着公司一块成长的一分子,我深感欣慰。蓦然回首,发现我们竟然有了诸多产出与成果。有平台,有工具,有产品,有项目。有些项目进行中,有些产品已夭折。但不管怎样,看着这么多已有成果,还是小小的骄傲了一下。然而骄傲之余,精心沉思,我们积累的太少,沉淀的不够。以前,我们就像是在打仗,为了生存,你死我活,兵贵神速,分秒必争。现在,我们多少可以喘一口气的时候,有必要回顾下,总结下,沉淀下了。


那么,今天就先回顾下我们之前这些项目的技术选型过程吧。


时间回到2013年,当时刚刚换了一份糊口的工作。一家广告公司,美女如云,帅哥成堆,有充足的时间和资源让你定位自己的性取向。然而胖子的一通电话让我没有时间再去思考性取向的问题了。他电话中对云计算一阵云里雾里的吹嘘,让我的小心脏顿时扑通扑通的久久不能平静啊。立马决定加入他的新公司,拥抱云计算,迎接新挑战。


一个月后,到了新公司,哦不,应该说到了兄弟公司,借位办公(新公司还没完全成立,办公地点也还没选好,这些都不重要了,重要的是新产品已经开始规划了)。挖了两个前同事立马开干,做一个可视化云设计平台,主要面向阿里云(国内云计算老大嘛,抱大腿嘛,当然要抱老大的大腿喽)。通俗的讲呢,通过这个产品,用户可以方便直观的设计出云资源架构。


产品有几个基本需求:


1.免安装

2.兼容iPad

3.拖拽操作

4.呈现的架构够直观

5.能够同步基础云资源(阿里云)


基本需求不多,但各个切中云计算痛点。发挥的余地还是比较大的。对于第一点,免安装,那么基本只考虑WEB方式了。

既然是WEB应用,就要先考虑五花八门的浏览器的兼容性。由于这个产品的客户比较面向技术,IE也就暂时不考虑兼容(不解释)。最后选了两款浏览器作为主要兼容目标:Chrome、Safari。

选好浏览器就是开发语言的选型了。JS肯定是必须的,另外,那么后端语言,零零总总一堆:PHP、NodeJS、Python、JAVA、ROR... 


• PHP是WEB霸主,有很多成熟的WEB框架

• NodeJS是新贵,本身就是JS语言,前后端基本不存在兼容问题

• Python语法够优雅

• JAVA够厚重稳定,但是开发慢

• ROR够快,但是比较适合MES系统

• ...


我们这个产品有什么特点呢:


• 面向云计算的设计和同步平台

• 前端有大量复杂的逻辑和计算

• 后端不需要太负责的逻辑支持

• 能够快速开发和产出,因为当时如果不及时产出,公司可能就死掉了(QAQ)


既然这样,我们直接先排除了JAVA、Python、ROR。后来在PHP和NodeJS之间犹豫了好久。最后考虑到PHP恶心的语法,考虑到NodeJS完美支持JSON,最后考虑到我们需要实时同步而NodeJS领域有个Socket.io可以完美支持,就选择NodeJS了(其实那些都是为了说服自己的理由,PHP毕竟还是很成熟的)。


接下来的事情就是选几个已经有很多轮子的框架或工具,帮我们造车。


• 由于前端需要Canvas,最后找了一个很不错的Canvas框架KineticJS(其实我们是先看到了KineticJS,再定了Canvas),KineticJS封装了丰富的Canvas组件,让我们可以以组件的方式操作画布,方便开发。

• 模板层我们选了轻量的Handlebars。

• 后端NodeJS层面选用Express

• MongoDB层面选用Moogoose来操作数据

• 由于前后都是JS,为了提高开发效率,强制大家都用Coffeescript(js的转义语言)来编写代码(几乎所有项目沿袭至今)

• CSS用Less,就像Coffeescript一样

• 项目构建采用Grunt


其实这些技术选型还是很盲目的,然而技术永远不可能有最好的,只有最适合的。虽然是盲目的选型,但是选型和推广的过程的确是痛苦的,不管团队是人多还是人少。世界上最难得的事情莫过于说服别人改变自己的习惯。比如推广coffeescript,有一个开发很排斥,一开始死活不愿用coffee写js,感觉这样不够正宗,他的一句话还让我快吐血了,是男人就不该戴套。不过私下里他还是尝试了coffee,也很发现了coffee带来的快感。


后来的事实也证明我们的技术选型带来了很大的优势。三个人,两个月就出了第一版,并参加了阿里云开发者大会,收获也不同凡响。后来又经过几个月雕琢,出了好几个版本。奈何当时阿里云API尚缺稳定,也不够丰富(当然我们也是对API深度使用了),我们只发布了一个设计版。


这里有必要发一下我们这个产品的简单部署架构。


8bb525c1a8df655b5edbdb40520437b7f1225b59


架构很简单,同时,这个架构也是我用我们这个产品画出来的。其实这个产品还是有很多bug的,以及体验上的缺陷。


然而,这些都不重要了。我们度过了生存期,而且还带来了个意外的项目,为阿里云做一个VPC的可视化平台(这个平台现在你已经看不到了,放个图吧)

 

2340764afde11915c55df237d0cd295cb22c6d2b

 

有时候事情的发展就是这样,做好了自己的本职工作,幸运就会降临,就像国足这次进入12强,赢得了牵动亚洲的计算题一样。

 

这个项目的技术选型和上面那个产品差不多,就不赘述了。需要提一下的是这个项目在部署阶段遇到拦路虎了。因为是阿里云的项目,部署环境理应是用阿里云资源,一开始的架构是这样的:

 

f850324f2b87631addcf8cfa98a1a345319c8a99

 

前面还是负载均衡,挂载两台机器,缓存服务采用阿里云的OCS,数据库我们尝试用OTS。


在部署的过程中,发现SLB无法透传Websockets,也就无法支持Socket.io工作,而Socket.io在这个项目中起了很大的作用。我们尝试着SLB从HTTP换成TCP模式(毕竟SLB对TCP模式是直接转发的IP),但也不行,当时没搞清楚是阿里云产品的问题还是我们配置问题(当然现在的阿里云SLB已经很完美了)。后来经过多次尝试,终于曲线救国,socket.io 改用polling的方式,不用websockets。另外为了充分发挥多核的性能,NodeJS也开启多个进程。但是为了满足Socket.io,要保证Session在同一进程,Nodejs每个进程就开启了不同的端口,前面通过Nginx 配置 IP Hash并反向代理到不同的NodeJS端口。如下图所示


3ef9593e424e65a1e1c9aabbef018b660863bb36


再后来,发现OCS的Node SDK不稳定,就启用了OCS,直接换成了ECS搭建Memcached。

 

2340764afde11915c55df237d0cd295cb22c6d2b

 

经过几个月的奋战,这个项目成功上线,来不及喘息,新项目又来了。

 

这次要做一个云管理平台,典型的MES系统。项目开始,技术选型这块就出现了矛盾。基本明确的是基础语言不变,后端还是NodeJS,数据库换成RDS。


但是前端的框架起了争执。之前的那些框架或工具明显不适用了,得选一个能够快速开发并且方便维护管理的前端框架做支撑,这时候AngularJS和EmberJS进入了我们的选择。一个是Google出品,上手快,但深入难。一个是社区项目,更面向生产,但不够轻盈。我坚持选择EmberJS,因为更加面向生产,也更加面向团队协作,不像AngularJS引入了很多新概念,学习成本更低。一个同事坚持Angular,他之前就用过,而且Angular更火一点。最后我做了妥协,毕竟不管哪个,对我来说都是新的。而如果团队里有一个有经验的人在,会更加可靠一点。


后来的情况是这样的,Angular配合着NodeJS带来了极速开发,项目一个多月就上线了(你没看错,是一个多月)。这个框架在公司也就火起来了(虽然开发还是不多)。这期间,我个人也对Angular上手了,感觉框架本身的理念还是很超前的,开发非常快,特别适合MES系统,如果你的系统是管理系统,BOSS系统,或是信息系统,用它,绝对没错。


公司这时候也逐渐壮大了起来,产品和项目也多了起来。一个产品或项目再也不是只有一个两个人奋战的情况了。团队成员之间的协作也变得日趋重要和紧密,程序需要解耦,团队协作同样也需要“解耦”。敏捷开发时代,前端程序是不可能等后端API都调试好了再进行开发的。这个时候就有人提出了“前后分离”这个词。这个词当下很火,阿里也在做这样的事情,只不过业务不同罢了。几个人坐下来一合计,感觉这事靠谱,做吧。接口规范定义清除,数据格式定义清除。后端无需关心前端的业务逻辑,只要保证好什么样的接口应该具有什么样的权限,应该如何传参,返回什么样的数据就行。校验不通过,按照既定的数据格式返回给前端。前端业务只需要根据后端的API返回数据做进一步的逻辑处理就行。前后端同步进行,没有完成的接口,前端通过Mockup调试,完成了就联调。直到现在,我们的前端妹子,还在说,“前后分离”大法好啊。

 

• 永远没有一招鲜的技术

 

永远没有一招鲜吃遍天的技术,也没有一招鲜的选型。因为业务的需求,我们接了一个外包。对方公司要求做一个CMS系统 + 开发者平台。如果不考虑其他因素,CMS系统我们可能就直接上Drupal啦,开发者平台就通过Angular +NodeJS实现。可是对方还有一个需求就是开发完成3个月内能够接手代码,而对方公司技术人员大多数是JAVA背景。为了能够让对方快速接手,我们做了如下的技术选型。


78833c18eebfdb914b18dbe926550c5ce13a9afa


在这个模型中JAVA层只负责和客户的TOP数据接口打交道,然后通过提供RESTful风格接口为前端系统提供接口服务。其中CMS和开发者平台都是基于Angular打造。由于网站直接面向公众,更多也是静态页面,需要有更好的加载性能和SEO友好,所以通过NodeJS进行渲染,而NodeJS又和JAVA进行数据交换。


开发的过程,其实并不是太顺利。一方面因为对于CMS系统(业务复杂性很高)的不了解,我们等于说是从0打造,没用太多的轮子可用。另一方面,项目存在三方协作的问题,协调效率并不是太高。但不管怎样,项目还是顺利完成了。

 

• 新的挑战


随着业务的发展,公司想要对最早的架构云重新打造,让其上升到一个更高的高度。如果要用数字1表示一个产品是完整的,那么之前的架构云只能说是0.8。毕竟是公司初期的产品,也有很多产品外的压力因素导致我们没有做到1。不过公司今非昔比了,有充分的时间让我们静静思考下产品,我们有了更高的目标和要求,那就是把产品从0.8做到1,再做到5。基于这个目标,经过团队人员的讨论和商量,老产品维护成本太高,基础选型也不够成熟,我们打算对其进行重构。重构的第一关就是技术选型啦。结合之前的经验,我们认为,轻量级的框架会给我们带来更高的掌控性和稳定性。后端选了NodeJS,数据库采用Mysql。更多的工作是在前端。经过Demo尝试,SVG性能更好,开发起来也更加舒服。基于SVG选了Snap.svg(比较轻量的SVG工具)。在渲染层面,选了鼎鼎大名的ReactJS。ReactJS的VirtualDOM对于画布的渲染有着非常高的性能和可维护性,也能方便的做到组件化和模块化,进一步降低开发成本。以下就是我们新的架构云技术选型


e17ffaf6dfacc5447e25186e3ba2d807d9a296eb

新的架构云已经如火如荼的进行中了,几个月后,大家将会看到漂亮的第一版。敬请期待~~~

好啦~本文到这里就结束了,同时,如果喜欢我们的话就赶紧订阅我们吧~~~每天定时推送新鲜干货~~~也可以关注我们的微信公众号:架构云专家频道 每天同步更新哟~~~


网友评论

登录后评论
0/500
评论
驻云科技
+ 关注